New Cargo Transportation Scheme [CTS] – Discussion ...

Discuss, get help with, or post new graphics for TTDPatch and OpenTTD, using the NewGRF system, here. Graphics for plain TTD also acceptable here.

Moderator: Graphics Moderators

User avatar
OzTrans
Tycoon
Tycoon
Posts: 1680
Joined: 04 Mar 2005 01:07

New Cargo Transportation Scheme [CTS] – Discussion ...

Post by OzTrans »

The discussion started here shall continue in this topic ... first a reply to a comment in the other topic ...
DaleStan wrote: ... Try not setting more than one of "piece", "bulk", and "liquid" for any given cargo. ...
That is precisely what I do; an example :

Ore Hopper : primary cargo iron ore, include cargo class 0010h, exclude all other classes FFFEh.

This will now give me a huge list of cargoes refittable to; now I go and exclude, coal, wheat, cereal, cement, oil seeds, potash, sulphur and gravel (or all cargoes defined as bulk only and not desirable), wasting a lot of bits in the bit mask. This should leave me with iron ore and copper ore. as well as sand, lime stone and gravel plus maybe a few other eligible ones.

Now someone goes and removes the refrigerated flag from fruit, and I end up with fruit in my ore car; who is going to eat that afterwards. Or, someone believes oil seeds should be changed from bulk to something else; I will end up with oil seeds in my ore hopper. This situation is not acceptable, I would have to change my set far too often.

I've already used up 28 of the 32 bits in the bit mask, I have very little room to move and I will definitely not release a set, that makes unsuitable cargoes available (refittable) for some of the freight wagons.


Now to the Cargo Transportation Scheme (CTS) ...

We need a reliable interface between industry/cargo sets and vehicle sets; the Extended Cargo Scheme [ECS] has failed; actually it has never worked in the first place. It is inadequate and needs to be replaced. Once a new scheme has been adopted, every vehicle set developer, that wants to provide transportation for cargoes beyond the 'original' TTD cargoes must use it; so do the industry/cargo set developers.

The cargo set developers have the easy job by simply defining cargo class (cargo property 16) correctly. BTW, all reference to properties and variables refer to the train ones.

The interface is simply the cargo class. These cargo classes must be redefined; once agreed they will be set in concrete. This scheme aims to avoid cargoes, like crude oil, milk, petrol or water, having the same cargo class. Here is a suggestion of the 16 possible, new or redefined, cargo classes :

1] (0001h) passengers (must be retained, as various functions within TTDPatch/OpenTTD rely on it)

2] (0002h) mail (same as above)

[The following classes will always exclude the 2 above.]

The next 3 classes define the cargo as in 'Is it Animal, Vegetable or Mineral' ? Each cargo will have one and only one of these defined :

3] Animal, for a cargo, like livestock.

4] Vegetable, all cargoes that are edible, but are not still an animal alive.

5] Mineral, all cargoes, that would be hard to swallow, like coal, ore or timber.

Then we come to the origin of the cargo; there are 2 classes, each cargo will have maximum one of these defined :

6] Raw material, everything that has been dug up or chopped down, e.g. coal, ore, timber

7] Processed, for cargoes that have been processed, e.g. livestock -> meat, iron ore -> steel, pulp -> paper.

The next 4 classes define its transportability; again each cargo will have one and only one of these defined :

8] Bulk, everything that would be transportable in an open wagon (a sided wagon not a flat bed), or on the back of a truck and could be exposed to nature, like rain.

9] Packaged, now packaged does not necessarily mean, a bag or a box, it also means protected from the environment; i.e. it needs to be undercover, like grain, wheat; or consists of fine particle nature, like cement or potash. a packaged cargo goes in box cars, covered hoppers or containers.

10] Liquid, all cargoes, that traditionally are transported in tankers. If it is not a tanker cargo, it most probably would be defined as packaged.

11] Piece Cargo, everything of bulky nature, that is happy to be transported in the open, like timber, machinery or motor vehicles.

Next come the finer and optional definitions :

12] Refrigerated, a perishable cargo that requires refrigeration, like fish or milk.

13] Express, a cargo that should be transported as quickly as possible, like tourists, although tourists could simply be defined passengers only. Maybe this one could be depreciated.

14] Armoured, the armour class might even be scrapped too. We'll leave it in for the moment, but if we do need another class it might have to go.

15] Special, simply a flag that this cargo is of special nature; like Pikka's gear boxes.

