Extended Cargo Scheme (ECS) discussion

[wallyweb]

13. Build several truck stations in your town so that at least one will receive food whenever the town moves houses.

this forces me to either give a vehicle multiple orders (for example to visit ALL those stations) which makes train/road networks quiet busy and stuckable
or
to built multiple vehicles some for every station, which is also not so good since we are often out of vehicles (remember, there's only 240 vehicles per type) and some of them will give no income (because some of them will always have same cargo, until station accept food)

That's right ... and that's the point of the game ... you have to manage your transportation as effectively as possible.
Making another industry building (warehouse?) that accepts and pays for food/goods is a cop out for those who only want an easy way to make money.

[Siema]

Here's how to do it:

Your solution is not realistic for me and it force player to use trucks (for example I don't want to use trucks and I'm playing well without making such strange combinations), but as Shadow-XIII, and krtaylor said they have problems for example with deserts cities and there was suggestion about independent building that accepts food/goods - it's a difference from station which is in this case most eye-candy and doesn't have function what we were talking about.

I am so evil

Yes, you are

edit:

Making another industry building (warehouse?) that accepts and pays for food/goods is a cop out for those who only want an easy way to make money.

I said the same at the begining, but they said that they have real problems with food/goods acceptance...

[wallyweb]

Here's how to do it:

Your solution is not realistic for me and it force player to use trucks (for example I don't want to use trucks and I'm playing well without making such strange combinations), but as Shadow-XIII, and krtaylor said they have problems for example with deserts cities and there was suggestion about independent building that accepts food/goods - it's a difference from station which is in this case most eye-candy and doesn't have function what we were talking about.

I am so evil

Yes, you are

edit:

Making another industry building (warehouse?) that accepts and pays for food/goods is a cop out for those who only want an easy way to make money.

I said the same at the begining, but they said that they have real problems with food/goods acceptance...

Rather than add another building, how about making sure more houses accept food? For example, Zimmlock's TTRS has too many townhouses that do not accept food.

[Raichase]

Uhhh, why not simply use shared orders for the trucks?

IE They all use the same set of orders, and when one truck stop stops accepting, you simply re-route one truck, and it automatically changes it's orders.

It's more efficant too, as the trucks are not visiting multiple stops for no reason .

[SHADOW-XIII]

Uhhh, why not simply use shared orders for the trucks?

IE They all use the same set of orders, and when one truck stop stops accepting, you simply re-route one truck, and it automatically changes it's orders.

I do this way now, but it makes me checking it around once a year (or when trains stuck because one of them,heavly loaded ,did not unload cargo at station and is going uphill very slow)

[PikkaBird]

I have been reading the wiki on action 0 properties 28 and 29, and I have a request - can we change the definition of "refrigerated" cargo (bit 8) to "food" cargo?

I'd like, for example, to be able to disallow the carrying of grain or fruit in coal trucks - however, grain clearly does not need to be refrigerated. So a grain-style cargo would be defined as [bulk, food], while a processed food delivered to town would be [express, food].

[Patchman]

I could add another class for "organic" cargo. I think refrigerated should stay a separate class, because some organic cargos need refrigeration (and thus special equipment) and some don't.

[michael blunck]

[...] can we change the definition of "refrigerated" cargo (bit 8 ) to "food" cargo?

I don´t think we should.

The basic problem is that there are different classification schemes for cargoes. I.e., cargoes in the ECS (which original game cargoes are a subset of) are categorisied by means of production and the cargo classes of the patch´s action0 are classified by means of transportation.

Hence, "refrigerated" is a "transportation class". It´s incompatible with "food", because that´s a "product class".

Moreover, the transportation class "refrigerated" is a special class applicable to different product classes like "food" or "fish". It´s important in game because of the requirement of special wagons (reefers)).

I'd like, for example, to be able to disallow the carrying of grain or fruit in coal trucks -

I don´t see any problems here because both "grain" and "coal" are already existing cargo classes (in the ECS) and hence should be well represented in rolling stock of diverse vehicle sets.

however, grain clearly does not need to be refrigerated. So a grain-style cargo would be > defined as [bulk, food], while a processed food delivered to town would be [express, food].

Well, no.

In reality, "bulk" is differentiated with respect to weight:

