Transport Tycoon Forums

michael blunck wrote: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.

michael blunck wrote:at least not ATM.

Oh? Do I detect a spark of interest?

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 ...

wallyweb wrote: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

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.

Mazello wrote: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

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.

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?

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.

wallyweb wrote: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.

Csaboka wrote: 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

michael blunck wrote: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.

wallyweb wrote: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 [...]

Well, no. These are ECS´s cargo slot and cargo bits definitions.

[...] and also from your excellent paper here which includes a definitive table. I can't find any reference to flexibility in either location.

Well, simply because that´d be a matter of a cargo translation table in a specific vehicle set.

Perhaps the tables should be prominently described as examples that are not set in stone.

Well, those cargo bits are definitely fixed (aka "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.

Honestly, I have a problem with the term "people" here. I don´t think that .grf coders which are actively coding vehicle or cargo/industry sets would have any problem with understanding the relevant information on the Wiki. OTOH, it seems that "people" like to take part in many unneeded discussions <cough>, especially if it comes to "ECS bashing".

regards
Michael

michael blunck wrote:Well, no. These are ECS´s cargo slot and cargo bits definitions.

Well, simply because that´d be a matter of a cargo translation table in a specific vehicle set.

Well, those cargo bits are definitely fixed (aka "set in stone").

Well, for ECS to be a definition for general use, should it not accommodate some level of flexibility? Also, the second table, Cargo Labels, has a column for "ECS Vectors" which are George's implementations.

Honestly, I have a problem with the term "people" here. I don´t think that .grf coders which are actively coding vehicle or cargo/industry sets would have any problem with understanding the relevant information on the Wiki.

Sorry. By "people" I meant coders as you rightfully point out. But there are novice coders who might not be aware of these things.

OTOH, it seems that "people" like to take part in many unneeded discussions <cough>, especially if it comes to "ECS bashing".

Yes, and I notice that this same group of people tend to bash things in general without saying anything constructive or meaningful. Just tell them to PM me and I'll set them straight.

Wallyweb wrote:> Well, those cargo bits are definitely fixed (aka "set in stone").

Well, for ECS to be a definition for general use, should it not accommodate some level of flexibility? Also, the second table, Cargo Labels, has a column for "ECS Vectors" which are George's implementations.

What do you mean with "level of flexibility"? As Csaba pointed out, there are 32 distinctive bits for cargoes, and consequently these are defined by ECS.

As to the column "ECS vectors": this has been added by George. It may or may not be of relevance in this context, though.

regards
Michael

Now I'm getting confused, too. If there is a cargo bit "set in stone" for every ECS cargo, how can it have more than 32 cargoes? That would mean there are pairs of cargoes that are mutually exclusive by the spec.

Maybe bits (and slots) shouldn't be in the spec at all. It only encourages people to use the bits directly instead of using a translation table. If you're using a translation table, cargo bits should be irrelevant, except for the coder who codes the cargo.

michael blunck wrote:

Wallyweb wrote:> Well, those cargo bits are definitely fixed (aka "set in stone").

Well, for ECS to be a definition for general use, should it not accommodate some level of flexibility? Also, the second table, Cargo Labels, has a column for "ECS Vectors" which are George's implementations.

What do you mean with "level of flexibility"? As Csaba pointed out, there are 32 distinctive bits for cargoes, and consequently these are defined by ECS.

Flexibility would be the ability to and ease of redefining any of the bits to fit another industry scheme while at the same time remaining true to the concept of ECS. As an example, I think Csaboka implied that COKE could replace one of the other cargo types. The grf author would have to decide which one was to be replaced. This would be simplified if there were one, two or three empty bits available for optional use. Another approach would be to use the same framework with only the base TTDX industries defined and the remaining bits available for optional definition, which begs another question ... Do all 32 bits have to be used?

Right now there are 32 bits defined for cargoes, and 32 cargoes defined by ECS. This is all well and good, but the thing I propose as well would be the option for alternate labels outside the 32. Set a standard, by all means, this I agree with. What I don't agree with is saying "these are the only cargoes we can have, no more are possible if the don't fit in the ECS scheme." If I want a slightly different auto chain with aluminum instead of glass, then in the current scheme I'd have to use a possibly completely different cargo label. I'd say add more labels as a contingency plan, but don't replace others. More than 32 options should be possible, just not in existing games.

Unless of course we can raise the 32 bit limit on cargoes...

You are free to define up to ~4.29 billion cargos. Actually, most people would appreciate it if you limited yourself to ~81 million[0], but that's still a pretty large space. If your cargo doesn't fit in ECS, well, who cares? Just document it properly on the wiki.

[0] Limiting each character of the the cargo labels to the low-ASCII printables.

Csaboka wrote:Maybe bits (and slots) shouldn't be in the spec at all. It only encourages people to use the bits directly instead of using a translation table. If you're using a translation table, cargo bits should be irrelevant, except for the coder who codes the cargo.

Would it be possible to have runtime-assigned bits and slots, similar to the way that houses and industry tiles get runtime-assigned IDs?

I admit I'm having difficulty finding a good way to not break old GRF files in the process here. Maybe the way to do this would be to allow setting properties and graphics for cargos 20..3F, for which property 08 is ignored, and would get inserted wherever they fit in the 00..1F space after the 00..1F cargos take the slots and bits they want?

DaleStan wrote: If your cargo doesn't fit in ECS, well, who cares? Just document it properly on the wiki.

Herein lies the problem.

It's the fact that some people DO care.

Csaboka wrote: Maybe bits (and slots) shouldn't be in the spec at all. It only encourages people to use the bits directly instead of using a translation table. If you're using a translation table, cargo bits should be irrelevant, except for the coder who codes the cargo.

Exactly that´s why they´re in there.

Dalestan wrote: If your cargo doesn't fit in ECS, well, who cares? Just document it properly on the wiki.

Correct. And then it´s up to vehicle sets to set up proper cargo translation tables.

Dave Worley wrote:Since there appears to be a few people making the rules around here,

Dave Worley wrote:It's the fact that some people DO care.

Could you please refrain from such unsubstantiated comments, Dave? They´re not very helpful.

Thank you.

regards
Michael

Michael,

Do you consider ECS as being done or do you consider it as a work still in progress? If the later, what is the next phase in its development?

Wally