Proposal - Cargo Class refinement

[PikkaBird]

Andy, I've taken a few of your posts from other threads and merged them in here.

I've noticed you have a habit of finding ancient threads related to a topic and bumping them, so suddenly we have the same discussion going on in 3 different places. Perhaps it would be better to try and stick to one thread and just link to/quote from old threads which may be relevant, rather than fragment the current conversation? Just a plea from my tired old brain.

[andythenorth]

Currently i have the most worries about the "covered" class. it looks to me much like andythenorth's proposed "clean" class a "hack" that has nothing to do with refitability, in this case it seems just for graphical changes.

Heh. My hack was 'foodstuffs', someone else proposed it should be 'clean'

Anyway, I have the same concerns as Eddi about 'covered'.

Eddi - you're missing a flat car from your large scheme, and you might also figure out containers. IRL they carry everything from bulk ore to frozen peas, but most sets seem to treat them as express/piece.

Perhaps it would be better to try and stick to one thread and just link to/quote from old threads which may be relevant, rather than fragment the current conversation? Just a plea from my tired old brain.

Sorry. FWIW I was trying to keep a separation between improving label-based refitting and all this discussion of classes, as they seem different to me But maybe better all discussed in one thread.

[PikkaBird]

IRL they carry everything from bulk ore to frozen peas, but most sets seem to treat them as express/piece.

Mostly to stop every freight train ending up with the same wagons with identical graphics. "Realistic" for some parts of the world, potentially, but very boring.

[frosch]

So, I thought about keeping compatibility last night. It should be possible to also translate cargoclasses whenever translating cargobits with the cargo translation table. (Though vehicle var 42 might be tricky here)

While it is IMO no problem to add new classes to existing cargos, which no vehicle grfs knows about, it is a problem to change known cargoclasses. (I consider "covered", "oversized", "powderized" and "not pourable" new.) I.e. for these type of changes no new cargo labels are needed IMO.

For the other cases I suggest adding adding a new cargo property: (actually inspired by some unrelated work by michi_cc)

• Equivalent cargos: A list of cargolabels and their associated cargoclasses, which can be considered equivalent to a cargo.
• The list would be cleared, when a cargolabel is assigned to a cargo, i.e. when a grf redefines a cargo slot.
• For every GRF the list of equivalent cargolabels is checked against the cargo translation table. If the CTT knows the actual cargo label, none of the equivalent labels takes effect. Else the first equivalent label that is present in the CTT is used.
• So every GRF with a cargo translation table might get reported the same in-game cargo using a different label, and with different classes assigned to that.
• Every cargo is only assigned to a single label wrt. a GRF. A cargo cannot use an equivalent label that is already used by some other present cargo.
• I am not sure about the behaviour of Action 7 cargo label tests.
• For the default cargos, OTTD could provide these equivalent cargos. (not the baseset; we already did that wrong for engine overrides )

[michael blunck]

Currently i have the most worries about the "covered" class. it looks to me much like andythenorth's proposed "clean" class a "hack" that has nothing to do with refitability, in this case it seems just for graphical changes. Anyway, it doesn't really fit into my scheme...

Then, what about "refrigerated"? Or with any of your other "OR/AND NOT" cargoes? Seem similar cases to me. W/r to "covered", a tarpaulin might be regarded as a "hack", but a Ta (closed hopper)?

regards
Michael

[andythenorth]

Then, what about "refrigerated"? Or with any of your other "OR/AND NOT" cargoes? Seem similar cases to me. W/r to "covered", a tarpaulin might be regarded as a "hack", but a Ta (closed hopper)?

Eddi proposed 'powderised' for cargos that need moisture protection, i.e. covered hopper.

IMHO, any vehicle can be 'covered' via tarpaulin or such. I don't think that the class has any information content resp. refitting.

