Extended Cargo Scheme (ECS) discussion

[michael blunck]

Of course this is a complicated task. Some people already know that but most have been ignorant of the complexity which stems simply from the fact that in TTD cargoes are related to just everything: industries, vehicles, buildings, stations.

Now, in the "community", we already have self-contained sets of vehicles, buildings, stations and (new or modified) industries designed by different people. There is no "all-in-one" set and it´s hard to believe that there will be such sets in the near future (and we´d need many of them!).

And that´s why cargoes cannot be handled the same way like vehicles or stations have been handled: cargoes have an inherent interconnectivity and we have to deal with it, if we like it or not.

The cheap alternative would be "do away with compatibility", i.e. surrender to total chaos.

Now, from my opinion the whole task is two-fold:

- one side would be to define something like a "standard set" of cargoes, an "umbrella" for all climates. This must be done in such a way that it gives a good mapping on real cargoes and real transportation and those new cargoes must bring about interesting solutions for the design of new industries, new vehicles and possibly new station facilities.

- the second side would be the implementation of a framework which would define e.g. cargo slot IDs, cargo bit masks, cargo names, icons and all the other cargo property data. Because here too (as in general) we won´t have only one or two "big new cargo" .grf(s), simply from the fact that the task of developing all the new cargoes including appropriate new industries etc would be too much work for one person but OTOH, splitting the workload between many people and integrating their work into one single application .grf wouldn´t work as well (people would like to have their own graphics incuded or would like to have variated implementations of cargoes and industries, there would be copyr**** issues, etc. pp.) we have to implement it independently and define a proper interface between the single "modules".

ATM, I don´t see any other possibility.

regards
Michael

[eis_os]

Well I haven't said all should be in one grf.

How I would arrange it:

ttdpcargo.grf

There we define what each cargo is and translation in all languages.
It would be nice to have a default sets of icons for them.

Means, a vehicle set author only needs to support ttdpcargo.grf
Regardless of industrie chains or something this simple works for the default cargos + the extended new ones

If someone doesn't like these cargos, they can overwrite them but if something fails, it's not "our" fault.

Town buildings will get overwritten so they will accept the "right" cargos.

Town sets should be compatible to the extended cargos but don't need to worry if industrie type a or be is installed. ( I guess we could defined some bit field to store what a town should accept. Patchman?
This can be switched on by the industry that are in the end of the chain and would deliver the stuff created to towns. [ONLY IDEA])

Stations know aswell how cargo should be displayed.

Industry Vectors
We defined new cargos before so for all Industry grfs we have the common cargo base.
And we have guaranteed that the end products will be accepted by Town Buildings.

That means with some agreements between all grf coders individiual vectors can be defined, sample we get chemicalpetrol.grf and fishbeerfood.grf

It's not a problem if chemicalpetrol.grf will be exchanged, fishbeerfood.grf will still work as it should.

Until now I haven't yet need any parameters, it's easy for a town set author to fullfill a working set,
aswell everyone can provide industries.
Maybe even there is someone who will provide some base industries that get later overwritten.

[George]

I think I have to write a big post about how I see it. I'll try to answer everyone about their worries. I’d also like to mention, that I’ve discussed some things with Csaboka and he said he’ll try to help.

Variants and Complexity

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?

We can draw anything on them. It can be the same schema, it can be different. Are there any reasons to disallow it?

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

Than how would we allow other sets to redefine parts of the schema? Making it as several GRFs allows to replace parts. If it is one big GRF will require to change it as soon as someone would like to change some part of it

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

That’s why it is supposed to be possible to switch the vectors on and off

Compatibility between saves of different players and old saves
For achieving the compatibility between saves from different players it is required for everyone to have all the appropriate GRFs (the latest ones) in his newgrfs.cfg (marked with ! if they are not used). The save stores the list of active GRFs and uses the required ones. Because of this reason, using parameters is not a good idea, because they are not stored in the GRF. The same is for scenarios, because they are saves and store GRFs list as well.
2PatchDevs: May be the saves format can be modified to store the GRF parameters too and report, when they are different or the GRF is missing?

