Proposal - Cargo Class refinement

[Eddi]

B - mail vans, also usable for "valuables"

i think this should be "D" instead, to coincide with the real classification

to compare your proposal (how i understand it) with mine:

Code: Select all

wagon | OR-mask   | AND-mask                              |
type  | c | u | l |s-m|ali|pou|n-p|ref|arm|lar|lig|hea|cov|
-----------------------------------------------------------
 A    | x         | x                                     |
 D    | x         |             x       x       x       x |
 E O  |     x     |         x   x               x   x     |
 F    |     x     |         x                   x   x     |
 G T  | x         |             x               x   x   x |
 H    | x         |     x       x               x   x   x |
 I    | x         |             x   x           x       x |
 KLRS | x         |             x           x   x   x     |
 U    |     x     |         x                   x   x   x |
 U2   | x         |             x           x       x     |
 Z    |         x |         x                   x   x   x |

(note that no set actually defines a cargo such as "transformers", so the U2 type is fairly useless)

andythenorth brought up the issue of his mining trucks, which should not be used for "light" cargo like fibre crops, which would result in something like:

Code: Select all

 F2   |     x     |         x                       x     |

[michael blunck]

i think this should be "D" instead, to coincide with the real classification

Arrgh! A typo, copy&pasted .. .. fixed now.

to compare your proposal (how i understand it) with mine:

Nice table.

Something like this:

Code: Select all

Vehicle classes (16)

See train prop. 28/29 for a description of the utility of this property.

This is a bit mask of all vehicle classes to which this cargo belongs, out of the following:
Bit	Value	Vehicle class 
0	1	A (passenger coaches) 
1	2	D (mail and luggage vans, also for cargo type "valuables") 
2	4	Express cargo(*) 
3	8	Armored cargo(*)  
4	10	E (ordinary open high- and low-sided wagons) 
5	20	G (ordinary covered wagons, box cars, vans) 
6	40	Z (tank wagons)
7	80	I (refrigerator wagons)

8	100	F (special open high-sided wagons)
9	200	T (goods wagons with opening roof)
10	400	K (ordinary flat wagons)
11	800	L (special flat wagons, automobile transporters) 
12	1000	H (special covered wagons, livestock transporters, sliding wall wagons)
13	2000	U (special wagons: silo wagons, low-loaders)
14	4000	<unused>
15	8000	<unused>

------
* obsolete cargo classes retained because of compatibility reasons for original TTD cargoes  

Only cargos which are in class 0 (passengers) will appear in bus stations. Only cargos which are not in class 0 will appear in truck stations.

regards
Michael

[andythenorth]

It would be interesting to see the UIC classes worked through for ships, road vehicles (including trams) and planes. They're an appealing concept, but rather train specific currently.

[andythenorth]

I wanted to try and codify some more thoughts on this.

