Incoming rate modifier - proposal of new vehicle property

[TadeuszD]

I do not know if it was already discussed.
I'm NewGRF developer and I would like to have the vehicle parameter for modifying incoming rate for selected vehicles and cargos.
For example - passengers transported in 1-st class carriage should generate higher incoming rate than passengers in 2-nd class carriage. The grain transported in the cheap open wagon should generate lower incoming rate (grain is not protected against the rain) than grain transported in specialized wagon.

It will be nice to have callback for modifying this incoming rate parameter depending on special conditions...

[michael blunck]

Why not use "custom cargo ageing period" for this?

regards
Michael

[TadeuszD]

Why not use "custom cargo ageing period" for this?

I'm not sure how "cargo ageing period" works now. For me it allows to prevent decreasing the incoming rate due to transportation time. But it does not allows to increase this incoming rate.

[planetmaker]

I understand what you want and why.

Effectively you want to introduce a 2nd place in the NewGRF specs where the value of a cargo upon delivery is defined: not only in the cargo specs but now also in the vehicle specs.

We already have the cargo_aging property for vehicles which effectively results in a cargo paying more for delivery, if it aged slower than usual, and paying less, if aged faster than usual. Given this, and being reluctant to add a 2nd place to change the exact same thing, the base price for a cargo, I'm opposed to adding the suggested property.

[Transportman]

Why not use "custom cargo ageing period" for this?

I'm not sure how "cargo ageing period" works now. For me it allows to prevent decreasing the incoming rate due to transportation time. But it does not allows to increase this incoming rate.

It is not possible to change the base cargo payment for different vehicles at this moment, but with changing cargo_age_period you can still obtain the behavior you want to have. And by setting the cargo_age_period in a switch that depends on the cargo_subtype should do the trick.

Take a look at this piece of code from the Dutch Train Set, lines 207-213. There it is used to choose which graphics to use based on the livery, but it should also work for other stuff like the cargo_age_period.

[michael blunck]

I'm not sure how "cargo ageing period" works now.

Property "custom cargo ageing period" allows to set the ageing time for cargo, which will in turn modify the revenue.

For example - passengers transported in 1-st class carriage should generate higher incoming rate than passengers in 2-nd class carriage.

Well, "custom cargo ageing period" is perfectly usably for features like this. If set lower for 2nd class coaches, revenue for passengers in 1st class coaches will be higher. Or, vice versa, increasing it for the 1st class coaches will result into the same effect.

Same procedure with all other cargo subtypes:

grain transported in the cheap open wagon should generate lower incoming rate [...] than grain transported in specialized wagon.

I.e. "cargo ageing period" set to lower for the open wagons will result into lower revenue for grain transported with this kind of wagon. In turn, grain transported with other types of wagons will automatically gain higher revenue. You could o/c leave the cargo aging period for the open wagon at default, and increase the ageing period for the modern wagon.

In addition, the cargo ageing period can be set by callback 36.

regards
Michael

[TadeuszD]

Thanks guys for all answers.

...to add a 2nd place to change the exact same thing, the base price for a cargo...

Not exactly. I was thinking about percentage multiplier which could modify the base value defined for cargo, but not about overwriting this value. I was thinking about something like the cost_factor and running_cost_factor.

The cargo_aging property works in very specific way. For very short lines relative difference between revenues for 1-st an 2-nd class wagons (described in the example) will be very small, but for very long distances this difference will be dramatically bigger.

But OK. I understand your opposition. Every changes in NewGRF specification should be very thoughtful. It was just proposal.

[michael blunck]

[...] I was thinking about something like the cost_factor and running_cost_factor.

The cargo_aging property works in very specific way. For very short lines relative difference between revenues for 1-st an 2-nd class wagons (described in the example) will be very small, but for very long distances this difference will be dramatically bigger.

Yes, it´s a *factor*, just like cargo price factor is. It is not some constant.

regards
Michael

[Snail]

In my set, I also use that property to differentiate between the revenues of different passenger classes or freight wagons.

I ran some tests and I found out that using this property makes a non-negligible difference only when applied to distances >= 60ish tiles. Moreover, the relationship between the parameter you set for cargo aging and the increase/decrease in revenue you will observe is not linear, but more like hyperbola-shaped. Below certain levels (50ish) you will see a sharp drop in revenue, while above certain levels (around 500) the revenue won't increase any further (as if you had reached a horizontal asymptote). You therefore have a limited set of numbers to play with (default is 180).

[michael blunck]

I ran some tests and I found out that using this property makes a non-negligible difference only when applied to distances >= 60ish tiles. [...]

Yes, this is a direct result of the formula used for calculating cargo revenue:

Code: Select all

income = ((((distance/2) * timefactor * amount_moved) >> 7) * cargopricefactor) >> 13

Disclaimer: this is TTDPatch, can´t be bothered to look up OTTD´s formula right now.

