Transport Tycoon Forums

andythenorth wrote:As I see it, the primary goal ...
As I see it, the secondary goal ...
Enabling cargo set authors to control which vehicles (or vehicle types) can transport a cargo is IMHO an invalid goal.

I have to agree with Andy on this. It actually mimics reality:
An industry announces that it has a cargo to be shipped and the industry provides a description/specification of the cargo.
A transportation company checks it's inventory of vehicles and offers up a solution as to how to efficiently transport the described/specified cargo.
Considering the extensive variety of cargoes and the fact that many of them share similar specifications, the transportation company merely needs to know the general specifications (liquid, solid, piece, large, small, heavy, light, ore, bales, crates, refrigerated, etc.) for vehicle selection. It can then use a specific cargo name (coal, steel, goods, autos, fish, food, passenger, tourist, etc,) provided by the industry. Vehicle configuration is the responsibility of the transportation company.

A question: Is there a way for the industry set designer to provide a variable text 'cargo name' for an industry's product, perhaps as an Action0 property? That way, the vehicle provided by the transportation set author would, upon arrival at the industry's station, read that property 'name' for consignment purposes. I think this would help to keep the class/label system as simple as reasonable.

EDIT: Corrected Action8 to Action0

Eddi wrote: first and formost, the goal of cargo classes should be that a vehicle set author has a way to ensure that every cargo, known or not.

Seems something is missing here.

Eddi wrote: this is solely the responsibility of the vehicle set author, regardless of whether the classes are "right" or "wrong"

Well, this is nothing new. In fact, it´s the same as I wrote above and which has been the "philosophy" behind the current cargo scheme since years.

Eddi wrote: second, the cargo classes should give a suggestion of which wagons should load the cargo. it is mostly the responsibility of the industry set author to make sure that this classification has is sensible, but the general properties on which grounds to decide classes should be derived from a general consensus,

Again, nothing new. It has been (or better(?) should have been) always this way.

Eddi wrote: third and last, the vehicle set author should have a way to override the "suggestion" that the cargo classes give,

This has been also in existence since the cargo classes feature had been introduced.

Eddi wrote: in a way that is both flexible, but not too tedious.

Now, this might be new. It reiterates Josef´s question from 2005, in what kind cargo classes should be best linked with cargo types: by XOR, by AND NOT, or by operating two lists (include, exclude).

regards
Michael

michael blunck wrote:Now, this might be new. It reiterates Josef´s question from 2005, in what kind cargo classes should be best linked with cargo types: by XOR, by AND NOT, or by operating two lists (include, exclude).

Two lists for labels (include, exclude); indices to CTT.
Two lists for classes (include, exclude).

Keep the classes now using bits 0 through 7, and 15. Clarify the terminology.
Establish a spec about the use of classes, i.e do not exclude piece, bulk, liquid.
Have ottd/ttdp mask out the bits 8 through 14, making them unavailable for use.

I´ve just taken a look on Eddi´s scheme: http://newgrf-specs.tt-wiki.net/wiki/User:Eddi

Some remarks:

- don´t change TTDcargo classes, let me rephrase:

petern wrote: Changing existing labels is a really bad idea, especially for the base cargo types.

- proposed addition of "oversized" to (original) TTD "steel" and "wood" isn´t needed, just add "oversized" to "building materials", which could either be manufactured from "wood" or from "steel", no funny names like GODS, LOGS or STEE required,

- changing EXPRESS to "air freight" sounds silly in some cases: FOOD would get "air freight", but FRUT won´t, which is quite a contradiction to RL. Using EXPRESS, this contradiction would´t occur. Same with FISH: granted, Nile perch or Pangasius are flewn in in large quantities today, but transporting fish was the realm of railways for decades, and having the "air freight " label for all those fish transport wagons would be really silly. In addition none of those funny labels like FUI, FOO_ would be required.

- "cement" won´t have it´s own label anymore, since just before this discussion began, another large discussion about the new ECS version had just ended, making CMNT a sub-cargo of BDMT for now.

- FERT and POTA are definitely not "powderized",

- is there a reason why SCRP has been changed to SCMT?

- SULP is not "powderized", and will be removed in the new release of ECS,

- ... <more to follow?>

regards
Michael

michael blunck wrote: Seems something is missing here.

mäh... was late... not concentrated...

Eddi wrote: this is solely the responsibility of the vehicle set author, regardless of whether the classes are "right" or "wrong"

Well, this is nothing new. In fact, it´s the same as I wrote above and which has been the "philosophy" behind the current cargo scheme since years.

it's probably a good thing that the goal is still valid.