- heavy bulk (iron ore, coal, sand, gravel, ...)
- light bulk (grain, pulses, sugar, nitre, coke, ...)

O/c, "grain" may be transported by the same classes of wagons as "coal" (open wagons, gondolas, hoppers) which is OK. Remember, you´d have to refit and pay a small fee which would be for cleaning the wagons.

Regarding "fruit", this is a cargo of it´s own (in the ECS) and includes also "vegetables" which both would need different transporting means, e.g. bananas or grapes could be filed under "refrigerated" but sugar beets would be OK under "bulk".

regards
Michael

[wallyweb]

I think its time to sit back and clear the air a bit.

I support the New Cargo Concept.

Unfortunately, for any of a host of reasons, it seems to have gone off on several tangents and it has become an issue that is needlessly complicated and misunderstood.

Hopefully, these comments that I am about to make will help return this concept to the simple thing that it is.

To begin, some basic principals:
Transport Tycoon, in all its versions, is a transportation simulation game. It is, quite simply, about transportation, by sea, by air, by road and by rail.
For transportation to work, something must be transported, in general terms ... cargo.
For cargo to be available for transportation, it must be produced. In its original concept, Transport Tycoon did this in a variety of ways, simulating as much as possible, real life situations.
Due to limitations in its original conceptualization, not all cargos could be made available at once. This was addressed by the game being offered with a choice of climates. For similar reasons, transportation vehicles were very basic and weakly based on reality.

Enter the Patch! (Thank you Josef Drexler )

The game was extended by the patched versions that we all know and enjoy, enabling the addition of levels of reality beyond our dreams.
Artists and coders such as Michael Blunck and George and too many others to name, jumped on the opportunities, providing us with graphics and functionality astounding for their faithfulness to the real item.

This metamorphosis is ongoing with hardly a week going by without the addition of some brilliant new feature.

The Topic wherein you see this post is all about one of those new features ... a New Cargo System.

To a large extent, it is implemented through the Action 0 properties of the patch. Please go to the patch's wiki and read up on Action 0. Take note of the section on cargo classes.

At this writing, there have been two New Cargo implementations:
- newcargo(w).grf by Michael Blunck
- NewCargosPetrolTourists(w).grf by George
This is where the confusion and misunderstandings begin.

Many people believe that these implementations are a faite accomplis and that they must be used in all past and future set development.
This is wrong. The only faites accomplis are the definitions found in the patch's wiki.

These two grf's are simply excellent and well thought out examples of what can be accomplished when implementing the patch's powerful features with respect to action 0 and cargo classes.

To be sure, Michael and George and others colaborated in developing the vectors so that these two grf's would be mutually compatible. The cargo ID's used are unique to these two grf's but they are open and available to other set designers who may wish to work them into their own sets.
Michael and George were simply the first on the block.

For inter-set compatibility, it would be nice if developers could take advantage of Michael's and George's grounbreaking efforts, but they should keep in mind that those efforts do belong to Michael and George. From personal experience I can assure you that they are both open to suggestions and are available to share their advice and assistance.
But (and this is a big but) other set designers are also free to follow their own paths and develope their own implementations, keeping in mind that their work might not be compatible with other sets.

On a related note (yes ... I like those related notes ) ... another source of confusion ... the accronym ECS. I always took it to be the European Cargo Set, until I saw others using it with reference to new cargoes. I searched but could find no discussion. Only after asking someone did I find out that it also refers to Extended Cargo System, which is very descriptive, but if you are going to rename something, then you have to announce it properly so that others may know what the heck you're talking about. It does pay to advertise.

Another related note (:roll:) ... to end confusion and speculation, why not, instead of merely reacting to questions, post ongoing development status in this topic. Until I had to persue a couple of questions with George, I honestly thought this topic was dead.

Thank you for reading these comments.
Please flame at will but be imaginative with it.

Regards,
wallyweb

[DaleStan]

(relocated from the NARS thread)

Trimming your quotes (taking out the irrelevant stuff, like I did) is not hard. You don't have to repeat every character of the post to which you're replying.

Hm. I trimmed the part of your post. What did I do wrong?

Maybe I trim too energetically, but I would have only quoted as above.

The [NCS] release GRFs, if they exist.

They do

