Game design is opinionated :)

I think game mechanics should reward good track design: when vehicles operate smoothly in the network.
On the other hand: stopped vehicles, waiting at signals, or in stations, are a sign of bad design.
As such I think the incentive here to make waiting trains less punishing is weird. I would rather see stronger reliability drops when vehicles do not operate at the speed limit (too few, too weak engines), or when they have to go through stop-start cycles (many blocking signals), ...

Either way, the usual disclaimer applies: moddable game mechanics are better, they allow for more opinions :)

I like your idea about tying reliability drops to how hard the vehicle is working — either climbing hills or from many start-stop cycles. When I worked for the railroad, pushing machinery like this was the cause of most breakdowns. However, that would need a new algorithm which opens up many new questions of game design and balance. :) My goal is to find a simple remedy to the most-unpopular aspects of breakdowns, and leave room for others to iterate later (perhaps based on the Improved Breakdowns patch, which is in JGRPP).

I disagree that vehicles waiting in a station are a sign of bad design. Industry production mechanics require frequent service, and always having a vehicle loading with a "full load" order is recommended practice.

Vehicles stuck in traffic or at signals are indeed symptoms of inefficient design, but I don't feel it's the job of reliability decay to punish this. We have running costs and cargo decay for that, not to mention the mathematical inefficiencies which requires more vehicles to transport a given amount of cargo.

I agree that moddable game mechanics are ideal, but unless I'm mistaken it's not currently possible for NewGRF authors to change reliability decay.

Yeah, every extra stop is already heavily penalized with cargo payments. And breakdowns don't just penalize, they turn small mistakes into a huge disaster that takes ages to clean up because vehicles are not even moving anywhere as they're constantly breaking.

I like this PR, but not 100%. ;) I think that the stoppage should still have some impact on the reliability drop. Otherwise it would be too simple and not relevant to reality.
Real life example: Stop in a traffic jam on a motorway on a hot or very cold day, and stand still for many hours. It doesn't work for the car the same as stopping it in the garage. So, if you want to reduce the drop in reliability during standstill, it definitely not should be none. -50%? Maybe even -80%?

I also like the idea that a vehicle traveling at a speed other than the maximum it can reach will lose reliability faster.

I would see it like this:
-the vehicle is traveling at full speed - rate of decline in reliability: 80%
-the vehicle is traveling at a speed other than the maximum speed - rate of decline in reliability: 120%
-the vehicle is outside the workshop - rate of decline in reliability: 20%
-the vehicle is standing in the workshop - rate of decline in reliability: 0%
The numbers given are examples. Ultimately, breakdowns shouldn't be more frequent than they are today.

The fundamental question here is: How could this change be implemented? As a modification to "reduced" breakdowns, or as a new setting? Maybe you should consider this as part of an "improved" breakdowns? When playing on JGR's servers, many players felt that this was one of the best things about JGRPP that is missing from the regular version of the game.

the vehicle is traveling at a speed other than the maximum speed - rate of decline in reliability: 120%

Hmm, sounds weird to me. If a vehicle is traveling at a speed, different from it's maximum speed, it is slower without exception. To me slower speed means lower abrasion and lower abrasion means lower maintenance cost. So IMHO the decline rate as an equivalent for variable maintenance costs has to be lower than the 80% for travelling at maximum speed in your example.

To me slower speed means lower abrasion and lower abrasion means lower maintenance cost.

I think the extra penalty for unusual speeds is to simulate wear-and-tear caused by acceleration and braking.

the vehicle is traveling at a speed other than the maximum speed - rate of decline in reliability: 120%

Hmm, sounds weird to me. If a vehicle is traveling at a speed, different from it's maximum speed, it is slower without exception. To me slower speed means lower abrasion and lower abrasion means lower maintenance cost. So IMHO the decline rate as an equivalent for variable maintenance costs has to be lower than the 80% for travelling at maximum speed in your example.