Eddi wrote: second, the cargo classes should give a suggestion of which wagons should load the cargo. it is mostly the responsibility of the industry set author to make sure that this classification has is sensible, but the general properties on which grounds to decide classes should be derived from a general consensus,

Again, nothing new. It has been (or better(?) should have been) always this way.

apparently this is the first problem. the scheme was apparently not clear enough, so both vehicle set and industry set authors did The Wrong Thing(tm). so this part is in need of clarification

Eddi wrote: third and last, the vehicle set author should have a way to override the "suggestion" that the cargo classes give,

This has been also in existence since the cargo classes feature had been introduced.

Eddi wrote: in a way that is both flexible, but not too tedious.

Now, this might be new. It reiterates Josef´s question from 2005, in what kind cargo classes should be best linked with cargo types: by XOR, by AND NOT, or by operating two lists (include, exclude).

regards
Michael

right, and that needs a decision how to proceed.

wallyweb wrote:A question: Is there a way for the industry set designer to provide a variable text 'cargo name' for an industry's product, perhaps as an Action8 property?

Hi Wallyweb, can you expand how you see this working?

michael blunck wrote:- is there a reason why SCRP has been changed to SCMT?

Yep, I'm also wondering what the reason of this change was... It requires vehicle set designers to change their code, with no apparent benefit whatsoever...

Snail wrote:

michael blunck wrote:- is there a reason why SCRP has been changed to SCMT?

Yep, I'm also wondering what the reason of this change was... It requires vehicle set designers to change their code, with no apparent benefit whatsoever...

The class was changed from piece goods to bulk.

Changing the label seems insane, because the newgrf wiki was incorrect anyway and had SCRP listed as bulk. Exactly why the wiki was wrong is lost in time. Anyway, the label has to be changed because the classes have changed. For current implementation, classes are *not* an abstraction mechanism from labels as they should be imho. This could be fixed to some extent by removing the XOR between classes and labels, which has been proposed but not agreed.

Scrap metal is valid for both bulk and piece goods, but setting both is likely to lead to unwanted exclusions, so I changed it to bulk as scrap metal is more like bulk than piece imho.

In short the whole thing is a mess, maybe I should just revert it and scrap metal should continue to travel by boxcar as piece goods with the label SCRP. It was one of the factors that caused this week long discussion of cargo refitting.

The FIRS classes and labels should never have been published in the wiki, I apologise for that (apologies to whoever added them to the newgrf wiki, I know it was well-intentioned but it has proved to be a significant problem)

I would like to find the correct way to do this, but as 'we' don't agree on the what the spec should be, that's currently impossible.

andythenorth wrote: Scrap metal is both bulk and piece goods imho, [..]

Hmm. I´m still under the impression that it´s "bulk", >90% (want pictures? ).

andythenorth wrote: The FIRS classes and labels should never have been published, [...]

Yeah. It should have only be communicated personally in dark nights to a very small circle of vehicle authors.

regards
Michael

michael blunck wrote:Hmm. I´m still under the impression that it´s "bulk", >90% (want pictures? ).

I'd rather not play 'image search tennis' I think it's bulk too in most cases. However when it's scrap cars or such, or baled scrap, it's definitely piece goods, although they are to some extent also pourable

If I was a vehicle set author, I would avoid supporting FIRS. On the one hand it's not being actively developed any more, so it looks stable, but on the other I want to pick it up again one day, and classes may yet change (possibly to remove some of the classes that I think should not be used). There is a history of sadness around FIRS cargos changing, but it's a big complicated set, and things have had to change many times for game balance.

If I was a vehicle set author, I would consider refusing to do much cargo support for any set without a better spec. But YMMV.

andythenorth wrote: Scrap metal is valid for both bulk and piece goods, but setting both is likely to lead to unwanted exclusions, so I changed it to bulk as scrap metal is more like bulk than piece imho.
In short the whole thing is a mess, maybe I should just revert it and scrap metal should continue to travel by boxcar as piece goods with the label SCRP. It was one of the factors that caused this week long discussion of cargo refitting.

I see... Well, I also think it would make more sense to have scrap metal travel as bulk, rather than piece goods. It's mostly made by shredded pieces of metal coming from car wrecks, remains of demolished buildings, or something of the like. So, I think it'd be more convincing to toss wrecks an open wagon, rather than orderly place them in a closed van (IMO, closed vans are more suited for finished products rather than wrecks).
So far, with scrap metal being classified as piece goods, I had to manually exclude it from my closed vans' cargo list, and include it in my open wagons'

Snail wrote:So far, with scrap metal being classified as piece goods, I had to manually exclude it from my closed vans' cargo list, and include it in my open wagons'