16] [spare one]

Note: the numbering at this stage does not represent the bit setting.

Now in the wiki, there is the 'hazardous' class defined. I would use the special class for that one. The vehicle set developer most probably will use the cargo label to provide transport in special purpose wagons; otherwise it is just another ore like cargo.

Example :
a) Uranium Ore could be defined as 'Mineral', 'Raw Material', 'Packaged' as it shouldn't be transported in open wagons.
b) Uranium itself would be defined as 'Mineral', 'Processed', 'Packaged'.
c) Depleted Uranium, the same as Uranium.

Having these classes and sub classes would allow industry/cargo set developers to more precisely define their cargoes and vehicle set developers would be able to choose what goes into a particular vehicle with more accuracy. A special purpose wagon would use the cargo label (bit in bit mask) only; e.g. coal wagon would define COAL in prop 16, 0000h/FFFFh for 28/29 respectively. The ore hopper would then allow 'Mineral' + 'Raw Material' + 'Bulk' class, automatically excluding edible stuff. The only thing would be to exclude coal.

The cargo class is the only link between vehicle sets and cargo sets. Whether a vehicle set uses only a few freight wagons, as is the case with the 'original' TTD freight wagons or uses a large number of freight wagons (by vehicle ID) this scheme should provide more compatibility between the various sets.

There will be a few problems, like vehicle variable 42 (tt of) cargo classes transported, bits other than passengers/mail would be inaccurate. But there is of course variable 47.

Now for home work : think whether a particular cargo needs an even finer definition. We have at least one more slot available. Next, I'll put together a Cargo Table for all cargoes defined in the wiki, and define a cargo class according to the above.
User avatar
DanMacK
Tycoon
Tycoon
Posts: 3906
Joined: 27 Feb 2004 20:03
Location: Ontario, Canada
Contact:

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by DanMacK »

I like this proposal, it's A LOT more flexible than the hard defined ECS cargoes are. It would also set a standard for industry sets as well. I take it each car type would be cosed to accept an appropriate cargo as well? IE, autos would be able to be transported in a boxcar as well as an auto rack?

I like it personally.
User avatar
PikkaBird
Graphics Moderator
Graphics Moderator
Posts: 5602
Joined: 13 Sep 2004 13:21
Location: The Moon

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by PikkaBird »

I think there's probably a case for adding a "needs to be protected from the elements" cargo class. Otherwise, I can see very little that your spec would do that the existing spec doesn't, apart from break all existing sets.
DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by DaleStan »

You also seem to have a massive disconnect between "ECS", which is a possibly-less-than-useful use of the current cargo-classes system, and "the current cargo-classes system", which, as Pikka said, you seem to want to rape eight ways from Sunday.

"George can't get his cargo classes to match the documentation" has nothing to do with anything except George's typos. "The documented classes are useless" has at best, very little to do with the current system, just the way that it is being used.

"If class $FOO were added, and the cargos marked appropriately, then the documented classes would be useful", now *that* is something that makes it worth actually changing the system.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by wallyweb »

Not being a coder or a developer, I apologize in advance for butting in here. However, I am a player, aka the end user aka the customer. Anybody who has seen my screenshots knows that I like realism in my games. With that in mind, I have to appreciate OzTransLtd's frustration in trying to code appropriate wagons for loose cargo (bulk) that is sensitive to weather and prone to flying about if left open to the wind. I looked at the Cargo classes described in the wiki here with the types and labels described in the wiki here.

OzTransLtd's proposal is sound, however, as PikkaBird pointed out, it would require significant rework on the part of existing set authors and coders and not just for trains but for RV's and ships as well. This would require consensus from several quarters. The only way I can see that happening is that OzTransLtd's proposal would have to provide some very significant benefits to justify acceptance. The first and probably most important benefit would be ease of implementation. How much work and time would be required to make the changes? Can the switch be implemented without affecting code (thus eliminating any need for code revision)? This proposal needs more description including examples of any required rework. So I suggest giving OzTransLtd time to make his case in detail before dismissing it outright.

