Extended Cargo Scheme (ECS) discussion

[Patchman]

Should default cargos have these identifiers or should the GRF specify them?

The patch defines names for them, of course.

Are they what the MB's page says?

I can make them whatever you want. The ones on that page will work, so I'll use them.

Seems like it is not clean to me now. Let me describe how it should look like and let you say, is it possible and how hard to do it this way or may be it is possible already. Let us considerate that GRF has only one vehicle.
1) the vehicle GRF file have graphics for cargos "GRAN" "CELR" "WHET" "MAIZ" "COAL" "IRNO" "CPRO" "PTSH" "LMST" "SAND" "FRTL" "SLFR". It is a dump truck. Some graphics are the same ("GRAN" "CELR" "WHET" "MAIZ")

Grain, Wheat and Maize will all have the same identifier.

Not a good solution. For example, valuables, gold and diamonds should have different transportations costs, weights and in my sets armoured trucks have different capacities for them. Tropic wood is a different cargo than wood in temperate. I think they should have different identifiers, but may have same graphics.

OK, that's easy enough to change. It only affects how the default cargos are labelled. Just give me a list of all cargo types in TTD and what their labels should be.

2) the vehicle GRF file checks, are they accessible and loads required graphics
3) the vehicle GRF file specifies the ID and characteristics of the vehicle. The default cargo and capacity is not specified here. The capacity should be specified in the refit call-back.
4) the vehicle GRF file specifies the list of this supported cargos (4 letters ones). The first defined cargo from this list is default cargo.
5) the refit list is calculated from the list of supported cargos

Is that how you want it to work, or how you think it works?

This is the way I think that would be the easiest to code vehicles (If I understood it right). I mean the vehicle coder should not know anything about refit list or default cargos or bits where they are located. He should only specify the list of supported cargos.

That's basically how it works. The refit list will still be made up from three parts: (1) allowed cargo classes, (2) forbidden cargo classes and (3) the explicit refit mask.

Yes. And vehicle GRF has not to know it. It should know only the list of global identifiers. And it should support the on that level. for example, if the vehicle supports "WATR", it should support it regardless of the slot, used to put it there. Even if it is on slot 9, 1 or anything other (that cargo GRFs define), it should represent the same graphics for it because it is water.

And that's exactly how it works.

Bit 1 in the refit mask is whatever cargo you defined as second slot in the translation table, i.e. in my example bit 1 would refer to petrol.

That way allows the GRF to support only 32 cargos in general.

No. You can support all possible cargos using the cargo classes still. You are only limited to 32 cargos which need exceptions in the refit list. Out of the 253 possible cargo types you can list in the translation table, 221 must be accessible through cargo class-based refit, and 32 can have exceptions to that.

You can have

• unlimited cargos available for refitting, through cargo class based refit
• unlimited cargos with generic (non-specific) graphics based on, for example, their cargo class
• different graphics for up to 253 different cargo types of your choice, specified through the translation table
• exceptions to the refit list for 32 different cargo types of your choice, specified through the first 32 entries of the translation table
• generic refit capacities for all cargo types based on their cargo class
• different refit capacities for the 253 cargo types in the translation list

