Transport Tycoon Forums

This is what I got. That do you think?

I also suggest to rename the topic to
"Cargo classes - Discussion"

P.S. May be I was wrong in uniting ref and armoured into special. May be to add bit 12 "Protected". May be we also need a class "dangerous". But all this is (imho) a question for the second byte, that is used for flags, not first that should define main characteristics.

[slightly OT]

OzTransLtd wrote:AUPT - auto parts

I suppose it's in development, because it's not stated in Wiki? How many new cargos you'll have and which?

OzTransLtd wrote:Yes, I know, the cargo translation table can have up to 255 entries; I have used already 67 of them.

My God, I thought I use biggest number of labels... And I hardly solved them...

[/slightly OT]

Apparently, some people like to complicate things to no end.

Now, that´s not the way I prefer it. When George and me were setting up the ECS scheme, we tried to keep it as simple as possible. E.g., although there are many different animal species with agricultural importance in real life like sheep, cows, hens, turkeys, ..., the ECS category of livestock (LVST) fits them all. There´s absolutely no use to differentiate between them inside the limits of TTD. All "animals" (except fish) are LVST in ECS and that´s sufficient. Same goes with CERE (cereals), although this is a much more complicated issue.

Now, if a newindustries´ author insists to have a special kind for his livestock, there´s always the possibility to use a sub-cargo type, like e.g. "food (beer)", etc. I´ve mentioned this time and again, BTW ...

O/c, same is true for unneeded labels like "AUPT - auto parts". With the same legitimacy, one could "invent" dozens and even hundreds of new labels for every semi-manufactured product. E.g., inside ECS, the proper way to something like this would be to make it an appropriate sub-cargo under either GOOD, STEL or VEHI and use TTDPatch´s cargo class "piece goods".

Now, because this isn´t another discussion about the legitimacy of the existing ECS scheme (it already proved to be succesful), nor the discussion about another and different cargo scheme (not needed), but "only" a discussion about some improvements with regards to TTDPatch´s cargo classes, we don´t need to go over the top once again, but should restrict ourselves to the least possible enhancement of those classes to KEEP IT SIMPLE.

A good approach would be to take into account existing freight wagons. Now, Railion has "more than 100,000 types of freight wagons" (cit.) in its freight car catalogue (available only in German), so let´s take a look into it. But to KEEP IT SIMPLE, I´ll only mention the main class UIC terms here, as well as the appropriate TTDPatch cargo classes:

- E... (open waggons)
These are suitable for many different goods, either bulk (coal, scrap metal, ore, stone, ...) or piece goods (bales, coils, barrels, logs, steel slabs, ...). They may be fitted with tarps to protect against wind and rain. -> bulk | piece goods (+covered/sheltered)

- F... (open self-discharging hoppers)
These are used for all bulk cargo non-sensitive to wind/rain, like coal or ore. -> bulk

- G... (box vans)
These are used to transport all goods sensitive to weather conditions. Goods are usually packaged in bags, crates, cardboard boxes, or palletized. Box vans are also used for fruit and vegetables which don´t need to be cooled. -> mail | piece goods (+express, +refrigerated, +covered/sheltered)

- H... (sliding door wagons)
These wagons are especially suited for loading by fork lifts. Goods may be palletized goods or larger piece goods (like automobile parts). -> piece goods & covered/sheltered (+express)

- I... (refrigerator van)
Used for cooled and refrigerated food (fish, meat, vegetables, fruit, ...), both fresh and processed. -> refrigerated

- K... (flat cars)
These come in different versions: with or without stakes, side and front panels, tarpaulins etc, for transportation of diverse piece goods. -> piece goods

- L... (special cars for automobile and truck transport)
Different versions used for transportation of manufactured cars, or for transportation of loaded trucks (RoRo). -> piece goods

- R/S... (bogie wagons, flat, four/six axles)
These are used for transportation of large and heavy products, namely of the iron and steel producing industry, for prefabricated building materials, semifinished parts, lumber, vehicles, coils etc. They may be fitted with tarps and special appliances for steel coils or large sheet metal boards, or with fastening belts for pipes and trunk wood. -> piece goods

- T... (closed self-discharging hoppers)
Used for bulk cargo sensitive to weather conditions, like cereals. -> bulk & covered/sheltered

- Uc... (silo wagons)
For pulverulent cargoes like cement, sodium carbonate, aluminium oxide, etc., for edible cargoes like sugar, flour, salt, etc. -> bulk & covered/sheltered

- U... (flat cars for heavy cargo)
Usually for machines or machin parts, heavy vehicles, etc. -> piece goods