In the meantime, how to handle covered bulk with what is currently available? My suggestion is to dump Hazardous Cargo. No cargoes or labels have been defined for it. No grf's exist for it. The last TTDPatch proposal was opened Feb 06, 2007 by WhiteHand in his Nuclear Industry Chain thread with the last post being two days later, Feb 08, 2007. Wile E. Coyote did add it to his Serbian set here with the following comment: "(altough you can't see that until those cargos will be introduced)". I was able to find a couple of OTTD threads mentioning uranium, one of which seems to have died and the other being a futuristic mod of Toyland which is still seeing some activity but appears to be far from the onset of any serious coding work. Dumping Hazardous Materials (a poor choice of phrasing) will have a very minimal impact (even worse). Replacing it with "Bulk - Covered" and realigning a few labels makes good sense to me.

Thank you for your forbearance.

Oh yes ... don't worry about affecting saved games. That's a crock. How many players actually return to an old game or scenario without having to rework them due to updates to the patch and sundry grf's? And as for a current game or two? How often do players update the grf's in the middle of a game?
DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by DaleStan »

wallyweb wrote:Oh yes ... don't worry about affecting saved games.
Old saved games are one thing. Old newgrfs are something else entirely.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by wallyweb »

DaleStan wrote:Old saved games are one thing. Old newgrfs are something else entirely.
True, but I thought that point would have been covered under
I wrote:The first and probably most important benefit would be ease of implementation. How much work and time would be required to make the changes? Can the switch be implemented without affecting code (thus eliminating any need for code revision)?
User avatar
George
Tycoon
Tycoon
Posts: 4362
Joined: 16 Apr 2003 16:09
Skype: george-vb
Location: Varna, Bulgaria
Contact:

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by George »

OzTransLtd wrote:Now someone goes and removes the refrigerated flag from fruit, and I end up with fruit in my ore car; who is going to eat that afterwards. Or, someone believes oil seeds should be changed from bulk to something else; I will end up with oil seeds in my ore hopper. This situation is not acceptable, I would have to change my set far too often.
Just to mention, only 3 or 4 classes were changed for ECS cargo during 2 years and a half. Incredible amount of changes :roll:
OzTransLtd wrote:I've already used up 28 of the 32 bits in the bit mask,
What for? I currently used 5. All the other were well with labels and classes
OzTransLtd wrote:Now to the Cargo Transportation Scheme (CTS) ...
We need a reliable interface between industry/cargo sets and vehicle sets; the Extended Cargo Scheme [ECS] has failed;
It is not. Also the text below in no way disables it. It expands it. I suggest not to fight for the honest name "Schema inventor", but collaborate. The text below should be named "ECS. Cargo classes", while the previous discussion is "ECS. Cargo labels".
The main idea of the ECS in no way is negated with your suggestion. If vehicle set knows the cargo, it uses it's label. If it does not (it is a new cargo or a new set), it uses the cargo class. Periodically the vehicle set gets updated and new labels go in.
Let me remind, that translation table may have up to 255 entries. Single vehicle in a vehicle set can support all of them. See the way LV4 uses translation tables as example.
OzTransLtd wrote:actually it has never worked in the first place.
It works excellent in LV4, Serbian set and some others. This statement is wrong.
OzTransLtd wrote:It is inadequate and needs to be replaced.
It may be improved.
If you fight for more possibilities of ECS by adding it more flexibility by more productive usage of cargo classes - I'm with you. We work together for one aim.
If you fight against ECS and want be the leader of the new schema over the skull of the other schema - I'm against you.
OzTransLtd wrote:Once a new scheme has been adopted, every vehicle set developer, that wants to provide transportation for cargoes beyond the 'original' TTD cargoes must use it; so do the industry/cargo set developers.
He must do it not. He may use it. In fact the label based way is more flexible, because vehicle set knows more about the cargo. The class based schema is the addition. Forcing using classes instead of labels is non-productive.
OzTransLtd wrote:The cargo set developers have the easy job by simply defining cargo class (cargo property 16) correctly. BTW, all reference to properties and variables refer to the train ones.
He should specify BOTH label and class. That gives more information for vehicle set.
OzTransLtd wrote:The interface is simply the cargo class.
If your point is to remove label as a property - I'm strongly against it. If you suggest to give more information in the cargo classes - I support you.

Suggestion about classes would go later.
Last edited by George on 03 Dec 2007 06:44, edited 1 time in total.
Image Image Image Image
User avatar
George
Tycoon
Tycoon
Posts: 4362
Joined: 16 Apr 2003 16:09
Skype: george-vb
Location: Varna, Bulgaria
Contact:

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by George »

