Cargo altering decay rate proposal.

[michael blunck]

IMHO what is actually needed [...] would be a modification to the decay rates depending on vehicle type, like a dining car reduces decay for passengers, and a refrigerated van reduces decay for food.

i don't think it needs to be on a per-cargo basis. my immediate thought is that it only really makes sense for the passengers and the refrigerated cargo classes. [...]

a possible vehicle set design could be:
local passenger coach: high capacity, unchanged decay
long distance passenger coach: medium capacity, half decay
luxury/sleeping car: low capacity, quarter decay
dining car: no capacity, but half decay for whole train [cumulative with long distance = quarter decay, cumulative with sleeping car: one eighth decay]

Just some thoughts on your proposal.

1. IMO, your original idea is (and should be) part of a much larger undertaking, namely "economy and (re-)balancing". And something like this should be integrated into the game engine but not into the vehicle newgrfs.
2. The usual way to handle the "decay" of cargo is speed, especially for passengers.
3. Restriction to only two cargo types (passengers, refrigerated cargo) seems to be arbitrary in the general context, IMO.
4. Decay rates should be bound to cargoes, i.e. being implemented into the cargo/industry newgrfs.
5. With custom cargo/industry sets available, it´s already possible to handle cargoes in a different way w/r to "decay". E.g., in ECS, the "tourists" cargo is already a member of the "passenger" cargo class, it could easily been used as a "less-decaying cargo" for long-distance hauling. Likewise for "refrigerated" cargoes.

[load amount]

actually, i did not forget it, i omitted it. because i think it is of minor significance. especially with destinations, where trains rarely unload completely.

Well I would´t call the use of "load amount" being of "minor significance", with loading time relations being in the range of [1 .. 8] for the DB Set. The problem with "destinations" seems to be intrinsic to that feature, though. I don´t use cargo destinations, so I don´t know about.

i understand how you tried to solve the balance with this, but it doesn't solve the fact that the capacities of local and long-distance coaches is reversed. (which you admitted yourself here and here).

Yes, that´s a feature, not a bug. It´s keeping people away from using larger capacity local couches also on long distances, and vice versa. The dining-cars, loading even slower, are an extra penalty for very long trains, so it makes only sense to use them on really long distances.


In conclusion, IMO this is a pseudo problem. We don´t need additional adjustable decay rates for long distances, but faster trains for those routes, i.e. not "half decay" but "double speed" (like in RL). And for reeeaaally long routes, you should think about using planes instead of trains, simply because TTD is a transport game, not a railway game. In case you don´t like that "realism" aspect too much.

regards
Michael

[Eddi]

1. IMO, your original idea is (and should be) part of a much larger undertaking, namely "economy and (re-)balancing". And something like this should be integrated into the game engine but not into the vehicle newgrfs.

yes, but a full rebalance is a really huge task. i don't see anyone capable of managing this. several people have attempted it already, none succeeded. that's why small incremental improvements are useful.

2. The usual way to handle the "decay" of cargo is speed, especially for passengers.

yes, there is nothing wrong with that, but "speed is not everything". that's why i said "TTD is very shallow in some places". in original gameplay, speed was literally the only thing that had any effect on transportation.

3. Restriction to only two cargo types (passengers, refrigerated cargo) seems to be arbitrary in the general context, IMO.

i agree, this part is clearly demanding more discussion.

4. Decay rates should be bound to cargoes, i.e. being implemented into the cargo/industry newgrfs.

they are, they have always been, but this is global, not based on the transportation method.

5. With custom cargo/industry sets available, it´s already possible to handle cargoes in a different way w/r to "decay". E.g., in ECS, the "tourists" cargo is already a member of the "passenger" cargo class, it could easily been used as a "less-decaying cargo" for long-distance hauling. Likewise for "refrigerated" cargoes.