I think this should rather look at "if the vehicle is unable to reach the maximum speed for its configuration and track it's running on", i.e. a train or road vehicle that is underpowered compared to its weight, and is hence running the motor at maximum load.

a train or road vehicle that is underpowered compared to its weight, and is hence running the motor at maximum load.

So this would have to take the power/weight ration into consideration. But in reality the effect of underpowerness is different from construction to construction. I've no idea how to bring that into a game in a simple way. :-/

This is functionality that can be implemented and controlled by NewGRF, and doing so in the base game would interfere with how that works.

And as frosch123 says,

Either way, the usual disclaimer applies: moddable game mechanics are better, they allow for more opinions :)

Therefore a big no from me.

This is functionality that can be implemented and controlled by NewGRF, and doing so in the base game would interfere with how that works.

Purely from a player point of view, functionality like this is far more likely to work correctly if it's in the codebase, instead of it being kludged in a NewGRF.
It's not clear from the NewGRF spec how this would be achieved properly.
Similar functionality which has been tried in NewGRFs such as running costs or cargo ageing which vary with vehicle speed/state is typically broken, very limited, or creates multiplayer desync problems.

+1 to everything JGR wrote.

I would appreciate an explanation of how to implement variable reliability in NewGRF, as I must be missing something — I see a static property for reliability decay and a variable which holds the current reliability, but no callback to change the decay rate based on speed or other author-defined logic. I would also prefer to see this implemented in OpenTTD itself, but if that's not agreeable would be willing to implement it in my own train set and push for inclusion in other popular sets.

auge8472: So this would have to take the power/weight ration into consideration. But in reality the effect of underpowerness is different from construction to construction. I've no idea how to bring that into a game in a simple way. :-/

Such an approach, where any speed other than the maximum speed causes increased wear, is a simplification. Of course, the point is that accelerating or braking always causes more wear than driving at a constant, even high speed. In my opinion, there is no point in complicating it too much, because the end result will not be significantly different anyway.

PeterN: This is functionality that can be implemented and controlled by NewGRF, and doing so in the base game would interfere with how that works.

I fully understand this approach, that's why I asked about Improved breakdowns - this modification could be part of this option.

But I also really don't like this solution.
This is hidden, unrepeatable, because each add-on can work differently, and the worst it has nothing to do with the reliability parameter. It makes no sense at all. A vehicle with a reliability of 99% may fail more often than the one rated at 80%. How is the player supposed to understand this? Where's the logic in that? How is the developer of the add-on would to convey this information to the player? How to name it? Reliability of reliability? Why should something that can be simple be complicated?
The mechanism of declining reliability should not be hidden, let alone be different for each vehicle. Moreover, I believe that the level of reliability should not be random - it can breaks the balance of the add-ons and makes it impossible to mark vehicles as more or less reliable - everything is hidden. When creating an add-on with real vehicles, it is often known which vehicles were reliable and which were excessively emergency - this fact cannot be easily transferred to the game. The reliability parameter should be configurable, not some incomprehensible and illogical mechanisms hidden from the player - in my opinion these should be constant and the same, because it allows them to be understood.
Sorry, but I can't write any softer. It's not for you, Peter. I just don't like this solution and would really prefer it to go a different route.

In conclusion:

1. I believe it is worth reducing the rate of decline in reliability while the vehicle is stoppage, but not completely.
2. This is less important, but I also think it would be worth adding the effect of vehicle load on the rate of decline in reliability. However, I don't think it's worth making it too complicated.
3. Developing the ability to individually modify the rate of decline in reliability is a dead end - it does not make it easier to understand what affects the failure rate of vehicles. In my opinion, the main property of reliability should be able to be defined, not only random.
4. The question still remains, how could this change be add? As long as it is right, of course. And how does this relate to the improved breakdowns that are in JGRPP?
5. In my opinion, it will be better as separate, new setting than modifying the existing ones.

Closing this to reduce my open PRs.

I may revisit this later with some form of improved breakdowns which consider how hard the vehicle is working, but it's clear that simply changing this behavior is too contentious to get merged as-is. 😃