wallyweb wrote:How much work and time would be required to make the changes? Can the switch be implemented without affecting code (thus eliminating any need for code revision)? This proposal needs more description including examples of any required rework. So I suggest giving OzTransLtd time to make his case in detail before dismissing it outright.
If it is an expanding of ECS than:
about an hour to fix the wiki
about an hour to fix LV4, no change in the saved games
about an hour to fix ECS vectors, no change in the saved games
That is fine for me.
Image Image Image Image
michael blunck
Tycoon
Tycoon
Posts: 5948
Joined: 27 Apr 2005 07:09
Contact:

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by michael blunck »

This whole discussion is moot, like so many others connected with ECS.

If a vehicle set will support the ECS scheme it´ll use its cargo labels. Cargo classes OTOH are unimportant.
the Extended Cargo Scheme [ECS] has failed; actually it has never worked in the first place. It is inadequate and needs to be replaced. Once a new scheme has been adopted, every vehicle set developer, that wants to provide transportation for cargoes beyond the 'original' TTD cargoes must use it; so do the industry/cargo set developers.
That´s complete rubbish.

regards
Michael
Image
DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by DaleStan »

michael blunck wrote:If a vehicle set will support the ECS scheme it´ll use its cargo labels.
michael blunck wrote:That´s complete rubbish.
Thanks for the useful quotes there. There are 32 cargoes in ECS, right? There are also, wonder of wonders, 32 cargos in the refit mask. What happens when someone wants to support a non-ECS cargo? Or is no one ever supposed to have a set that supports more than 32 cargos?

Cargo labels are just fine for graphics, but they are completely inappropriate for determining refitability. The classes MUST be sufficient for refittability.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
User avatar
Zimmlock
Tycoon
Tycoon
Posts: 2112
Joined: 02 Dec 2003 16:01
Location: Belgium

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by Zimmlock »

This discussion is a lost of time CTS versus ECS we need just one. I vote for ECS its far more developed, allready up and running, it maybe needs some work, i dont know. I just wonder what OzTransLtd's problem is with ECS, he'd better work constructive together with ECS developers then suggesting a new Scheme.
Ill come soon with a new cargo "Cokes" :twisted:
Hodie Mihi Cras Tibi
michael blunck
Tycoon
Tycoon
Posts: 5948
Joined: 27 Apr 2005 07:09
Contact:

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by michael blunck »

DaleStan wrote:What happens when someone wants to support a non-ECS cargo?
He would include the cargo label of such cargo into his set´s CTT. Although, that would only work properly if some information about that cargo would have been made public by the author/inventor of said cargo. Other than that, no reasonable support of a foreign cargo could be established within a vehicle set.
Or is no one ever supposed to have a set that supports more than 32 cargos?
Well, "32 cargoes" are a limitation by TTDPatch, not by ECS. And TTDPatch´s "cargo classes" have never been part of ECS. AFAIR they were set up by Josef in the first place when introducing CTTs. The only later addition with ECS in mind was "refrigerated", IIRC.

O/c, the already available cargo classes of TTDPatch could be further improved. But "improving" them in such a way that eventually cargo class == cargo label would be not much helpful, especially with 32 bits available as well.

regards
Michael
Image
User avatar
Wile E. Coyote
Tycoon
Tycoon
Posts: 8515
Joined: 08 Jul 2004 22:14
Skype: wile.e.coyote2
Location: Belgrade, Serbia
Contact:

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by Wile E. Coyote »

michael blunck wrote:If a vehicle set will support the ECS scheme it´ll use its cargo labels. Cargo classes OTOH are unimportant.
But if you want to support more than 32 cargos, you have to do hard gymnastics with both cargo classes and cargo table (remember our discussion in Serbian rail set thread?)
Serbian rail set with Serbian scenario (ECS, PBI, FIRS and Tourist set compatible) Website | Topic and download | Latest version: 03.06.2015.
Serbian tram set Tracking table | TTD Patch tram set Latest version: 17.06.2015. | Open TTD Remix Latest version: 11.07.2015.
WIN-DOS GRF Converter Topic and download | Version 0.2.1: 09.01.2005.


Runner-up in "Best avatar Forums award" for years 2006 and 2010!
michael blunck
Tycoon
Tycoon
Posts: 5948
Joined: 27 Apr 2005 07:09
Contact:

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by michael blunck »

Wile E. Coyote wrote:remember our discussion in Serbian rail set thread?
Not really, but let´s take a look ...
Serbian Rail Set thread wrote: [wec]> Pikka indeed haven't coded lumber and plastic as stays in Wiki. In UKRSI lumber is coded as piece goods only instead of bulk and piece goods, and plastic is coded as liquid and piece goods instead of liquid only.