"tourists" are a very wrong concept for completely different reasons. likewise, separating "unrefrigerated food" from "refrigerated food" by cargo is complete rubbish. (maybe i just don't see your point)

i understand how you tried to solve the balance with this, but it doesn't solve the fact that the capacities of local and long-distance coaches is reversed. (which you admitted yourself here and here).

Yes, that´s a feature, not a bug. It´s keeping people away from using larger capacity local couches also on long distances, and vice versa. The dining-cars, loading even slower, are an extra penalty for very long trains, so it makes only sense to use them on really long distances.

just because it's a feature, doesn't mean i have to like it

In conclusion, IMO this is a pseudo problem. We don´t need additional adjustable decay rates for long distances, but faster trains for those routes, i.e. not "half decay" but "double speed" (like in RL).

i disagree, speed has its limits, you can't just increase speed forever. historical development agrees, there are phases of fast development, where a technology jump occured, and then phases of stagnation, where the technical development gets at its limts. during these phases of stagnation, other things have to be improved. IMHO the game lacks methods to model these "other things".

And for reeeaaally long routes, you should think about using planes instead of trains, simply because TTD is a transport game, not a railway game. In case you don´t like that "realism" aspect too much.

there is no reason that this method wouldn't work on planes as well. there are "cheap" airlines whose only concern is shoving as many people into one plane as possible, neglecting all sorts of comfort, and there are "expensive" airlines, who have increased leg space, food, headphones etc. included. clearly, passengers would undertake much longer journeys in those. also ships could benefit from this, because ships are often much slower than any other means of transportation, but cargo that takes ships doesn't usually care about how long it takes at all...

[Voyager One]

You're BOTH right in most of the things you've written. Now, the problem (as far as I can see it) is to make a compromise between your different views on this matter. What would be viable (code-wise, game-wise etc.)? What would be interesting to implement? Is there a problem at all?

IMHO, someone could go on making a patch and extending this to the limit but I'd suggest a simple "switch" (in the game menu i.e.) for altering decay rates from, just as a "first-aid" solution if someone reeeaaaly needs it. As I've said, I'm fine with the current setting.

[Leanden]

And for reeeaaally long routes, you should think about using planes instead of trains, simply because TTD is a transport game, not a railway game.

So back to my original point, why are RVs at such a disadvantage. If this is a transport game, it should be rebalanced so that Railways arent always used in favour of RVs

[Tafidis]

Some code-side points w.r.t implementation of this feature. (NOTE: My coding skills and knowledge of OpenTTD code are limited, just want to help if I can)

Cargo aging in OpenTTD occurs periodically (every 185 ticks), where for each vehicle (I guess this means a part and not a consist, e.g. a wagon, articulated part of RV, "shadow" of plane carrying mail), the cargo currently loaded is aged by one day.

If a callback is implemented that queries a property of this vehicle (let's call it "cargo_decay_rate") regardless of the type of vehicle/cargo, would that be flexible enough? That is, it would be entirely up to the NewGRF set to set that property depending on its own parameters, presence of dining/sleeping cars etc.

This way, each set author would be able to code which cargoes decay at what rate and for which vehicles/consist types, without limiting it to refrigerated food/long distance passengers.

As already mentioned, this property would need to be updated (via another callback) when consist is rearranged/reffitted. E.g. you could buy a standard Boeing 737-800 and optionally refit it with the extras [TVs/headphones/offer meals - one option: all or nothing] which would make the pax payment decay slower (rather than increase base price, which IS possible atm), but not that of mail, of course (different vehicle in the consist).

About "cumulative" effects

Is this possible with the current NewGRF spec? Especially w.r.t trains, is it possible to set this property for each vehicle in the consist based on the presence/absence of dining car?. I am aware of a related discussion (querying other vehicles in consist), at least I think it is related?

[Eddi]

let's assume you add a property "cargo decay frequency" defaulting to 185 for each vehicle, and use this property's value in the function that calls AgeCargo. this is enough for refrigerated food wagons or long distance cars to work like described above.

then you need a callback like cb 36 to make the value more flexible. it would be called in all important cases like refitting or changing the consist.

what the newgrf then can do during the calculation of that callback is check var 60 to look whether a dining car is present in the consist, and return a different value.

in this case, it would be the sole responsibility of the NewGRF author to make the "cumulative" values add up, the game will just take any value you define.

PS: this has actually nothing to do with the "check properties of other vehicles" discussion

[michael blunck]

[...] what the newgrf then can do during the calculation of that callback is check var 60 to look whether a dining car is present in the consist, and return a different value.

Usually, "special" types of coaches like dining-cars, sleepers, ..., are just overrides of normal coaches. They don´t have a distinct veh-ID to check for.

regards
Michael

[Eddi]

[...] what the newgrf then can do during the calculation of that callback is check var 60 to look whether a dining car is present in the consist, and return a different value.

Usually, "special" types of coaches like dining-cars, sleepers, ..., are just overrides of normal coaches. They don´t have a distinct veh-ID to check for.

regards
Michael

Yes, it wouldn't quite work that way for the DBSetXL, but i am speaking about some hypothetical set which implements this differently and allows adding a dining car explicitly (as a vehicle that doesn't have capacity, but has the effects mentioned earlier)

[Leanden]

[...] what the newgrf then can do during the calculation of that callback is check var 60 to look whether a dining car is present in the consist, and return a different value.

Usually, "special" types of coaches like dining-cars, sleepers, ..., are just overrides of normal coaches. They don´t have a distinct veh-ID to check for.

regards
Michael

Yes, it wouldn't quite work that way for the DBSetXL, but i am speaking about some hypothetical set which implements this differently and allows adding a dining car explicitly (as a vehicle that doesn't have capacity, but has the effects mentioned earlier)

Like BROS will do.

[michael blunck]

