Transport Tycoon Forums

Hello,

before starting a edit war, I would like to discuss two pages on the wiki, as multiple parties seem to be involved
a) http://wiki.ttdpatch.net/tiki-index.php?page=CargoTypes
b) http://wiki.ttdpatch.net/tiki-index.php ... CargoTypes

So far I can identify parts of the information on those pages to head for
1) Document cargo slots of default cargos.
2) Document cargo bits of default cargos.
3) Document cargo classes of default cargos.

4) Document cargo classes and bits of old and new cargos in various newgrfs.


Items 1 to 3 head for documenting the stuff, which is provided by TTDP and OTTD as defaults, which then might be changed by various (newcargo- resp. newindustry-/newhouse-) grfs.
The content of 1 to 3 should reflect the definitions in
http://svn.ttdpatch.net/trac/browser/tr ... t.asm#L940 (linenumber is valid for TTDP r2023)
resp.
http://svn.openttd.org/trunk/src/table/cargo_const.h (OTTD rHEAD)
(they should be equal).


All four items head for documenting the usage of cargo bits and classes for developing vehicle and station grfs.


Wrt. 4, there seem to be at least the definitions of George's ECS and of andythenorth's and FooBar's FIRS. It seems like MB's unreleased ECS has joined them specifiing stuff.


Personally I would like these information on the wiki:
i) The defaults of 1 to 3, clearly separated from the rest. (though a separate column would also be acceptable)
ii) The cargo classes and bits of released newgrfs. The new cargos and the changes to the old cargos.
iii) No "fictional" information about newgrfs in development without a single test release.
iv) A note about the various troubles caused by inconsistent cargo class usages across multiple newgrfs.


Do your goals differ from mine?

frosch wrote:Do your goals differ from mine?

I can only agree that I find these pages confusing. As a vehicle set author, that's a problem. I have no real idea what I'm supposed to do with my cargo translation table to get the best experience for players. I've searched the forums for answers and only found arguments and disagreements.

And all of the above despite that I'm also one of the instigators of FIRS. In fact, whenever we debate these issues for FIRS, it's just confusing as to what we're supposed to do to do this 'right'. I don't want to put words in their mouths, but I _think_ Zephyris and FooBar have similar thoughts.

I don't know how to help, just my 2c. Actually designing cargo chains etc is easy. Cargo labels are also mostly easy. It's classes where it becomes confusing. Perhaps it's just a difficult problem.

Blame me for the FIRS part on that page...
As ECS and PBI cargos were added there, I decided to add the FIRS cargos well. A while after MB added these nice orange labels for ECS. I added those for FIRS as well later on and expanded both to the original cargos making it a more uniform list. I did not change any existing definitions, only add new things.

As I edited the page, I understand it. I did not realise that it could be confusing to others. To be honest, I don't see the confusion, but that could be due to that I understand the page...

i) ofcourse, that's the main aim of the page IMO.
ii) those are there currently, but could be documented in a different way, e.g. one table of cargo labels and their classes per newgrf.
iii) both George's ECS Vectors and 'our' FIRS have (test) releases available. MB probably will not release test releases...
iiii) I'm unaware of what those troubles could be (I understand too little about the cargo class system with respect to vehicles, I know what they're for, but am unsure about how they're defined wrt including and excluding certain classes), but if there are pitfalls, they should be noted. If those are severe, some FIRS cargos might require changing.

