Extended Cargo Scheme (ECS) discussion

[Wile E. Coyote]

I tried to re-code Serbian rail set to support ECS, but I had all time steel and water as hopper cargo. Then I thought I did something wrong, and then disabled all cargos except bulk. Same error! I downloaded again all ECS files again and same errors. Then I fastly checked through all ECS files and found following errors:
Machinery vector:
STEL coded Action 0 prop. 16 10
Basic tropic vector:
WATR 16 10; CERA 16 04
Agricultural vector:
WOOL 16 04; FERT 16 10; OLSD 16 10; FICR 16 20
Construction vector:
CMNT 16 90
Town vector:
TOUR 16 01
Wood vector:
WDPR 16 20
(Maybe there are other errors, I checked all vectors fastly.)

EDIT: two more errors:
Basic vector:
GLAS 16 04
Basic vector for arctic:
GLAS 16 04

[Michael24]

I added the ECS Wood file, but it tells me i need to load ECS Town first, and when i do that snow comes..

I dont want snow Can i some how get the industries in ECSwoodw without getting the snow?

[michael blunck]

> I dont want snow

According to http://www.tt-forums.net/viewtopic.php?p=531504#531504 you want snow.

(if not, get rid of your snow-in-temperate file)

regards
Michael

[wallyweb]

More snow questions

Patchman's snowline.grf and DanMack's Canadian Set have parameters to set snowline height.
ECS has a snow feature for when the patch's tempsnowline switch is on.
As far as I can tell, ECS has no parameter setting for this and sets the snowline at the ttdx default.
If ECS and either snowline or canset are set to on, ECS will overide the other's parameter with the ttdx default snowline.

Is anybody aware of an ECS parameter setting or a workaround that will allow the other grf's parameter settings to prevail?

Note that as far as I know ECS must be loaded before any other grf, especially those that handle cargo.

[michael blunck]

Snowline height or even snowline at all isn´t a feature of ECS.

O/c, it could well be an (additional) feature of a .grf implementing ECS cargoes in the first place ...

regards
Michael

[wallyweb]

Snowline height or even snowline at all isn´t a feature of ECS.

O/c, it could well be an (additional) feature of a .grf implementing ECS cargoes in the first place ...

regards
Michael

By ECS I meant the vector grf's by George.

I checked by doing a test game with all grf's off except the ECS grf's and snow was created in Temperate. I believe it is a feature of the ECS town vector. I believe there is a post much earlier in this thread that mentions that.

[Csaboka]

ECS has a snow feature for when the patch's tempsnowline switch is on.
As far as I can tell, ECS has no parameter setting for this and sets the snowline at the ttdx default.
If ECS and either snowline or canset are set to on, ECS will overide the other's parameter with the ttdx default snowline.

AFAIK, George's GRFs define a variable snowline. The snowline is pretty low during the winter months, while only high mountains are snowy during the summer. It would be a good idea to allow turning it off, though.

[wallyweb]

ECS has a snow feature for when the patch's tempsnowline switch is on.
As far as I can tell, ECS has no parameter setting for this and sets the snowline at the ttdx default.
If ECS and either snowline or canset are set to on, ECS will overide the other's parameter with the ttdx default snowline.

AFAIK, George's GRFs define a variable snowline. The snowline is pretty low during the winter months, while only high mountains are snowy during the summer. It would be a good idea to allow turning it off, though.

Thanks Csaboka,
When I get home from work later today I'll let it run through a year to see what happens. If it is indeed the seasonal effect then I can live with that, I think.

EDIT Further testing has been done with the following results:

ECSTownw.grf provides snow coverage in the Temperate climate that varies with the seasons, ranging in coverage from a dusting at level 15 during the summer to typical snow coverage down to level 4 in winter with levels 1, 2 and 3 above sea level being snow free all year.

Any grf's that offer snow coverage parameters will be overiden by ECSTownw.grf making it impossible to set a minimum year round snow coverage other than the dusting at level 15. It matters not whether those grf's are placed before or after ECSTownw.grf.

Conclusion: A suggestion to anybody making future revisions to ECSTownw.grf : Provide a parameter that allows the feature to be 1. turned off thus allowing other grf's to prevail with their own snow parameters and 2. Allow for a minimum year round snow coverage to be set as a parameter, thus allowing for player determined year round snowy peaks and seasonal coverage at lower levels.

[Michael24]

> I dont want snow

According to http://www.tt-forums.net/viewtopic.php?p=531504#531504 you want snow.

(if not, get rid of your snow-in-temperate file)

regards
Michael

Well, yes. But the snow in the ECStown can not be changed to different hights, which wallyweb pointet out.

But thanks for giving me an answer ppl.

[michael blunck]