- Z... tanker
These are used both for edible and non-edible liquid cargoes, as well as for powdered cargo (see Uc... too). -> liquid (+hazardous)



I´ve added cargo class bit9 (covered/sheltered freight) to be able to differentiate between open and closed wagons, to further enhance TTDPatch´s "bulk" cargo class.

Feel free to add more types of wagons and point out what else would be needed.

regards
Michael

Two adds:

- G-series wagons could be used to transport livestock too.
- I-series wagons (refrigerators) could be used for transporting food, fruit, etc.

I like the outline/breakdown of the hoppers. For the North American sets, the T and Uc voppers could be combined as aside from a few rarities, there are no "silo wagons" on the continent.

Wile E. Coyote wrote: - G-series wagons could be used to transport livestock too.
- I-series wagons (refrigerators) could be used for transporting food, fruit, etc.

Thanks. I simply forgot them because Railion doesn´t seem to use refrigerators. In addition, their catalogue misses tankers ("Z") as well. Both added to post above.

DanMacK wrote: For the North American sets, the T and Uc voppers could be combined as aside from a few rarities, there are no "silo wagons" on the continent.

Ah yes. Interesting. "Silo wagons" are quite common over here (but hard to draw ...). BTW, the UIC "T" type stands for every car with removable/opening roof, not only for "hoppers". E.g., there are also "gondolas" with removable roof in this category -> http://www.railfaneurope.net/pix/de/car ... az.jpg.jpg which may be used for piece goods as well.

regards
Michael

With apologies to Michael and George,

First of all, ECS is too entrenched and other than some fine tuning, it can't be changed. Too many sets have committed to it.

Now for the critique:
The problem lies in the "Cargo Types". It is too specific and defines a specific cargo as a type, a situation that would best be handled by "Cargo Labels". Indeed, many Types also have Labels. The ECS scheme requires this with the result being a level of duplication in definitions. The result is a loss of flexibility.

A more elegant solution would have been to define specific cargoes with Labels and then to use the "Cargo Classes" to define type. The "Cargo Classes" table seems to be rather comprehensive although I would have probably used the following:

- Passenger = passenger; tourists;
- Goods (0) = Generic identifier for all cargo types accepted by towns.
- Express = Mail; Luggage/Baggage; Packages; Valuables;
- Break Bulk = Boxed; Bagged; Palleted; Crates; Strapped; Rolled; Baled; Containerized;
- Refrigerated = Break bulk cargo requiring refrigeration or in some cases, heating.
- Livestock = Live animals;
- Fluid = Liquid; Gas;
- Bulk = Loose material;
- Dry Bulk = Bulk materials sensitive to elements/weather
- Engineered = Large engineered items; Machinery; Vehicle; Transformer;
- Custom = Cargoes that do not fit above and requiring special handling methods.
(0) Goods is questionable and would probably be better handled as a cargo that falls under several classes.

Conclusion:

1. Keep ECS with adjustments as and where required.
2. Establish a second scheme that can use the existing Cargo Labels directly with the existing Cargo Classes. The Industry Set author/coder should be aware of the nature of his products and be properly selective as to which class they would fall under. Then the Transportation Set author /coder only needs to provide the appropriate conveyance according to class, all with refit availability automatically being limited to the Labels assigned to a Class, with an occasional need to design specifically to a Label without refit.

wallyweb wrote: The problem lies in the "Cargo Types". It is too specific and defines a specific cargo as a type, a situation that would best be handled by "Cargo Labels". Indeed, many Types also have Labels. The ECS scheme requires this with the result being a level of duplication in definitions. The result is a loss of flexibility.

Mmh, I´m not sure if I understand this right. Let me elaborate a bit about the way cargoes (and cargo types) are "defined" in ECS.

On the one hand, due to the restriction of 32 cargoes to be used simultaneously, a "clash" of categories and sub-categories in the ECS cargo list seemed to be unavoidable. E.g., because of its importance (both in RL and in the game), we tried to stuff as many important cargoes into the agricultural vector. Yet, due to the 32 cargoes limit, a couple of problems arose: although "cereals" is a vast category in RL, in ECS it doesn´t contain "leguminous crops" (beans, peas, lentils, ...) nor vegetables. And although we succeded in including important sub-categories ("oil seeds", "fibre crops", and "fruits") we´re lacking many products and whole sub-categories, especially for the tropics, like sugar cane, rice, and even grapes.

For some of ECS´s other categories in the agricultural vector, this looks much better, "fish" and "livestock" are OK, IMO.