It seems most useful as a graphical hint that 'this cargo is commonly covered IRL', e.g. grain. But in practice
- covering hides the cargo, and some authors like to show the cargo, e.g. many of us show bulk cargos in open vehicles, irrespective of whether they would be covered IRL or not, it adds to the charm of the game
- many of us cover cargos we don't know about, simply because we can't draw what's known (or in my case, I got bored of drawing cargos).

So I think it's a dubious refit class. There are very few piece goods where we can't trust that the packaging or an optional tarpaulin provides weather protection, there's not much that's specific to vehicle types. And most bulk can be covered by a tarp, except the special case of powders.

[wallyweb]

Eddi - you're missing a flat car from your large scheme, and you might also figure out containers. IRL they carry everything from bulk ore to frozen peas, but most sets seem to treat them as express/piece.

Mostly to stop every freight train ending up with the same wagons with identical graphics. "Realistic" for some parts of the world, potentially, but very boring.

Reality says that a container is essentially a box-car/van or a reefer without wheels. This is a graphical interpretation. Why not simply define the cargo classes and/or labels and leave the interpretations to the set authors?

WOOD ... rename to LOGS?

What about wood chips/sawdust and lumber? WOOD is more appropriate because it is more generic.

It would seem that there is a tendency in this discussion to become too specific. For example, what does it matter the coarseness of a bulk material? Should the use of a box-car/van, a container, a tarpaulin covered open gondola, an open hopper, a closed hopper, or a silo wagon be dictated by several classes and/or labels for what are essentially all bulk? Get rid of 'powderized' ... It is merely another form of 'bulk'. 'Pourable'/'Not Pourable' are also similarly redundant.

For the default cargos, OTTD could provide these equivalent cargos.

TTDP is still a viable option and very much in use by many players.

[michael blunck]

IMHO, any vehicle can be 'covered' via tarpaulin or such. I don't think that the class has any information content resp. refitting.

Not "any" vehicle. But o/c, eligibility of that statement depends on whether we´re talking about a "cargo class" system or a "wagon class" system. Which isn´t always clear, these days.

But in practice
- covering hides the cargo, and some authors like to show the cargo, e.g. many of us show bulk cargos in open vehicles, irrespective of whether they would be covered IRL or not, it adds to the charm of the game

E.g., in the (old) DB set, a number of cargoes are covered after finishing "normal" loading stages (grain, paper, ..). As such, there´s no conflict.

Eddi proposed 'powderised' for cargos that need moisture protection, i.e. covered hopper.

This justification seems somewhat "artificial". But as I know Eddi, he´d like to make a sharp decision between "weather-protected" (tarps) and "moisture-protected" (silo-wagons?).

But o/c that was never the basic point of introducing:

11 | 800 | Powder-shaped material (bulk cargo needing special silo-wagons, e.g. equipped for compressed air unloading; for cargoes like cement, plaster, lime granulates, coal dust, plastic granulate or powder, PVC, metal powders, salt, sugar, semolina, ...)

The basic point was "silo-wagons", everything else is just additional information for cargo set authors.

I´m aware that ECS´s CMNT seems to be the only cargo so far needing this special type of wagon, but they´re quite noticeable IRL, and there cannot be a DB Set w/o them (I could show pictures ...).

IMO, neither "compress air unloading" nor "moisture-protection" (which isn´t even mentioned in the above) are its key points, but the "silo-wagon" itself, in its unmistakable manifestation.

BTW, those vehicles were used to transport even coal(!) (in pulverulent form) in ex-East-Germany, something that Eddi should be interested in ...

So I think it's a dubious refit class

There are many "dubious" refit classes. As I wrote somewhere else, in the end we´d need only "solid" and "liquid".

Apropos dubious: Eddi´s "unpourable bulk" would nicely translate into German "unschüttbare Schüttgüter". Hehe, what a mess!

[edit]

WOOD ... rename to LOGS?

What about wood chips/sawdust and lumber? WOOD is more appropriate because it is more generic.