Coding
Many GRF vs Single GRF
The first reason to split the file was the copyrights issue. But now the idea of splitting GRFs has one more reason – creating mods. It is impossible to deactivate the part of the GRF file, but if the schema is split into parts, parts can be deactivated with simple GRF deactivation. Making it with parameters would be much harder.
Compatibility with old cargos
This problem can be easily solved this way: one of the ECS GRFs is so called “main” GRF file (I used town vector for that). Every grf can test, if it is loaded or not. If not, it supports the default cargo. If yes, for each cargo ID it tests the possible ECS grfs, that can affect it (it can be the basic GRF or the mod) and defines CargoID with action 2 for it. The for action 3 it applies the defined CargoID. That means, that you need only as much tests as the possible sets for every cargo ID. There is no exponential growth, that DaleStan is afraid of, only a lineal growth, that is not much

If, for example, I choose not to load the chemicals GRF, then what do I do with sulfur?

It will not appear

Or will the basic GRF detect this and not define sulfur, nor define the power plant to produce sulfur?

It will define the plant not to produce sulphur. It works that way already. You can test it

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?

It is done that way already.

Well, then, I guess you'll have to demonstrate, because I am under the impression that setting availability

max 9 test for 9 grfs

refitability,

If you specify the refitability to non-existing cargo, that it simply not displayed. It is a would harder with mods, because they can specify the other type of cargo on the same slot (tank vs box van for example), but such situations would be rare. In this case the vehicles set should test only “conflicting” combinations of mods. But it would be RARE case

and default cargo

Again, only 9 test for 9 grfs

depending on the presence of one or more of *nine* different GRF files is non-trivial.

lineal amount of tests is 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.)

Have a look. It is only one test in basic grf. Yes, in this case we can have combinations, where some cargo is produced, but not accepted (glass if you enable only basic, chemical and town vectors) or vice versa (the case of sulphur and fertilizer). It can be also fixed with additional checks, but it is rather special cases that IMHO can be ignored now.

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.

It is possible to predefine the order of GRFs once and check it in the beginning, or make a pairs of checks in the GRF. I used the second way


Turning vectors on/off
As soon as Csaboka will implement required possibilities. Now the problem is that switching the GRF off makes the defaults, it overrides, to appear.

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

Loading a part of them will give you a part of ECS.

Used values

So, where *is* the cargo property info?

some is on the schema, some are in GRFs. I plan to make the whole table, but it is in progress.

Additional comments

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.

v334 only splits the buses. Only LVv1 was single file.

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

I’ve deleted it. I’ll fix it.

2 Patchman: why do check for var 42 for RVs works in alpha 60 and does not work in alpha 61 and 62?

[Patchman]

2 Patchman: why do check for var 42 for RVs works in alpha 60 and does not work in alpha 61 and 62?

Possibly because I've broken something. Please submit a proper bug report (but not in this thread.)

[DaleStan]

X-TomeSize: 2

splitting the workload between many people and integrating their work into one single application .grf wouldn´t work as well

And how is this project is different from the USSet? The PlaneSet? P:GS?
(And by that I mean: "Why is the development scheme that has been proven workable multiple times guaranteed to be useless this time?")

We can draw anything on them. It can be the same schema, it can be different. Are there any reasons to disallow it?

Disallow what? And you didn't answer my question. Why do we have to have the same scheme in all three standard climates? Why can't we have three or four completely different schemes, one for each of the original climates?

Than how would we allow other sets to redefine parts of the schema?

Quite easily. By having them appear later in the newgrf[w].cfg and overriding the ECS.

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

That’s why it is supposed to be possible to switch the vectors on and off

Which doesn't make things any less complicated for the user (in order to decide whether you want it on or off, you first have to understand it.)
And makes it *FAR* more complicated for the GRF coders.

It is impossible to deactivate the part of the GRF file,

but it is incredibly easy to *override* a GRF file.

Compatibility with old cargos
This problem can be easily solved this way: one of the ECS GRFs is so called “main” GRF file (I used town vector for that). Every grf can test, if it is loaded or not. If not, it supports the default cargo. If yes, for each cargo ID it tests the possible ECS grfs, that can affect it (it can be the basic GRF or the mod) and defines CargoID with action 2 for it. The for action 3 it applies the defined CargoID. That means, that you need only as much tests as the possible sets for every cargo ID. There is no exponential growth, that DaleStan is afraid of, only a lineal growth, that is not much