For other large groups of products, e.g. the cargoes of "manufacturing of food products", we´re supporting only the general term "food" in our scheme, but none of the products of it´s important constituent sub-categories like meat, dairy products, grain mill products, bakery products, or tobacco, or beverages. O/c, especially in this group, the cargo sub-type mechanism seems to work well: "food (tobacco)" or "food (beer)" are acceptable, IMO.

Another large group, namely products of "manufacture of textiles" (wearing apparel, leather, footwear, ...), is missing completely in our scheme. Instead, this has been subsumed under "goods", being the generic cargo explicitly delivered to towns. This had been a point intensively discussed in the past.

Likewise the "wood manufacturing" sector. We decided to introduce a rather artificial and generic term here ("wood products"). Fortunately enough, this too works OK with cargo sub-types: "wood products (wooden chips)" or wood products (plywood)" seems OK to me.

"Paper" is a rather generic term in itself. We don´t differentiate here, although the term stands for a whole category as well as for a specific product. One reason for this decision was to keep compatibility with the original cargoes as much as possible.

Now, where I see the largest problems with the clash of categories and sub-categories in ECS is in the "chemical sector": Usually, this one is divided between "manufacture of coke" and "manufacture of refined petroleum products" (due to the different kind of industries involved). Now, in ECS "refined products" has been chosen the main term for a diverse amount of products like basic chemicals, plastics, pesticides, paints and varnishes, soap, detergents, man-made fibres, pharmaceuticals, rubber products, ... some very important sectors in their own, but we could only use a generic term again. OTOH, some of the constituent members of this category have been chosen to be present in ECS as own products, as an example, like "fertilizer" or "dyes". This is due to two reasons: the important chemical sector should have been represented by more than just one general term, and there were already industries in TTD which would be suitable for these products, namely farms (->"fertilizer") and "printing works" (->"dyes").

A more elegant solution would have been to define specific cargoes with Labels and then to use the "Cargo Classes" to define type. The "Cargo Classes" table seems to be rather comprehensive although I would have probably used the following:

Well, IMO "cargo classes" are quite a different categorisation than "cargo types". Even with the aforementioned restrictions and shortcomings, "cargo types" are names of specific products, product sub-categories, or even categories, which have nothing in common with the special means of its transportation. OTOH, "cargo classes" are linked directly with the way of transportation: "express", "refrigerated", "bulk", ..., are all addressing specific types of freight wagons or services. Although, there are some ambiguities like "passengers" which on the one hand stands for the type of cargo ("voyagers") and OTOH for the special requirements of its transportation (in local passenger trains, express trains, first class, ..., you name it).

These two different views shouldn´t been mixed up. That´s exactly why I was addressing RL freight wagon categories when thinking about possible enhancements of those cargo classes.

- Passenger = passenger; tourists;

This one would be OK, although it still preserves that old ambiguity.

- Goods = Generic identifier for all cargo types accepted by towns.

This is exactly the way GOOD is defined in ECS, hence a special cargo class would be superfluous.

- Express = Mail; Luggage/Bagage; Packages; Valuables;

OK

- Break Bulk = Boxed; Palletted; Crates; Strapped; Rolled; Baled; Containerized;

These would all be "piece goods" according to my understanding.

- Refrigerated = Break bulk cargo requiring refrigeration or in some cases, heating.

Well, "refrigerated" refers to the use of special vehicles, namely "refrigerators". I know of "heating" only in connection with tankers.

- Livestock = Live animals;

More or less a tautology, not needed if we stick to the ECS definition of LVST and probably use cargo-subtypes in case someone insists on having e.g. "horses" as a specific cargo.

- Fluid = Liquid; Gas;

Well, "liquid" is good enough, IMO. Firstly, because most gases would be transported in liquified form in RL, and secondly, we don´t have to differentiate between tankers for low pressure or high pressure in TTD, n´est-ce pas?

- Bulk = Loose material;

OK. But keep in mind that even "scrap metal" would be bulk then.

- Dry Bulk = Bulk materials sensitive to elements/weather

Yes, that makes sense. OTOH, I´ve already proposed the class "covered/sheltered" which wouldn´t only fit for bulk but also for piece goods where you´ll also find cargoes sensitive to weather.

- Engineered = Large engineered items; Machinery; Vehicle; Transformer;

That´s "piece goods", definitely. I don´t understand why should there be a need to split "piece goods" in such many sub-classes? To ensure transportation in the right variant of flat wagon you could define "heavy"?

- Custom = Cargoes that do not fit above and requiring special handling methods.

Yeah, that wouldn´t help anything for a better connection cargo/industry .grf to vehicle .grf.

Conclusion:

1. Keep ECS with adjustments as and where required.

S.a. What exactly are your propositions for adjustments?

2. Establish a second scheme that can use the existing Cargo Labels directly with the existing Cargo Classes. The Industry Set author/coder should be aware of the nature of his products and be properly selective as to which class they would fall under.

IMO, that´s already the case. Say, I wanted to design "fish" as a new cargo, then I´d would set the (existing) cargo class "refrigerated" (and possibly "express") for that cargo to give vehicle sets a clue what type of wagons they should use. Problem remains in case no such vehicle would be available in a certain vehicle set.

Then the Transportation Set author /coder only needs to provide the appropriate conveyance according to class, all with refit availability automatically being limited to the Labels assigned to a Class, with an occasional need to design specifically to a Label without refit.

Yes, we already have that.

regards
Michael

Thanks for your comments Michael. As insightful as ever and much appreciated.

First an apology. In my Cargo Classes table, I should have indicated that the items to the right of the "=" signs were examples of packaging (or lack thereof) that would be best handled by a wagon class. Hence my note (0) questioning whether goods should appear as a class in that table where they would be better described as a generic form of packaging.

What I was trying to address was that transportation providers (railroads, airlines, shipping, trucking, bus, etc.) are more concerned with the physical properties of the package rather than what is inside the package. For the sake of TTDX, we have to know what is inside the package. All that the Transportation Set authors/coders need to know is how to handle the package with consideration given to special handling requirements determined by the Industry Set authors/coders. (Refrigerated, Heated, Open, Covered etc.)

My use of "Refrigerated" was unfortunate. "Climate controlled" would have been more appropriate. Heated service is a very serious consideration here in North America (and probably similar locations elsewhere) where many products are just as sensitive to cold as they are to heat. DanMack would be the authority on that aspect for North America. The guy is a walking railroad encyclopedia (Canadian Edition).

Break Bulk or Piece Goods is a matter of semantics. The intent remains the same.
Fluid or Liquid ... more semantics although my physics instructor would probably kick me for saying that.
Dry Bulk or covered/sheltered ... semantics. Thanks for adding it in though. It was needed.
Scrap Metal as Bulk? Yep! Sure is bulky. I agree.
"Heavy"! That's the word I was looking for. I was not comfortable with "Engineered".
I would expect Vehicles to be more in line with piece goods or heavy. "Custom" was included just in case. I don't expect it would ever be used in TTDX, but you never know what some of those crazy forum members are going to suggest that some enterprising set author decides to use.

Now, on to Cargo Labels and Cargo Types ...
If I understand you correctly, Cargo Types addresses the 32 cargo type limitation. Obviously it works for ECS and especially George's Vectors. But, does it have to be so set in stone? Why couldn't another Industry Set author/coder simply bypass it while keeping in mind that they are still limited to 32 types which they could define directly with labels? If it is mandated by the TTDX internals or the Patch internals, what is to prevent another Industry Set author/coder from modifying it to their own needs? Or is the ECS Cargo Type table analogous to the Cargo Translation Table (might be the wrong term) I see mentioned from time to time?

"What exactly are your propositions for adjustments?" I have none ... I was merely being open ended.

"Problem remains in case no such vehicle would be available in a certain vehicle set." - Box Car seems to be the catch-all of choice until the Vehicle Set author/coder decides to provide something more appropriate. Our faithful forum members will keep after them should they remain delinquent.

Then the Transportation Set author /coder only needs to provide the appropriate conveyance according to class, all with refit availability automatically being limited to the Labels assigned to a Class, with an occasional need to design specifically to a Label without refit.

Yes, we already have that.

Then why is OzTransLtd so frustrated?

Respectfully

Wally

George wrote: ... spreadsheet cargo classes ...

Thanks, I'll work through it and incorporate it with what I've already got.

Wile E. Coyote wrote: ... AUPT (auto parts) ...

Yes, these cargoes are for the North American Industry Set by DanMack. It is very much WIP and not much has happened yet. They haven't been added to the wiki, they are part of the Automobile Manufacturing Vector.

Wile E. Coyote wrote: ... why so many cargoes in the translation table ?

My Cargo Translation Table has 2 sections; 1 .. 32 for cargoes that need bits set in the refit mask (property 1D) [currently 27 (actually), then there are 5 spares left], 33+ for cargoes that are used either in ...

a) aiding the AI in purchasing correct equipment
b) being able to allocate differing liveries depending on actual cargo carried

With both these options I have absolutely no problem; I simply need an entry in the table and there is enough room. That table is large because I have to include all known cargo types of all industry sets I want to provide compatibility; i.e. ECS, Pikka Industries, NAIS.