I would like to say that every CARGO LABEL should have ONLY ONE defined value of CARGO CLASSES, represented on that page (http://wiki.ttdpatch.net/tiki-index.php?page=CargoTypes).
Every set that would like to have the same cargo, but with the other cargo class, should provide NEW LABEL!
Example - PLST and PLAS.
Cargo class of the EXISTING cargo can not be changed unless value for cargo class bits is changed at http://wiki.ttdpatch.net/tiki-index.php ... ion0Cargos

As for http://wiki.ttdpatch.net/tiki-index.php ... CargoTypes, the labels part should be removed, all the labels for the sets should be defined at http://wiki.ttdpatch.net/tiki-index.php?page=CargoTypes

I agree because It is a problem when I code the wagons and their sprites.

I'm fine with that as well. Regarding FIRS we'll either change our cargo class definition and keep the label, or change the label if we're not happy with the original class definition of a particular label.

Changed http://wiki.ttdpatch.net/tiki-index.php?page=CargoTypes

George wrote:I would like to say that every CARGO LABEL should have ONLY ONE defined value of CARGO CLASSES, represented on that page (http://wiki.ttdpatch.net/tiki-index.php?page=CargoTypes).
Every set that would like to have the same cargo, but with the other cargo class, should provide NEW LABEL!
Example - PLST and PLAS.

Let's look at some hypothetical situations:

Hypothetical #1:
Fred defines Plastic as PLAS, 0060 Piece goods, liquid
Bill defines Plastic as PLAS, 0070 Bulk, piece goods, liquid

Player Joe loads both sets, and his Fred hopper trucks are now refittable to plastic, but they have no plastic-specific graphics! The sky falls in.

Hypothetical #2:
Fred defines Plastic as PLAS, 0060 Piece goods, liquid
Bill defines Plastic as PLA2, 0070 Bulk, piece goods, liquid

Joe loads both sets, and he now has two cargos called "Plastic", which come from and go to their own industries. His vehicles are refittable to either. He has no way of telling which "Plastic" goes to what industry, or indeed which "Plastic" his vehicles can carry.

Clearly, the second scenario is preferable.

PikkaBird wrote:Clearly, the second scenario is preferable.

Actually, neither scenario is preferable.
This is a good example as to why this system is broken.
Plastic is plastic. PERIOD.
It can be liquid or solid.
Only one label should be required.
The class system adds an unnecessary level of complication and is overly restrictive for the transport set author.
An industry set author should be able to design industries that produce or receive plastic. Whether it is liquid or solid is immaterial.
A competent transport set (rail, RV, ship or plane) author will provide appropriate vehicles for transporting the product, whether it be bulk, liquid or solid. The vehicle selection should be up to the player's imagination
A simple label based refit option is all that is required.
I honestly fail to see a good reason for the classification system other than to force an author and a player into using somebody else's concept of what should be used.

wallyweb wrote:I honestly fail to see a good reason for the classification system

How is my vehicle set that I made three years ago (eg, UKRS) supposed to carry the cargo that you invent tomorrow?

The class system isn't restrictive for vehicle set authors at all - it's there to make coding vehicle sets easier. But you can use a cargo translation table and directly code refittability for up to 32 cargos (the limit of the refit bitmask property), if you really want to.

PikkaBird wrote:How is my vehicle set that I made three years ago (eg, UKRS) supposed to carry the cargo that you invent tomorrow?

If your client (the player) asks for support for a newly defined cargo, the label can simply be added as a minor revision to your set.

The class system isn't restrictive for vehicle set authors at all - it's there to make coding vehicle sets easier.

I am currently studying coding for an RV set that I am designing. I am at the stage where I must consider refit options. My mind boggles at the complexity of the process.

But you can use a cargo translation table and directly code refittability for up to 32 cargos (the limit of the refit bitmask property), if you really want to.

I really want to.

wallyweb wrote:I am currently studying coding for an RV set that I am designing. I am at the stage where I must consider refit options. My mind boggles at the complexity of the process.

Don't substitute "it's broken" for "I don't understand it".

If you want to make, say, a tanker road vehicle, you can do this with cargo classes simply setting its cargo class properties 1D and 1E appropriately (40 00 and 00 00 respectively). You can then use a cargo translation table and either action 3 or vehicle var 47 to apply appropriate graphics for cargos that you care about, and just let it use some default graphics for cargos you don't care (or don't know) about.

This is much better than the other way: you don't have to work out bitmasks, you can code for more than 32 cargos, and it's futureproof. If you want to talk about coding in more detail, perhaps we should move to the sticky nfo questions thread?

PikkaBird wrote:Let's look at some hypothetical situations:
<...>
Clearly, the second scenario is preferable.

Well, when you put it that way, Pikka, I suddenly have a hard time arguing in favor of defining a new label if you don't like the class for the existing label.

However, I still don't like the idea that one label can have different classes depending on which GRF is loaded. Going back to hypothetical #1:

Player Joe starts a game with Bill's set. PLAS is bulk/piece/liquid, and the hopper vehicles are able to carry plastic.
Part-way through the game, Joe adds Fred's set, which overrides Bill's definition, and suddenly the hoppers can no longer be refitted to plastic.

PikkaBird wrote:Don't substitute "it's broken" for "I don't understand it".

I didn't.

If you want to make, say, a tanker road vehicle, you can do this with cargo classes simply setting its cargo class properties 1D and 1E appropriately (40 00 and 00 00 respectively). You can then use a cargo translation table and either action 3 or vehicle var 47 to apply appropriate graphics for cargos that you care about, and just let it use some default graphics for cargos you don't care (or don't know) about.

