How is max reliability computed?

[palsecam]

I'm playing with breakdowns ON.

I understand that each time a train is serviced, its own reliability increases.
But is it possible to increase the overall reliability for a particular vehicle type ?
How to increase max reliability ?

thx

[jfs]

Max reliability is just a property of the vehicle model. The same vehicle model will always have the same max reliability across different games. The max reliability starts out very low when a model is first introduced, rises quite fast to the max value the model can have, stays there for the available period of the model, then begins to drop as the vehicle is no longer supported by the manufacturer.

There's nothing you can do to influence it.

[palsecam]

rises quite fast to the max value the model can have

You mean the max reliability is only time dependent ?

[planetmaker]

Yes, it's a vehicle type property, not a vehicle property. You can only influence the actual reliability of a vehicle by servicing it - which will set the reliability to the (current) max reliability of the vehicle model.

[PikkaBird]

Max reliability is just a property of the vehicle model. The same vehicle model will always have the same max reliability across different games.

Er, no?

The maximum reliability is randomised (between 75 and 100%) for each vehicle model in each game. It is not a set property and cannot be modified by NewGRF.

[jfs]

The maximum reliability is randomised (between 75 and 100%) for each vehicle model in each game. It is not a set property and cannot be modified by NewGRF.

Huh I always had that impression that vehicle models were defined to be more or less reliable as a(nother) way of balancing them against each other.
But yeah, you're right.

[Korenn]

I'm playing with breakdowns ON.

I understand that each time a train is serviced, its own reliability increases.
But is it possible to increase the overall reliability for a particular vehicle type ?
How to increase max reliability ?

thx

yes, it's possible - by accepting and using the prototype before it's released, the max reliability for that vehicle will be increased once it's officially released.

[Edit] Oh wow, I just checked to make sure. apparently that's not a thing. I always thought it was

[palsecam]

thx all

I'll end up by maximizing controlled servicing, to reduce breakdown impact

[odisseus]

If you have problems with train reliability, you should read about the advanced depot configurations, in particular about forced servicing.

[LaChupacabra]

I'll end up by maximizing controlled servicing, to reduce breakdown impact

You don't have to maximize it too much. It is enough that the vehicle goes to the service at least once every XXX (censored)* days. I never hope that any vehicles will go to the service at the right time - this only creates problems, sometimes big ones. The best method always been (censored)* which odisseus mentions with (censored)* time between compulsory services. Thanks to this, you can even eliminate breakdowns completely, and trains will never pass the station because they just wanted service.

*I won't give you password to the treasury , it would be too easy

Huh I always had that impression that vehicle models were defined to be more or less reliable as a(nother) way of balancing them against each other.

by accepting and using the prototype before it's released, the max reliability for that vehicle will be increased once it's officially released.
[Edit] Oh wow, I just checked to make sure. apparently that's not a thing. I always thought it was

Methinks everyone thought or still thinks because it seems obvious.

This random reliability was maybe a good solution once, when there were several vehicles, and practically only one, because there was no competition between vehicles - the latest was always the best. At that time, the reliability parameter was only relevant during the period of introducing a new vehicle.
Now, when there are even several dozen comparable vehicles in one set, this random reliability makes no sense. Many sets try to give a real cross-section of vehicles from a given country or region. They reflect all technical specifications but cannot show reliability that is random. For many vehicles, it is often well known which are / were reliable and which are unreliable. Here in the game often these parameters look completely the opposite.

From what I know, it is currently impossible to determine the reliability value in newGRF, but ...
if I am not mistaken, it is possible to determine the rate of decline of this reliability, and hence the actual reliability.
This means that the reliability value shown could be linked to the authentic parameters set by the authors of the addons.

From my observations, even this random value of reliability does not determine this reliability, or has a very small impact - no matter what reliability they have, they break down on average after the same time since the last service. I may be wrong, but the differences are really small.

[ekowi]

Hello,

I am wondering how could this happens: start a new game, and I observe the vehicles have high max reliabilities. In another game, I notice the vehicles have more or less lower reliability. See both savegames. Both are fresh starts, no newgrfs, OTTD version 1.10.1.
In the "high reliability" game, the new model RV and planes have max reliabilities close to 100% OR 75%, while in the "low reliability" game, they have about 86-88%, so curious.

[PikkaBird]

I am wondering how could this happens

As I said, each vehicle model's maximum reliability is randomised in each new game.