1. there could be alternatives (as suggested by Eddi, Michael), but the class system is one option
- cargo set author stuff -
2. cargo authors need to treat cargo classes as OR
3. cargo authors should not be concerned about what vehicles carry what, only what the intrinsic properties of the cargo are
4. setting lots of classes is probably unwise (I can't prove this, but I think it will hold)
5. freight cargos should set at least one of: bulk, piece, liquid; this ensures widespread cargo support
6. don't use real-life transport examples as a guide to the classes, use the intrinsic properties. Milk can travel in churns, oil can travel in barrels, water can travel in bottles, but all are properly liquid not piece goods. If a vehicle set author wants to allow liquid transport by box van (liquid in containers), it's up to them
- vehicle set author stuff -
7. vehicle set authors should include at least one of: bulk, piece, liquid; exceptions for special vehicles or label-based support only (planetmaker has evidence that I am wrong about this)
8. vehicle set authors should not exclude: bulk, piece, liquid; this is likely to lead to poor support for future cargos
9. labels and explicit support are the solution to awkward cargos (highly specific cases)
10. vehicle set authors should only exclude the known classes (i.e only set the known class bits). Setting a general exclude may damage the abstraction in future

[TadeuszD]

Hello!
I'm new on this forum, but I'm NewGRF developer on polish OTTD forum.

I'm reading this topic very carefully, because I'm using cargo classes in my NewGRF very often. In my opinion, using UIC classification is very interesting proposal, but too complicated... Remember, that wagons with one type (i.e. "G") have many subtypes. For example, wagon described Gags can carry grain, but Gas don't. You can't correct this exceptions without additional cargo "subtypes" and complicated AND and OR dependences. And, what about cars and planes?

In my opinion, in (O)TTD we have only a few base "cargo classes":
- passangers,
- bulk,
- goods,
- liquid.
This classes shouldn't be mixed. Typically, the carriage intended to carry passangers can't carry goods or liquid.

Next, we have "cargo subclasses":
- valuables,
- armored,
- covered,
- food,
- refrigerated,
- oversized,
- special
This cargo subclasses is intended for mixing with base cargo classes.

No another classes or subclasses is needed. We can obtain many different cargos by mixing cargo classes and subclasses, using AND operator. For example, you can define cargos:
goods + valuables = mail,
goods + valuables + armored = gold, diamonds...
passangers + valuables = VIP?
bulk = coal, ore, sand...
goods = wood, bricks, concrete, steel...
bulk + covered = cemment, lime...
goods + oversized = cars, containers, long pipes, long pieces of wood...
goods + oversized + special = transformers (?)
goods + covered = paper, cotton, furniture, clothes, TV, devices...
bulk + food = corn, sugar-beet...
bulk + food + covered = grain...
goods + food = tinned food, noodles, jam...
bulk + food + refrigerated = frozen fish (raw)...
goods + food + refrigerated = portioned meat, frozen vegetables, dairy products...
etc.

If we define a new wagon or a car, you can enable or disable any subclasses.
For example, the wagon for "dirty" cargos should be defined by allowing bulk class and forbiding covered and food subclasses.

Tadeusz

[Eddi]

Something like this:
[...]

i have a few problems with this

• it needs much more clarification, e.g. what is a "special open wagon"?
• the class "U" covers two entirely distinct things, so should be split in two classes
• the class "F" is a subset of class "E"
• what's the specialty of class "T"? which cargos benefit from that?
• class "H" combines both the problems of "U" (covers two entirely different things) and "T" (what are the benefits of sliding walls?)

I wanted to try and codify some more thoughts on this.
[...]
6. don't use real-life transport examples as a guide to the classes, use the intrinsic properties. Milk can travel in churns, oil can travel in barrels, water can travel in bottles, but all are properly liquid not piece goods. If a vehicle set author wants to allow liquid transport by box van (liquid in containers), it's up to them
[...]

i disagree with this one. e.g. for beer, you find far more examples of it being transported as piece goods (bottles, crates, barrels) than as liquid (tank wagons), so the cargo classes should reflect that.

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.

[michael blunck]

In my opinion, using UIC classification is very interesting proposal, but too complicated... Remember, that wagons with one type (i.e. "G") have many subtypes. For example, wagon described Gags can carry grain, but Gas don't. You can't correct this exceptions without additional cargo "subtypes" and complicated AND and OR dependences. And, what about cars and planes?

I don´t think the "wagon class" scheme is more complicated as an ever-increasing cargo class system. In fact, we´ve already eliminated 2 entries. And if it´d be possible to get rid of those "obsolete" classes (EXPRESS, ARMOURED) in some way, and possibly clean up some of the old stuff ("goods" being EXPRESS only), it´d get even more simple.

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

[insertion]
Most important, the cargo system should be a particular topic for the newGRF authors (both cargo set authors and vehicle set authors working together (I´m missing George in this thread)). It should not be primarily a topic for OTTD developers not concerned with newGRF authoring. That won´t do any good, but most probably complicate everything.
[/insertion]

With regards to other vehicle classes (rvs, ships, planes), I think the proposed scheme could be carried over, most easily for rvs, but also for ships (there are way less ship types than freight wagon types (in this very scope)).

E.g.:
class - railway car <-> ship
E - (ordinary open high- and low-sided wagon) <-> (bulk carrier)
G - (ordinary covered wagon, box car, van) <-> (general cargo ship)
Z - (tank wagon) <-> (tanker)
I - (refrigerator wagon) <-> (reefer)
...

W/r to aircraft, I don´t know anything about air freight classification.

i have a few problems with this
it needs much more clarification, e.g. what is a "special open wagon"?

You mean "F"? Mainly self-discharging hoppers.

the class "U" covers two entirely distinct things, so should be split in two classes

Not necissarily. You could always get away by setting more than one class in the cargo specification. OTOH, those heavy-load flatcars could be taken out of U and put into a different class, either K or into a new class "S", if *needed*.

the class "F" is a subset of class "E"

Probably. Boiled down, we´d end with only two classes: rigid and liquid.

I think the difference is significant: open wagons would start as E and later advance to F (capacity, speed, loading time).

what's the specialty of class "T"? which cargos benefit from that?

It´s kind of a "multivariate" wagon. It could be used as an open wagon but also as a closed one. Hence acceptable for moisture-sensitive freight, but also for that "bulky" piece goods.

class "H" combines both the problems of "U" (covers two entirely different things) and "T" (what are the benefits of sliding walls?)

Modern H are generally wagons with high volume, hence especially convenient for "light" cargo (FICR?). In addition, they allow short loading times because of their very large doors. The old type of H (livestock) could be problematic, but in any way we need a vehicle for livestock transportation, do we?

one major problem with the existing spec is the refit mask being XORed

You´re thinking of a technical problem or a comprehension problem?

regards
Michael

[Eddi]

i have a few problems with this
it needs much more clarification, e.g. what is a "special open wagon"?

You mean "F"? Mainly self-discharging hoppers.

i didn't mean I don't know what it is, but the description should be more elaborate so others can grasp what it means without researching UIC classifications first.

the class "U" covers two entirely distinct things, so should be split in two classes

Not necissarily. You could always get away by setting more than one class in the cargo specification. OTOH, those heavy-load flatcars could be taken out of U and put into a different class, either K or into a new class "S", if *needed*.

a transformer should not be carried in a wagon for pulverized moist-sensitive cargo and vice versa. that's the point of a cargo class. so splitting this off is rather mandatory, or we gain nothing.

what's the specialty of class "T"? which cargos benefit from that?

It´s kind of a "multivariate" wagon. It could be used as an open wagon but also as a closed one. Hence acceptable for moisture-sensitive freight, but also for that "bulky" piece goods.

but that same could be achieved by setting the wagon type to both "G" and "K". that doesn't need a special class from the cargo's point of view.

class "H" combines both the problems of "U" (covers two entirely different things) and "T" (what are the benefits of sliding walls?)

Modern H are generally wagons with high volume, hence especially convenient for "light" cargo (FICR?). In addition, they allow short loading times because of their very large doors. The old type of H (livestock) could be problematic, but in any way we need a vehicle for livestock transportation, do we?

again like above, it should be split into a separate class for "lightweight" and "livestock" cargos, as these are transported by totally distinct sets of wagons. (which coincidentally brings us back to my post at the beginning of this thread)

one major problem with the existing spec is the refit mask being XORed

You´re thinking of a technical problem or a comprehension problem?

i mean a technical problem here. if previously some set designer set his vehicle to refit to "piece goods, and additionally GOOD", then changing the GOOD cargo to also be "piece goods" would remove the cargo from the refitability list. if we had separate include and exclude masks in the first place, nothing would change, so it would be perfectly fine to change the specs in this way.

[planetmaker]

i mean a technical problem here. if previously some set designer set his vehicle to refit to "piece goods, and additionally GOOD", then changing the GOOD cargo to also be "piece goods" would remove the cargo from the refitability list. if we had separate include and exclude masks in the first place, nothing would change, so it would be perfectly fine to change the specs in this way.

Indeed, this probably would un-complicate cargo classes quite a bit as it would de-couple classes and labels.

[andythenorth]

The XOR on the refit mask cripples the abstraction of classes scheme quite horribly.

The refit cb proposed by frosch would not have that problem, and would also permit access to CTT entries >32 when refitting.

Irrespective of the final class schema, I am very much in favour of the cb route. If its shipped, I would encourage adoption by all sets that are being actively developed.

[michael blunck]

i have a few problems with this
it needs much more clarification, e.g. what is a "special open wagon"?

You mean "F"? Mainly self-discharging hoppers.

i didn't mean I don't know what it is, but the description should be more elaborate so others can grasp what it means without researching UIC classifications first.

Ah yes. O/c this has to be explained somewhere. Moreover, an identical scheme had to be set up for the other vehicle classes.

Not necissarily. You could always get away by setting more than one class in the cargo specification. OTOH, those heavy-load flatcars could be taken out of U and put into a different class, either K or into a new class "S", if *needed*.

a transformer should not be carried in a wagon for pulverized moist-sensitive cargo and vice versa. that's the point of a cargo class. so splitting this off is rather mandatory, or we gain nothing.

It´s kind of a "multivariate" wagon. It could be used as an open wagon but also as a closed one. Hence acceptable for moisture-sensitive freight, but also for that "bulky" piece goods.

but that same could be achieved by setting the wagon type to both "G" and "K". that doesn't need a special class from the cargo's point of view.

Well , the idea is to replace "cargo classes" by "wagon classes", so that an industry/cargo set would define the wagon class needed. It would not define any cargo attributes. Further idea is to not change the existing system with cargo class bits and interaction with the cargo mask. It´s just the interpretation of those bits which would be changed.

After some experiments, I´ve found that allocation of (railway) vehicles could be significantly simplified. O/c, question remains if it´s easier for a cargo set author to define cargo attributes or the proper wagon class to be used with a particular cargo.

if previously some set designer set his vehicle to refit to "piece goods, and additionally GOOD", then changing the GOOD cargo to also be "piece goods" would remove the cargo from the refitability list.

But that´s somewhat hypothetically, right? To my knowledge, a set designer cannot change GOOD to "piece goods".

The XOR on the refit mask cripples the abstraction of classes scheme quite horribly.

This may not have been the best bet in the first place (it was Josef´s idea) but it works as intended, and it´s understandable, isn´t it?

The refit cb proposed by frosch would not have that problem, and would also permit access to CTT entries >32 when refitting.

Well, yes. There is a limitation with the cargo mask (a DWORD), but it is quite possible to handle all ECS plus FIRS cargoes simultaneously in this way. I had already done it and I didn´t need even 16 entries for that.


Some remarks w/r to the existing system of cargo class.

The first 8 classes are "basic" classes. As a cargo set author, you should/must define one of them. Other classes are thought to be refinements to describe the cargo even further.

There are o/c some problems with the actual class list:

- EXPRESS makes no sense. Especially, it makes no sense to have GOOD with only this class,
- likewise, HAZARDOUS makes no sense. Years ago someone put it in the list but to my knowledge it is used in no set and I doubt its usage would make any sense,
- SPECIAL makes no sense too, in fact it causes more trouble than benefit,
- CLEAN is completely useless in this context, because it deals only with refit cost (IMO),
- NEO-BULK is unnecessary. IMO it complicates things, instead of simplifying them,

- there were questions w/r to OVERSIZED: this is an additional attribute for exceptionally large or heavy piece goods (primarily), requesting special means of transportation, i.e. special freight cars (depressed-center flats, ...)
- POWDER has a similar function: it addresses those cargoes which are bulk but cannot be transported in the usual hopper wagons because of their pulverulent form, making it impossible for gravity-unload. Instead it requires very special wagons (silo-wagons).

From a set developer´s POV, these additions make sense because they reduce the number of exceptions to deal with in setting cargo masks.

regards
Michael

[Eddi]

you can unify "neo-bulk" and "oversized" if you define it to mean "needing special treatment, because it's larger than a usual crate/palette".

in your scheme that would mean either "can travel in class E, but not in class F" (e.g. wool, sugar cane, fibre crops, livestock (?)), or "must travel in class K" (e.g. wood, steel, ...)

[andythenorth]

I would be in favour of unifying neo-bulk and oversized to something like 'inconvenient' (better term needed), for exactly reasons Eddi stated.

I can't see how to use 'oversized' meaningfully. I might add a molten steel torpedo car, a low loader, a heavy-lift ship, an antonov, a schnabel car, or a glass transporter. Then I'm going to need to add support for specific labels anyway, or it's not going to make a lot of sense.

I proposed neo-bulk as a way to help authors exclude certain cargos which can be piece, bulk (or both), but aren't handled well by e.g. hoppers and/or covered vehicles with small doors. I am happy to see the idea be consolidated or refined, I'm not sure that it can be easily discarded.

Express - the historical reasons for this are lost on me, but it seems widely used as a convenience class, especially for aircraft sets that want to allow some cargos. It seems to equate to both 'lightweight' and/or 'priority. I have no idea if it should be removed or not, but it's clearly seeing practical use in sets.

Clean - I think this was a nice idea we had for refit cost tricks, but it's an abuse of the class system, and in that form, is a bad idea.

Hazardous - I don't see a use for this in refits. It's at once too detailed a requirement, and too vague. It *would* be useful to authors who want to do things like restrict vehicle speed limits when carrying hazardous cargo, or enforce the use of a caboose on trains carrying hazardous cargo. Yes, it's arguably an intrinsic property of the cargo so maybe a class, but the gameplay use doesn't seem to be for controlling refitting, so plausibly making it a refit class is an abuse.

Special - used for regearing and other tricks? I (inconsistently) set it as an exclude to prevent any quirky cargos appearing in future.



One clever abuse of the refit class system was a nice hack (special). As more such hacks get suggested - clean, hazardous(?) - this makes the core refit function more complicated and more fragmented. Suggests there might be a requirement for extensible properties of cargos that do not rely on abusing refit classes.

[michael blunck]

you can unify "neo-bulk" and "oversized" if you define it to mean "needing special treatment, because it's larger than a usual crate/palette".

Well, yes:

- NEO-BULK is unnecessary. [...]

It´s probably not a 1:1 mapping (especially not for the term in RL) but in game terms there could be an overlap of ~90%?

in your scheme that would mean either "can travel in class E, but not in class F" (e.g. wool, sugar cane, fibre crops, livestock (?)), or "must travel in class K" (e.g. wood, steel, ...)

The latter is envisaged for "oversized". And in fact, even more than a "K" is needed, more something like an "Ui" or "Uaai".

I can't see how to use 'oversized' meaningfully. I might add a molten steel torpedo car, a low loader, a heavy-lift ship, an antonov, a schnabel car, or a glass transporter. Then I'm going to need to add support for specific labels anyway, or it's not going to make a lot of sense.

Well, it´s kind of a "preselection" like any other of those "additional" classes. And something like this will be always the case, except we make cargo classes == cargo type.

Express - the historical reasons for this are lost on me, but it seems widely used as a convenience class, especially for aircraft sets that want to allow some cargos. It seems to equate to both 'lightweight' and/or 'priority. I have no idea if it should be removed or not, but it's clearly seeing practical use in sets.

I don´t see any practical use in my sets for it, and I´ve been cultivating reservations ever so long. Now, that I seem to remember that "express" was Josef´s idea, I have been digging in my old mails, et voilà:

"The origin of specific cargo classes" - Discussion with Josef Drexler, 24.08.05:

mb> [...]

JD> Meine Liste dafuer waere: Passagiere, Post, Expressfracht (Gueter,
JD> Essen, Wertsachen?), Schuettgut, Stueckgut, Fluessigkeiten. Sonst noch
JD> was? Dies waere dann wohl eine Bitmaske, so dass eine Fracht mehrere
JD> dieser Arten sein kann.

JD> Dann wuerde man bei den Fahrzeugen zusaetzlich eine entsprechende
JD> Bitmaske angeben, auf welche dieser Arten es umruestbar sein soll.
JD> Evtl. noch eine Einstellung, wie das mit der urspruenglichen Refitmaske
JD> verknuepft werden soll, entweder ein bitweises ODER (also umruestbar
JD> wenn eine Frachtart entweder in der Umruestmaske erscheint, oder den
JD> richtigen Typ hat), oder ein AND NOT, also umruestbar, wenn es den
JD> richtigen Typ hat aber NICHT in der Umruestmaske erscheint. Das waere
JD> dann allerdings inkompatibel mit aelteren Alphas, scheint mir aber
JD> flexibler zu sein. Alternativ koennte es auch zwei solcher Masken
JD> geben, eine additiv und eine subtraktiv, so dass man sagen koennte
JD> "Expressfracht aber keine Fluessigfracht". Was meinst du?

mb > Ist so OK. Man könnte natürlich "Post" unter "Expressfracht"
mb > einordnen, aber das wäre bestimmt gegen den Geist von TTD. :) Und
mb > "Kühlgut" könnte eine eigene Kategorie sein (Lebensmittel, Bier,
mb > Fische, ...), bzw man könnte "Expressfracht" umbenennen, denn was
mb > soll das sonst noch sein? Bloss Wertsachen? Wenn das nur "Güter"
mb > wären könnte man das schlecht unterscheiden, Container zB wären ja
mb > keine Expressfracht, sondern sogar eher langsam. Mmh.