[...] what the newgrf then can do during the calculation of that callback is check var60 to look whether a dining car is present in the consist, and return a different value.

Usually, "special" types of coaches like dining-cars, sleepers, ..., are just overrides of normal coaches. They don´t have a distinct veh-ID to check for.

Yes, it wouldn't quite work that way for the DBSetXL, but i am speaking about some hypothetical set which implements this differently and allows adding a dining car explicitly[...]

I wouldn´t think of this being specific for the DB Set, as this is exactly the envisaged usage of the "livery override" feature.

[...] E.g. It has been suggested that food on refrigerated wagons should age slower than on normal container wagons (in the graphics forums, I did a search earlier today)

Makes not much sense for me, because

- "food" is a general term. It´s handled in newgrfs quite differently. E.g. in the DB Set I´m using cargo sub-texts of "meat products", "canned fish", "frozen fish", ..., for "food", which all may be transported in a reefer car.

- everybody would only buy reefer cars to minimize the effects of cargo aging altogether.

Let me refer to one of my recent posts: handling of cargo decay should stay in the domain of the cargo-defining newgrfs, and shouldn´t be handled by the vehicle newgrfs.

regards
Michael

[Eddi]

- everybody would only buy reefer cars to minimize the effects of cargo aging altogether.

the gameplay effect here would be the following:
in the early vehicle sets, refrigerated wagons are not available, so you can only transport food over very short distances. with increasing speed, you can deliver it slightly higher distances, but only with the advent of the refrigerated transport, you can transport it really far.

[michael blunck]

- everybody would only buy reefer cars to minimize the effects of cargo aging altogether.

the gameplay effect here would be the following:
in the early vehicle sets, refrigerated wagons are not available, so you can only transport food over very short distances.

Which would be quite inconsistent, because refrigerator cars had been used nearly from the start. That would be a no-go for vehicle sets modelling a specific railway or a specific country.

regards
Michael

[Leanden]

- everybody would only buy reefer cars to minimize the effects of cargo aging altogether.

the gameplay effect here would be the following:
in the early vehicle sets, refrigerated wagons are not available, so you can only transport food over very short distances.

Which would be quite inconsistent, because refrigerator cars had been used nearly from the start. That would be a no-go for vehicle sets modelling a specific railway or a specific country.

regards
Michael

But if you were to model a real-life railway, then you would want to transport food over long distances so it wouldnt really be a no-go unless you were then using that set just for gameplay purposes rather than realism.

[Eddi]

- everybody would only buy reefer cars to minimize the effects of cargo aging altogether.

the gameplay effect here would be the following:
in the early vehicle sets, refrigerated wagons are not available, so you can only transport food over very short distances.

Which would be quite inconsistent, because refrigerator cars had been used nearly from the start. That would be a no-go for vehicle sets modelling a specific railway or a specific country.

regards
Michael

well, that's the point where you have to decide whether to implement "realism" or "interesting gameplay".

but that is no reason against this feature in general, only to not put it into your grf, which is entirely your choice. just leave it at the default value.

[Leanden]

well, that's the point where you have to decide whether to implement "realism" or "interesting gameplay".

Exactly, for example BROS would go for realism while UKRS would probably go for interesting gameplay.

[Tafidis]

Ok, let me get this straight: I (a hypothetical train set author) draw some sprites as models of actual railways etc. I then define which cargoes each of my vehicles can carry. The proposition we are discussing can then be summarized as: I want pax on my long distance coaches or food on my refrigerated trucks to decay slower, so that the player will have more incentive to use them instead of standard wagons.

Let me refer to one of my recent posts: handling of cargo decay should stay in the domain of the cargo-defining newgrfs, and shouldn´t be handled by the vehicle newgrfs.

I am guessing this is kind of the "opposite" argument? E.g. I define a cargo sub-type "fresh-vegetables" (hint:needs refrigeration) which decay faster than "cans of tomatoes". Can then "fresh-vegetables" be carried ONLY in refrigerated wagons, or how can their decay vary amongst different modes of transport?

How does this then apply to passengers without defining "tourists", "travellers", "commuters" etc? Will there need to be sub-types for EVERY cargo in order to model decay rate variance?

Also, OpenTTD and I am guessing TTDPatch too, age the cargo only when it is loaded on vehicles, so it makes sense that the vehicle type has an effect on a specific cargo, and each vehicle set author would be free to use/not use this feature of course.

everybody would only buy reefer cars to minimize the effects of cargo aging altogether.

Don't think so. E.g. they could have high running costs (need power for refrigeration) so they are less profitable for short routes (because the difference in days_in_transit is small and so the increased profit doesn't make up for the increased running costs)

PS: this has actually nothing to do with the "check properties of other vehicles" discussion

Thanks, I think I understand this now from the rest of your explanation + some reading I had done before on the NewGRF spec description and CB36 specifically.

