New Cargo Transportation Scheme [CTS] – Discussion ...

[George]

I thought about it again...
I think we have a error in concept. I mean we are trying to achieve future compatibility, but we are forgetting about most important thing. If the cargo is unknown, the only correct solution to display it is to HIDE it.
So, I think vehicles GRFs should support cargoes the way like this:
1) if the cargo is known and fits the refit with current classes - we add it after 32-th position in the table.
2) if the cargo is known and does not fit the refit with current classes - we put it in first 32 positions. Yes 32 is a limit, but how near are we? I need in fact 2 positions there, onodera needs about 5 for all the existing sets (correct me if I'm wrong). Not much.
3) if the cargo is unknown - we use cargo class to hide it
3a) if it is a tank only class - store it in tanks
3b) if it has armoured class - store it in armoured vans
3c) if it is a mail only class - store it in mail van
3d) if it has passenger class - store it in passenger wagons
3e) if it has refrigerated class - store it in refrigerator
4) in all the other cases store it in box vans
It is not absolutely correct solution according to cargo transportation in RL, but it shows the cargo with the right graphics and hides the cargo without graphics, providing the most appropriate wagon to hide the cargo.

IMHO, that is the best way to provide future compatibility support. And it is much better than to discuss, should coal hopper or grain hopper transport salt. It does not matter! Salt is not black nor yellow, transporting it in coal hopper or in grain hopper is wrong. The best way is to transport salt in box van unless you provide full support for salt both for label support and graphics.

[Draakon]

IMO ECS is good as it is currently. I don't see no problems with it. So a little friendly suggestion: Don't like it, don't use it.

[wallyweb]

IMO ECS is good as it is currently. I don't see no problems with it. So a little friendly suggestion: Don't like it, don't use it.

Are you confusing the ECS system with George's ECS Industries which use the ECS system? They are not the same thing. The concern is not with George's ECS Industries. It is with the ECS system. The ECS system assumes specific cargo/wagon configurations which makes it very difficult for set designers who may require alternate configurations. Different railroads do not always handle the same cargoes in the same manner. CTS should give the transport set designer the flexibility to assign wagon types for the cargoes specified by an industry set designer such that those wagon types fit in with the theme of the transport set, which is not necessarily the theme specified by the ECS system.

[Draakon]

....

Does it matter? Because this thing started in ECS Vectors thread by this thread creator stating that he didn't like the current ECS implementation (maybe the scheme too). Instead implementing in a different way, he proposed another Cargo Scheme (If he didn't like the scheme). SO, does it matter?

Also, currently i see that the whole thing about here is the cargo classes and labels. George may not want to change or has time to do that what this thread author said will be better about cargo classes and labels so he started this thread because of this IMO.

Also, no offense meant, this is just my view trough my eyes.

[onodera]

....

Does it matter? Because this thing started in ECS Vectors thread by this thread creator stating that he didn't like the current ECS implementation (maybe the scheme too). Instead implementing in a different way, he proposed another Cargo Scheme (If he didn't like the scheme). SO, does it matter?

Also, currently i see that the whole thing about here is the cargo classes and labels. George may not want to change or has time to do that what this thread author said will be better about cargo classes and labels so he started this thread because of this IMO.

Also, no offense meant, this is just my view trough my eyes.