JD> Kuehlgut ist eine gute Idee. Expressfracht habe ich im Hinblick auf den
JD> Transrapid "erfunden", das waeren also die Frachtarten, die man sich
JD> vorstellen koennte, dass sie vom Transrapid transportiert werden.

I´m too lazy to translate it ATM, but in fact I didn´t liked it from the beginning, but then it had been included for the TransRapid, resp for all other maglevs as well. Other than that, an interesting read, also w/r to that XOR/OR/AND discussion ...

Hazardous - I don't see a use for this in refits. [...]

As I said. It had been included into the list by somebody unknown and it had never been used. I´d strongly vote for a removal.

Special - used for regearing and other tricks?

Refiting of no-cargo vehicles (engines) can be done in other ways. This class is not needed, it derogates usage of proper cargo types (e.g. in ECS) and should be removed.

Some more free bits to play with, hehe.

regards
Michael

[wallyweb]

... 'inconvenient' (better term needed)

'specialized' / 'dedicated' / 'custom' ... take your pick ... From the discussion it would seem that we are trying to define a class of cargo that is not conveniently handled by standard/typical mass transport solutions. The problem with this is that for visible cargoes, a vehicle set author would have to have an individualized graphic for every possibility that an industry set author could dream up. Note that this goes beyond a simple recolouring of a bulk mineral cargo. For what is essentially a simple game, do we really need this degree of specialization?