[ekowi]

Yes I understand that but why I'm seeing unfairness between game to game? I'm sure in a "low reliability" game I never get any vehicle with max reliability above 92%. Or is this by design? midpoint of 75% and 100% is 87.5%, in a "low reliability" game, the randomizer gives 87.5 plusminus some small amount, giving me 86-90, while in a "high" reliability" game the randomizer gives 87.5 plusminus a large amount giving 75% or 99%-100%, maybe this is just my thinking but I feel very suspicious.

And I never observe this in previous OTTD version, maybe since 1.8, I forget.

[_dp_]

in a "low reliability" game, the randomizer gives 87.5 plusminus some small amount, giving me 86-90, while in a "high" reliability" game the randomizer gives 87.5 plusminus a large amount giving 75% or 99%-100%

That's just how random is. Sometimes you get lucky, sometimes you don't. If you see anything suspicious in this line (that hasn't changed for 11 years) feel free to open an issue or pull request.

[ekowi]

Where/how should I ask if I want to make sure I understand the code correctly?

[ekowi]

Here is my understanding of the code, please correct me if I'm wrong.

Line 654: a random seed is generated from 1) world generation seed, 2) veh. introduction date, veh. type, and GRF id.
658: random() is called once, I call this r1. it is used to randomly shift the introduction date.
667: r1 is also used for starting reliability.
668: random() is called again, call this value r2.
669: the lower 14 bits of r2 is used for max reliability.
670: the higher 14 bits (from bits 16-31) of r2 is used for final reliability.

I also read how the pseudorandom function is generated, in random_func.cpp, which utilizes XOR and bit-rotate operations.
I copied the relevant part of the reliability-calculation code and the random functions, test it in code::blocks in c++. What I observed from the result is:

1. the max reliability is not random enough, small changes in the seed (I tried incrementing it 100 times, maybe not large enough difference) does not make the result change much.

2. In the other hand, starting and final reliability differs randomly enough for me.

3. I load again my recent OTTD (1.10.1) savegame with egrvts v2 and NARS 2.51, sort the vehicles by intro date, and observe that vehicles with similar introduction dates tend to have similar max reliability too, which supports my argument in 1).

What I tried to address this issue was adding just one more random() call before line 669. This makes all 3 reliability values looks "random" enough.

[PikkaBird]

What I tried to address this issue was adding just one more random() call before line 669. This makes all 3 reliability values looks "random" enough.

One of the golden rules of random values is they don't always look random. Our brains are trained to spot patterns even where patterns don't exist - and you appear to be making a call about how "random" these values are based on a sample size of one.

In any case, I'm not sure how calling the random() function a second time is going to make it "more" random.

[ekowi]

I'm giving more evidence for my suggestion that reliability calculation is not random enough, for a single game (certain generation seed), a vehicle type (e.g. trains), and single GRFid.

My understanding of the code is that max reliability then depends on the base introduction date, so if there are 2 trains with identical base_intro value, the start/max/final reliabilities will be identical too. Am I right? Because if not, then the rest of this post is meaningless.

I tried calculating reliability values for all dates from 1950 to 2050. For the (generation seed ^ engine type ^ grfID), I substituted it with google-generated 32 bit random number. I tried 4 times, but could be more if needed (but how should I show the result from 10000 tries?).

This is the result from original code:

original code

output.png (27.33 KiB) Viewed 3721 times

Horizontal axis = years, vertical axis = reliability in %
blue = starting reliability, red = max reliability, orange = final reliability.
You can see here, that for these cases, which I didn't preferentially select from any other cases, that for most of the time, max reliability tends to change little by little. Sometimes it jumps. But if you have 2 trains introduced within 2-5 years, it is much more likely than not, that the max reliability will be similar. Which is what I see in my games.

Now this is the result when 2 extra Random() is called before calculating max reliability:

2 extra Random()

output2r.png (29.32 KiB) Viewed 3721 times

This is the result when 2 more extra Random() is called:

output4r.png

4 extra Random()

(125.84 KiB) Not downloaded yet

So what I think is, the code is designed to scramble numbers based on a parameter, the base_intro, but the result is like scrambling an egg with only 1 stroke of the fork, not quite scrambled.

[jfs]

I'm going to agree with you on that, it looks very fishy and wrong. The RNG also seems to be very predictable in some of the bits after initial seed, the RNG itself should possibly also be reviewed.