Proposal - Cargo Class refinement

[Eddi]

"Bestandsaufnahme": (current status of the proposal how i understand it)

Code: Select all

bit|value|  old class | new class                    |  usage | cargos (examples)
-----------------------------------------------------------------------------------------------------
 0 |   1 | passenger  | passenger (A)                |no other| PASS, TOUR
 1 |   2 | mail       | mail/express/valuable (D)    | OR     | MAIL, VALU, GOLD, GOOD (remove TOUR)
 2 |   4 | express    | lightweight (H)              | AND NOT| GOOD, FICR, SGRC, WOOL
 3 |   8 | armored    |  - (deprecated)              |  -     |  - (remove VALU, GOLD)
 4 |  10 | bulk       | uncountable (E)              | OR     | COAL, *ORE, SCRP
 5 |  20 | piece      | countable (G)                | OR     | GOOD, FOOD, BDMT, BEER(?)
 6 |  40 | liquid     | liquid (Z)                   | OR     | OIL_, RFPR, MILK, BEER
 7 |  80 | refrig.    | refrig. (I)                  | AND NOT| FOOD, FISH, FRVG
 8 | 100 | (hazard.)  | pourable (F)                 | AND NOT| COAL, *ORE
 9 | 200 | covered    | moist-protected (U1)         | AND NOT| LIME, FERT (FMSP?), BDMT (cement)
10 | 400 | oversized  | oversized (K/L)              | AND NOT| STEL, WOOD, VEHI, ENSP, FMSP
11 | 800 | (neo-bulk) | not pourable ("E, but not F")| AND NOT| SCRP
12 |1000 | (clean)    | -                            |  -     |  -
13 |2000 |  -         | -                            |  -     |  -
14 |4000 |  -         | -                            |  -     |  -
15 |8000 | special    | - (deprecated)               |  -     |  -

cargos without sensible class:
LVST (-> possibly G?)
"transformators" (-> possibly K?)


this leaves us with the problem how to switch classes for existing cargos without breaking old sets.

[Eddi]