Any grf's that offer snow coverage parameters will be overiden by ECSTownw.grf making it impossible to set a minimum year round snow coverage other than the dusting at level 15. It matters not whether those grf's are placed before or after ECSTownw.grf.

Conclusion: A suggestion to anybody making future revisions to ECSTownw.grf : Provide a parameter that allows the feature to be 1. turned off thus allowing other grf's to prevail with their own snow parameters and 2. Allow for a minimum year round snow coverage to be set as a parameter, thus allowing for player determined year round snowy peaks and seasonal coverage at lower levels.

Let me refer to the second point only, because the first one should be addressed directly to George.

A rather similar suggestion had already been issued by Wile some time ago:

@Wile E. Coyote

> Most realistic IMO there would be 2 parameters: one to set lowest snow height in winter, and one to set lowest snow height in summer. But it'd be probably huge amount of work (if it's possible?).

It would be possible but need some additional work because I´d have to include more than one snow height table which would be selected according to the used parameters. Don´t know if this would be of any broader interest, though.
[...]

To have parameterized max and min snow height would be a lot of work resp a lot of overhead in the .grf.

In fact, to cover the whole spectrum of min and max snow heights would require n*(n+1)/2 snow height tables, i.e. for n=15 (max height), you´ll need 120 different snow height tables from which one would be used then according to the settings of those two parameters.

Personally, I won´t do it, at least not ATM.

regards
Michael

[wallyweb]

Personally, I won´t do it

Quite understandable, but it was worth a thought and now if others run into this issue at least we have a place to point them to. Thanks Michael.

at least not ATM.

Oh? Do I detect a spark of interest?

[eis_os]

Well if I remember Josef, most stuff in TTDPatch currently is turing complete. We have variables, gotos and stuff for calculations.
So if you have a formula for to calculate the results for all entrys with two variables it should be possible to write a generic TTDPatch GRF routine.



Set a grf parameter called now X to 0
:jumpdest

Set a grf parameter called now R to 0

You need a formula to calculate for two grf parameters the exact snow height table for entry X in the table. You should be able to calculate this result with Action D into a grf parameter called R

With Action 6 change the next action 6 to alter the right byte (so apply X)
With Action 6 you can modify the table and store the result of R at X(you have written above)
Set Action 0 snowline table. (Internal it sets a pointer to the bytestream, so we can do it several times without harm, as action 6 supports only modifing the following sprite...)

Increase X
With goto labels and action9 you should now be able to jump back if we still need entries.

Disclaimer: Without any warranty of functionality... or TTDPatch breakage...

I hope we get someday a bit easier grf language ...

[michael blunck]

Quite understandable, but it was worth a thought and now if others run into this issue at least we have a place to point them to.

Well, IMO, because "snow" isn´t (and shouldn´t) part of the ECS framework, this thread isn´t the right place to discuss problems with it either. It is more or less a coincidence that George´s ECStown .grf doesn´t only implement ECS cargoes (and industries) but also includes a mechanism to set the snow line in temperate.

In my own implementation these two features are/will be separated:

- new (ECS) cargoes (and industries) are included in the NewCargo .grf, industry buildings only reacting on a detected "snowline",

- "snow" is included in AlpineClimate (and hence had been discussed in that thread until now).

@eis_os
[on generating snow height table(s)]

Yes, this would be possible. In the past, I made an attempt to "generate" a single parameterized snow height table "on the fly", but because the varying snowline in AlpineClimate is (more or less) sinusoidal, I didn´t find an easy way to calculate it inside the .grf. In either way, ATM it´d be just far easier to set up a couple of snow height tables externally and load them according to the given parameters

regards
Michael

[Mazello]

Uhh my first post here and it is complaining. Sorry for that

I have problem with tycoon and ecs. When some wood products are appearing to station game will crash and go to xp desktop and give that xp crash window. I am pretty sure of that, that the problem is something with wood products but i don't have skill to be sure or repair it.

So what files you guys need (george maybe) to investigate and help me with this problem?

If you dont want contact in this topic, please use msn or e-mail.

[wallyweb]

Uhh my first post here and it is complaining. Sorry for that

I have problem with tycoon and ecs. When some wood products are appearing to station game will crash and go to xp desktop and give that xp crash window. I am pretty sure of that, that the problem is something with wood products but i don't have skill to be sure or repair it.

So what files you guys need (george maybe) to investigate and help me with this problem?

If you dont want contact in this topic, please use msn or e-mail.

Check George's topic here --> http://www.tt-forums.net/viewtopic.php?t=30188

[wallyweb]

Hi Michael,

In the Future of Cargoset topic you posted this link to Cargo Labels. Why don't you add it to the first post of this topic so that it would be easier to find? It really is hard to discover if one is not aware of its existence.

[wallyweb]

Sorry folks but, although somewhat related to my previous post above, this post concerns a different question so I do not think it qualifies as a double post in a strict sense of the phrase.