[pb]> That shouldn't mean your wagons can't carry them though, unless you're using extremely restrictive cargo classes.

[wec]> Unfortunately, it seems I use... For example, I restricted tankers to transport liquids only, because I wanted to exclude dyes from tankers, but obviously I restricted plastic too.

[wec]> In ECS [George´s ECS vectors, mb] there are also cargos which are not coded as stated in Wiki, as I posted here.

[mb]> Well, if your findings are correct, those would be clearly bugs and should be reported to George.

[wec]> Probably LV4, UKRS, Planeset etc. are working good with ECS and UKRSI because they have no so restrictive classes like Serbian rail set.

[mb]> Both approaches have advantages and disadvantages (as we see here). A clean solution would be to have it as restrictive as needed for a train set to function properly. O/c that´d rely on the correctness of the cargo definitions supplied by other sets ...
Apparently, we don´t need a replacement for "crappy ECS". What we need in the first place is to get rid of bugs in appropriate industry and vehicle .grfs and a proper usage of TTDPatch´s already available cargo classes when trying to use both ECS and non-ECS industry .grfs.

Using even more cargo classes as we do now wouldn´t necissarily simplify the task of inter-grf communication, though.

[edit]
PikkaBird wrote:I think there's probably a case for adding a "needs to be protected from the elements" cargo class.
Right. We should add a flag for "covered/sheltered", to enforce transportation in box vans and silo wagons (or when using open wagons, use a tar). I.e.:

Code: Select all

9	200	covered/sheltered freight (transportation in box vans, silo wagons, etc.)
I don´t think a special label for "edible" cargoes would be needed, though.
[/edit]

regards
Michael
Image
User avatar
George
Tycoon
Tycoon
Posts: 4362
Joined: 16 Apr 2003 16:09
Skype: george-vb
Location: Varna, Bulgaria
Contact:

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by George »

DaleStan wrote:
michael blunck wrote:If a vehicle set will support the ECS scheme it´ll use its cargo labels.
michael blunck wrote:That´s complete rubbish.
Thanks for the useful quotes there. There are 32 cargoes in ECS, right? There are also, wonder of wonders, 32 cargos in the refit mask. What happens when someone wants to support a non-ECS cargo? Or is no one ever supposed to have a set that supports more than 32 cargos?
Cargo labels are just fine for graphics, but they are completely inappropriate for determining refitability. The classes MUST be sufficient for refittability.
LV4 supports more than 32 cargoes, but not at once of cause.
I use cargo class 1 only, while all that does not fit well I define with refit mask. I do not know why OzTransLtd used 28, I was fine with 5 (LVST, MAIL, PASS, TOUR, VEHI).

Important:
Yes, I agree, that classes are useful for refit and should be improved!
Last edited by George on 03 Dec 2007 11:06, edited 1 time in total.
Image Image Image Image
User avatar
George
Tycoon
Tycoon
Posts: 4362
Joined: 16 Apr 2003 16:09
Skype: george-vb
Location: Varna, Bulgaria
Contact:

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by George »