With "timefactor" being a multiplier in the range 0 .. 255, calculated in the following way:

T1 is the value of cargo property 10,
T2 is the value of cargo property 11,
t is the time the delivery took (the unit is 185 game ticks, respectively the value "cargo aging" is set to)

Then,

if t <= T1 then timefactor := 255
else if t <= (T1+T2) then timefactor := 255 - (t-T1)
else timefactor := 255 - (t-T1) - (t-T1-T2)

If the above rules result in a timefactor <31, 31 is used instead.

regards
Michael

[TadeuszD]

In my set, I also use that property to differentiate between the revenues of different passenger classes or freight wagons.
I ran some tests and I found out that using this property makes a non-negligible difference only when applied to distances >= 60ish tiles. Moreover, the relationship between the parameter you set for cargo aging and the increase/decrease in revenue you will observe is not linear,...

I applied this mechanism in my set, but I am not happy with the result. The result is distance and time dependent and in many cases - difficult to predict. Generally, for long distances the income from 1st class wagon is greater than from 2nd class. But for short distance always the 2nd class generates bigger income. It is stupid for me.

Code: Select all

#define AGE_1_CLASS     2*185
#define AGE_2_CLASS     185
switch(FEAT_TRAINS, SELF, switch_abdnu_cargo_age_period, cargo_subtype % 3) {
    1: return int((24*AGE_1_CLASS + 40*AGE_2_CLASS)/64);
    2: return AGE_1_CLASS;
    return AGE_2_CLASS;
}

[michael blunck]

Generally, for long distances the income from 1st class wagon is greater than from 2nd class. But for short distance always the 2nd class generates bigger income. It is stupid for me.

But indeed this is both "realistic" (i.e. what people expect it to be in RL) and called for: "Thou should not use 1st class coaches in local traffic!".

It is exactly how I use this feature in my train set. Before introduction of this feature, I had to switch the usual scheme of 1st vs 2nd class coaches, by enlarging capacity of 1st class coaches, which had always unleashed a discussion about "realism".

In fact, a good set should balance modelling RL against usability. Excessive "rivet counting" on its own would be counterproductive (I´m not speaking about your set here, but I know about excessively designed sets, which most of the time are demanding more game support to implement their sophisticated features.).

regards
Michael

[Transportman]

Generally, for long distances the income from 1st class wagon is greater than from 2nd class. But for short distance always the 2nd class generates bigger income. It is stupid for me.

But indeed this is both "realistic" (i.e. what people expect it to be in RL) and called for: "Thou should not use 1st class coaches in local traffic!".

It is exactly how I use this feature in my train set. Before introduction of this feature, I had to switch the usual scheme of 1st vs 2nd class coaches, by enlarging capacity of 1st class coaches, which had always unleashed a discussion about "realism".

In fact, a good set should balance modelling RL against usability. Excessive "rivet counting" on its own would be counterproductive (I´m not speaking about your set here, but I know about excessively designed sets, which most of the time are demanding more game support to implement their sophisticated features.).

regards
Michael

In the Netherlands you pay ~70% more when traveling first class independent of distance traveled (compared to second class), so "realism" depends on where you are living.

[michael blunck]

In the Netherlands you pay ~70% more when traveling first class independent of distance traveled (compared to second class), so "realism" depends on where you are living.

Sure, that´s also the case over here, and most probably everywhere. But as already stated many times, "realism" (in this game) is not the same as "realism" (outside this game). We´re only using the "real realism" as a common denominator and as a resource of ideas in the development of our sets (at least we should do so, and don´t try to achieve the impossible).

And IMO this is modelled quite nicely by that "custom ageing" feature. It allows to directly influence the decay of cargo value, and thus indirectly manipulating the revenue of that cargo. Hence, it should be used inside that scope, i.e. not on setting amount of revenue but e.g. on introducing "comfort levels", as I do in DBXL (see pic). Thus, the player gets a hint on how to best use a vehicle, it´s not needed to introduce a fixed price scheme for the different coach classes.

cargo aging.png (8.77 KiB) Viewed 2835 times

In fact, there cannot be a direct influence on the revenue itself, since that is a cargo property, defined by the appropriate cargo sets. And BTW, that´s the reason why "tourists" have been introduced in ECS in the first place.

I don´t think there should be another property introduced in the vehicle specs, messing directly with properties of another feature (cargo).

regards
Michael

[Snail]

Shouldn't comfort level vary with the class you refit your coach to? In this specific case, wouldn't that coach had a "medium-high" comfort level if refitted to 1st class, and a "low" level if refitted to 3rd class?

[michael blunck]

Shouldn't comfort level vary with the class you refit your coach to? In this specific case, wouldn't that coach had a "medium-high" comfort level if refitted to 1st class, and a "low" level if refitted to 3rd class?

Well, not all of the DBXL coaches are refittable, and in this case their "comfort level" is static. Otherwise, it is changed by use of CB36 / CB_PROP.

regards
Michael