All of that is per grf file. Each grf file can have its own translation table, so if you split the grf file in two, the numbers double in principle (if there's no overlap in the cargos).

For example, slot 1 is coal if coal is defined, water if coal is not defined, rubber if not coal nor water are defined and so on. That would be hard to code I think.

I don't see why you think you need this. This does not affect the "real" cargo slots, these are still determined by the cargo grfs. My proposal only concerns how vehicles and stations decide the graphics to display and refittability.

For graphics, you can support 253 different cargo types, of which those that aren't active will be ignored. For refitting, you can also support 253 different cargo types, but 221 must be set via cargo classes, and 32 can be set or removed from the cargo class selection.

There's no need to know or care which cargo is in the "real" cargo bit or slot 1.

That could lead to a problem with lunching saves on the other PCs, where some global cargo identifiers are missing

There will be no problem unless there are vehicles refitted to cargos which have changed (or don't exist now), but then they'll just use the new type instead. That cannot be changed.

But how can I specify, that the second slot is coal if the coal is specified, water if not, rubber if not neither coal nor water? Have a look:

Again, you seem to be talking about real cargo bits, which simply don't matter here. The very idea of this translation table is that each vehicle grf can define its own idea of which IDs a certain cargo should use, no matter what its real cargo slot and bit are.

As you can see, different schemas can specify different slots for one cargo, and different combinations are possible. It would be rather hard to search for all the possible locations of one cargo for the vehicle.

You don't need to. That's what the translation table does for you.

[krtaylor]

So, it sounds like we could make it so the Japanset had "rice" instead of "Maize", but all the usual RVs and ships that carry grain-stuff would work fine with the rice. An excellent method, I think, in principle.

[Hyronymus]

That sounds workable indeed. A problem might arise when a RV-set doesn't support the Japanese trainset though. Or will there be a solution to make RV's show rice in their loading stage even though their graphics haven't been changed? I don't think that's possible, right? Or am I thinking in the wrong direction?

[krtaylor]

My understanding of how this would work, is that in the Japanset, "rice" would be encoded using the standard flag for "grain". So when you used, say, the ships, they would know that the cargo "rice" was really just "grain" from their point of view. And you could refit them to rice, even though they were never designed to handle it. Of course, the graphics would show the stuff in the ship as yellow, not white, because that's the way they were originally drawn, but the gameplay wouldn't suffer.

[Hyronymus]

I kind of figured the gameplay wouldn't suffer but the graphics would (as far as you can state that). This almost forces you to include sprites of loading stages for RV's and ships too . You can predict people will complain about graphical glitches otherwise.

[krtaylor]

Well, that is true, that someone might complain "Why is the rice in my cargo vessel yellow?" But it's better than "Why can't I carry rice in my cargo vessel?" isn't it?

[George]

...

It looks like I'm very stupid now, but I can't understand. Lets have an example. My vehicle supports 40 cargos

Code: Select all

Coal	COAL
Water	WATR
Rubber	RUBB
Mail	MAIL
Oil	OIL
Livestock	LVST
Goods	GOOD 5
Cereals	CERE 1
Grain	GRAN 1
Wheat	WHET 1
Maize	MAIZ 1
Wood	WOOD 2
Tropic wood WODT 2
Iron ore	IORE
Copper ore	CORE
Steel	STEL
Plastic	PLAS
Valuables	VALU
Gold	GOLD 3
Diamonds	DIAM 3
Paper	PAPR
Food	FOOD 4
Fruit	FRUT 4
Fish	FISH 4
Wool	WOOL
Potash	POTA
Sand	SAND
Glass	GLAS
Wood products	WDPR
Dyes	DYES 5
Fertiliser	FERT
Oil seeds	OLSD
Refined products	RFPR
Vehicles	VEHI
Petrol	PETR
Bricks	BRCK
Sulphur	SULP
Cement	CMNT
Fibre crops	FICR
Lime stone	LIME

Numbers marks the same graphics (if the capacity is different, it is different graphics because how call-backs work). as you can see, 8 of them are the same, so we have 40-8=32 so called 32 different cargo types (if I understand what it is). What should be the table?
Now, let us add a new cargo MILK, that have specific graphics. How should it be added? We have 33 different cargos in that case.

[michael blunck]

I kind of figured the gameplay wouldn't suffer but the graphics would (as far as you can state that). This almost forces you to include sprites of loading stages for RV's and ships too . You can predict people will complain about graphical glitches otherwise.

Yes.

Since the advent of "newcargoes" we´ll have to establish strong links between vehicle .grfs and "new cargo" .grfs. Not only with regards to managing "new cargo overhead" but o/c with regards to a graphical representation of those new cargoes.

That´ll a lot of work. I´m doing nothing else since weeks.

O/c, the DBXL or the NS Set wouldn´t have to support "rice" as a grain crop variety in a graphical way, simply because these train sets aren´t supposed to be used in a chinese or japanese scenario. Nevertheless, using a sophisticated cargo management scheme, it´ll be possible to refit their vehicles to "rice" as well but without displaying any new graphics for that cargo (closed wagons for that cargo come to mind ...).

regards
Michael

[Patchman]

My vehicle supports 40 cargos

Your translation table would look like this:

Code: Select all

  -1 * 0   00 08 01 29 00 
            "COAL" "WATR" "RUBB" "MAIL" "OIL " "LVST" "GOOD" "CERE" "GRAN" "WHET" // 0-9
            "MAIZ" "WOOD" "WODT" "IORE" "CORE" "STEL" "PLAS" "VALU" "GOLD" "DIAM" // 10-19
            "PAPR" "FOOD" "FRUT" "FISH" "WOOL" "POTA" "SAND" "GLAS" "WDPR" "DYES" // 20-29
            "FERT" "OLSD" "RFPR" "VEHI" "PETR" "BRCK" "SULP" "CMNT" "FICR" "LIME" // 30-39
            "MILK" // 40

and the action 3 for a wagon that has different graphics for grain (8), wheat (9), maize (10) and cereals (7) looks like this:

Code: Select all

  -1 * 0   03 00 01 1B 04 08 <grain-cid> 09 <wheat-cid> 0A <maize-cid> 07 <cereals-cid> <default-cid>

and a wagon that has graphics for water (1), rubber (2), oil (4), petrol (34) and milk (40):

Code: Select all

  -1 * 0   03 00 01 1C 05 01 <water-cid> 02 <rubber-cid> 04 <oil-cid> 22 <petrol-cid> 28 <milk-cid> <default-cid>

Does that make it clearer?

Since the advent of "newcargoes" we´ll have to establish strong links between vehicle .grfs and "new cargo" .grfs. Not only with regards to managing "new cargo overhead" but o/c with regards to a graphical representation of those new cargoes.

Well, I've been trying very hard to break these strong links. They are a liability, because they prevent players from mixing and choosing the grfs files as they please, and they prevent support of future cargo files without modification.

One possibility to resolve this would be using the upper 8 bits of the cargo classes. If we agree that the current classes are sufficient and we'll never need more distinct classes, the upper 8 bits could become the "looks like" property that krtaylor has been lobbying for.

Alpha 66 will have a variable like var.42, but without the uu field and instead with the full 16 bits of the cargo class; it will also only apply to the current wagon.

This way, vehicles can change their graphics based on the fundamental cargo class (bits 0..7), and also based on the subclass (bit 8..15), which could be set to any value. It doesn't have to be a bit mask either; we could, for example, define that for bulk freight, the subclass should mean 0=looks black (coal), 1=looks brown (iron ore), 2=looks red (?), 3=looks yellow (sulphur), 4=looks green (copper ore), etc.

So then, new cargo grfs can set their properties so that "incompatible" sets (that don't know about it) still show reasonably correct graphics, and the sets that do know about it can use the translation table for proper graphics.

Of course, all of this adds extra work for the vehicle grf coder, but IMHO it's still a lot less work than would've been necessary to support all permutations of the original vector-based propositions in this thread.

[Hyronymus]

But how do you define reasonable exactly, Patchman? What's the trade-off in a reasonable but not perfect resemblance?

[George]

My vehicle supports 40 cargos

Your translation table would look like this:
and the action 3 for a wagon that has different graphics for grain (8), wheat (9), maize (10) and cereals (7) looks like this:
and a wagon that has graphics for water (1), rubber (2), oil (4), petrol (34) and milk (40):

Code: Select all

  -1 * 0   03 00 01 1C 05 01 <water-cid> 02 <rubber-cid> 04 <oil-cid> 22 <petrol-cid> 28 <milk-cid> <default-cid>

Does that make it clearer?

Yes. Some questions left.

1) May I cpecify the ID that is not active (skipped with action 7). For example, where I define <water-cid> I check, is the water available. If not, than I disable its graphcis. And then I should disable the <water-cid>, because it should refer to nonexisting graphics. So, in that line 01 <water-cid> refers to wrong ID, but it should not be accesed because there is no water. Is it ok?

2) What should be props 0F (capacity) 10 (default cargo type) 16 (refit list) in action 0?

[Patchman]

But how do you define reasonable exactly, Patchman? What's the trade-off in a reasonable but not perfect resemblance?

Well, whatever most closely resembles the new unsupported cargo type. In any case, this way has to be better than just displaying the default cargo type.

Does that make it clearer?

Yes. Some questions left.

1) May I cpecify the ID that is not active (skipped with action 7). For example, where I define <water-cid> I check, is the water available. If not, than I disable its graphcis. And then I should disable the <water-cid>, because it should refer to nonexisting graphics. So, in that line 01 <water-cid> refers to wrong ID, but it should not be accesed because there is no water. Is it ok?