OzTransLtd wrote:The cargo set developers have the easy job by simply defining cargo class (cargo property 16) correctly. BTW, all reference to properties and variables refer to the train ones.
Specifying classes is as easy as specifying labels. So I think we should use both.
OzTransLtd wrote:The interface is simply the cargo class.
The interface is Cargo label AND cargo class. The label is the first interface, that specifies the single cargo exactly. A vehicle set will use it first. Class is the additional (but not less important) interface, that allows vehicle set to provide a behaviour for a group of cargo.
OzTransLtd wrote:These cargo classes must be redefined; once agreed they will be set in concrete. This scheme aims to avoid cargoes, like crude oil, milk, petrol or water, having the same cargo class. Here is a suggestion of the 16 possible, new or redefined, cargo classes:
As I can see it specifies subtypes, while assembled they become a class (up to 65536 classes in total)
OzTransLtd wrote:2] (0002h) mail (same as above)
What for? Do we really need it?
OzTransLtd wrote:The next 3 classes define the cargo as in 'Is it Animal, Vegetable or Mineral' ? Each cargo will have one and only one of these defined :
3] Animal, for a cargo, like livestock.
4] Vegetable, all cargoes that are edible, but are not still an animal alive.
5] Mineral, all cargoes, that would be hard to swallow, like coal, ore or timber.
Are fertiliser mineral? What to do with valuables?
Imho, we have a bit wasting here. First two should be united, while the difference should be achieved with bit 15 (for example)
OzTransLtd wrote:Then we come to the origin of the cargo; there are 2 classes, each cargo will have maximum one of these defined :
6] Raw material, everything that has been dug up or chopped down, e.g. coal, ore, timber
7] Processed, for cargoes that have been processed, e.g. livestock -> meat, iron ore -> steel, pulp -> paper.
Do not see how we can use it yet. Could you explain it in more details?
OzTransLtd wrote:The next 4 classes define its transportability; again each cargo will have one and only one of these defined :
8] Bulk, everything that would be transportable in an open wagon (a sided wagon not a flat bed), or on the back of a truck and could be exposed to nature, like rain.
9] Packaged, now packaged does not necessarily mean, a bag or a box, it also means protected from the environment; i.e. it needs to be undercover, like grain, wheat; or consists of fine particle nature, like cement or potash. a packaged cargo goes in box cars, covered hoppers or containers.
10] Liquid, all cargoes, that traditionally are transported in tankers. If it is not a tanker cargo, it most probably would be defined as packaged.
11] Piece Cargo, everything of bulky nature, that is happy to be transported in the open, like timber, machinery or motor vehicles.
Paper is Packeged?
OzTransLtd wrote:Next come the finer and optional definitions :
12] Refrigerated, a perishable cargo that requires refrigeration, like fish or milk.
13] Express, a cargo that should be transported as quickly as possible, like tourists, although tourists could simply be defined passengers only. Maybe this one could be depreciated.
14] Armoured, the armour class might even be scrapped too. We'll leave it in for the moment, but if we do need another class it might have to go.
Special? May be this should be used for hazard too?
Valuables = mail + packaged + special(armored) + raw?
Uranium = mineral + raw + packeged + special (armored)?
OzTransLtd wrote:Now for home work : think whether a particular cargo needs an even finer definition. We have at least one more slot available. Next, I'll put together a Cargo Table for all cargoes defined in the wiki, and define a cargo class according to the above.
Write your classes for ECS vectors please, we will look how good would it look like. I suppose we could get excellent addition.
Image Image Image Image
User avatar
George
Tycoon
Tycoon
Posts: 4362
Joined: 16 Apr 2003 16:09
Skype: george-vb
Location: Varna, Bulgaria
Contact:

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by George »

I think we need groups of subclasses
a) nature (only one)
1) passenger
2) produced (mail, valuables)
3) gathered
4) mined
b) transporters (any)
1) flat bed
2) hopper
3) box
4) tanker
c) special (any)
1) Express
2) Special (a2, a4 is armoured, a3 refrigerated, a1 animals)
3) Covered?

currently 11 bits. I'll try make a list for all ECS cargoes today
Image Image Image Image
User avatar
OzTrans
Tycoon
Tycoon
Posts: 1680
Joined: 04 Mar 2005 01:07

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by OzTrans »

First, a few general comments ...

The new scheme is intended to deal with cargoes that are unknown to vehicle sets; especially newly created cargoes. The way we are going, there will soon be hundreds of them. Someone creates a new industry chain, that will be well received and accepted by the playing community, but there is no vehicle set to deal with them. Don't say this will not happen (or has never happened). In this situation, well respected vehicle sets must be able to cater for new cargoes without modifications. That is the aim of this exercise.

Cargo labels : I have never said that the cargo label would be dropped. That is an integral part of the system and the cargo translation table feature. However, the label is irrelevant when a vehicle set deals with unknown cargoes, that is why the cargo class is the only link between cargo and vehicle sets for unknown cargoes. George, do keep defining those cargo labels, it is a must.

My suggestion is to give cargoes better characteristics without having to know its name aka cargo label, so that vehicle sets have it easier when selecting the various cargoes for their freight wagons, especially newly defined ones. Defining, iron ore, dust, coal, cement, flour, sulphur, grain ... as simply 'bulk' is not good enough.

Why do I have to do the following ? For the box car my coding software spills out when compiling ...

Vehicle property 1Dh set to : LUMB, WDPR, AUPT, GRAI, CERE, FOOD, OLSD, CMNT, FICR, FERT, -LVST, -WOOD, -VEHI, GOOD
Vehicle carries : goods (40 crates), steel (40t)[, lumber (37t)][, wood products (37t)][, auto parts (40t)], grain (38t)[, paper (40t)][, food (40t)], [other piece cargo (37)]