Yes, "logs" (tree trunks) is a quite uncommon type of "wood transport" (at the time being, on railways). O/c, this is (again) somewhat disputable, because of TTD´s original cargo from forests is named "wood", but not "logs". In ECS, this cargo is kept as "wood", but any "machined" form of "wood" (wood chips/sawdust and lumber) is called "wood products" (WDPR). HTH
[/edit]

regards
Michael

[Eddi]

Eddi - you're missing a flat car from your large scheme, and you might also figure out containers. IRL they carry everything from bulk ore to frozen peas, but most sets seem to treat them as express/piece.

hm... IMHO a flat car is just a stake car with the stakes pulled out.

i might write something up about containers, though.

[Eddi]

WOOD ... rename to LOGS?

What about wood chips/sawdust and lumber? WOOD is more appropriate because it is more generic.

like MB said, "Wood Chips"/"Lumber" is represented by WDPR, the original WOOD cargo is really unprocessed wood from the forest to the saw mill.

but in case this hasn't been clear, this is not about renaming anything ingame, only changing the label exposed to NewGRF authors.

[peter1138]

Changing existing labels is a really bad idea, especially for the base cargo types.

[andythenorth]

There are many "dubious" refit classes. As I wrote somewhere else, in the end we´d need only "solid" and "liquid".

"I find this view interesting and would like to subscribe to your newsletter"

FWIW, when devising cargos, I would rather set minimal classes and not have so much detail.
Interpretation of cargo should be left to the vehicle set author.

As a cargo set author bulk, piece, liquid would suit me.
That idea unfortunately is doomed to fail.

Classes should be seen properly as a fallback to help players, but they are not. Instead the expectation is that classes should provide vehicle set authors with a way to avoid having to add support for specific cargos (via labels and the CTT), and that this support should be highly accurate.