CODE IT!! Write code to DTRT (do the right thing) in all three climates, for all the different possible activation sets (2^NUM_ECS_GRFS), regardless of where the ECS GRFs appear.
I know you know how to write code, so you can't use that as an excuse.
And then show me the code, and convince me that:
1) it works, regardless of which ECS GRFs are loaded (and how they are loaded), and
2) it is not an absurd number of checks to be making.

Well, then, I guess you'll have to demonstrate [the triviality], because I am under the impression that setting availability

max 9 test for 9 grfs

...per vehicle. Whole different hill of beans there.

(Sulfur, for example, would require both the appropriate basic vector and the chemicals vector, and that's six checks[0] just for one cargo.)

Have a look. It is only one test in basic grf. Yes, in this case we can have combinations, where some cargo is produced, but not accepted or vice versa

And that will lead to masses of "Where do I find $CARGO?" and/or "Where do I take $CARGO?" posts. It might mess up the subsidy generator too.

Now the problem is that switching the GRF off makes the defaults, it overrides, to appear.

Which is why we *DON'T* *CHANGE* *THE* DEFAULTS*! Is this really that hard a concept?
We can still have the same bits in all three climates, but we cannot have the same slots in all three climates.

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.

v334 only splits the buses.

That's not my point. Unlike almost every other GRF in existence, I can't just extract the new version and have it work. I have to figure out which LVv3 GRF each LVv3¾ GRF replaces, and then fix my newgrfw.cfg to point to the LVv3¾ GRF, instead of the LVv3 GRF.

With the USSet, the DBSetXL, the PlaneSet, &c. I just extract the new GRF into my newgrf folder and, wonder of wonders, it magically *works*.
No futzing with newgrfw.cfg, no trying to figure out which GRFs replace which other GRFs, I just overwrite the old GRF with the same name, and go happily on my way, knowing that the only mistake I could possibly have made is that I put the GRF in the wrong folder.

The LVs problem will apply to the ECS if it ends up being 9 GRFs, instead of a sane 1 to 3.

[George]

We can draw anything on them. It can be the same schema, it can be different. Are there any reasons to disallow it?

Disallow what? And you didn't answer my question. Why do we have to have the same scheme in all three standard climates? Why can't we have three or four completely different schemes, one for each of the original climates?

The player can choose to have the same schema in all landscapes or to have different. He can apply any combination in any landscape. Why do we have to disallow it? For example, he can play tropical vectors in temperate.

Than how would we allow other sets to redefine parts of the schema?

Quite easily. By having them appear later in the newgrf[w].cfg and overriding the ECS.

That would be harder for the vehicles sets, because for them the ECS is loaded.

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

That’s why it is supposed to be possible to switch the vectors on and off

Which doesn't make things any less complicated for the user (in order to decide whether you want it on or off, you first have to understand it.)

And what do you suggest? If the player have new GRFs, he understands, that they can be switched on and off

And makes it *FAR* more complicated for the GRF coders.

Where? I've coded the ECS, the ECS support for LV and did not find it hard. What did I missed?

It is impossible to deactivate the part of the GRF file,

but it is incredibly easy to *override* a GRF file.

But much harder to test it later. For LVs I've added the check of all known RV GRFs for that. The case of LVs is easier. With GRM I can disallow overwriting of them. But what can we do with ECS, that would be supposed to be overwritten?

Compatibility with old cargosThis problem can be easily solved this way: one of the ECS GRFs is so called “main” GRF file (I used town vector for that). Every grf can test, if it is loaded or not. If not, it supports the default cargo. If yes, for each cargo ID it tests the possible ECS grfs, that can affect it (it can be the basic GRF or the mod) and defines CargoID with action 2 for it. The for action 3 it applies the defined CargoID. That means, that you need only as much tests as the possible sets for every cargo ID. There is no exponential growth, that DaleStan is afraid of, only a lineal growth, that is not much

CODE IT!!

For LVs and basic mods? I plan to do it this week.

Write code to DTRT (do the right thing) in all three climates, for all the different possible activation sets (2^NUM_ECS_GRFS), regardless of where the ECS GRFs appear.

it is not 2^NUM_ECS_GRFS. I was afraid about this in the beginning, but found a way to solve this problem.

I know you know how to write code, so you can't use that as an excuse.

Yes, I know, and I've also made some research, so, I'm sure about things I say unless I made a coding error somewhere in my tests

And then show me the code, and convince me that:
1) it works, regardless of which ECS GRFs are loaded (and how they are loaded), and
2) it is not an absurd number of checks to be making.

