The cargo compatibility table

[PikkaBird]

Hi all,

I am attempting to put together a table of all compatible/non-compatible cargo GRFs and schemes available for TTDP.

Can anyone who has made a cargo scheme and/or grf please post the details in this thread, so I can add them to the list? I'm not sure of the status of, for example, MB's newcargo.grf.

[michael blunck]

> I'm not sure of the status of, for example, MB's newcargo.grf.

NewCargo will be re-implemented according to ECS.

Speaking of "new cargoes", could you please remove GEAR ("specially used for livery refit tricks rather than actual cargos") from the Wiki cargo list because it has nothing to do with a real cargo and will only cause confusion?

We have other means for "tricks", e.g. a user-defined bitmask (action0, prop25).

regards
Michael

[PikkaBird]

I fail to see how it will cause confusion. The only people who will be reading that information are people coding grf sets, and I should think they'll have the intelligence to recognise it for what it is - a cargo label which has been defined, and which they can ignore.

I'm not particularly bothered and I'll quite happily remove it, although it means I'll be using a cargo label (and, if you want me to remove the reservation of bit 15 of cargo class, a cargo class bit) that isn't documented on the wiki, and I imagine that has much more capacity to cause problems in the future.

[michael blunck]

> I fail to see how it will cause confusion. [...]

Already by definition. We have vehicles and sub-classes for vehicles, we have stations, buildings, industries and cargoes. Messing things up between those well-defined classes makes no sense at all, even if myself and some other .grf developers would well be able to recognize your new cargo as being not a cargo.

Second point is that IMO there´s no need to introduce the concept of a "pseudo cargo" just for "livery refit tricks" because there are established features which have been especially developed (user-defined bits ... ("user" == .grf author)) to allow all sorts of "tricks".

In that way the required information would be "private" to the .grf in question whereas your "pseudo cargo" won´t be, needs further support (a new cargo class) and could generate even more incompatibilities between cargo/industry .grfs.

regards
Michael

[PikkaBird]

IMO there´s no need to introduce the concept of a "pseudo cargo" just for "livery refit tricks" because there are established features which have been especially developed (user-defined bits ... ("user" == .grf author)) to allow all sorts of "tricks".

Yes, but as you have noted yourself on many occasions, you can't refit a vehicle that doesn't carry a cargo. If you want to lobby a patch coder to change that, be my guest.

[michael blunck]

> [...] you can't refit a vehicle that doesn't carry a cargo.

True. At least not explicitly.

> If you want to lobby a patch coder to change that, be my guest.

AFAIR that has been discussed a couple of times.

OTOH, it´s possible (and I do it myself in many places by using said prop25) to implicitly change the livery of a locomotive, and until now, I didn´t encounter a case where this method didn´t work.

I don´t know of your exact needs but if it´d work using prop25 (or by a new patch feature ...) this would be the way to go. Other than that, more "pseudo cargoes" and "pseudo cargo classes" would emerge over time which would be a bad thing.

regards
Michael

[DaleStan]

I understand where multiple "This is not a cargo" cargoes could be useful, but I fail to see how more than one "This is not a cargo" class can possibly be useful. Can you expound, please?

[PikkaBird]

I don´t know of your exact needs but if it´d work using prop25 (or by a new patch feature ...) this would be the way to go.

Well, certainly, if I could do what I wanted to do more tidily, I would. OTOH I'm not too worried about grf set compatibilities; the set will be incompatible with ECS, but then so is just about everything else I make.

Indeed, that is the point of this thread and the compatibility table; it will list all sets which use cargos, so that end-users can work out which are compatible, and grf authors can work out which cargo slots they need to use or avoid if they want to be compatible with a particular set.

Other than that, more "pseudo cargoes" and "pseudo cargo classes" would emerge over time which would be a bad thing.

Especially if I didn't document those already created on the wiki, hmm?

[George]

I don´t know of your exact needs but if it´d work using prop25 (or by a new patch feature ...) this would be the way to go.