That ultimately suggests vehicle classes (I refuse 'wagon classes', it's not just a train game). I don't like this idea at all, but it seems to be the required spec


@wally - TTDP is pretty much unmaintained AFAIK, at some point it's impossible to maintain a spec between the two games. We're pretty close to that.

[michael blunck]

Classes should be seen properly as a fallback, but they are not. Instead the expectation is that classes should provide cargo set authors with a way to avoid having to add support for specific cargos (via labels and the CTT), and that this support should be highly accurate.

That ultimately suggests vehicle classes (I refuse 'wagon classes', it's not just a train game). I don't like this idea at all, but it seems to be the required spec

Just for the record.

The concept of "cargo classes" had been initially established as a "joint" effort between cargo set and vehicle set authors. The idea was that a vehicle set author should use the cargo classes to define what type of cargo his vehicles should be refittable to, and the cargo set author should add appropriate labels to his new cargo definitions.

That was the idea. In fact, both the original cargo classes being derived from TTD and some of the user-added classes turned out to be of not much use in the end. From hindsight, it would have been an alternative to set up a list of all "real" cargo types in advance (i.e., not toyland or any other fantasy cargoes) with or w/o classes. But back in those days we had the idea of a "participating community" and liked to allow this explicitly. (Hence the number of weird cargo classes and cargo types.)

In addition, a method how to link cargo classes with (known) cargo types was needed. As can be seen in the posted excerpt of Josef´s mail, 3 alternatives had been discussed:

- bitwise OR, i.e. refittable if a cargo is included in the cargo refit mask, or is of the proper class,
- AND NOT, i.e. refittable if it´s of the proper class but is NOT included into the cargo refit mask,
- using two masks, one additive and one subtractive, allowing things like "express freight but not liquid".

regards
Michael

[George]

@wally - TTDP is pretty much unmaintained AFAIK, at some point it's impossible to maintain a spec between the two games. We're pretty close to that.

I do not think so. If we'd add new props, the sets would support TTDP with old props and a more configurable support for OTTD with new props. Do not see much problem here. That's like having introduction date and long introduction date props.

[wallyweb]

@wally - TTDP is pretty much unmaintained AFAIK, at some point it's impossible to maintain a spec between the two games. We're pretty close to that.

A reply has been posted here.

[DaleStan]

@wally - TTDP is pretty much unmaintained AFAIK, at some point it's impossible to maintain a spec between the two games. We're pretty close to that.

I do not think so. If we'd add new props, the sets would support TTDP with old props and a more configurable support for OTTD with new props. Do not see much problem here. That's like having introduction date and long introduction date props.

I fail to see how this is relevant to the current discussion. How does changing the definition of the cargo classes affect a conformant NFO implementation?

[George]

@wally - TTDP is pretty much unmaintained AFAIK, at some point it's impossible to maintain a spec between the two games. We're pretty close to that.

I do not think so. If we'd add new props, the sets would support TTDP with old props and a more configurable support for OTTD with new props. Do not see much problem here. That's like having introduction date and long introduction date props.

I fail to see how this is relevant to the current discussion. How does changing the definition of the cargo classes affect a conformant NFO implementation?

instead of changing current classes it is possible to provide new props that operate new classes

[andythenorth]

Eddi has convinced me that a new property for included cargos (indices into the CTT) should also have an equivalent property for excluded cargos (also indices into the CTT).

I think an exclude property is inelegant and encourages lazy thinking, but Eddi has made a strong case for it.

The downside of an exclude prop is that it is no longer explicit. With only one prop, you can tell which known cargos from the CTT a vehicle will carry just by reading one prop + your CTT. (If it's in the CTT and not in the list, it isn't carried, at all, ever).

With an exclude property, to figure out which known cargos are refittable, you instead have to run a calculation using the classes, which means looking up the classes, hoping they are documented correctly, and then looking at your vehicle's props for included/excluded classes. (i.e. setting up the exclude list the first time for each vehicle is going to be a proper pain in the arse).

That seems like madness to me and not something that should be happening at all.

But only having a prop for include means that you have to update a lot of action 0 entries in your set every time you add a cargo to the CTT, as cargos that previously refitted on classes will now stop refitting until you update the include prop for each and every one of them And that would be a lot of work, and every time they have to do it people will gripe, and on that basis Eddi is correct

[Eddi]

i think we should take a step back, and see if we agree on what goals we want to achieve.

first and formost, the goal of cargo classes should be that a vehicle set author has a way to ensure that every cargo, known or not. this is solely the responsibility of the vehicle set author, regardless of whether the classes are "right" or "wrong"

second, the cargo classes should give a suggestion of which wagons should load the cargo. it is mostly the responsibility of the industry set author to make sure that this classification has is sensible, but the general properties on which grounds to decide classes should be derived from a general consensus, otherwise we will have this same discussion next year all over again. or in five years, with a whole new generation of developers, none of which remember the reasonings behind it all.

third and last, the vehicle set author should have a way to override the "suggestion" that the cargo classes give, in a way that is both flexible, but not too tedious.

[andythenorth]

As I see it, the primary goal is to provide the following to players
- add any newgrf that defines cargos
- add any vehicle newgrf (any general set, excluding niche or add-on sets)
- 100% of the cargos defined by the cargo newgrf will be transportable by the vehicle newgrf

As I see it, the secondary goal is to provide vehicle set authors with a way to precisely control the refitting of any vehicle to any known cargo.

Enabling the vehicle set author to have some control over refitting of vehicles to unknown cargos is a valid tertiary goal, and not essential.

The only warranty on refitting to unknown cargos should be:
(a) refittable vehicles will be provided for all cargos now and in the future
(b) for a specific combination of cargo newgrf and vehicle newgrf, refitting of any vehicle may be inconsistent between different versions of either grf
(c) where cargo 'foo' is unknown to the vehicle grf, a quick image search will show that the current refittable vehicles for 'foo' are 'unrealistic'

Enabling cargo set authors to control which vehicles (or vehicle types) can transport a cargo is IMHO an invalid goal.

I have omitted all mention of labels and classes above, they are one of the available solutions, not the goal