Yes, it should be. According to the action 7 docs, it's safe to skip an action 2, but its definitions continue to apply. So as long as you make sure never to skip an action 1 that can possibly be used later (or else you'll get random sprites instead), it should be fine.

2) What should be props 0F (capacity) 10 (default cargo type) 16 (refit list) in action 0?

Capacity is the capacity of the default cargo type. I suppose the default cargo should be one of TTD's cargo types if possible. I'm not sure if it would work well to translate this too. I'll have to think about that.

The refit list should be zero if you're using class-based refitting. Otherwise you set the bits for the cargos from your translation table where the cargo classes don't give the right result.

[Hyronymus]

Won't it be possible to start work on a grf that contains new cargos for loading stages in trains, RV's and ships? The Japan set i.e. can refer to that cargo grf to 'load' the proper garphics but the DBset can also refer to that grf to 'load' cars.

[Patchman]

I don't follow what you mean here. Do you mean that the cargo grf should define the graphics for all wagons that transport its cargos?

That's not possible unless it also has the graphics for all other cargos, which means we have the same problem as before.

I suppose it would be possible to code a way for vehicle grfs to "import" certain graphics from other grf files (such as a cargo grf), but I'm not sure that solves the problem really.

[George]

Does that make it clearer?

Yes. Some questions left.
1) May I specify the ID that is not active (skipped with action 7). For example, where I define <water-cid> I check, is the water available. If not, than I disable its graphics. And then I should disable the <water-cid>, because it should refer to non-existing graphics. So, in that line 01 <water-cid> refers to wrong ID, but it should not be accessed because there is no water. Is it ok?