Thinking about the AI brings me to an idea. The AI asks me what equipment it should purchase to carry cargo XXXX (slot in table), I am able to provide an absolute correct choice. Of course, it must be refittable to, otherwise things get stuck.

Now, why can't we have the same for the human player. ATM, there is an 'internal' refit table (array) to which the GRF has absolutely no access, it cannot build it nor can't it read the table. This table is built by using information from properties 28/29 (cargo class) as well as 1D (refit mask).

For cargo types known to the GRF :
There could be a generic callback [triggered by either a new flag, property 27; or simply if the vehicle carries cargo]. It would be called when that internal refit table is built; i.e. for every vehicle that carries cargo, one by one. The CB provides the vehicle ID and an iteration to the GRF, and the GRF would return all cargo types (slot in CTT) one by one. Once done or if there are no refittable cargoes 0xFF or let the CB fail. This would cater for all cargoes known to the GRF in an absolute precise way. We would not waste any bits in the refit mask, nor would we need cargo classes.

For cargo types unknown to the GRF :
There we still have the option of using the cargo class, together with the refit mask (to not add a cargo type, if in cargo class but bit is set). These cargo types would be added to the refit table after the above callback and if it finds a cargo type already there it would simply leave things as they are. However, it would still not solve our problem, but at least this would only apply to cargo types unknown to the GRF.

Thus, the cargo label would come in very handy, we could add up to 255 cargo types to a single vehicle without any problems, not that we would want to do that, of course.

michael blunck wrote: ... LVST = livestock (pigs) or FOOD = food (beer) ...

Why, then do we have tourists [TOUR] as cargo type, why not passengers (tourists) ? TOUR is defined as an ECS cargo type, is it not ?

michael blunck wrote:... I´ve added cargo class bit9 (covered/sheltered freight) to be able to differentiate between open and closed wagons, to further enhance TTDPatch´s "bulk" cargo class. ...

Now, that is jumping the gun, or let's jump in quickly while the door is still open. We have not come to any conclusion yet and nothing has been signed off. I do believe, in protecting existing definitions and settings, but that one would not qualify, as it has been added after we started our discussion.

wallyweb wrote: ... [exhaustive explanation] ...

I hear you loud an clear what you mean, but currently how things are this is not possible, because if I use cargo types by label, I waste too many bits in the refit mask; if I use cargo types by class, I end up with inappropriate cargoes refittable to for my freight cars, like iron ore, cement, copper ore, grain, clay, cereals ... That is the problem. I am not in the same situation as George, who just needs to provide 32 cargo types to his LVs; or like a developer who just deals with his/her only sets, which are industry/cargo and vehicles as a combination. If I had a Canadian Industry Set at my disposal, I would give a hoot what those Europeans do.

In ECS there are all those vectors, a player selects one or two; I have to deal with all of them at once, plus with all other industry/cargo sets as well.

Then we have those rather complex freight wagon schemes; e.g. we have simple box cars, hi-cube box cars, express cars, container flat beds, double stack containers, road railers. All of them are capable of carrying anything that is suitable for a box car. To make game play more interesting/challenging, we allocate different cargo types to different cars. Of course a player could just put everything in ordinary box cars a be done with, forget about all the other options.

Then there is that other problem; when I did the cargo type allocation scheme for my freight cars. There was 'Fertiliser', defined as 'bulk' 'piece goods', I dealt with it appropriately. Now it is defined as liquid fertiliser, when that happened, I don't know. Where I explicitly excluded it, it has become refittable to (ore car) and where I explicitly included it (box car), it is now inappropriate. Now, it should go into a tanker. Well, I can fix that, but once the set has been released, I'm not prepared to modify the set all the time, just because a new cargo type has been invented or an existing one changed.

Where from here ? I still have to finish my spreadsheet, and things no longer look as bad. With additional bit definitions (leaving all existing ones intact and in place) in the cargo class definition would get us much closer to a solution. Existing vehicle set would only need some mods if they use cargo classes with intent. So far, nobody has come forward and said : 'I use cargo classes in my vehicle set(s) and these are the already released sets that would have to be changed.'.

Just in case, anyone is wondering ... this discussion isn't over yet and it will be resumed as soon as I have sorted through all the information that has come to light just recently. It seems, there is a bugs and design fault galore, and if not addressed the outlook for the current cargo scheme is very grim indeed ...

... and I still don't know, what released sets are currently using cargo classes to allocate cargoes to freight cars; I now assume, there aren't any, as my request for that information has resulted in nil responses.