Why do I have to set 14 bits in the refit mask ? Because the current system is inadequate.

BTW, prop 28 is set to '20 00', and 29 to 'CF FF' so that any unknown cargo defined as 'piece goods', like bricks, ceramics, glass and wool get picked up too, but I don't want livestock, wood and vehicles; then I have to add oil seeds, cement, fibre crops and fertiliser explicitly.

If someone comes along and defines 2 new cargoes, pigs and sheep, as piece cargo, too; I will have a problem, because I don't want them in my box car, I want them to go in the livestock car.

That is why we need a finer grading of all cargoes.
DanMack wrote: ... autos would be able to be transported in a boxcar as well as an auto rack?
There would be no change to how it works today. Known cargoes (the CanSet chooses VEHI to be a known cargo, because we want to transport it in different freight wagons), like automobiles (VEHI) can go into any car (e.g. auto rack as well as box car) by explicitly adding it.
... existing vehicle sets that are actively using cargo classes to allocate cargoes to freight wagons ...
How many are there ? There are hardly any released ones, otherwise we wouldn't get queries, like “What sets allow me to transport new cargoes ?”
... existing system vs new one ...
I've just gone through all the cargoes known to me from the wiki, and defined the class they should belong to (in my opinion). That is when I realised, that all the currently defined classes will still be used and can be retained, there are just additional ones, for which is still room. Now, we are already halfway there. That list will be published for comments sometimes this week.

Yes, if a new system gets adopted, there will be significant work involved, especially by vehicle set developers and not just for trains, but also road, air and sea sets. However, how many such sets do exist today AND have been released AND have already used the cargo class to allocate cargo to freight cars ? Hardly any. I only know, Pikkabird's sets George's LVs and the Serbian set. I have implemented cargo classes in the CanSet v0.3, but it has not been released yet.
wallyweb wrote: ... The first and probably most important benefit would be ease of implementation. How much work and time would be required to make the changes? Can the switch be implemented without affecting code (thus eliminating any need for code revision)? ...
Implementation would be straight forward : No need for TTDPatch//OpenTTD mods, ...

Cargo/Industry sets would define the cargo label (like 'FERT' for Fertiliser) and the cargo class. Those 2 are the responsibility of the cargo set developer. They will have to be documented in the wiki, so that vehicle set developers know what they are up against.

Vehicle sets have a bit more work to do; they will have to allocate the various subgroups defined by the cargo class to their freight wagons; basically it involves the setting of property 28 AND 29 (if train) for each cargo carrying vehicle. If more than one sub group goes into the same vehicle, setting 28/29 gets a bit trickier.

However, only vehicle sets, that have already used cargo classes will be affected negatively. Would be nice to know, which ones ?
George wrote:
OzTransLtd wrote:I've already used up 28 of the 32 bits in the bit mask ...
What for? I currently used 5. All the other were well with labels and classes
You probably only deal with sets of your own, i.e. ECS cargo and RV. I have to deal with, ECS cargoes, Pikka's Industries and NAIS (DanMack). All need to be supported.
George wrote: ... <a lot> ...
Why CTS ? There is nothing wrong with ECS as name, but it is confusing. Currently it stands for the implementation and definition of the Extended Cargo Scheme but also for your sets and ECS, the European Cargo Set. Do I have to say more. I have used Cargo Transportation Scheme [CTS] to keep things separated, name it what ever you like, but at the moment we need something to distinguish between ECS and what we are discussing. Afterwards we can always return to ECS as name.

Yes, I know, the cargo translation table can have up to 255 entries; I have used already 67 of them. We are dealing here with cargoes a vehicle does not know about, i.e. a newly created cargo. That is why, we have to use the cargo class instead. You won't have any problems with your sets, because your are the developer of both your cargo set(s) and your vehicle set(s); so has Pikkabird with his sets. But, I'm trying to support you both. Of course, I could walk away, don't bother about ECS and Pikka's Industries; but that would not be fair to my customers aka players. Another option, I have is inventing the wheel and developing my own industry/cargo sets and tell my customers to use these instead because ECS and any other industry/cargo sets won't be supported.

I'm not against your sets and ECS. You've done an excellent job, but the scheme as it is implemented is not working for someone, who tries to provide compatibility between industry/cargo and vehicle sets by various developers.