based on the current list of cargo labels i propose the following changes. we will (likely) need to introduce new labels for the ones marked in bold, especially for the default cargos. italic are new classes. (compare with Frosch's proposal)

also i slightly revised the proposed cargo classes, as imho the "pourable (F)" cargo class is not really needed, only the "not pourable (not F)" class (in the "and not" mask).

Code: Select all

bit|value|  old class | new class                    |  usage
-----------------------------------------------------------------------------------------------------
 0 |   1 | passenger  | passenger (A)                | do not combine with other bits
 1 |   2 | mail       | mail/express/valuable (D)    | OR
 2 |   4 | express    | lightweight (H)              | AND NOT, only with G
 3 |   8 | armored    |  - (deprecated)              |  -
 4 |  10 | bulk       | uncountable (E)              | OR
 5 |  20 | piece      | countable (G)                | OR
 6 |  40 | liquid     | liquid (Z)                   | OR
 7 |  80 | refrig.    | refrig. (I)                  | AND NOT, only with G
 8 | 100 | (hazard.)  | not pourable ("E, but not F")| AND NOT, only with E
 9 | 200 | covered    | moist-protected (U)          | AND NOT, only with E, implies "not F"
10 | 400 | oversized  | oversized (K/L)              | AND NOT, only with G
11 | 800 | (neo-bulk) | -                            |  -
12 |1000 | (clean)    | -                            |  -
13 |2000 |  -         | -                            |  -
14 |4000 |  -         | -                            |  -
15 |8000 | special    | special                      | do not use

• PASS - A
• COAL/IORE/CORE/AORE - E
• MAIL - D
• OIL_/FUEL/PETR/RFPR - Z
• LVST - ?
• GOOD - G, H, D
• GRAI/WHEA/MAIZ - E
• WOOD - G, K
• STEL/COPR - G, K
• VALU/GOLD/DIAM - D (remove armoured)
• PAPR - G, H
• FOOD - G, I (remove express)
• RUBR - Z
• FRUT - E, G, I ("bulk and refrigerated" doesn't really make sense. either "bulk" (E) or "piece and refrigerated" (G and I))
• WATR - Z
• SUGR/TOYS/BATT/SWET/TOFF/COLA/CTCD/BUBL/PLST/FZDR - ?? (no clue about toyland cargos)
• BEER - Z, G, H(?)
• BDMT - G, E, U (if splitting off "cement", only G, remove U)
• BRCK - G
• CERA - G
• CERE - E (rather not covered here?)
• CARB - E, "not F"
• CLAY - E, "not F", U(?)
• CMNT - E, U
• DYES - Z, G
• ENSP - G, K (remove express) (possibly rename to "machines")
• FERT - E, G, U
• FICR - E, G, "not F", H
• FISH - G, I (remove express)
• FMSP - E, G, U, K (this really should be split into FERT and ENSP (machines))
• FRVG - E, G, I (remove express)
• GEAR - (...)
• GLAS - G, K
• GRVL - E
• LIME - E, U
• MILK - Z, G, I (remove express)
• MNSP - G, H
• OLSD - E, "not F" (remove covered)
• PLAS - G, Z (maybe add H?)
• POTA - E, "not F", U
• RCYC - G (remove covered)
• RSGR - E, "not F" (deprecated)
• SAND - E
• SCMT - E, "not F"
• SGBT - E, "not F"
• SGCN - E, G, "not F", H
• SULP - E, U
• TOUR - A (remove express)
• TWOD - G (remove? if not, add K)
• VEHI - G, K
• WDPR - G, K, H (possibly remove E - "wood chips" has nothing to do with "lumber", otherwise add "not F")
• WOOL - G, H (remove covered)
• WSTE - E, "not F"
• SILI - E (remove?)
• DURA - ? (remove)
• MATE - G (remove)
• OXYG - Z (remove)
• RCKT - ? (remove)
• UORE - ? (remove)
• URAN - ? (remove)
• WATT - ? (remove)

Example list of wagons:

• Open Wagon: OR: E, AND NOT: U
• Hopper Wagon: OR: E, AND NOT: "not F", U
• Silo Wagon: OR: U
• Large Closed Wagon: OR: H, AND NOT: I, K
• Small Closed Wagon: OR: G, AND NOT: I, K (cargos of "H" class are reduced in capacity)
• Refrigerated Wagon: OR: I

(disclaimer: may contain errors/mistakes)

[frosch]

Not all cargo classes affect only refitting. Here is a list of stuff they are also used for in OpenTTD:

1. Sorting of cargotypes in lists or filters: Cargos of class 0 "passengers" appear at the top, followed by class 1 "mail" and then the rest. Within these 3 groups the cargos are sorted alphabetically.
2. Cargos of class 15 "special" are excluded from certain lists and cargo filters.
3. The passenger class 0 is used to
   • define "bus" vs. "truck",
   • passenger vs. cargo liveries,
   • whether aircraft have a mail compartment and to
   • decide the number of victims in crashes.
4. Stations are called "mine" when they are near an "extractive" industry, which produces a cargo that is not liquid (class 6), passenger (class 0) or mail (class 1).
5. Cargoclasses are also exposed to AIs, but likely that does not matter.

I cannot find similar uses of cargoclasses in TTDPatch. TTDPatch uses them in cargodist, but the configuration of that is up to the player anyway.


So, I suggest:

• Class 15 "special" should be kept, as it has indeed special behaviour in the GUI.
• Mail should remain separate from Armoured/Valueables/Express. Mail is a very special passenger-like cargo in TTD, which should be marked as such. (Also think of Cargod[ei]st here.)

[andythenorth]

+/- 1 for these:
- remove hazardous
- remove clean (use a special flag on the cargo instead)
- consolidate oversized/neo-bulk concept (also name this class better)

[planetmaker]

+1 - remove hazardous
+1 - remove clean (use a special flag on the cargo instead)
+1 - consolidate oversized/neo-bulk concept (also name this class better)

[George]

Addendum:
one major problem with the existing spec is the refit mask being XORed. if there were two separate properties for "include these cargos explicitly" and "exclude these cargos explicitly", then changing cargo classes for existing cargos would be much less of a hassle (e.g. no existing sets would break by adding "piece goods" to the GOOD cargo)
maybe that should be covered with GRFv8.

Agree

[George]

Moreover, we shouldn´t care for a covered wagon being "Gags" or "Gas" or something else. IMO, this is way beyond the scope of the game. But whenever the cargo system is discussed, it is derailing almost immediately. Personally, I´d like to keep it simple and *stable* (I´ve already reworked three times the DBXL cargo system due to an ever-changing FIRS). I really don´t like these endless discussions about the same topic every few months. So, my current proposal might be seen as somewhat "provocative".

And why is it not possible to have cargo class and wagon class properties for a cargo? This way cargo sets would be able to provide more information for vehicles sets. On the other side, vehicle sets could make a decision based on the schema they prefer (cargo class, wagon class or both)

P.S. In LV4 I used cargo labels to provide the most appropriate graphics for the cargo transporter. There are not much cargo sets and it was not too hard to support all the cargo labels provided.

[AndersI]

Take an example of an open wagon. How much should it cost to refit from coal to wool? And how much to refit from wool to coal?

If you look at it 'realistically', that refit should only be available when the wagon is newly bought. There's no way a coal carrying wagon will ever be refitted to wool (or oil tanker to milk, etc.).

(Do I lose the discussion now, by using the 'r' word?)

[Eddi]

after a lengthy disagreement with andythenorth on IRC, i feel like i need to clarify some design rules i imposed for my changes on the previous page:

1. imperative for choosing classes of a cargo is the thought "which wagon does this cargo usually go in?", if you come from the perspective of "what properties does this cargo have", you may get to slightly different results.
   
   most apparent is this on the matter of whether GRAI should have "covered"/"moist protected" flag. sure, you'd probably want to prevent rain from falling on your grain, but that can be achieved by a simple tarpaulin on your open wagon, you do not need a special water-tight silo wagon to achieve that.
   
   so if you ask yourself "what should go into a silo/powder wagon", then you get to the conclusion "grain should probably not have this flag, but (powderized) lime or sulphur probably should."
2. there's a set of "basic" cargo classes, which are marked with "OR" in the usage column.
   
   a cargo set author may set as many of these as they want
   a vehicle author should not ever set these bits in the "AND NOT" mask of a vehicle, to ensure at least one vehicle carries these cargos.
   
   Example: we have three cargos: A, B, C. and two vehicles 1 and 2.
   Cargo A is defined as "piece goods", B as "liquid", and C as "piece goods, liquid".
   if the vehicle set author would now define that vehicle 1 is set as "piece goods, but not liquids", and vehicle 2 as "liquids, but not piece goods", then 1 would be refittable to A, 2 would be refittable to B, but this vehicle set cannot support cargo C.
   instead set vehicle 1 to "piece goods", and vehicle 2 to "liquids", resulting in 1 being refittable to A and C, and 2 being refittable to B and C. all cargos can now be transported.
3. there's a set of "specific" cargo classes, which are marked "AND NOT" in the usage column. these are only valid in combination with one basic class.
   
   a cargo set author may only set these bits, if they set the matching basic bits as well.
   a vehicle set author may use these in the "OR" mask, or in the "AND NOT" mask, if the matching basic bit is set in the "OR" mask.
   
   Example: the cargo set author wrongly set cargo D to be of classes "piece goods, needs moisture protection".
   the vehicle set author sets vehicle 3's OR mask to "needs moisture protection" with the assumption that all cargos will be "bulk"/"uncountable", but it would be refittable to cargo D, which is only piece goods.

if we were to adapt these changes, the wiki page about cargo classes should explicitly explain these restrictions/design rules.

[andythenorth]

Cargo types as used in Action 3 are already translated, so we could therefore say that any (valid) cargo type used in Action 3 for a vehicle will automatically be added to the vehicle's refit list.

+1 for that idea.

If the cargo is in the CTT, and not in the action 3, treat it as 'exclude'.

Callback or props 28/29 (trains) using classes for cargos not known in CTT (only provides fallback support for unknown cargos, use labels for known).

[andythenorth]

(1)imperative for choosing classes of a cargo is the thought "which wagon does this cargo usually go in?", if you come from the perspective of "what properties does this cargo have", you may get to slightly different results.

I disagree that cargo authors should be trying to control which vehicles cargo travel in. That's a wrong-headed way to do it imho. The rest of (1) makes complete sense.

(2)...[snip]...a vehicle author should not ever set these bits in the "AND NOT" mask of a vehicle, to ensure at least one vehicle carries these cargos.

Completely agree.

(3)there's a set of "specific" cargo classes, which are marked "AND NOT" in the usage column. these are only valid in combination with one basic class.

The only way I can see this working is if it's enforced in some way.
e.g. we switch AND NOT classes (prop 29 in trains case) to be in the format something like bb pp ll xx

with each byte as a bit mask setting explicit excludes (or maybe it should be include - AND) for specific core class, e.g. bb for bulk, pp piece goods, ll liquids, and xx a combined byte for pax/mail/express/armoured cargos

The bits for the exclude classes would then be moved to bytes, which looks possible to me based on what we're currently treating as 'exclude' classes.

I can see two advantages to this
- vehicle sets can never explicitly exclude one of the core properties, there's simply no method to do it. That would be useful, as these exclusions can and do destroy the class-based fallback support for unknown cargo types.
- there is a little more precision in class based refitting. If the cargo sets 'bulk and needs moisture protection', you can prevent it travelling by open hopper, but if it also sets 'piece goods' you can allow it to travel by open vehicles that support piece goods (and you can draw a mental picture of it being packaged in barrels or whatever, I'm not too bothered about those details when talking about classes).

This would still leave open the possibility that a set doesn't provide vehicles for all the core classes. That can't be helped.

This would involve some complexity imho. It's complex, but actually not complicated

This would limit the 'exclude' classes for each type to 8(?). That is actually too many imho, 4 would be better. If more precision is wanted, then basically the rule should be 'use labels and keep maintaining your vehicle set'.

If this route was adopted, I think adding a new callback for refitting based on classes would then be the wrong route, as it would allow authors to break the robustness of the scheme by accident.

See also action 3 based refitting idea for labels: http://www.tt-forums.net/viewtopic.php?p=979345#p979345

[andythenorth]

So following irc discussion, the newgrf wiki has been updated to remove proposed classes for 'clean' and 'neo-bulk'.

I think 'hazardous' should be left in place, but marked as 'deprecated, do not use'. The only set known to use it so far is eGRVTS, and the usefulness of this class is widely doubted.

I think the neo-bulk proposal should be merged with the oversized class, and reworded. irc discussion seems to be favouring something like 'this cargo needs a flatbed or stake vehicle (or vehicles with removable roof etc)', and that this should only be applied to countable (piece goods) cargos. The intention is to be able to distinguish things like logs and steel, which are awkward to handle.

'express' has been discussed at length with no good suggestion. I think it should be left as-is. It's a convenient way for a cargo to indicate to a vehicle set author 'you probably have some fast cargo vehicles in your set, such as planes, express vans or hovercraft, and this cargo is suitable for them'. It has been suggested that it should be changed to 'air freight'. IRL, this designation doesn't necessarily mean the cargo travels by air, but rather by highly expedited services.

There are is also a proposal for refining 'covered/sheltered' to apply only to bulk, and to maybe imply 'requires pressure discharge' for this class as the silo and covered hopper vehicles for both cases tend to be highly similar.

There is a proposal for 'non-pouring' to apply only to bulk, for cargos like sugar cane, scrap metal, waste, recyclables.

Generally I would prefer removal of (some) classes and treat them as a minimal set of fallbacks, rather than precise support.

Eddi however has some other proposals and appears to be working on a spec

[andythenorth]

Following discussion current proposal is:

New action 0 prop for all vehicle types.

This will be a list of indices into the grfs cargo translation table (CTT).

Cargos from the CTT that are included in this list will be included in the refit list for this vehicle. These are cargos that are known to the grf and considered suitable for this vehicle.

Cargos not included in this list, but in the CTT will be excluded from the refit list. These are cargos that are known to the grf and considered suitable for this vehicle.

Cargos that are not in the CTT are considered unknown to this grf and refittability will be determined via classes, using the current method (props 28/29 for trains and similar for other vehicles, or in an improved fashion (to be determined).

This:
- decouples the labels and classes robustly
- provides an easier interface for many people to use than a bit mask
- provides an easy way for people who use CPP and similar text processors to use defines and templates for cargo refits

[Eddi]

having to add a cargo to every wagon's refit list, just because i need it at one place in the GRF is a horrible thought.

this can only work when there are two lists, an include and an exclude list, for each vehicle.

[michael blunck]

The problem I see it is that there seem to be three proposals in parallel ATM:

- to get rid of the "clean" and "neo-bulk" classes,
- to evert the "cargo class" system into a "wagon class" system, with the side effect of getting rid of some of those not-convincing classes,
- a reorientation of the established cargo/refitting system.

This is problematic, IMO.

I think the neo-bulk proposal should be merged with the oversized class, and reworded. irc discussion seems to be favouring something like 'this cargo needs a flatbed or stake vehicle (or vehicles with removable roof etc)', and that this should only be applied to countable (piece goods) cargos. The intention is to be able to distinguish things like logs and steel, which are awkward to handle.

Well, for DB wagons (before UIC), "k" once stood for "kranbar" (craneable?), i.e. in connection with wagons with sliding roof allowing crane loading/unloading. This would fit that "small doors" problem, but o/c "oversized" originally was aiming at the use of special wagons (low loaders, depressed center flat, or any other special wagon for transporting unusually large or heavy loads). A cargo being "bulky" isn´t really fitting into it, "logs" and "steel slabs" using normal flat cars quite happily.

There are is also a proposal for refining 'covered/sheltered' to apply only to bulk, and to maybe imply 'requires pressure discharge' for this class as the silo and covered hopper vehicles for both cases tend to be highly similar.

"Requires pressure discharge" was never proposed (by me). The idea of "powder/silo wagons" simply derived from the specialty of these wagons being used only for a couple of cargo types, and not fitting well in any of the existing classes, even not in "bulk". OTOH, "covered" could also be used for "piece goods", either transported in vans or under tarps on flat wagons. Tarps giving the possibility to allow some view on the cargo (when being loaded/unloaded) in spite of travelling all "covered".

Generally I would prefer removal of classes and treat them as a minimal set of fallbacks, rather than precise support.

I´d second this, whole-heartedly. OTOH, there are many too "generic" cargoes which makes this hard for a vehicle set author.

regard
Michael

[Michi_cc]

Well, for DB wagons (before UIC), "k" once stood for "kranbar" (craneable?), i.e. in connection with wagons with sliding roof allowing crane loading/unloading. This would fit that "small doors" problem, but o/c "oversized" originally was aiming at the use of special wagons (low loaders, depressed center flat, or any other special wagon for transporting unusually large or heavy loads).

None of the currently defined cargoes is oversized in the sense that it would require special wagons, like for example big transformers do. As you'd need special graphics support for such a cargo anyway, it could just be handled directly with the label instead of any generic cargo classes.

-- Michael Lutz

[michael blunck]

[cargo class "oversized/overweight"]
None of the currently defined cargoes is oversized in the sense that it would require special wagons, like for example big transformers do. [...]

IIRC, ECS´s GLAS and VEHI have that attribute. A "big transformer" would be most probably in VEHI, which always included "machinery" (e.g. as a "supply" for extractive industries) as well.


BTW, congratulations to YAIM. Sounds very promising, although I didn´t find any time to try it.

regards
Michael

[Eddi]

ECS´s GLAS [has] that attribute.

but that rather supports the argument why STEL and WOOD should have it as well. if you don't want to redefine the existing "oversized" cargo class, we need a new cargo class for "doesn't fit into a closed wagon". and as you pointed out previously, we should not add classes too quickly, because only few spots are free.

[michael blunck]

but that rather supports the argument why STEL and WOOD should have it as well. [...]

The question is: do we want to base the cargo(class) scheme in some way on "realism", or do we want to set up a pure "logical" scheme? Usually, I like to be precise, but this doesn´t always work in the TTD domain.

On the same note, you should switch "countable (piece goods)" to "piece goods (countable)", and "uncountable (bulk)" to "bulk (uncountable)". It might be attractive from a mathematical POV, but will look odd from all other POVs.

regards
Michael

[Eddi]

For those not following "secret" discussions, here is my proposed scheme:
http://newgrf-specs.tt-wiki.net/wiki/User:Eddi
(now additionally has a proposal/example for vehicle set design)

but that rather supports the argument why STEL and WOOD should have it as well. [...]

The question is: do we want to base the cargo(class) scheme in some way on "realism", or do we want to set up a pure "logical" scheme? Usually, I like to be precise, but this doesn´t always work in the TTD domain.

Ideally, something in the middle. Although i'm leaning towards "logical" here.

Point 1: STEL and WOOD are very frequent exceptions currently (also see my wagon schemes)
Point 2: Hardly any cargos in TTD-Scale ever need "specialized" wagons, so the original interpretation of "oversized" has almost no meaning.

On the same note, you should switch "countable (piece goods)" to "piece goods (countable)", and "uncountable (bulk)" to "bulk (uncountable)". It might be attractive from a mathematical POV, but will look odd from all other POVs.

done.


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...