Well, certainly, if I could do what I wanted to do more tidily, I would. OTOH I'm not too worried about grf set compatibilities; the set will be incompatible with ECS, but then so is just about everything else I make.

I'd like to ask all the coders.
Who is ready to represent a set with 37 new industries at once? I suppose it is fast impossible. Then why don't we split the work between us and make parts of the whole set, that covers all the 37 industries and 32 cargoes. These parts can be made so that they are able to be switched. Have a look at ECSConst and ECSCPikk. I hope it can demonstrate the profits of these idea.
So, once again, I ask all the GRF authors, who make industries, could we first make one FULL set of industries and only after that to start separate projects? Do not say about my ECS vectors as a full set, it is only a demonstration. Only 2 vectors are more that halve done and it will take a lot of time to make the others.
ONCE AGAIN I ASK, PLEASE, let us do one full set first

P.S. I'm open for any suggestions for changing my sets. Fell free to write how do you see the full set. Please let me know.

[Csaboka]

Why do you think that you need 37 industry types for a full set? If TTDPatch supported 128 industry types, would you work on a full set that has 128 industry types? UKRSI (for example) is a full set, you can transport every cargo to some industry, it's balanced and works well. It has a compatible train set too, so it isn't a problem if other train sets don't fully support it. I appreciate your work on ECS, but I don't think everyone must go the ECS way. If PikkaBird wants to have his own cargo chains and industy types instead of working in a grand scheme, he has every right to do that. If it means I cannot mix and match UKRSI with ECS implementations, I can live with that, and I guess most of the players will think the same.

[wallyweb]

With all due respect to all, I do not see the problem.
1. PikkaBird's table is an excellent idea. As a player, it will give me an excellent idea as to which industry set would be most appropriate for a particular scenario.
2. The Serbian Set is an excellent example of multi industry set support. It is compatible with either ECS or UKRSI ... just not both at once.
3. I believe other rail sets will be similarly compatible, either implicitly or via switches.
4. If an author decides to stray from the ECS implementation, that is fine as long as he/she keeps in mind that ttdx is a total transportation experience with not only rail but buses, trucks, airplanes and ships as well. If the author wishes to make his/her implementation generally available as opposed to for his/her own personal use, the author should ensure that ALL forms of transport are available and fully support the author's industry implementation. For example, it is not up to Michael Blunck to make his ship set UKRSI compatible, but it is up to PikkaBird to ensure that a UKRSI supporting ship set is available to his implementation.
5. If an author decides to produce a stand alone transport set (rail, bus, truck, airplane or ship) for general release, then that author should make sure that ALL industry implementations are supported, but this is definitely at the author's discretion. We players can only hope and pray.
6. As I understand it, the purpose of ECS was to provide a common platform to facilitate compatibility. Unfortunately, from where I sit watching all these discussions, it seems to fail in one area ... flexibility. It appears to dictate as opposed to facilitate. Perhaps this is a misconception on my part, in which case the documentation should be more explicit.
7. George, with all due respect, I like your ECS implementation, but I do not think that it should mandate that other sets fit its structure. It is good to know that you are willing to allow other authors plug into your vector structures, but these other authors must be allowed to follow their own paths if they chose not to support your vectors or even ECS for that matter.
8. A general note to all authors ... I am a player ... I am your customer ... I would like to use your product ... please make it easy for me to do so.

[michael blunck]

Who is ready to represent a set with 37 new industries at once? I suppose it is fast impossible. [...]

Why do you think that you need 37 industry types for a full set? If TTDPatch supported 128 industry types, would you work on a full set that has 128 industry types?

He didn´t say that. He asked who of the .grf authors would be prepared to present a "full set" (of 37 cargoes and appropriate industries).

>> I suppose it is fast impossible.

(You have to translate George´s notorious use of "fast" into "almost", BTW)

[...]I appreciate your work on ECS, but I don't think everyone must go the ECS way.

