Breaking changes to cargo?

[peter1138]

Back in the mists of time, TTDPatch had already gone through various compatibility stages, using IDs, introducing "bitnum" for some semblance of compatibility, and finally settling on 4-character labels.

All this was before OpenTTD gained support for NewGRF defined cargo types in 2007, yet we attempted to support bare IDs, bitnums and cargo labels.

There are currently very few NewGRFs that implement cargo types that don't use labels, and those that do do not really work very well these days. They didn't work very well back then either, which is why labels were created.

Since OpenTTD 14.0, we've moved to defining built-in data with cargo labels instead of bare IDs. This had a few hiccups but mostly works pretty well, and some of the undocumented restrictions placed on cargo sets become lifted. There is (at least) one remaining niggle which is that some older sets don't install a cargo translation table and assume the default cargo types (and positions). These can end up with incorrect cargo types being used.

My proposal to fix this issue is forget about about cargo slot positions, and always install a default cargo translation table. This default table matches the original cargo types, but does it by label instead of slot, which means that if cargo types are moved or removed, the set still behaves correctly. This is implemented in https://github.com/OpenTTD/OpenTTD/pull/12646.

For sets that define a cargo translation table, there is no change. Any set that has any business with cargo types (including setting cargo types of vehicles) should be setting up cargo translation table these days.

So the potential breaking change here is that some very old sets that DO intend to use different cargo types, but pre-date cargo labels, and that probably don't work very well already, will end up not working any more.

I'm not sure what the scope of breakage is, but things like Michael Blunck's NewCargo Set, and Cargo set are notable, as they are from the 2003-2005 era predating labels.

[kamnet]

This seems like a minor enough issue that if anybody doesn't like the breakage, they can re-code the set. And the worst case scenario is to decompile a GRF and start hacking at the NFO. A not pleasant, but not unimpossible task.

[Eddi]

if anybody doesn't like the breakage, they can re-code the set.

uhm, i think this argument is invalid. if a recode hasn't happened in the last 20 years, what makes you think there's any likelyhood a recode is happening now?

in the past, we made some shims to make specific sets continue to work, an example coming to mind is when we separated ID ranges for vehicle sets, we added specific rules to make sure old known "addon" sets that relied on modifying other GRFs IDs continued to work. not entirely sure if that's a good idea here.

[peter1138]

If we extend GRF overrides (which currently only affect vehicles) to include translation tables, then creating 'shim' NewGRFs would be possible. Not ideal, but possible.

[kamnet]

uhm, i think this argument is invalid. if a recode hasn't happened in the last 20 years, what makes you think there's any likelyhood a recode is happening now?

Very low. Just as low as anybody still actively using those files, which are probably only found here on tt-forums, buried in the 1.2 million posts.

If developers want to spend the time to make sure that no NewGRF gets let behind, that's fine. But I won't cry if they also decide to leave old stuff in the past.

[Eddi]

If we extend GRF overrides (which currently only affect vehicles) to include translation tables, then creating 'shim' NewGRFs would be possible. Not ideal, but possible.

that might be useful, because there exist things like DBSet cargo addons, that were *intended* to add a CTT, but afair that never actually worked this way.

[peter1138]

I think at the moment if you want to override the cargo types of an existing NewGRF you need to install a cargo translation table and then modify the cargo properties of everything within the NewGRF.

So perhaps as a separate change we could make the cargo translation table also be installed into the overridden NewGRF so that the file's own cargo properties then use the table.