Transport Tycoon Forums

Could it be that everyone is talking about something else here? Regardless of labels or classes, the primary question seems to be if there should be some kind of abstraction layer between the actual cargoes and the vehicles transporting them. The obvious difficulties of some vehicle set authors with the current options seem to promote that idea. Now an abstraction layer should group cargoes by their properties, possibly in various dimensions. From the top of my head, not claiming completeness:
- aggregate: is it fluid or bulky?
- dumpable: can you heap it up and shovel it around (for example coal or grain)?
- edibility: is it edible or inedible?
- weather affected: should it be protected from weather influence or not?
- refrigerated: should it be kept cool?
- valuable: should it be kept safe from intruders?
- lifeform: is it human, animal or lifeless?
- express: does it need a fast delivery?
A cargo set author would define one value of each dimension for each cargo. Coal for example would be bulky, dumpable, inedible, non-weather-affected, non-refrigerated, invaluable, lifeless and non-express. A vehicle set author would then provide vehicles also with a value for each dimension. Cargo can only be transported in a vehicle if it matches all the dimension values of the vehicle. For greater flexibility each dimension may also allow a "don't care" value which matches all values of that dimension on the cargo side. A box car has bulky, don't care, don't care, don't care, uncool, invaluable, lifeless and slow. From this perspective we only need _one_ abstraction layer, not two. In fact any secondary labelling mechanism seems to be redundant and a waste of bits. How to squeeze all that into 32 (?) bits I don't know, but it should be possible.
The benefit is obvious though. Both, the cargo and vehicle authors don't need to explicitly support the other side, but only define general properties of their vehicles and cargoes to be compatible with _all_ sets of the other side that also do that.

fonso wrote:Could it be that everyone is talking about something else here? Regardless of labels or classes, the primary question seems to be if there should be some kind of abstraction layer between the actual cargoes and the vehicles transporting them. The obvious difficulties of some vehicle set authors with the current options seem to promote that idea. Now an abstraction layer should group cargoes by their properties, possibly in various dimensions. From the top of my head, not claiming completeness:
- aggregate: is it fluid or bulky?
- dumpable: can you heap it up and shovel it around (for example coal or grain)?
- edibility: is it edible or inedible?
- weather affected: should it be protected from weather influence or not?
- refrigerated: should it be kept cool?
- valuable: should it be kept safe from intruders?
- lifeform: is it human, animal or lifeless?
- express: does it need a fast delivery?
A cargo set author would define one value of each dimension for each cargo. Coal for example would be bulky, dumpable, inedible, non-weather-affected, non-refrigerated, invaluable, lifeless and non-express. A vehicle set author would then provide vehicles also with a value for each dimension. Cargo can only be transported in a vehicle if it matches all the dimension values of the vehicle. For greater flexibility each dimension may also allow a "don't care" value which matches all values of that dimension on the cargo side. A box car has bulky, don't care, don't care, don't care, uncool, invaluable, lifeless and slow. From this perspective we only need _one_ abstraction layer, not two. In fact any secondary labelling mechanism seems to be redundant and a waste of bits. How to squeeze all that into 32 (?) bits I don't know, but it should be possible.
The benefit is obvious though. Both, the cargo and vehicle authors don't need to explicitly support the other side, but only define general properties of their vehicles and cargoes to be compatible with _all_ sets of the other side that also do that.

This requires modifying TTDPatch and OpenTTD. Right now we're stuck with classes.

I am a newbie that stumbled upon this thread by accident, but somehow got really interested in this cargo class problem, and ended up reading the entire thread.

It seems to me that since these classes are supposed to help the computer AI decide on appropriate wagons to use when presented with unknown cargos types, wouldn't it be easier if cargo classes were instead "wagon suitabililty" classes. This means that the classes would be the different characteristics of train wagons instead of the properties of cargos. The designer coming up with new cargo types will specify which type of wagon(s) his cargo should be placed in, what characteristics are compulsory, what characteristics are defintely not to be considered, and what characteristics are optional.

I'm not sure how feasible this is at the programing level, though it seems to me to be the easier solution from a purely logical point of view. My two cents and thanks for all the work.

onodera wrote: ... confusion ... I'd rather we stopped using "ECS" to refer to the current cargo classes. It seems to confuse people

You are welcome to call the current scheme [ECS] the 'old/current' Cargo Transportation Scheme [CTS]; that leaves George's ECS industries as they are and the two are totally different things.