That is enough for today ...

I have responded until and including post #9 by George ... the rest will come tomorrow ...

Please, do remember, this discussion is all about cargoes that are unknown to vehicle sets and the only avenue open are cargo classes.
User avatar
OzTrans
Tycoon
Tycoon
Posts: 1680
Joined: 04 Mar 2005 01:07

Re: New Cargo Transportation Scheme [CTS] – Discussion ...

Post by OzTrans »

DaleStan wrote: ... Cargo labels are just fine for graphics, but they are completely inappropriate for determining refitability. The classes MUST be sufficient for refittability.
Thank you, I second that.
George wrote: ... Specifying classes is as easy as specifying labels. So I think we should use both. ...
Yes, we need both. Because we must be able to allocate certain cargoes with the same cargo class to different wagons; e.g. coal to the coal hopper, other ores classed 'raw bulky minerals' to the ore hopper. In this case, the coal hopper gets coal via cargo label (CTT) in 15 and the ore hopper of above cargo class in 28/29 minus COAL in 1D.
... The interface is cargo label AND cargo class. The label is the first interface, that specifies the single cargo exactly. A vehicle set will use it first. Class is the additional interface, that allows vehicle set to provide a behaviour for a group of cargo. ...
If the cargo is known to the vehicle set, then I would use the class before the label if that suits me better; i.e. I can avoid having to use a slot in the bit mask. Otherwise, I will use the label. This is the case for cargoes known to the vehicle set.

If the cargo is unknown to the vehicle set, I only have the class at my disposal.

You are right, by saying the label and the class are the link, but not when the cargo is unknown. We want to cater for these situations.
... why class 0002h mail ...
For the same reason as we have passengers and tourists (express); one day someone wants mail (express) to be handled.
... why Animal, Vegetable, Mineral ...
Is fertiliser 'mineral' ? Yes, it is; does it walk, it is not an animal; can you eat it, I wouldn't want to try; then it must be mineral. I know this sounds stupid, but that is how the world works. I was thinking to combine 'Animal' and 'Vegetable' and call it 'Edible'; afterall we have only LVST and FISH in the 'Animal' class, but what about in future, there are pigs and sheep. We could classify livestock as 'Raw' 'Vegetable' and 'Piece Goods' and meat as 'Processed' 'Vegetable' and 'Packaged' plus 'Refrigerated'. Let's have another look at it once I have finished classifying the cargoes.

Valuables is a difficult one, it's similar to mail. How do you want to handle gold and diamonds then ?
... Raw vs Processed ...
A good example is crude oil and petrol; both are 'Liquid' 'Minerals', but one is 'Raw' the other 'Processed'. Someone may want to transport them differently and have that distinction. Another one is Wood (as in chopped trees) vs Lumber or Wood Products.

It'll distinguish between a raw cargo, which could be handled rough and a processed one. Or, livestock into meat, iron ore into steel.
... Paper is Packaged ? ...
As I said, packaged can be read in many ways. It could mean, bagged, boxed, transported in enclosures such as a covered hopper or simply protected from rain, snow .... You would not want to transport a roll of paper on a flat bed from the paper mill to the printing works.

The transportability class can of course be interpreted as Bulk = Hopper, Packaged = Box Car, Liquid = Tanker and Piece Goods = Flat Bed. It's just the naming, the end result is the same.
... optional classes ...
mail = mail; valuables = mail + special; that could work
uranium ore = mineral + raw + packaged + special; that is exactly what I came up with. uranium and depleted uranium the same except that would then be processed instead of raw.
... Write your classes for ECS vectors please, we will look how good would it look like. I suppose we could get excellent addition. ...
I've done that, it's not quite finished yet. I'm still fine tuning it. You'll have it by the end of the week, if not sooner.

Also, I'd like to see whether we can come up with a working solution for the 'original' TTD vehicles; i.e. can we cater for any type of cargo and have a reasonably matching cargo allocation, that would make it possible to use cargo sets and no 3rd party vehicle sets (except redefinition set of cargo properties of all 255 vehicles).
... get away with 32 cargoes ...
This is not really possible for vehicle sets; they need to cater for all vectors and a variety of cargo sets. I already have Lumber in NAIS and Wood Products in ECS. That takes 2 slots for the same thing.
Post Reply

Return to “Graphics Development”

Who is online

Users browsing this forum: Ahrefs [Bot] and 89 guests