Ok. I will not require 512 tests

Well, then, I guess you'll have to demonstrate [the triviality], because I am under the impression that setting availability

max 9 test for 9 grfs

...per vehicle.

Yes. I code LVs taht way. You can already see this for buses. Is there the other ways even if ECS is realised as a group of orthogonal vectors?

(Sulfur, for example, would require both the appropriate basic vector and the chemicals vector, and that's six checks[0] just for one cargo.)

Have a look. It is only one test in basic grf. Yes, in this case we can have combinations, where some cargo is produced, but not accepted or vice versa

And that will lead to masses of "Where do I find $CARGO?" and/or "Where do I take $CARGO?" posts.

This can be fixed with lineal amount tests.

It might mess up the subsidy generator too.

How?

Now the problem is that switching the GRF off makes the defaults, it overrides, to appear.

Which is why we *DON'T* *CHANGE* *THE* DEFAULTS*! Is this really that hard a concept?

I've asked Csaboka for possibility to fix it. That concept is not always acceptable. When I define new LVs, I replace DEFAULT trucks. The same for new cargos. I do not like the concept to hardly define things, that can be made customisable.

We can still have the same bits in all three climates, but we cannot have the same slots in all three climates.

Any reason to keep it that way? I thought about that a lot and did not find a good reason to leave it this way.

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.

v334 only splits the buses.

That's not my point. Unlike almost every other GRF in existence, I can't just extract the new version and have it work. I have to figure out which LVv3 GRF each LVv3¾ GRF replaces, and then fix my newgrfw.cfg to point to the LVv3¾ GRF, instead of the LVv3 GRF.

The one with the same name except the first number. I do not believe it is hard for you.

With the USSet, the DBSetXL, the PlaneSet, &c. I just extract the new GRF into my newgrf folder and, wonder of wonders, it magically *works*.

The same is for updates for LVs. Changing the version of the LVs is a rare process, that it united with changing vehicles IDs. It happen about once a year. I do not believe it is hard to change 10 numbers in newgrf.cfg so often.

No futzing with newgrfw.cfg, no trying to figure out which GRFs replace which other GRFs, I just overwrite the old GRF with the same name, and go happily on my way, knowing that the only mistake I could possibly have made is that I put the GRF in the wrong folder.

You are mixing 2 cases - "small update" and "version update". For case of small update LVs are exactly the same other sets. And the case of "version update" was never applied to other sets. May be because they are not so old? In case of USset it is even not v1. The DBset passed through steps like tempset, dbset, dbsetxl. And you hade to change newgrf.cfg to support that!

The LVs problem will apply to the ECS if it ends up being 9 GRFs, instead of a sane 1 to 3.

Well, I plan to code all the LVs to support ECS this week. Then we'll have a look into GRFs. Ok?

PS. BTW, uniting ECS files into one can be done in 10 minutes. All the work is to remove the cross checks.

P.P.S. thank you for active participating in discussing the ECS

[michael blunck]

[mb:]splitting the workload between many people and integrating their work into one single application .grf wouldn´t work as well

And how is this project is different from the USSet? The PlaneSet? P:GS?
(And by that I mean: "Why is the development scheme that has been proven workable multiple times guaranteed to be useless this time?")

You´re mixing things (maybe due to excessively trimming quotes?). In the (trimmed) quote above I wasn´t talking about the process of implementing ECS itself but about the task of implementing all additional cargoes and all new industries.

And yes, that process would indeed be different from the making of the USSet, simply because it wouldn´t be an orchestrated undertaking by a certain leading person, a coder and lots of drawers but a real distributed process of many persons developing their own .grfs within the ECS framework.

regards
Michael

[Csaboka]

Turning vectors on/off
As soon as Csaboka will implement required possibilities. Now the problem is that switching the GRF off makes the defaults, it overrides, to appear.

I don't understand this one. First, the feature isn't designed to allow turning industries and cargoes on/off during gameplay. Second, what should it do instead? If a GRF is disabled, it can't modify anything, so the defaults stay. I can't see in what other way it should work.

[eis_os]

It seems like I get simple ignored

I guess my system is to open for everyone and won't be supported by George & Michael. The good thing is that everyone can do GRFs and support other grfs.

If there is a high demand to make a different system (the description is in my last post here), please contact me via pm, I guess I will write ttdpcargo.grf as I described in my last post as alternative way.

[michael blunck]

> It seems like I get simple ignored

No, Oskar, you are read and you would have been answered as well.

There are some questionable things in your proposal:

- to have a "definition" .grf is alright, but it has to allow for those "mods" George did mention,

- it needs some additional patch support. Would this be implemented?

- support for single "vectors" seems not to be as flexible as in George´s scheme.

Could you give some more detail on these items? (Ginge auch per mail)

> I will write ttdpcargo.grf as I described in my last post as alternative way.

That´s not needed because in principle that has been done already. Take a look onto George´s ECS development pages.

In any way, it would be good to have some more discussion to get the compatibility question settled before people are beginning to code different cargo implementations.

regards
Michael

[DaleStan]

[the number of different possible activation sets] is not 2^NUM_ECS_GRFS.

Convince me. My logic is that there are NUM_ECS_GRFS files, and each can be either on or off. This is makes two possible states for each GRF, and each GRF is independent of all others, therefore with one GRF there are 2 possible states; with two, four states; with three, eight states; ... with NUM_ECS_GRFS, 2^NUM_ECS_GRFS states. It may be there's a hole in my logic somewhere, but I guess I'm not seeing it.

Arbitrary assertions do little to convince me of their truth or falsehood; if I object or make a contrary claim, just telling me that I'm wrong isn't going to do much; you have to prove to me that I'm wrong.

I know you know how to write code, so you can't use that as an excuse.

Yes, I know, and I've also made some research, so, I'm sure about things I say unless I made a coding error somewhere in my tests.

I'd really appreciate it if you'd share these insights with the rest of us GRF coders. Either they work as you say they do, and most of my arguments just collapse for lack of support, or they don't, and at least a few of your arguments collapse. In either case, we spend a lot less time arguing, which would be a Good Thing, at least as far as I'm concerned.


On testing for the presence of the ECS GRF(s):
If the vectors are orthogonal, then many fewer tests will be required:

Code: Select all

set_props //as if no ECS_GRFS are loaded
foreach grf in ECS_GRFS{
 if(grf.IsLoaded()||grf.WillBeLoaded()){
  set_props // enable vehicles that only apply if this grf is loaded
  set_props // change default cargos, if necessary
 }
}

Average case, this is O(NUM_ECS_GRFS) (linear on number of ECS GRFs). Worst-case, this is O(NUM_ECS_GRFS^2) (proportional to the square of NUM_ECS_GRFS), and that only in rather pathological cases: One vehicle that defaults to $CARGO1 if $ECS_GRF1 is loaded, else $CARGO2 if $ECS_GRF2 is loaded, else ... and another that defaults to $CARGO4 if $ECS_GRF4 is loaded, else $CARGO3 if $ECS_GRF3 is loaded, else ...
Or, you can just put the whole ECS in one GRF, and then the above code degenerates to:

Code: Select all

set_props //as if ECS_GRF is not loaded
if(ECS_GRF.IsLoaded()||ECS_GRF.WillBeLoaded()){
 set_props // enable vehicles that only apply if ECS_GRF is loaded
 set_props // change default cargos, if necessary
}

Which is O(1). (constant number of tests.)
If the ECS_GRFS are interconnected, then the best course of action is (AFAICT) to test each vehicle separately, with an average case num_tests of about O(NUM_VEHICLES*NUM_ECS_GRFS). (Worst case, is, I believe, O(NUM_VEHICLES*((2^NUM_ECS_GRFS)^2)). Whether that's achievable or not is a different matter.)

[The problem where some cargos are produced, but not accepted or vice versa] can be fixed with lineal amount tests.

Linear on what?
1 (that is, constant)? NUM_ECS_GRFS? NUM_CARGOS? NUM_ECS_GRFS*NUM_CARGOS?

It might mess up the subsidy generator too.

How?

Well, I was thinking that if the generator tried to generate a subsidy on a cargo that could not be delivered, it might either crash or produce a bogus subsidy, but now that I think about it, I know I've seen scenarios that would trigger this bug, if it existed, and they don't. So scratch that.


On not changing the slots of the default cargos:

I do not like the concept to hardly define things, that can be made customisable.

So why didn't you change passengers, mail, &c.? (You're contradicting yourself here. Either admit that defaults can be a good thing, or use none of TTD's original cargos.)

We can still have the same bits in all three climates, but we cannot have the same slots in all three climates.

Any reason to keep it that way?

Because changing the slots for the default cargos will break things so fast the it'll break the law of causality[0] too.

[0] Grr... either I'm misremembering here, or google is being uncharacteristically useless. The text I'm remembering for that law is (basically) "the cause must happen before the effect".

The one with the same name except the first number. I do not believe it is hard for you. I do not believe it is hard to change 10 numbers in newgrf.cfg so often.

There's a difference between "hard" and "TMWFTLB". Note the absence of the word "hard" anywhere in the acronym. It's work. It's work that I don't feel like doing. That which is genuinely hard doesn't usually take me to long; it's that which is simple but tedious that never gets done.

With the USSet, the DBSetXL, the PlaneSet, &c. I just extract the new GRF into my newgrf folder and, wonder of wonders, it magically *works*.

The same is for updates for LVs.

...except that I have to track ten files, instead of one.

Now, if you took the TTRS path, and released one GRF (LVv1.GRF => LVv2.GRF => LVv3.GRF => LVv4.GRF ...) then a lot of the tedium would vanish, and I'd upgrade a whole lot quicker. But I've complained about this before, to no obvious effect.

The DBset passed through steps like tempset, dbset, dbsetxl. And you hade to change newgrf.cfg to support that!

Actually, I don't believe I did. IIRC, I discovered TTDPatch (or, at least newgrf) after DBSetXL was released. The LVs, OTOH, have been version-upgraded twice (2 => 3 and 3 => 3¾) in that same time period. And even if I did have to change newgrfw.cfg, I had to add one file, not $LARGENUM $LONGNAME files. (The longer the filename, the less likely I am to feel like adding it to newgrfw.cfg. There's a reason I chose "ArcticOrew.grf" and not "ArcticIronOreAndSteelIndustriesw.grf")

I wasn´t talking about the process of implementing ECS itself but about the task of implementing all additional cargoes and all new industries.

And yes, that process would indeed be different from the making of the USSet, simply because it wouldn´t be an orchestrated undertaking by a certain leading person, a coder and lots of drawers but a real distributed process of many persons developing their own .grfs within the ECS framework.

Erm. Something is severely wrong here. I realize it's probably my brain, but that doesn't change the fact that something is *wrong*.

It seems to me like you just said that there may (will?) be multiple implementations of each vector? If so, why are the GRFids fixed?[1] And if not, what did you really say?

[1] I'm sure I don't have to point out to you that having multiple GRFs with the same ID will break things royally.


On Oskar's proposal:

- to have a "definition" .grf is alright, but it has to allow for those "mods" George did mention,

The point of the ECS is to allow the one-size-fits-all GRFs (eg LVs, PlaneSet, NewShips) to properly handle newcargos, right? Making the ECS easily mod-able promotes this end exactly how?

- it needs some additional patch support. Would this be implemented?

What additional patch support? I would have guessed any GRF that a patchdev offers to write would be highly likely to work with the current patch.

[eis_os]

Hello Michael

I guess you wouldn't have answered if I didn't say it's possible to create an alternative grf set.

> - to have a "definition" .grf is alright, but it has to allow for those "mods" George did mention,

>- it needs some additional patch support. Would this be implemented?

In general it's already there: Action D Writable variables (global)
A new variable for setting bits of cargo slots used by industries could be added I think.

The is no formal design, a text file or something where you really show how it works. How should overwriteing work as you mention? The dev page has only a lot grfs...

> support for single "vectors" seems not to be as flexible as in George´s scheme.
Hmm, you can provide a vector file, what is the problem? What do you mean with single vectors? It's no problem to put a complete chain say for wood goods in one grf. But the difference in my design is that a town set or a station set doesn't really need to know what industries are enabled.

Stations:
Check ttdpcargo.grf there? -> Support the common set of cargos

Townbuildings:
Check ttdpcargo.grf there? -> Check via Action D standard cargos a town buildings need to really accept... (because there is an industry grf loaded)


>That´s not needed because in principle that has been done already. Take a look onto George´s ECS development pages.

Well on the page there is no really description of how ecs should work,
what the "mods" by George mean.

Sample for my system:

ttdpcargo.grf defines for every climate the TTDPatch default cargos

Stations (grf id can be anything):
Check ttdpcargo.grf there? -> Support the common set of cargos

Industry set (Agricultural) (grf id can be anything)
Check ttdpcargo.grf there? -> Can be loaded, ok, sets bit via Action D for Food, fruits and so on

Townbuildings (grf id can be anything):
Check ttdpcargo.grf there? -> Check via Action D standard cargos a town buildings need to really accept... (because there is an industry grf loaded, it has enabled food, food now needs now be supported)


Your design on the other hand has for each chain a fixed grfid. (so other sets can check them). How you now let others create new industries?

Please don't say they use the same GRFID, this is forbidden!

[michael blunck]

We can still have the same bits in all three climates, but we cannot have the same slots in all three climates.

Any reason to keep it that way?

Because changing the slots for the default cargos will break things [...]

Noone wants to change cargo slot IDs like "passengers", "mail" etc. because there´s no reason to do this. IMO, there are only a few cargo-IDs which would be affected, namely

- 01 coal (rubber in tropic)
- 04 livestock (fruit in tropic)
- 08 iron ore (copper ore in tropic)
- 09 steel (paper in arctic, water in tropic)
- 0B paper* (food in arctic and tropic)

* introduced by "moreindustriesperclimate".

There's a difference between "hard" and "TMWFTLB".

On a different note: could you please refrain from over-abbreviation? I noticed you seem to like it but there are many non-native English speakers on the forums that may never have seen such acts. Thank you.

[implementation of ECS != implementation of specific .grfs]

It seems to me like you just said that there may (will?) be multiple implementations of each vector? If so, why are the GRFids fixed?

O/c there will be no double .grf IDs.

What additional patch support? I would have guessed any GRF that a patchdev offers to write would be highly likely to work with the current patch.

Town sets should be compatible to the extended cargos but don't need to worry if industrie type a or be is installed. ( I guess we could defined some bit field to store what a town should accept. Patchman?

regards
Michael

[eis_os]

Michael please read again my last post.

But you didn't really my answered my question, what if say I want to create new industries for chemical stuff, then each GRF has to be changed to check if my new one is active to support chemical stuff. How is that easy to change?

Sure you and George simple can change their grfs with the grfid to add new stuff, change stuff for chemicals, but you said it should be designed for all authors. Or I am wrong?

My system doesn't need to work with the current TTDPatch, to allow fish grounds TTDPatch had to be altered aswell... Michael, thats a very bad argument.

But Action D is already written and we need to add a new variable so it works. If Towns don't need food to grow, you don't even need the bit system ...

-edit-
I don't want to be rude and excuse if something was not good verbalized.
And sure, I do mistake, I haven't written new cargos but I do want that other grf authors are able to create industries. And that isn't a hell to find bugs.

[michael blunck]

My system doesn't need to work with the current TTDPatch, to allow fish grounds TTDPatch had to be altered aswell... Michael, thats a very bad argument.

Mmh, sorry?

>- it needs some additional patch support. Would this be implemented?

In general it's already there: Action D Writable variables (global)
A new variable for setting bits of cargo slots used by industries could be added I think.

if this would work then it´d be OK, o/c.

From all the previous posts, it should be clear what the implementation should be able to do in the first place, namely to allow people to "switch off", resp. to "override" parts of the "general" scheme.

regards
Micchael

[eis_os]

I only see the mixture of things sorry.

If I disable a default industry vector as you say, example Agricultural as I see on the list, all grfs will see the grf disabled and stop working to say accept food because 4D656F97 isn't active anymore.

Sorry, as you maybe have seen with my post I simple don't understand it. I have tried to back read some posts but for me it isn't clear how you want to get it working... sorry...

a) you enable the grf and have a complete industry vector
b) you disable the grf the information is lost
c) you have a new grf by a different author that isn't recognized by other grfs, because each grf has to check the presence of the other grfs.