When OzTransLtd said he didn't like the ECS implementation, he actually meant classes and labels given to the ECS cargoes. He wasn't talking about the cargoes and industries themselves. This thread is not about using ECS vectors in your game, it is about providing support for new cargoes in vehicle sets, a technical issue.
(I'd rather we stopped using "ECS" to refer to the curent cargo classes. It seems to confuse people.)

[wallyweb]

SO, does it matter?

It matters if you are a coder whose set becomes extremely complicated due to the limitations of the ECS system.

Also, currently i see that the whole thing about here is the cargo classes and labels. George may not want to change or has time to do that what this thread author said will be better about cargo classes and labels so he started this thread because of this IMO.

As I understand it, CTS would still use labels so George would not have to change anything.

Also, no offense meant, this is just my view trough my eyes.

No offense taken. Your thoughts are important and these forums are the place to discuss them.

[Draakon]

....

From http://www.tt-forums.net/viewtopic.php?p=656656#p656656

As Pikka wrote
Quote:
You are free to modify my GRFs for your own taste.
If you do not like new graphics - provide a better one

[George]

Also, currently i see that the whole thing about here is the cargo classes and labels. George may not want to change or has time to do that what this thread author said will be better about cargo classes and labels so he started this thread because of this IMO.

As I understand it, CTS would still use labels so George would not have to change anything.

I suppose that CTS would provide more cargo classes, ore even more cargo properties to check, but it would not take much time to add them to ECS vectors. About 20 minutes I suppose

[wallyweb]

I suppose that CTS would provide more cargo classes

As I understand it, CTS would avoid classes. The transportation set coder would assign wagons directly according to the cargo labels supported by an industry set.

[onodera]

I suppose that CTS would provide more cargo classes

As I understand it, CTS would avoid classes. The transportation set coder would assign wagons directly according to the cargo labels supported by an industry set.

I suppose you are wrong.

[wallyweb]

I suppose you are wrong.

It wouldn't be the first time that I'm wrong about something and probably not the last time.

[Draakon]

Hmm, IMO it will be better if we stop muttering and get on to the business. By that i mean make the NewGRF and discuss what should be in this NewGRF and how are coded.

Besides, when it comes to support ability to other NewGRF then this NewGRF author decides how is this supported and how are the cargo labels and classes dealt. IMO it will be better if you ask if this is good scheme currently, what needs do be done to make it perfect and so on.

But hey, what i am to tell?

[George]

There is nothing to do with labels. They work fine. The problem is that labels DO NOT DEFINE the refit. That makes GRF coders to look for other props to controll refit. Currently we have
1) refit list (32 cargoes only)
2) cargo classes (16 classes only)
The whole discussion is aimed to provide a group of classes that allows to specify refit list in a best way. May be classes may not provide all the required support, then we'll ask developers to provide more properties.

[wallyweb]

There is nothing to do with labels. They work fine.

Who said something was wrong with labels?

The problem is that labels DO NOT DEFINE the refit.

What do labels define? What is their function?

1) refit list (32 cargoes only)

I believe that your ECS Industries currently has the most cargoes. How many?

[Draakon]

I know you asked George but may i answer too?

Who said something was wrong with labels?

http://www.tt-forums.net/viewtopic.php?p=645175#p645175
The person of who's post is it.

I believe that your ECS Industries currently has the most cargoes. How many?

32 i think

[wallyweb]

Who said something was wrong with labels?

http://www.tt-forums.net/viewtopic.php?p=645175#p645175
The person of who's post is it.

I did not see anything negative about labels.

[onodera]

I know you asked George but may i answer too?

I believe that your ECS Industries currently has the most cargoes. How many?

32 i think

More than that.

[Draakon]

More than that.

35 of 37 then.

[onodera]

More than that.

35 of 37 then.

Yes. And the refit list is only 32 cargoes long, so you have to use cargo classes. And current cargo classes are not the most convenient way to specify possible refits. This thread is about trying to come up with a better class system. Now, what did *you* want from this thread?

[George]

There is nothing to do with labels. They work fine.

Who said something was wrong with labels?

The problem is that labels DO NOT DEFINE the refit.

What do labels define? What is their function?

They define graphics when vehicle is ALREADY refited.

1) refit list (32 cargoes only)

I believe that your ECS Industries currently has the most cargoes. How many?

At once you can have only 32 cargoes, but the problem is that in vehicle set you need to define all the cargoes. In LV4 I have 54 entries in translation table. But I use only 4 entries in the refit list and in fact I need only 2 entries there (2 entries are used because I used them, not because I could not do it the other way).