Yes, it should be. According to the action 7 docs, it's safe to skip an action 2, but its definitions continue to apply. So as long as you make sure never to skip an action 1 that can possibly be used later (or else you'll get random sprites instead), it should be fine.

So, in this case because no water is active, it is safe to refer to inactive water-cid in action 3

2) What should be props 0F (capacity) 10 (default cargo type) 16 (refit list) in action 0?

Capacity is the capacity of the default cargo type.

And if it is not active?

I suppose the default cargo should be one of TTD's cargo types if possible.

It can be disabled. It is not safe to refer to it unless the availability check. Is it possible to have it zero (or FF) as for refit mask? The patch should pick up the first one in the action 3 list.

I'm not sure if it would work well to translate this too. I'll have to think about that.

Disabling default cargos is possible. So it is required too, I think

The refit list should be zero if you're using class-based refitting.

Ok

Everything is clear now. Thanks Josef

[Hyronymus]

Hmm, you're right. I was going backwards again . Still I think there could be a huge problem if new cargo's are only available by using trainsets. I think that the creator of a new cargo type should release his new cargo for free to the community so other sets in the community can freely use the new cargo to fit in with their sets.

[Patchman]

Well, here's a test version with all this implemented (as documented on the wiki).

I haven't written the action 7 for it yet.