This is much better than the other way: you don't have to work out bitmasks, you can code for more than 32 cargos, and it's futureproof.

This is still a fair bit of overhead (extra lines of code) for something that on it's face would seem to be capable of being simpler.

If you want to talk about coding in more detail, perhaps we should move to the sticky nfo questions thread?

I'll probably end up there eventually if the men in white coats don't catch me first. ...

wallyweb wrote:A simple label based refit option is all that is required.
I honestly fail to see a good reason for the classification system other than to force an author and a player into using somebody else's concept of what should be used.

http://bugs.openttd.org/task/2553#comment6383

George wrote: http://bugs.openttd.org/task/2553#comment6383

Hmmm ... this bug would seem to be related to vehicle length and not cargo refitting.

PikkaBird wrote:Don't substitute "it's broken" for "I don't understand it".

Burrrr. I don't understand it, and I'm on my third set

Or rather, I understand it just about, but it's on a par with understanding*very* complex varaction 2. I wouldn't say it's baroque, but I think it's one stop on the way to baroque.

George - sorry, think you're wrong about Plastic. I'm not going to screw around giving players *broken industry chains* just to keep the vehicle graphics tidy. *If* that's what you're implying - that's how I read your point anyway. True apologies if I've misunderstood you.

Meanwhile HEQS players will be treated to a nice box trailer or tarpaulin covered open trailer for just about any cargo that I haven't explicitly chosen to deal with. That covers most cases and if the realists don't like it, they can volunteer to draw the load sprites.

In the last year I've drawn *so many fricking load sprites* that I borderline lost the will to continue. I've certainly lost fingers. It's on par with a trip to IKEA in terms of *complete absence of joy*.

In other fun news, I've started a ship set. Most ships will be refittable to most things. Most of the graphics will excitingly feature covered holds. If any of *you people* need timber on deck, I for one welcome your help

my 2p.

Some remarks:

1. Adding new classes (like the recently added "oversized") to existing cargos results in the same problems as changing membeship of existing classes. A vehicle set that encounters an old set using the old classes, and a new set already using the new class will run into the same problem.

2. The main reason for keeping class membership constant, is imo not when changing newgrfs in game (who uses grm for cargos anyway resp. does not use all slots anyway?). But only the "XOR"-ness of the refitmask. Resulting in vehicles carrying a certain cargo when they explicitly shall not, and vice versa.

3. OTOH removing the "XOR" property and instead replacing it with some explicit "yes"/"no"/"let cargoclass decide" would allow vehicle grfs to exactly specify which cargos to carry, and to be only affected by cargoclasses for unknown cargos.

frosch wrote:3. OTOH removing the "XOR" property and instead replacing it with some explicit "yes"/"no"/"let cargoclass decide" would allow vehicle grfs to exactly specify which cargos to carry, and to be only affected by cargoclasses for unknown cargos.

That's actually something I had wished for when I meddled recently with the refit of the 2cctrainset cargos. Having that possibility would IMO help a lot to ease the decision of cargos for vehicles.

wallyweb wrote:

George wrote: http://bugs.openttd.org/task/2553#comment6383

Hmmm ... this bug would seem to be related to vehicle length and not cargo refitting.

sorry, this one http://bugs.openttd.org/task/2673