Where? I found a bunch of suspicious-looking RARs in the development directory, but the name "development" makes me suspect they aren't for release yet. Also, I found no links to them; another point on the not-for-release side.

http://ttd.cernun.net/download/developm ... %2010c.png

That's a start. Now where's the data that corresponds to this data? Ditto for the data on these two pages

[Paper vs. Steel in slot 09]

The ECS is supposed to be used in any landscape. To make the game different, it suppose to have "mods", which can be applied in any landscape.

Sort of like how the LVs work oh-so-well in toyland? </sarcasm> And if you are going to contend that toyland is different, then why aren't any of the other climates different? (And don't say the graphics; those can be replaced. Ditto on the cargo/industry scheme.)
Are you quite sure that the NCS isn't just going to turn TTD into a one-climate game? Or is that what you intended all along?

That argument notwithstanding, I'll commence cooperating with the NCS in non-temp-climates just as soon as you fix, at the very least, the USSet, the ArcticSet, the LVs, and the NewShips, so they understand that paper is slot 0B and not slot 09, but only if the appropriate NCS GRF(s) are loaded. (Ditto for all the other cargos that NCS moves.)
I rather doubt that this moving-the-default-cargos thing is really going to fly, because the current GRFs will have to support the default cargos too, for some time to come, if not forever.

If you code a GRF that properly moves paper to wherever-it-belongs-in-arctic, I'll quite happily cooperate with said GRF.

What is properly? You can not support in the existing games on the other IDs.

See above. "Proper support" is such that the set uses these so-called "correct" slots, but only if the NCS GRF(s) that move the cargo(s) are loaded, otherwise it uses the game's default slots instead.

[George]

The [NCS] release GRFs, if they exist.

They do

Where? I found a bunch of suspicious-looking RARs in the development directory, but the name "development" makes me suspect they aren't for release yet. Also, I found no links to them; another point on the not-for-release side.

Yes, they are under development. But that does not mean that someone can't test them and give suggestions.

http://ttd.cernun.net/download/developm ... %2010c.png

That's a start. Now where's the data that corresponds to this data? Ditto for the data on these two pages

this pages were used as a start point for developing and coding the ECS

[Paper vs. Steel in slot 09]

The ECS is supposed to be used in any landscape. To make the game different, it suppose to have "mods", which can be applied in any landscape.

Sort of like how the LVs work oh-so-well in toyland? </sarcasm>

It is very easy to allow LVs in toyland, YOU KNOW it. The only thing, which is requred, is removing the landscape checks.

And if you are going to contend that toyland is different, then why aren't any of the other climates different? (And don't say the graphics; those can be replaced.

temperate-arctic - there are no diffs
temperate-tropic - forests and desert-snow (the tile checks)
temperate-toyland - lighthouses and forests (can be fixed with patch сап file) and there is no snow in toyland (I think it woun be not hard to add it)

Ditto on the cargo/industry scheme.)
Are you quite sure that the NCS isn't just going to turn TTD into a one-climate game?

It will ALLOW one-climate game. BUT, it will ALLOW different schemas in different climates, that is much more than 4 landscapes. The player just have to set the vectors, he wants to use. He can use all the vectors or a part of them. Up to him.
Our position is: the player showld be allowed to have as wide range of possibilities, as possible, and only the player should choose the ones, he wants.

That argument notwithstanding, I'll commence cooperating with the NCS in non-temp-climates just as soon as you fix, at the very least, the USSet, the ArcticSet, the LVs, and the NewShips, so they understand that paper is slot 0B and not slot 09, but only if the appropriate NCS GRF(s) are loaded. (Ditto for all the other cargos that NCS moves.)

It is very EASY, you know it. It would be done as soon as ECS grf files will get their first stable stage.
Now there are some problems. I've posted them to Csaboka already. May be you can also have a look at chemicals vector too? It does not want to define industries' names, while other vectors do

I rather doubt that this moving-the-default-cargos thing is really going to fly, because the current GRFs will have to support the default cargos too, for some time to come, if not forever.

It is not hard to code

If you code a GRF that properly moves paper to wherever-it-belongs-in-arctic, I'll quite happily cooperate with said GRF.

What is properly? You can not support in the existing games on the other IDs.