I proposed neo-bulk as a way to help authors exclude certain cargos

Wouldn't this then fit under 'inconvenient' / 'specialized' / 'dedicated' / 'custom' ? Once more, do we really need this degree of specialization?

Express - the historical reasons for this are lost on me

I can't speak to the European experience, but in North America, 'express' usually referred to single items/parcels addressed to one address and that are inconvenient for postal handling. Today this is currently handled by courier services such as UPS and FedEx. Historically, the service was provided by railroads using a boxcar/van in passenger livery and attached to a passenger train where baggage cars were dedicated to 'baggage' and mail cars were dedicated to 'mail'. Note that the Express Cars were not normally dropped at a siding for loading/unloading, but rather parcels were handled individually at each station while passengers did whatever passengers do at a station stop. For the sake of a tycoon's sense of competitive dominance, this was a convenient way to include 'goods' in a passenger consist. For the sake of the game, this is a convenient way to include 'goods' in a passenger consist.

Clean

'inconvenient' / 'specialized' / 'dedicated' / 'custom' ?

Hazardous

'inconvenient' / 'specialized' / 'dedicated' / 'custom' ?

Special - used for regearing and other tricks? I (inconsistently) set it as an exclude to prevent any quirky cargos appearing in future.

Obviously a hack. How about a 'hack' cargo class for these situations until such time as the developers come up with an appropriate game side solution?

