Proposal - Cargo Class refinement

[PikkaBird]

The GRFSpecs seem to be very restrictive as to the names of the cargoes in that the name is also the Cargo Type.
Then we have Cargo Labels where a Cargo Description is matched to a Cargo Class.
The Cargo Description seems to be the same as the Cargo Type.
Unless the Industry set author defines an new Cargo Label, he/she is locked in to what is available.
Would it not be simpler to simply define the Cargo Classes as per this discussion?
Then the set author would use three Action0 properties to set input cargoes classes and two Action0 properties to set output cargo classes.
There would then be, respectively, three and two Action0 properties that accept text entries where the set author could define any name that he/she feels is appropriate.
The transport set author would similarly assign Cargo Classes to his/her vehicles.
Vehicle refitting would be based on and limited to the names defined by the industry set author for that particular Cargo Class.

Mr Web, you make no sense, sorry.

- "Cargo Class" is entirely to do with refitting vehicles; these are broad categories such as "bulk" and "liquid". They are not suitable for defining industry acceptance or production.
- Yes, the author is "locked in to what is available" unless he or she "defines a new label", but this is tautological (the author is limited to what exists unless they create something new), so I don't see what your point is.
- I'm not sure I understand your idea of separating cargo types and descriptions. If we take the cargo livestock with the cargo label LVST; the author of the producing industry decides to describe it "sheep", the author of the vehicle describes it "cows", and the author of the accepting industry describes it "horses", yet it's all the same cargo, how is this in any way useful or non-confusing to the player? Perhaps if this is not what you mean you can provide a counter-example?

[wallyweb]

Mr Web, you make no sense, sorry.

This would probably require a considerable amount of "thinking outside of the box" where that box is constricted to expanding upon the limitations set by Transport Tycoon and TTDPatch.

- "Cargo Class" is entirely to do with refitting vehicles; these are broad categories such as "bulk" and "liquid". They are not suitable for defining industry acceptance or production.

Correct, as things currently stand.

- Yes, the author is "locked in to what is available" unless he or she "defines a new label", but this is tautological (the author is limited to what exists unless they create something new), so I don't see what your point is.

To give the author greater flexibility and not be restricted to a limited set of conventions.

- I'm not sure I understand your idea of separating cargo types and descriptions. If we take the cargo livestock with the cargo label LVST; the author of the producing industry decides to describe it "sheep", the author of the vehicle describes it "cows", and the author of the accepting industry describes it "horses", yet it's all the same cargo, how is this in any way useful or non-confusing to the player? Perhaps if this is not what you mean you can provide a counter-example?

I assume that the author of the producing industry is the same as the author of the accepting industry and would be careful in his/her name selections. Labels would no longer be used.
The vehicle set author would only define classes, not names. The game code would require/allow the vehicle set to access and read the appropriate names provided by the industry set. Hence:

I realize that this would probably require some major rewrites to the game code.

[Yexo]

@wallyweb: What I don't understand how this changes anything for vehicle set authors? They define refitability by classes (as now) and exceptions by name (=current label). At least, I assume that is what you mean by "the vehicle set can read the name".

[PikkaBird]

I assume that the author of the producing industry is the same as the author of the accepting industry and would be careful in his/her name selections. Labels would no longer be used.

And this is a valid assumption to make because...? BTW, the label is what identifies the cargo across GRFs; for all intents and purposes, the label is the "cargo type", with the human-readable name displayed in-game being the "cargo description".

The vehicle set author would only define classes, not names. The game code would require/allow the vehicle set to access and read the appropriate names provided by the industry set.

This is exactly the way things work at the moment, if you don't want to have any fancy special-purpose vehicles (which andy does).

[wallyweb]

I assume that the author of the producing industry is the same as the author of the accepting industry and would be careful in his/her name selections. Labels would no longer be used.

And this is a valid assumption to make because...?

Well, as things currently stand, I have yet to see multiple industry sets by different authors being accommodated in one game. Of course this would be a concern if a player were to be able to use more than one industry set in one game.

BTW, the label is what identifies the cargo across GRFs; for all intents and purposes, the label is the "cargo type", with the human-readable name displayed in-game being the "cargo description".

And why could this not be changed in a new game code to where it is the "cargo class" that is identified across GRFs? Would it still have to be done via a label?

The vehicle set author would only define classes, not names. The game code would require/allow the vehicle set to access and read the appropriate names provided by the industry set.

This is exactly the way things work at the moment,

Now that would simplify deriving the new game code.

if you don't want to have any fancy special-purpose vehicles (which andy does).

[Michi_cc]