See above. "Proper support" is such that the set uses these so-called "correct" slots, but only if the NCS GRF(s) that move the cargo(s) are loaded, otherwise it uses the game's default slots instead.

It is the question for the sets, not the ECS. I've wrote Josef about the problem with class prop since alpha 61 (in alpha 60 it worked fine). See the Skoda truck in the dev folder.

[eis_os]

I can't actively follow the conversation because of other stuff sorry.

I have some worries about the current stuff I read about the new cargo system. From my point of view it was always the goal to load old savegame and play with it. Surely I could have changed more stuff in moreindustriesperclimate, or even change the default cargo vectors, but I think TTDPatch Players have to be comfortable with their Game.

More and more I have to see TTD Games are incompatible, I tried to load a game Raichase gave me and it failed on A LOT places.

If you now can change the cargo vectors then you can't simple give someone a savegame anymore, not only the vehicles (which is most times easy to fix) but aswell the cargo vectors get screwed up. I see the problem that I won't never be able to reproduce the environment to actually play the game. Shareing scenarios will be very hard aswell.

Maybe you will think about it more when a Patch Dev tells you that you shouldn't make it so complicate.

I think players will benefit more if say 50% of the cargo vector png will be released as one grf without options to hassle with and you simple can say, you need the ECS, NCS or something grf to simple have your savegame working then to have 100% and end up with a chaos of options. For other sets it's easier to collaborate aswell.

I see this picture (it's only an example, exchange names with other sets if you like):

DBSetXL will only work good with setting a, b
TTRS3 will only with vector setting b, d
PGS works only right with a, c

And now?

Keep in mind, sometimes less is more ...

[michael blunck]

Maybe you will think about it more when a Patch Dev tells you that you shouldn't make it so complicate. [...] Keep in mind, sometimes less is more ...

Well, AFAIR, a "Patch Dev" made it "so complicate", namely Csaba when introducing the (long and desperately wished!) feature of more cargoes.

That´s why it is "so complicate" (and BTW, because of the introduction of the "moreindustriesperclimate" feature by yourself before).

> And now?

The aim of ECS is to ensure a maximum amount of compatibility and flexibility for the "newcargoes" and "newindustries" features of TTDPatch.

I.e. it´s the question where that "maximum" would to be find, but o/c it would be unequally higher than without any efforts towards a "standardization".

regards
Michael

[SHADOW-XIII]

Oskar just to let you know that I respect and admire yor work for TTDPatch
but if you did a poll with question if people want new features or compatibility with (loading) older games I think most of them would vote for new features

[broodje]

you think so? I want to be able to load a game from anyone withoud setting tons of options differend, sory but I'm with eis_os in this point. (and on top of that, all maps are way to small to have all these new industries ) I realy think there should be some standard in this before tons of sets with tons of differend settings are clashing in a big battle in the newgrf.txt....

[wallyweb]

Here I am, butting in again.
But I think the Extended Cargo feature is too important to ignore.

To begin, some thank you notes ... Michael for renaming the thread ... much easier to find now ... and DaleStan for moving his and George's discussion. This is definitely where it belongs.

ECS is grf implemented ... am I right or wrong?
If it is grf implemented then the concerns about the compatibility of older savegames and scenarios are simply handled ... Turn off the grf's that were not used when the game/scenario was started. The New Graphics Status window accessible both ingame AND under Game Options makes this so very easy.
If some settings in the patch are a concern, turn those settings off as well.
Result? Instant Backward Compatibility.
I believe we already do this, don't we? At least I do.

Somebody should have stated that in an instruction to players on how to use the ECS feature.

Instructions? Where is there a simple set of player instructions? I did not know that individual vectors could be turned off and on. I'm still not sure how to do this. Perhaps its as simple as turning grf's on and off? Let us know.

Vectors that can be turned on and off? Sounds almost like plugins. That would be very cool. Just plugin (turn on grf?) the vector(s) that you want in your game or scenario. Elegant in its simplicity. Is this the way it is supposed to work? I don't know. Let us know.

I'm not a coder, but I can sympathize with those that are. How can they code if they do not know what codes to use? Post those codes in the forums so they can be seen and commented on. Start a separate locked and sticky "No Comment" thread so they can be easily found and viewed. This current thread is a discussion thread and all comments should be directed here.

The suggested "No Comment" thread could also contain the simple player instructions and download links. Just make sure all information is up to date and current.

Don't want to post it because its still under development? HogWash! Post it all now as you develope it. That way you can benefit from comments and observations of others and perhaps save yourselves a whole lot of re-writing later. You'll also find that others might be a whole lot more cooperative.

Take your work out of that dark lab in the basement and lets see what it looks like in the daylight.

Oh yes .. one last thing ... Post a disclaimer. Let everybody know that they do not have to use ECS in their sets. They can always go their own route, even though it would be nice to have cross-set compatibility.

[DaleStan]

X-TomeSize: 2

Yes, they are under development. But that does not mean that someone can't test them and give suggestions.

It's mighty hard to test that which you can't find. And just because I managed to find it doesn't mean that everyone can. It was mostly luck that I found it.

this pages were used as a start point for developing and coding the ECS

So, where *is* the cargo property info?

temperate-arctic - there are no diffs
temperate-tropic - forests and desert-snow (the tile checks)
temperate-toyland - lighthouses and forests (can be fixed with patch сап file) and there is no snow in toyland

And that's about my point. Basically, we have four blank slates; why do we have to draw the same thing on all four of them?

[The ECS] will ALLOW one-climate game. BUT, it will ALLOW different schemas in different climates, that is much more than 4 landscapes. The player just have to set the vectors, he wants to use. He can use all the vectors or a part of them. Up to him.
Our position is: the player showld be allowed to have as wide range of possibilities, as possible, and only the player should choose the ones, he wants.

And I assume that all possible combinations of GRFs are all guaranteed to produce consistent states? If, for example, I choose not to load the chemicals GRF, then what do I do with sulfur? Or will the basic GRF detect this and not define sulfur, nor define the power plant to produce sulfur? That setup will also change the vehicles industry, the printing works or the textile mill, so that neither they nor their tiles accept or require Dyes, right?

I'll commence cooperating with the ECS in non-temp-climates just as soon as you fix, at the very least, the [major sets], so they understand that paper is slot 0B and not slot 09, but only if the appropriate ECS GRF(s) are loaded.

It is very EASY, you know it. It would be done as soon as ECS grf files will get their first stable stage.

Well, then, I guess you'll have to demonstrate, because I am under the impression that setting availability, refitability, and default cargo depending on the presence of one or more of *nine* different GRF files is non-trivial. (Sulfur, for example, would require both the appropriate basic vector and the chemicals vector, and that's six checks[0] just for one cargo.)