My generic road vehicle and tram set uses only generic cargo classes to allocate refittable/non-refittable classes...

I think the main problem of the cargo classes is their inconsistent use.
PLAS is liquid OR piece goods, and TOUR is passengers AND express.
What we need is to stick to a single operand.
AFAIR, the game uses AND to combine cargo classes, and the tanker won't carry plastic unless you add piece goods to its feature 28. If the patch/OpenTTD could be changed to use OR instead, the whole system could be simplified greatly by explicitly ANDing common class combinations into a new class:
The lower byte would have generic cargo types:
bulk (COAL, LIME, GRVL, SAND, POTA, SULP ...)
heavy bulk or simply ore (IORE, CORE)
sheltered bulk (CERE, OLSD, CMNT, CLAY, PLAS, FERT, WDPR ...)
piece goods (GOOD, GLAS, WDPR, STEL ...)
heavy piece goods (STEL, VEHI ...)
sheltered piece goods (FICR, DYES, PAPR ...)
liquids (OIL_, WATR, DYES ...)
The eighth type would probably be another bulk class, to simplify the coding of gondolas. Maybe a piece goods class is not needed, as most piece goods are sheltered piece goods. It can be replaced with two more flatcar-related classes instead: large flat piece goods and long round piece goods (see also the upper byte).

Hopper cars would carry bulk.
Ore cars would carry heavy bulk.
Covered hoppers would carry bulk and sheltered bulk.
Gondolas woud carry piece goods and bulk and sheltered bulk (or only gondolable cargo).
Boxcars would carry all 3 types of piece goods and sheltered bulk (in sacks).
Hi-cube boxcars would carry piece goods, sheltered piece goods and sheltered bulk.
Heavy flatcars would carry heavy piece goods.

The upper byte would use carriage specific classes:
passenger
mail
armoured
logs (or long round piece goods, like pipes or posts)
refrigerated
stock
The seventh and eighth types are open for discussion. Maybe it can be vehicles for autoracks and large flat cargo for centerbeam flatcars. I don't think a class for cement silos is needed - if someone makes a grf with several cement cargos, he can take his own life himself. Maybe even a vehicle class is not needed.

onodera wrote: ... the main problem of the cargo classes is their inconsistent use ...

That is one, but the fact that the GRF author has no control what cargo types become refittable to via cargo classes is the major one. This is then further complicated, with having bit(s) set in property 0x1D.

Currently, if you (must) use cargo classes, then set prop 0x1D to zero and if you do have bit(s) set in 0x1D then cargo class properties 0x28/29 should be 0x0000/0xFFFF respectively; 0x29 being the more important one. Thus, your set will work with 'new' cargo types. The CanSet is proof of that; I've yet to receive a single complaint attributable to the CanSet, which can transport 40 cargo types.

One day, CTS will come your way and then it will work for everybody whether they like it or not. This project is being worked on without further input from other parties; it will just happen.

onodera wrote:AFAIR, the game uses AND to combine cargo classes, and the tanker won't carry plastic unless you add piece goods to its feature 28.

No, that's wrong. Vehicles will be refittable to a cargo if;

a, at least one of the bits in their property 28 matches at least one of the bits in the cargo class; and
b, none of the bits in their property 29 match any of the bits in the cargo class.

Thus a vehicle with property 28 set to 00 60 and 29 set to 00 80 would be able to carry any bulk or liquid cargo that was not refrigerated. It seems to me that some of the cargo classes are "basic" classes which should be used with property 28 (Passengers, Mail, Bulk, Liquid, Piece) while others are "modifiers" which make more sense to be used with property 29 (refrigerated, hazardous, covered). "Express", I'll grant you, is a problem; the default cargos use it like a basic class (Goods, for example, has only this class set), but George uses it like a modifier class in his definition of Tourists. Perhaps this could be made more standardised by adding the Piece, Bulk and Liquid classes to Goods and Food. I don't think it's a huge deal though; there just aren't that many cargo types currently defined, and any legacy inconsistency is easy enough to work around.

Attached is the cargo refitting scheme I used for the generic road vehicle set, I think this one works well...

*edit* forgot my second sentance! The current cargo refit classes are very powerful for defining both cargoes and refittability, I really don't think an alternative is necessary.

This is a longer and better written version of my previous comment:

When designing a new cargo classes scheme, you have to keep in mind two things. The first one is forward compatibility. I can make US Set cars carry any currently implemented cargo, ECS or PBI. But if George changes his chemical vector as he said he wants to do, I'll have to rehash the code, as the better half of my cars uses only cargo labels. I could follow George’s advice and juggle the classes around to cut down on the amount of labels I use, but that'd still be a problem, as the combinations are not quite obvious and will not be forward compatible. An example: both cereals and coal have the same cargo class - 0010 (bulk). I have to use labels to XOR coal out in my boxcar and cereals in my mineral hopper. But what if some other vector will implement rice or bauxite? I will have to XOR them out as well. I may run out of labels if this continues and will have to make a separate label table for each industry set. And a separate mapping for each set-car combination.

The second one is carriage-orientedness. The final goal of all these labels and classes is determining what cargo can ride in what car. Therefore, the classes we provide should be easily and straightforwardly mapped to the rolling stock. Only this way both cargo and vehicle set coders will be able to provide support for any cargo. If we define an "animal" class, does it help? Livestock rides in stock vans, passengers, if they're unhappy enough to be classified as animals, ride in a plethora of passenger wagons, meat rides in reefers, milk rides in tank cars. Will it help the coders even a little bit? Or "raw" and "processed" classes. A boxcar carries "raw vegetable" grain and "processed mineral" glass. It doesn't carry "raw mineral" coal, which it will if we define the classes as such. To reiterate: cargo class doesn't define the properties of the cargo as much as it does define the properties of the rolling stock that carries it.

The third one (ha-ha, I lied to you when I said two) is avoiding AND logic. For example, we define the following classes: bulk, piece goods, sheltered. What is carried in a covered hopper, then?
>>>Action 28 is bulk or sheltered
Of course, we wanted to say bulk AND sheltered, but now we get sheltered piece goods in our hopper. Fine...
>>>Action 29 is piece goods
Okay, now we don't have piece goods in the hopper, but we still get non-sheltered bulk, like gravel and iron ore. Let's define an "ordinary" secondary class and force every bulk cargo that is not sheltered to use it.
>>>Action 29 is piece goods or ordinary
Wow, we did it. Our covered hopper carries correct cargo now. Let's try and screw something else up, shall we?

For example, a boxcar! A boxcar is a very versatile car, it can carry allsorts of piece goods and it can carry sheltered bulk (sacks of grain, etc.)
>>>Action 28 is piece goods or bulk or sheltered
Guess what? Now the boxcar can carry gravel and coal! Try and remove it from there using Action 29. Yes, you can stuff every ordinary bulk into your CTT, and XOR it out, but then someone will implement bauxite or phosphate, and you are screwed.
Let’s try a different approach. Grain is always sheltered, and is either bulk or piece goods. Any other cargo like this is also changed.
>>>Action 28 is piece goods or sheltered
Wow, now our boxcar is working fine. But guess what? Our covered hopper is broken.

Trying to add any AND logic to your cargo classes is a road to madness. This means any sensible AND combinations should be coded beforehand.

Let's start with the list of the most common cars:
Hopper
ore hopper
covered hopper
gondola
stake flatcar
centerbeam flatcar
heavy flatcar
boxcar
container
tanker
pax
mail
armoured
livestock
reefer
coil car
autorack
cement silo

Can't we simply use them as our cargo classes? Hm, we only have 16 classes and 18 cars. But guess what? Autorack carries only cars, and cement silo carries only cement. And coil car carries only steel. We can put these 3cargos into the label table and avoid using a separate class for them. Livestock vans and mail cars are also very specialized cars. Someone can try to implement sheep and pigs, letter sacks and parcels. They are perverts, of course, and should be ignored.13 cars left. That should be enough to implement a perfect 1-1 mapping. If you want, you can add bulkhead flatcars and hicube boxcars (which carry lighter cargo than ordinary ones). 15 cars, 16 classes? Cool, ain't it?

Okay, maybe this layout is a bit inflexible. Maybe we want a class for roadrailers and a class for a silo wagon that can carry not only cement, but also sugar.

In that case we can reshuffle all the bulk and piece goods carriers into the following classes:
bulk
heavy bulk
sheltered bulk
piece goods
heavy PG
sheltered PG

And the following simple classes:
long PG (timber, pipes, stake flatcar)
flat PG (plywood, drywall, centerbeam flatcar)
liquids
passengers
mail
armoured
stock
refrigerated

Two (four, if we scrap mail and stock) classes left. You can even add a class for pulverized bulk, if you want to support silos explicitly.

This way you also ensure forward compatibility. For example, your skyscraper building set has marble: heavy PG (for huge pieces of marble)flat PG (for flat slabs)Okay, now it can travel in boxcars and on heavy and centerbeam flatcars.

What about bauxite?
heavy bulk, and it travels in ore hoppers

Aluminum?
piece goods, and it fits in gondolas, boxcars, containers...