One clever abuse of the refit class system was a nice hack (special). As more such hacks get suggested - clean, hazardous(?) - this makes the core refit function more complicated and more fragmented. Suggests there might be a requirement for extensible properties of cargos that do not rely on abusing refit classes.

Again, do we really need this degree of specialization?

[planetmaker]

Clean

'inconvenient' / 'specialized' / 'dedicated' / 'custom' ?

Nah, that wouldn't fit. But as it's not a means which descripts an intrinsic cargo property, but means to describe or distinguish options for refit this might be ill-placed in the cargo classes. The initial idea behind this is to distinguish the amount of cleaning needed between refitting a wagon from grain to sugar beet as opposed when the wagon initially had potash, clay or coal loaded. Or from water to milk as opposed from crude oil to milk.

But maybe a property or flag for this kind of thing is better suited

[andythenorth]

From the discussion it would seem that we are trying to define a class of cargo that is not conveniently handled by standard/typical mass transport solutions.

(wrt neo-bulk) it's simply a class of cargos that "don't fit through doors neatly" That applies as much to trying to drop logs out the bottom of a hopper car as it does to fitting heavy machinery through the doors of a box car. Any cargo in this class can be placed into an open vehicle (gondola, dropside truck), or a flat vehicle (flatbed, stake car etc) and unloaded by a range of means.