[0] Two climate checks, so only the appropriate basic GRF is checked, one for each of the basic GRFs (three), and a check for the chemicals GRF. And that's assuming one check is sufficient for each GRF, which I'm not entirely convinced is true. I could find out for sure, but it isn't really relevant to my argument.

I rather doubt that this moving-the-default-cargos thing is really going to fly, because the current GRFs will have to support the default cargos too, for some time to come, if not forever.

It is not hard to code

You actually did it and everything worked correctly with all 512 possible combinations of the ECS GRFs? (More than that, if order is significant.) And it was "not hard"? I'd hate to see what you think is "hard", then.

See the Skoda truck in the dev folder.

*checks* There are no Skoda trucks in the dev folder.

Maybe you will think about it more when a Patch Dev tells you that you shouldn't make it so complicate. [...] Keep in mind, sometimes less is more ...

Well, AFAIR, a "Patch Dev" made it "so complicate", namely Csaba when introducing the (long and desperately wished!) feature of more cargoes.

No. Csaba made it possible. "Simple" is "Here's one GRF. Add it to your newgrf[w].cfg to use ECS." "Complicated" is "Here's 9 different GRFs, load all of them to use ECS; loading any subset may cause an inconsistent state. But you still have to track all of them."

There's a reason I'm still using LVv3. It's too much of a hassle to find all the LVv3¾ GRF files and try to remove/replace the appropriate GRFs. That, and figure out when each gets updated, and whether or not I really do have the latest version of each.

ECS is grf implemented ... am I right or wrong?
If it is grf implemented then the concerns about the compatibility of older savegames and scenarios are simply handled ... Turn off the grf's that were not used when the game/scenario was started. The New Graphics Status window accessible both ingame AND under Game Options makes this so very easy.