From now on, if I say ECS, I mean George's ECS industries; if I say CTS, I mean either the old/current or new cargo scheme.

This topic is about the link between rail, road, sea and air transportation sets and industry/cargo sets and the lack of a properly working interface between the two. It is a technical issue. It could be solved by changes to the Patch, but this is no longer an option as those developers have retired.

To get the 'new' CTS working, we don't need changes to the Patch, just some new definitions of cargo classes.

wallyweb wrote: ... As I understand it, [new] CTS would avoid classes. The transportation set coder would assign wagons directly according to the cargo labels supported by an industry set. ...

That is what we do today to get things working. The new CTS would indeed use cargo classes.

wallyweb wrote: ... I believe that your [George's] ECS Industries currently has the most cargoes. How many? ...

ECS vectors make available a maximum of 32 cargo types at any one time, depending on climate and vectors activated. But, that is not the issue. Currently the CanSet deals with 41 cargo types (and I can add one more) successfully. Why 41 ? First there are all the cargo types used in temperate and arctic ECS vectors; but I had to add 'grain/wheat' in case a player decides not to use the ECS Agri vector; because ECS uses 'cereals' instead of 'grain/wheat/maize' but any transportation set must support TTD 'original' cargo types too. Then, there are other cargo types that have nothing to do with ECS vectors.

The main problem is that a transportation set must be able to support many more cargo types than the largest industry/cargo set does (consider ECS vectors to be one single set).

Today, a vehicle transportation set must be able to support :

. ECS by George
. UKrsi by Pikkabird (including bricks chain)
. TTD 'original' industries

We can do that successfully, but in future we must support NAIS (North American Industry Set) too. That is when things will get very tricky and that is why we are having this discussion.

The main obstacle is the way cargo classes (properties 0x28/29) can influence the way the refit mask (property 0x1D) works. As long as a transportation set developer keeps them separated by having 0x1D set to zero when 0x28 is not and vice versa things work out. But with many more cargo types on the horizon this will not be possible.

... labels ...

There are no problems with labels, they are an integral part of the system and clearly identify a cargo type, but we can only use a maximum of 32 for refitting purposes. Currently, there is only one of them that has been used incorrectly; i.e. FERT=fertiliser, this should be changed into FRTD for dry fertiliser and FRTL for liquid fertiliser, because some industry and transportation sets assume fertiliser to be dry or liquid.

George wrote: ... In LV4 I have 54 entries in translation table. But I use only 4 entries in the refit list and in fact I need only 2 entries there ...

Yes George, I hear you loud and clear and you said it many times ... but you have a road vehicle set you deal with and it is your own set. I can make my own transportation and industry/cargo sets working with each other with little problems. Just try your hands on a rail set ... and the future will tell how well LV4 will cope with NAIS and ECS and ???.

fonso wrote: ... Both, the cargo and vehicle authors don't need to explicitly support the other side, but only define general properties of their vehicles and cargoes to be compatible with _all_ sets of the other side that also do that. ...

That is what we try to achieve. A transportation set should not have to worry about industry/cargo sets. In the end any rail, road, sea or air transportation set should be able to deal properly with any other industry/cargo set. Currently this is not possible and that is why we need a 'new' CTS.

engk wrote: ... It seems to me that since these classes are supposed to help the computer AI decide on appropriate wagons to use when presented with unknown cargo types ...

The funny thing is that the AI does have absolutely no problems in getting the correct wagon and with callback 18 we can guide it to a precise choice. It's the human player we have problems with.

How far have we gone by now ?

Things are no longer as bleak as they were when we started this discussions.

There will be no need for patch changes.

Industry/cargo set developers have the least to worry about, all they will have to do is changing property 16 (cargo class) and may be the odd cargo label. The new CTS could be implemented easily together with the old one by having the new properties only applied depending on a parameter setting and/or automatic set detection.

Transportation set developers that do not wish to update their sets to the new CTS will not have to do so, at worst they'll get inappropriate choices of wagon selection, but they would get that with the old CTS anyway.

Complex transportation sets (e.g. CanSet, USset, DBset ...) will benefit from making them 'new' CTS compliant.

The Canadian Trains Set v0.4 (@DanMacK: what you had noted as v0.4 will be v0.5 now) will be 'new' CTS compliant and it will support all TTD 'original' as well as all ECS vector and/or NAIS cargo types plus any other industry/cargo set that adopts the new scheme.

OzTransLtd wrote:Industry/cargo set developers have the least to worry about, all they will have to do is changing property 16 (cargo class) and may be the odd cargo label. The new CTS could be implemented easily together with the old one by having the new properties only applied depending on a parameter setting and/or automatic set detection.

Sorry, I can't find it fast. Did you suggest new cargo classes list for all ECS cargoes?

George wrote:Sorry, I can't find it fast. Did you suggest new cargo classes list for all ECS cargoes?

So, you're trying to retrofit a new abstraction layer into that basically broken system of classes and labels without changing any code. Did I get that right? That sounds adventurous, to say the least. But it could actually work on a limited scale, if you assign some of the most common combinations of cargo characteristics to a cargo class each. What about the following:

(aggregate/dumpability/edibility/weather-affectedness/refrigeration/value/lifeform/express status: non-exclusive example)
("-" means "don't care")
1. fluid/-/inedible/-/uncooled/invaluable/lifeless/non-express: oil tank car
2. fluid/-/edible/-/uncooled/invaluable/lifeless/non-express: milk/water/whatever tank car
3. bulky/dumpable/inedible/non-weather-affected/uncooled/invaluable/lifeless/non-express: minerals hopper, other raw material
4. bulky/dumpable/edible/weather affected/uncooled/invaluable/lifeless/non-express: covered grain hopper
5. bulky/undumpable/inedible/non-weather-affected/uncooled/invaluable/lifeless/non-express: wood, large things on flat cars
6. -/-/-/weather-affected/uncooled/invaluable/lifeless/non-express: box cars or containers
7. -/-/-/-/cooled/invaluable/lifeless/non-express: refrigerated cars
8. -/-/-/-/-/human/express: passenger cars
9. -/-/-/-/-/animal/-: cattle cars
10. bulky/-/inedible/weather-affected/uncooled/invaluable/lifeless/express: mail cars
11. bulky/-/inedible/weather-affected/uncooled/-/lifeless/express: armoured cars

These are 11. I guess there's room for at least another 4. Don't give them names, but only numbers and characteristics. If you define classes by a set of cargo characteristics, the cargo and vehicle set authors don't have to play around with each other's sets. If you give the classes names you'll be misleading someone to think of exclusive means of transport or exclusive cargo provided.

You will get collisions of course. Grain is either 4 or 6 for example. As I understand that there is a mechanism to overcome that by assigning multiple cargo classes to a vehicle. That's of course the wrong way around. You want to assign multiple cargo classes to a cargo and only one to a vehicle. Is that possible?

OzTransLtd wrote:The main problem is that a transportation set must be able to support many more cargo types than the largest industry/cargo set does (consider ECS vectors to be one single set).

Today, a vehicle transportation set must be able to support :

. ECS by George
. UKrsi by Pikkabird (including bricks chain)
. TTD 'original' industries

We can do that successfully, but in future we must support NAIS (North American Industry Set) too. That is when things will get very tricky and that is why we are having this discussion.

What current cargo classes can be used?

A group of cargos can be refered to by a single class/class combo and reside in the upper half of the CTT
only when:
1. They all share a class.
2. They all share a vehicle type.
3. They aren't used in any other combination.

1. Armoured cargo: GOLD, DIAM, VALU.
2. Liquid cargo: OIL_, RFPR, PETR, WATR, DYES (dyes do have a second class, but is also exportable). FERT and CMNT can't be exported, as they travel as bulk as well.
3. Piece goods that travel in boxcars or containers: PAPR WOOL CERA GLAS DYES
4. Reefer goods: FRUT FISH (FOOD is not always refrigerated)
5. Sheltered bulk: GRAI WHEA MAIZ CERE OLSD (fertilizer and cement have other modes of transportation)
6. Passengers: TOUR (PASS have to be in the main CTT)

Twenty cargoes. This lets us use at least 52 different cargos. There are 45 cargos in the ECS including original ones. If we add non-exportable nickel ore, nickel, copper, bauxite, aluminum, pulp and lumber from PBI and NAIS, we are already at 52. Bump.

If we make GRAI, WHEA, MAIZ and GOLD, DIAM, VALU share their slots and provide a separate table for each climate, we'll have 4 free slots left. Still not enough in case some other cargo set decides to implement more cargoes that do not fit into the 6 categories above, like coke, phosphate, wallboard etc.