It's not essential. But it's a matter of convenience for vehicle set authors.

For the sake of the game, this is a convenient way to include 'goods' in a passenger consist.

Convenience is the main thing in favour of this class. Especially for plane grf authors.

Obviously a hack. How about a 'hack' cargo class for these situations until such time as the developers come up with an appropriate game side solution?

Doesn't help. Adding hack classes is a way of storing additional information about the cargo. Adding the 'hack' class does nothing to add information.

Again, do we really need this degree of specialization?

It's not clear that we do. It arises from the new refit-cost cb. 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?

[michael blunck]

[...] How much should it cost to refit from coal to wool? And how much to refit from wool to coal?

No one knows.

Nobody either knows about maintenance cost .. . I.e., it´s a set- and game-balancing issue. I.e.², it has nothing to do with cargo classes.

regards
Michael

[andythenorth]

Nobody either knows about maintenance cost .. . I.e., it´s a set- and game-balancing issue. I.e.², it has nothing to do with cargo classes.

I agree - refit cost is the proper decision of the vehicle set, not the cargo set. Should the cargo be able to provide hints to the vehicle set about this?

[wallyweb]

The initial idea behind this is to distinguish the amount of cleaning needed between refitting a wagon ...

This smacks of overkill. How would this enhance the player's gaming experience other than adding another complication for that player to contend with?

But maybe a property or flag for this kind of thing is better suited

Agreed.

Should the cargo be able to provide hints to the vehicle set about this?

This smacks of overkill. How would this enhance the player's gaming experience other than adding another complication for that player to contend with?

(wrt neo-bulk)... It's not essential. But it's a matter of convenience for vehicle set authors.

Overkill is convenient?

Adding hack classes is a way of storing additional information about the cargo.

More overkill?

It arises from the new refit-cost cb.

Was this really needed to enhance the player's gaming experience?

Whatever happened to the K.I.S.S princilpal?