-edit-
To go back to industries you say, you don't want to have one grf to cover all (there I agree) on the opposite you have 9 grfs covering all where there is no valid way to add own/new industries or industry vectors
because other grfs have to check if these are enabled to know if a cargo support should be offered.

[George]

Turning vectors on/off
As soon as Csaboka will implement required possibilities. Now the problem is that switching the GRF off makes the defaults, it overrides, to appear.

I don't understand this one. First, the feature isn't designed to allow turning industries and cargoes on/off during gameplay.

When creating a new game or scenario. The list of grfs is defined with grfs files list panel from the title screen

Second, what should it do instead? If a GRF is disabled, it can't modify anything, so the defaults stay. I can't see in what other way it should work.

It should work as AI manager for RVS. Firts file (it is tested with all the files) removes all the default vehicles (sets prop 06 to incorrect landscape value) and then all the other sets add new ones. It prevents a mess of a default and new vehilces. The same is requred for ECS. The main ECS file removes all the cargos and industries and the other files add new ones. That should prevent apearing of default and new cargos at the same time. I thought I described it clean in the e-mail

[Patchman]

OK, I think too much discussion in this thread has been focussed on the problems associated with the proposed scheme(s), rather than their solution.

It seems to me that the main problem discussed so far is that each slot and each bit can have different cargo types associated with it depending on which grfs are loaded. Then the vehicle sets, the town sets and possibly industry sets get very complicated to code because they need to check all possibilities, in principle even possibilities that don't exist yet.