And why could this not be changed in a new game code to where it is the "cargo class" that is identified across GRFs? Would it still have to be done via a label?

Somehow I get the feeling that whatever you mean with "cargo class", it has no relation at all to the cargo classes of the NewGRF specs.

A NewGRF cargo class specifies properties of a certain cargo, for example in saying that iron ore is "bulk" just like bauxite is "bulk", too. The mapping of cargoes to classes is, in it's simplest form, a many-to-one mapping, so each cargo class has more than one cargo associated. No idea how you think the reverse one-to-many mapping could in any way be unambiguous.

-- Michael Lutz

[wallyweb]

@wallyweb: What I don't understand how this changes anything for vehicle set authors? They define refitability by classes (as now) and exceptions by name (=current label). At least, I assume that is what you mean by "the vehicle set can read the name".

What would change is that refitability would be by name and not by class. A vehicle is designed to accommodate a certain class of cargo, irregardless of the name of the cargo. The cargo name is the variable that changes. Iron ore and bauxite could conceivably be transported by exactly the same class of vehicle.

Somehow I get the feeling that whatever you mean with "cargo class", it has no relation at all to the cargo classes of the NewGRF specs.

Actually, it has everything to do with the cargo classes of the NewGrf specs. Somewhere in the current discussion I saw mention made of using the logical AND, OR, XOR(?) and NOT(?). This is as it should be.

A NewGRF cargo class specifies properties of a certain cargo, for example in saying that iron ore is "bulk" just like bauxite is "bulk", too. The mapping of cargoes to classes is, in it's simplest form, a many-to-one mapping, so each cargo class has more than one cargo associated. No idea how you think the reverse one-to-many mapping could in any way be unambiguous.

What is different is the naming of the cargo. As it stands, the author is constrained to using the currently available selection of names or find a way to rename or define a new label. My proposal is to allow the industry set author a simpler way to have more latitude in selecting the name of his/her cargo. In some locations maize is appropriate. In others corn is the proper name. Some locations drive automobiles. Other locations prefer cars. Livestock can be a cow. Cattle is the same beast. Do you prefer tar or bitumen for your roads? Petrol can also be gas or gasoline and fuel can be heating oil or bunker C.

Note that I am not proposing a change to TTTDPatch nor to OTTD as they currently exist. Spec 7 as it currently exists is actually quite manageable. However, if one is to consider some significant changes that might result in the need for NewGRF Spec 8, then perhaps that would be a good time to also consider freeing up a rather restrictive labeling system.

[andythenorth]

As it stands, the author is constrained to using the currently available selection of names or find a way to rename or define a new label. My proposal is to allow the industry set author a simpler way to have more latitude in selecting the name of his/her cargo. In some locations maize is appropriate. In others corn is the proper name.

This is a very bad idea. We tried it in FIRS. The result is confusing.

[Yexo]

What is different is the naming of the cargo. As it stands, the author is constrained to using the currently available selection of names or find a way to rename or define a new label. My proposal is to allow the industry set author a simpler way to have more latitude in selecting the name of his/her cargo. In some locations maize is appropriate. In others corn is the proper name. Some locations drive automobiles. Other locations prefer cars. Livestock can be a cow. Cattle is the same beast. Do you prefer tar or bitumen for your roads? Petrol can also be gas or gasoline and fuel can be heating oil or bunker C.

But the actual cargo name is already separate from the label.
Nobody stops authors to use the label "VEHI" and set the name as "Cars" instead of "Vehicles".

[wallyweb]

But the actual cargo name is already separate from the label.
Nobody stops authors to use the label "VEHI" and set the name as "Cars" instead of "Vehicles".

What if one wants to have Nickel Ore as well as Iron Ore (IORE) and Copper Ore (CORE) and Bauxite (AORE)?

As it stands, the author is constrained to using the currently available selection of names or find a way to rename or define a new label. My proposal is to allow the industry set author a simpler way to have more latitude in selecting the name of his/her cargo. In some locations maize is appropriate. In others corn is the proper name.

This is a very bad idea. We tried it in FIRS. The result is confusing.

Note that I am not suggesting that one industry set should be able to use more than one name for the same cargo. I agree that this would be very confusing. My question is why should two different industry sets be forced to use the same cargo names? Some industry sets could be Eurocentric while others could be North American or Asian. Some cargoes are realistic in some regions but absolutely foreign to others.

[andythenorth]

My question is why should two different industry sets be forced to use the same cargo names?

They aren't. They don't.

[wallyweb]

My question is why should two different industry sets be forced to use the same cargo names?

They aren't. They don't.

The Cargo Labels here seem to be quite fixed and definitive.

[Yexo]