EDIT: Perhaps the cargo-defining NewGRF could describe HOW the cargo decay rate is modified IF a vehicle has a FLAG to increase/decrease decay rate. E.g, If the vehicle set defines a long distance coach and sets this FLAG for all/some cargoes this vehicle can be refitted to (pax, tourists) , the cargo defining NewGRF could say (pax: x2 slower, tourist: no effect)

[oberhümer]

Just wanted to inform everybody that this has been implemented in r22713 by michi_cc.

[DJ Nekkid]

I heavnt read the WHOLE thread, but all of the 1st page, and rougly half of the 2nd page, but from a 'trainset dev' view, this proposal makes A LOT of sense. And also, as far as i undersetand MB, as well as i have played with the DB-set earlier, i've always found the local wagons in that set confusing. Why in the world would i add a coach that have actually LESS capacity to the same train then one with higher capacity.
In the later years i did found out that the local coaches did have a higher un/loading speed, but that werent mentioned any placed i did read, especially ingame.


But also, froma trainsetdev pov, adding the ability to add a i.e. dining car to a set, to let the decay rate be lower / profit be higher, would make sense. Some trains WOULD be able to attach it, some would not. Thus even seprarating the regional, local and IC train further.

Example, from the 2cc set (doh?):
Here we currently have 3 different passenger train types:
Metro : Very high capacity, Very high un/loading speed, low speed (roughly 120-250 capacity, 60people/tic, roughly <100kmh speed) - Not suitable for dining car
Regional: medium capacity, speed and un/loading speed (rougly between 60 and 120 capacity, 20people/tick, roughly 120-180kmh speed) - Mostly not a dining car, but mainly on the higher speeds? (150kmh+?)
Intercity: Low capacity and un/loading speed, high speed (roughly between 30 and 60 capacity, 8people/tick, roughly 200+kmh speed) - Often a dining car, but especially on the lower speeds? (150-230kmh?)

Adding inn the availability of a dining car to add less decay to certain trains would prove to be quite nice i think. Some of the higher speed regionals might have a dining car, but some of the lower speed IC's might not. Thus might a regional train fit better, or a IC train might fit better, depending on range and needed capacity. Especially in a cargodist/dest/whatnot game, where a LONG and FAST train would typically cost too much, but a 5 unit long (paxhead+trailer+dining+trailer+paxhead) would make A LOT of sense in many in many cases.
Last word: a callback where the +- range of such a wagon might make sense. I.e. any wagon within +-4 wagons of a dining car would have this bonus, but anything beyond 5 would be 'out of range' (people are damn lazy!).

I might be off on this point, but IRL i feel that the very high speed train links dont take A LOT of time (roughly 2hrs and less), and thus often dont have a dedicated dining car, but the 'low speed' intercity links might do? Say the 3+ hour train rides. Typically where trains have higher marketshare then airplanes the dining car might not be as important as vica verca? (Many question marks here, and PLEASE be free to correct me on this). But i feel that on a 2hr trainride i should not have the same food craving as on a long one. A typical vendingmachine with a snickers bar should be sufficient, where on a longer ride i probably would like a burger and fries, or meatcakes with brown sauce, or perhaps even a stake with baked potatoe ... ???

[Cadde]

At first i was like: Doesn't it suffice to think that these things are already taken into account?
For instance, adding the proposed cars would make regular cars less profitable as for example food is already in refrigerated cars and passengers already have access to a dining car. (even though not seen, just imagined it's there)

But from a diversity standpoint it is a good idea and i like it a lot. The same way i can hardly wait for speed limited freight cars in 2cc. (I tend to just pick the fastest loco even for freight because speed always offsets running costs)
With that said, may i also suggest that dining cars would have higher running costs associated with them? So that if you are transporting very few passengers the benefit of having one is offset by the cost of having one. And the more passengers the train is carrying the less the running cost of a dining car is as more passengers spend more money in the dining car.

One of these days maybe we will have several types of passengers?

* Those who want to get somewhere fast. (businessmen etc)
* Those who want a regular service. (commuters)
* Those who want fast and luxurious service. (the rich and famous)
* Those who just want to get there. (Your average Joe who can't afford 1st class etc)

Ofc that is a question for another GRF that implements these cargo types. (which leads me to the wish one could have more than 32 cargo types... )

As for someone who said OTTD is (already) too complex... You obviously haven't played OTTD long enough! Sure, it might be complicated for a newbie (newbies shouldn't use 2cc and ECS/FIRS anyways unless they are ready for the steep learning curve) but for a seasoned veteran who has played TT since it's inception it's not complicated enough!
The more depth that can be added the more fun it is and the longer it will last. The only reason people still play TT is because of TTDPatch and OTTD... No, not due to compatibility issues... But because of the features they add which prolong the enjoyment of the title.