That's why I wanted to change it I felt like having it as piece goods imposed extra work on vehicle authors for no good reason. But unfortunately changing classes is not possible and therefore a new label has to be created

andythenorth wrote:

Snail wrote:So far, with scrap metal being classified as piece goods, I had to manually exclude it from my closed vans' cargo list, and include it in my open wagons'

That's why I wanted to change it I felt like having it as piece goods imposed extra work on vehicle authors for no good reason. But unfortunately changing classes is not possible and therefore a new label has to be created

I see. If this is the reason, I understand

andythenorth wrote: [...] But unfortunately changing classes is not possible and therefore a new label has to be created

Since when? ECS classes had been changed a lot as well. If this is done in a proper way, there´s nothing speaking against it, IMO. Better than to spoil the environment with scrap labels.

regards
Michael

michael blunck wrote:Since when? ECS classes had been changed a lot as well. If this is done in a proper way, there´s nothing speaking against it, IMO

Changing the class has to be assumed to break sets due to XOR interaction with refittable label / classes. Additionally, even if the XOR could be shown to have no problems, apparently it is guaranteed that classes are a reliable way to refit to known cargos.

So I was strongly advised that changing classes without changing label is The Wrong Thing To Do, and that the correct route is to change the label. And tbh, the case seems strong so I followed the advice.

This means of course that in some sets, vehicles that *did* refit to SCRP might not now refit due to particular interactions of classes, so they are now 'broken' by FIRS changes. So the conclusion is, once published labels and classes can never be changed.

Which suggests that industry set authors need to be particularly savant about inventing good gameplay from the first public release of their set, as cargos may never be changed after that. Or we shouldn't release, but instead privately test for the 2-5 years an industry set might take to develop.

Perhaps industry sets should be merged with vehicle sets into one unified grf providing the entire gameplay world (might as well bundle in houses). In this way, one author controls all, and compatibility issues simply...disappear. So maybe OzTrans had the right idea with unified Canadian theme pack, but now we'll never know

A more practical alternative is to sanitise the spec. But so far we've failed to achieve that

It might be obvious that I think the situation is nuts.

One proposal is to add new vehicle properties for included and excluded cargos. These would be lists of indices to the CTT.

Assuming no changes to the vehicle properties for classes, refitting a vehicle would then work like this:

You've missed the original refit bitmask property there...

petern wrote:You've missed the original refit bitmask property there...

I know, I tried to figure out how to document the logic, then my brain exploded.

Additional version showing interaction with existing cargo refit mask. (Thanks to Eddi who worked it out)

andythenorth wrote:

wallyweb wrote:A question: Is there a way for the industry set designer to provide a variable text 'cargo name' for an industry's product, perhaps as an Action0 property?

Hi Wallyweb, can you expand how you see this working?

My bad. Action8 should be Action0 (1)

The GRFSpecs seem to be very restrictive as to the names of the cargoes in that the name is also the Cargo Type.
Then we have Cargo Labels where a Cargo Description is matched to a Cargo Class.
The Cargo Description seems to be the same as the Cargo Type.
Unless the Industry set author defines an new Cargo Label, he/she is locked in to what is available.
Would it not be simpler to simply define the Cargo Classes as per this discussion?
Then the set author would use three Action0 properties to set input cargoes classes and two Action0 properties to set output cargo classes.
There would then be, respectively, three and two Action0 properties that accept text entries where the set author could define any name that he/she feels is appropriate.
The transport set author would similarly assign Cargo Classes to his/her vehicles.
Vehicle refitting would be based on and limited to the names defined by the industry set author for that particular Cargo Class.

I realize that this would probably require some major rewrites to the game code.
Also, where TTDPatch is essentially an overlay to Transport Tycoon, it would be unable to use this proposal.
So, this would be an OTTD solution.
This would fit in with the accompanying NewGRF v8 discussion.
This would allow for NewGRF v8 to be implemented as an "OTTD only" solution.
NewGRF v7 would remain as an "all platform" solution so as to preserve existing sets, scenarios and saved games and to satisfy the needs of those wishing to design within it's parameters.

This would probably require a considerable amount of "thinking outside of the box" where that box is constricted to expanding upon the limitations set by Transport Tycoon and TTDPatch.
This would probably require going to OpenTTD II.
The advantage is that TTDPatch and OpenTTD I would remain as viable platforms still open to development and maintenance for those who want them.
OpenTTD II would then be free to expand into unrestricted/unexplored territory.
This would be a win-win solution for everybody.

@andythenorth - I don't know if this is what your were asking me for. If I've completely twisted your synapses, my sincerest apologies to your psychiatrists.

(1)

Eddi wrote:mäh... was late... not concentrated...