But every industry set author can add new labels as he/she wishes. As such I don't see the problem.

[andythenorth]

The Cargo Labels here seem to be quite fixed and definitive.

The name string "Goods" or "Scrap Metal" or whatever is defined by whichever grf defines the cargo.

The labels are...well...labels. If you change the label...it's a different label. But I guess that's obvious

As an example, FIRS has "Lumber", ECS has "Wood Products", both use the WDPR label. Although in that example, we think that's a bad case of label reuse (because it causes disagreement about what the cargo "is").

This particular issue (name strings) seems to be not the main part of your proposal though?

[wallyweb]

But every industry set author can add new labels as he/she wishes. As such I don't see the problem.

Simplicity. Why the need to add a label when a simple Action0 text entry could do the job? Also, there would no longer be a need to declare some cargo labels as being deprecated and also the CTT could possibly be avoided. What is the process to have a unique cargo that is not currently covered by a label?

This particular issue (name strings) seems to be not the main part of your proposal though?

Definitely an important component.

[Yexo]

I'm sorry wallyweb, but you're making less and less sense. Could you write down a spec how industry and vehicle sets should work in terms of cargo labels/classes/names?

[wallyweb]

I'm sorry wallyweb, but you're making less and less sense.

Sorry about that.

Could you write down a spec how industry and vehicle sets should work in terms of cargo labels/classes/names?

Let me try.
Industry:
- Can produce 1 or 2 cargoes
- Assigns a name to each produced cargo via Action0
- Assigns a set of classes to each produced cargo via Action0.
- Each name and it's corresponding set of classes is variably stored in an array of names and classes.
- Can accept by name via Action0 0, 1, 2 or 3 cargoes whose names are found in the array of names and classes.
Vehicle:
- Can accommodate a set of classes set via Action0.
- Refit window lists respectively appropriate cargo names drawn from the array of names and classes.

Note that the classes are per the suggestions found much earlier in this discussion.
Note that cargo labels are not used.
If one wants to be technical, the names assigned to each cargo could be considered as labels, but they are not predefined outside the industry GRF.

[Yexo]

Industry:
- Can produce 1 or 2 cargoes

Same as currently

- Assigns a name to each produced cargo via Action0

A name here is something like "Vehicles"? Currently an industry set already does is. In addition it'd set the label ("VEHI").

- Assigns a set of classes to each produced cargo via Action0.

Same as currently

- Each name and it's corresponding set of classes is variably stored in an array of names and classes.

Only industry sets should define cargoes, so this is approximately what is done currently

- Can accept by name via Action0 0, 1, 2 or 3 cargoes whose names are found in the array of names and classes.

Replace "name" by "label" and this is already done. Since industry set defines the labels and the names this doesn't matter at all.

Vehicle:
- Can accommodate a set of classes set via Action0.

Same as currently

- Refit window lists respectively appropriate cargo names drawn from the array of names and classes.

Same as currenlty.

So I ask again: what are the actual changes compared to the current situation? The only change seems to be that you want to limit vehicle sets to set refitability by classes and forbid them to allow/forbid specific cargoes.

[andythenorth]

Hi Wallyweb, in the proposed system, how would I create a logging truck? (I'm making the assumption that players would expect that to refit to only wood, although you could say that option is not available).

[wallyweb]

- Assigns a name to each produced cargo via Action0

A name here is something like "Vehicles"?

Or maize or grain or iron ore or steel or passengers ...

In addition it'd set the label ("VEHI").

This would be avoided.

Since industry set defines the labels and the names this doesn't matter at all.

Why have both a name and a label when only one will do the job?

So I ask again: what are the actual changes compared to the current situation?

The way labels are currently defined they have a sense of being mandatory and only able to be altered with some extra effort even though this might not be the case. Also, as mentioned above, having both names and labels seems to be an extra layer of code that is unnecessary.

The only change seems to be that you want to limit vehicle sets to set refitability by classes and forbid them to allow/forbid specific cargoes.

Not at all. With the logical AND, OR, XOR and NOT described earlier, specificity should still be very possible but by property and not by name.

Hi Wallyweb, in the proposed system, how would I create a logging truck? (I'm making the assumption that players would expect that to refit to only wood, although you could say that option is not available).

A logging truck is essentially the same as a truck used to haul structural steel or those concrete beams used to build overpasses. With an appropriate selection of classes the refit options could be 'logs'; 'steel beams'; 'concrete beams'; ... etc.
I suspect that what you are really asking is what about the cargo graphics ... A good question and another reason to set this proposal for an OpenTTD II. It should be possible to define a set of unique cargo graphics from the industry set and referenced by the vehicle set via the cargo name and classes array.