Sugarcane?
sheltered bulk, and it fits in covered hoppers and boxcars.

Of course, there are still some problems left. If you add tanks, they can only travel on heavy flatcars, not in boxcars like cars can. But hey, who's gonna have tanks as a cargo in TTD?

---------------------------------------------

And a reply to OzTransLtd's post about milk and oil sharing the same tankcar ("Further to this, I am really puzzled why crude oil, water, petrol, milk and honey are not distinguished; no wonder why there is so much food poisoning happening."). This is a straw man. We do not have an ability to refit a car on the fly or share it between the trains. We cannot write an order that looks like this:

Go to Chadinghattan Oil Wells (load)
Go to Milliburton Oil Refinery (unload)
Go to Milliburton Farm (load)
Go to Chadinghattan Food Processing Plant (unload)

And not even like this:
Go to Chadinghattan Oil Wells (load)
Go to Milliburton Oil Refinery (unload)
Go to the Milliburton depot
Refit to milk
Go to Milliburton Farm (load)
Go to Chadinghattan Food Processing Plant (unload)
Go to the Chadinghattan depot
Refit to oil

If, for some reason, you want to save some money and refit your oil tankers to milk, you have to do it manually. You can imagine that the refit cost includes cleaning and installing a glass lining, or you can stretch your imagination and imagine that you sell the oil tanker and buy a milk tanker. Or you can actually sell an oil tanker and buy a milk tanker. No one is forcing milk into a dirty oil tank car in TTD. Of course, someone might want to implement different sorts of tank cars in their set: simple tanks cars for oil and petrol, glass-lined tank cars for acid, glass-lined tank cars for milk and water, pressurised tank cars for natural gas, chlorine and ammonia... I say we slap them around till they come to their senses and start using action 3 for this kind of stuff.

And Oz, your project will not happen without input from other parties, because it’s these other parties that will have to modify their sets to make them work with your scheme.

onodera wrote:And Oz, your project will not happen without input from other parties, because it’s these other parties that will have to modify their sets to make them work with your scheme.

I must step in here in OzTransLtd's defense. I am currently using the latest version of the Canadian Train Set. As far as I know, it uses CTS. I have used it with it's support for the default TTDX industries. It worked very nicely. Chris Sawyer didn't have to change anything. I am currently using it with a full seven vector load of George's ECS industries. It is working very nicely. George didn't have to change anything. I haven't used PikkaBird's industries yet, but they are next on my list and I expect that they will find similar excellent support. Note that I am not a coder nor a dev. I am merely a player who will use whatever works, and CanSet works. If it is indeed using CTS, then CTS works as well.

I agree that this project can only benefit from input from other parties, but then, that is the purpose of this thread, is it not?

wallyweb wrote:

onodera wrote:And Oz, your project will not happen without input from other parties, because it’s these other parties that will have to modify their sets to make them work with your scheme.

I must step in here in OzTransLtd's defense. I am currently using the latest version of the Canadian Train Set. As far as I know, it uses CTS. I have used it with it's support for the default TTDX industries. It worked very nicely. Chris Sawyer didn't have to change anything. I am currently using it with a full seven vector load of George's ECS industries. It is working very nicely. George didn't have to change anything. I haven't used PikkaBird's industries yet, but they are next on my list and I expect that they will find similar excellent support. Note that I am not a coder nor a dev. I am merely a player who will use whatever works, and CanSet works. If it is indeed using CTS, then CTS works as well.

I agree that this project can only benefit from input from other parties, but then, that is the purpose of this thread, is it not?

As far as I know from the CanSet documentation, it doesn't use any classes at all, apart from express (for goods), armoured, passengers and mail. Everything else is using cargo labels, which is why it doesn't support sulphur.

onodera wrote:As far as I know from the CanSet documentation, it doesn't use any classes at all, apart from express (for goods), armoured, passengers and mail. Everything else is using cargo labels, which is why it doesn't support sulphur.

Correct. I don't know whether the limitation is a function of TTDX or the Patch, but I would think that the proper fix would be to arrange for more cargoes to be supported. Classes seems to be more of a work around than a fix. An unfortunate effect is that the class choses the wagon and was originally quite Eurocentric. Rail systems in other regions, particularly North America, occasionally, if not often, used other solutions for wagon/cargo compatibility. As for sulphur, I had some input in that decision. My reasoning was that it did not contribute as much to game play and as an income source as did the other cargoes. As it turns out, it would appear that George is of a similar mind as he mentioned sulphur specifically as one of the reasons for his considering a major rework of the Chemical Vector.