O/c not (I had oat flakes with milk and some cups of a good Darjeeling tea (FTGFOP) instead of toast and coffee for breakfast). OTOH, we already had that discussion in an exhaustive way before (with participation of krtaylor) and the result was that it would absolutely make sense to strive for maximum compatibility between foreign sets. And exactly that was the point George was addressing concerning UKRS a couple of days ago.

If PikkaBird wants to have his own cargo chains and industy types instead of working in a grand scheme, he has every right to do that. If it means I cannot mix and match UKRSI with ECS implementations, I can live with that, and I guess most of the players will think the same.

Apart from the "right" to be incompatible with whatever he wants, the question is not if you can live with it: the real problem is that it causes numerous issues and questions of people being not proficient with the intricacies of setting-up games like you and me. E.g., take a look into the german forums and notice how many people are trying (in a very silly way) to mix each and every set they´re able to find on the net. And yes, this does include ECS and UKRS compatibility problems to a considerable degree.

One of the main objects of TTDPatch (in comparison to OTTD?) has always been to allow the highest degree of flexibility in terms of using combinations of patch features and combinations of .grfs.

O/c, we could change that if ever we want to. With the neat effect that I could work on my own interesting but incompatible ideas w/o waisting further time in the usual "compatibility discussion". Vamos.

regards
Michael

[PikkaBird]

My current feeling on ECS/UKRSI compatibility is that it's just not going to happen. The ECS scheme is just far too different from the way I wish to use newcargos.

However, I do think that the incompatibility should be as transparent and non-issue-causing to the end-user as possible. The problem is not incompatibility; the problem is badly managed incompatibility. This seems to be much what Michael is saying.

The next version of the UKRSI will use GRM to check and reserve the cargo IDs it defines. Hopefully, all ECS implementations can do the same thing?

[George]

The next version of the UKRSI will use GRM to check and reserve the cargo IDs it defines. Hopefully, all ECS implementations can do the same thing?

It is in the to-do list, but there is a problem, that I found while coding the LV4. With GRM it is impossible to remove default object from slot, but to allow filling it with the other set. I had to remove all the default RVs from the game to allow correct locations of Trucks and Buses, but to allow tram slots be used by other GRFs. Now it is impossible. That's why I use GRM in LV4 only for some slots, while other slots are overwritten without GRM. That make a problem, that a tram set should know about this behaviour of the LV4 to support it correctly (the GRM tests do not work correctly because LV4 does not support it correctly on tram slots).
The same problem we have in ECS. ECS vectors disable default cargoes and industries, but do not fill all the disabled slots. Using the GRM correctly is impossible now (Please point me out if I mistaken)
Hope GRM could be expanded with new features, that could allow to use slots for deleting in some other way than for providing a new object, so the one GRF could disable the default object on the slot, but allow some other GRF to provide a new object on this slot.

[PikkaBird]

Well, you don't have to reserve every slot you modify. Just reserve the ones which, if another set tried to use them, would cause problems.

[michael blunck]

Well, certainly, if I could do what I wanted to do more tidily, I would. [...]

Just a wild guess: you want to allow the player to change liveries of engines carrying no cargo? If yes, this should be (granted: in a slightly limited way) doable even w/o introducing that weird construct of "no-cargo cargoes".

> OTOH I'm not too worried about grf set compatibilities; the set will be incompatible with ECS, but then so is just about everything else I make.

This has nothing to do with your sets being incompatible or not, the point is that we shouldn´t introduce messy definitions and constructs as a crutch for ill-implemented .grf sets.

>>Other than that, more "pseudo cargoes" and "pseudo cargo classes" would emerge over time which would be a bad thing.

>Especially if I didn't document those already created on the wiki, hmm?

No, on the contrary: I´d welcome it. If being "private" to your .grfs who´d care how you achieved its special functionality? Time will tell if any resulting incompatibilities of your .grfs will turn out as a real obstacle for the player.

What I want is to get rid of those weird "cargo definitions" in the Wiki.

regards
Michael