Wouldn't it be a good idea, then, to define something like globally unique cargo type identifiers?

Then a vehicle/town/industry set could say, "when I check cargo slot/bit X I mean global cargo ID Y". This would involve the translation of cargo slots/bits in the relevant actions but that shouldn't be too hard. If a global cargo ID isn't defined, it will be ignored. I could also add a check to action 7 for whether a global ID is or is not defined. It might be useful to have an additional pass over all grf data, to activate all cargo grfs first, and then the regular pass to process everything else.

I think all this shouldn't be too hard to implement, and I believe that it would eliminate most, if not all, of the problems discussed so far, wouldn't it?

[Hyronymus]

Excuse my ignorance but wouldn't Patchman's suggestion be smart indeed? It would solve many problems by simply centralising the cargo definitions.

At the risk of saying something for the 2nd time or something silly but what if the ttdpcargo.grf (as Oskar called it) checks for climate too? You can then add more Action 7's, which skip the climate-irrelevant cargo defintions. I don't know how many cargo slots are free but with this solution you're not necessarily tied to a climate.

Now onto future sets: imagine the Dutch Trainset wants different cargo types than defined in ttdpcargo.grf. How difficult would it be for the Dutch Trainset people to add a ttdpcargoDT.grf i.e., a grf that automaticly unloads ttdpcargo.grf.

[michael blunck]

> Wouldn't it be a good idea, then, to define something like globally unique cargo type identifiers?

Yes, of course.

> I think all this shouldn't be too hard to implement, and I believe that it would eliminate most, if not all, of the problems discussed so far, wouldn't it?

Most of the ado in this thread has been spawned because before no patch dev made a statement about a possible implementation of auxiliary features. That´s why we had to try to implement it without any new patch features.

regards
Michael