There's a test grf at http://www.ttdpatch.net/src/newgrfdemo/

[Patchman]

I've updated the wiki cargo page with the TTD cargo labels and classes.

I'd appreciate if you could add your new cargos there for reference, so we can avoid getting duplicate labels for different cargos.

[George]

What is wrong with my table? It does not work

Code: Select all

  610 * 55	 03 01 01 11 10 01 2F 00 02 5F 00 10 1E 00 14 AE 00 15 AF 00 16 AF 00 20 3F 00 30 8F 00 32 9F 00 40 7F 00 41 7F 00 60 4F 00 61 6F 00 62 6F 00 63 6F 00 64 6F 00 FF 00
  611 * 49	 00 01 14 01 11 00 DD 45 02 23 03 0A 04 14 06 0F 07 0B 08 A0 09 0B 0E FF 0F 22 10 03 11 0B 12 19 13 15 14 20 16 FF FF FF FF 17 2C 18 50 19 40 1A 01
  612 * 18	 04 01 1F 01 11 53 6B 6F 64 61 20 37 30 36 20 4D 54 00
  613 * 442	 00 08 01 70 00 09 50 41 53 53 4D 41 49 4C 47 4F 4F 44 54 4F 55 52 30 30 30 34 30 30 30 35 30 30 30 36 30 30 30 37 30 30 30 38 30 30 30 39 30 30 30 41 30 30 30 42 30 30 30 43 30 30 30 44 30 30 30 45 30 30 30 46 43 4F 41 4C 57 41 54 52 53 41 4E 44 47 4C 41 53 56 41 4C 55 47 4F 4C 44 44 49 41 4D 30 30 31 37 30 30 31 38 30 30 31 39 30 30 31 41 30 30 31 42 30 30 31 43 30 30 31 44 30 30 31 45 30 30 31 46 4F 49 4C 20 50 4F 54 41 44 59 45 53 52 46 50 52 50 45 54 52 53 55 4C 50 30 30 32 36 30 30 32 37 30 30 32 38 30 30 32 39 30 30 32 41 30 30 32 42 30 30 32 43 30 30 32 44 30 30 32 45 30 30 32 46 49 4F 52 45 43 4F 52 45 53 54 45 4C 50 4C 41 53 52 55 42 42 56 45 48 49 30 30 33 36 30 30 33 37 30 30 33 38 30 30 33 39 30 30 33 41 30 30 33 42 30 30 33 43 30 30 33 44 30 30 33 45 30 30 33 46 57 4F 4F 44 54 57 4F 44 50 41 50 52 57 44 50 52 30 30 34 34 30 30 34 35 30 30 34 36 30 30 34 37 30 30 34 38 30 30 34 39 30 30 34 41 30 30 34 42 30 30 34 43 30 30 34 44 30 30 34 45 30 30 34 46 42 52 43 4B 43 4D 4E 54 4C 49 4D 45 30 30 35 33 30 30 35 34 30 30 35 35 30 30 35 36 30 30 35 37 30 30 35 38 30 30 35 39 30 30 35 41 30 30 35 42 30 30 35 43 30 30 35 44 30 30 35 45 30 30 35 46 4C 56 53 54 43 45 52 45 47 52 41 4E 57 48 45 54 4D 41 49 5A 46 4F 4F 44 46 52 55 54 46 49 53 48 57 4F 4F 4C 46 45 52 54 4F 4C 53 44 46 49 43 52 30 30 36 43

[DaleStan]

Well, the first problem is that you're not using literal strings, and the second is that you don't seem to have any line breaks, much lessline breaks in happy places. (Read: "*between* the labels, not in the middle of the labels".)
Do you have to work at making things hard for us, or does that come naturally to you?

/me wanders off to str2hex

"0004" "0005" "0006" "0007" ...

Those labels belong to which cargos, exactly?

You don't set labels that don't belong to cargos. The whole point of this is to provide 253 climate independent IDs. You're defeating that if you use labels that will never be attached to cargos.