Although related to the Future of newcargos discussion, this post is specific to the Extended Cargo System (ECS) v0.3 mb 22.10.05 written by Michael Blunck, so it appears in this topic.

The reason for this post is that, from the Future of newcargos discussion, there appears to be some concerns as to how to handle coke, a product derived from coal and used by the steel industry to manufacture steel. The question arose due to Zimmlock's fine drawing of a coke plant. It would seem the discussion is valid in that a coke plant is a logical industry for use in TTDPatch games.

Coke should fit in somewhere under "3.Products", but there are no labels that would logically accommodate it. As it appears that all 32 available labels are in use, coke can't be simply added to the system.

This inflexibility has highlighted a small shortcoming in the ECS system. It is small in that the question does not arise often, but when it does, it provokes considerable discussion.

So, finally, my question: Is there any way to introduce a level of flexibility into ECS labeling such that these situations can be accommodated?

[Csaboka]

I may be clueless here, so feel free to correct me if I say something stupid, but this is how I see the problem:

First of all, the number of the cargo labels isn't limited to 32 in any way. You can only have 32 cargoes at any given time, but nothing prevents you from defining as many labels as you like. (The theoretical upper limit is 4 billion labels, so the number of available cargo labels are practically unlimited.) The ECS contains exactly 32 cargo specifications, but this is because of historical reasons. You don't have to find an ECS cargo type that's "close enough" - coke is coke, distinct from all ECS types. It wouldn't be hard to add a 33rd cargo specification, with the label COKE, and make vehicle sets support it. Of course, ECS doesn't necessarily have to include coke - as long as its specs are publicly available, vehicle set authors can always add support for it without breaking compatibility with ECS. Adding it to ECS would only make the support more certain - all sets that claim ECS compatibility would be forced to support coke as well.

There is a different issue, though: compatibility with ECS implementations. These implementations want to use all available cargo slots, so you must break at least one vector when adding an industry that uses coke. So, the real question is what should we kick out when adding coke.[1] This is something the GRF coder of the industry set should decide, not something that ECS should specify.

[1] I guess if the number of new cargoes is small, it may be feasible to use GRM and use any unused cargo slot for coke, but it seems that using GRM for this is more painful for a GRF author than it should be.

[michael blunck]

The question arose due to Zimmlock's fine drawing of a coke plant. It would seem the discussion is valid in that a coke plant is a logical industry for use in TTDPatch games.

Normally, a "coke plant" would be part of a "steel industry", hence no need to transport "coke" as an extra cargo over long distances.

Except from that, "coke" would be rather similar to "coal", both from its use in-game and it´s graphical appearance and handling, wouldn´t it?

As it appears that all 32 available labels are in use, coke can't be simply added to the system.

You still don´t understand how the cargo system works, but fortunately, Csaba seems to like to explain it again.

The ECS contains exactly 32 cargo specifications, but this is because of historical reasons. You don't have to find an ECS cargo type that's "close enough" - coke is coke, distinct from all ECS types. It wouldn't be hard to add a 33rd cargo specification, [...]

There are already more than 32 cargo labels, AFAIR.

I´m getting tired to repeat it again and again, but "ECS" as such isn´t an implementation (like George´s ECS vectors are), it´s a definition and as such acts as an interface between vehicle sets and cargo/industry sets.

[...] and make vehicle sets support it.

Exactly that´s the point. If a vehicle set has a cargo label for "XYZ" in its cargo translation table, there won´t any problems.

vehicle set authors can always add support for it without breaking compatibility with ECS.

I´ve written this again and again. Hopefully it´ll help that you´re repeating it once more.

regards
Michael

[wallyweb]

Normally, a "coke plant" would be part of a "steel industry", hence no need to transport "coke" as an extra cargo over long distances.

True, except that I do remember seeing a stand-alone coke plant in Lasalle, Québec, so I would imagine that similar facilities exist elsewhere.

Except from that, "coke" would be rather similar to "coal", both from its use in-game and it´s graphical appearance and handling, wouldn´t it?

Yes, with the exception that coal is a resource and coke is a product.

You still don´t understand how the cargo system works, but fortunately, Csaba seems to like to explain it again.

and he did a fine job of it too.

There are already more than 32 cargo labels, AFAIR.

Where? Are these available for viewing?

... it´s a definition and as such acts as an interface between vehicle sets and cargo/industry sets.

I understand this and have said as much myself elsewhere. I think part of the confusion comes from the wiki here which is actually a description of George's implementation rather than the actual definition and also from your excellent paper here which includes a definitive table. I can't find any reference to flexibility in either location. Perhaps the tables should be prominently described as examples that are not set in stone.

Overall, the system is excellent and now we have some idea that flexibility is implicit, but this should be mentioned in the specification and not rely on people having to search the forums for something they might not realize exists.