The reverse is the problem. Having all the appropriate GRF files. Especially with George's love of releasing ten files where one would do, and then updating them non-synchronously.

If some settings in the patch are a concern, turn those settings off as well.
Result? Instant Backward Compatibility.
I believe we already do this, don't we? At least I do.

More hassle. Not a major problem, but yet more hassle.

Vectors that can be turned on and off? Sounds almost like plugins. That would be very cool. Just plugin (turn on grf?) the vector(s) that you want in your game or scenario. Elegant in its simplicity.

Elegant in its simplicity to the player. The coders, OTOH, will have to handle several hundred different possible combinations of GRFs, possibly thousands, and behave correctly in all instances.

This is, IMO, a non-trivial undertaking.

[eis_os]

I wouldn't mind if we have say, 3 or 4 grfs, but if we get more and maybe even some with parameters then it really gets nasty...

[Patchman]

I have to agree. I have come to the conclusion that making these separate vectors is needlessly complicated.

If there have to be several grf files, they should all be orthogonal, i.e. you can use each one independently of any other and none of them should affect each other. It's complicated enough that cargo grfs affect all other grfs (vehicles, stations, town buildings), it will get insanely difficult to find bugs or problems if you also make them interdependent.

I am also quite strongly opposed to the idea of changing the default TTD cargos. As DaleStan says, that will make existing sets instantly incompatible. The idea of climate-independent cargo bits (prop. 08) should make it possible to deal with this appropriately without changing the existing cargos.

Also I think that if 32 cargo types aren't enough, you need to coalesce some of them that are similar (such as petrol, sulphur and chemicals). I cannot see how an excessively large number of cargo types will make the game more interesting, but they will make it more complicated.

In summary, I would prefer, very strongly prefer, if the NCS (or ECS or whatever you want to call it) was a single monolithic grf file that does not modify TTD's original cargo selection in the three standard climates. (I don't care about what you do in Toyland).

Until now, I had been under the impression that this would be the aim of the set, but that appears not to be the case. If you want, you can give the NCS grf the option to turn off various cargo types (I hesitate to call it "vectors"), but there should not need to be a choice of different cargo types in the same slot.

I have no problem at all with making several such NCS grfs, as long as they're all entirely independent of each other. If they're interdependent, I can just see us getting bombarded with questions and problems in getting it to work.

I'd like to remind you that "complicated" does not mean "interesting", and "simple" does not mean "uninteresting".

[wallyweb]

I'm not going to fill this post with a lot of "<username> wrote" quotes. We just need to scroll up a bit to review what was said.

This discussion is very illuminating and I'm gaining a whole new respect for what is involved.

It seems to me the issue is complication. Like any code anywhere, one small change can have a domino effect. This is especially so when looking at the vectors that accept cargo from and send cargo to other vectors. The other vectors become affected, as well as all the interelated supporting infrastructure.

There would appear to be only one simple solution.

An umbrella cargo scheme covering all sets is too restrictive. The plug in concept I now see as being somewhat unwieldly.

Perhaps it is better for each set to have its own scheme with industries and vectors designed and implemented by that set's authors to live or die on its own merrits.

The only problem with this is that the "one size fits all" satellite sets such as long vehicles, plane set, ship set and others might not be supported and similar sets would have to be independantly created to fit in order to provide that complete transportation mix.

So I have a question ... Can a scheme grf be made to write to these "one size fits all" satellite sets, overwriting approprate properties so that they would fit? Can these "one size fits all" satellite sets be made to accomodate the input from a scheme's grf?

Example:
Michael's passenger liner would be ideal as a cruise ship that accomodates tourists via a refit option.
Michael has already said that this is possible and should be accomplished by the scheme's grf, in this case NewCargosPetrolTourists(w).grf, rather than in newships(w).grf

If this is the case then set designers should be able to follow independent paths.

The only other option is for each set to present its own complete mix of industries and conveyances and to completely do away with interoperability.

Edit: patchman posted as I was writing the above. We seem to be on the same channel. I especially agree that we must not modify TTD's original cargo selection in the three standard climates and I as well am not concerned about Toyland.

Let me add the kiss principal: "Keep It Simple Stupid"