Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change: Don't decrease vehicle reliability when stopped #8776

Closed
wants to merge 1 commit into from

Conversation

2TallTyler
Copy link
Member

@2TallTyler 2TallTyler commented Mar 1, 2021

Motivation / Problem

I frequently see comments from players that breakdowns are "broken" and seem random to players. #8317 improves breakdowns by making each service in a depot prevent future breakdowns, but vehicles still degrade while waiting in a station for a full load, waiting for a station track to open up, or while stuck in traffic jams.

I typically service vehicles before they load in a station using a depot overflow, but by the time the vehicle achieves a full load and departs, its reliability has already decreased significantly, despite having only moved a few tiles from the depot to the station. I would expect my vehicle's reliability to only degrade when the vehicle is moving.

While real-world vehicles do degrade in reliability when parked for long periods of time, this is on the order of weeks and months and isn't really applicable to OpenTTD.

We discussed disabling breakdowns by default in #8393 but the consensus was that they should be fixed, not just avoided. This is an attempt to iteratively improve them by fixing what I consider to be an unexpected behavior.

Description

With this proposal, vehicles only decrease in reliability if their speed is greater than 0.

Limitations

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

  • The bug fix is important enough to be backported? (label: 'backport requested')
  • This PR affects the save game format? (label 'savegame upgrade')
  • This PR affects the GS/AI API? (label 'needs review: Script API')
    • ai_changelog.hpp, gs_changelog.hpp need updating.
    • The compatibility wrappers (compat_*.nut) need updating.
  • This PR affects the NewGRF API? (label 'needs review: NewGRF')

@frosch123
Copy link
Member

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 :)

@2TallTyler
Copy link
Member Author

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.

@ldpl
Copy link
Contributor

ldpl commented Mar 2, 2021

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.

@LC-Zorg
Copy link

LC-Zorg commented Mar 10, 2021

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.

@auge8472
Copy link
Contributor

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.

@embeddedt
Copy link
Contributor

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.

@nielsmh
Copy link
Contributor

nielsmh commented Mar 11, 2021

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.

@auge8472
Copy link
Contributor

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. :-/

@PeterN
Copy link
Member

PeterN commented Mar 11, 2021

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.

@JGRennison
Copy link
Contributor

JGRennison commented Mar 11, 2021

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.

@2TallTyler
Copy link
Member Author

+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.

@LC-Zorg
Copy link

LC-Zorg commented Mar 11, 2021

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.

@2TallTyler
Copy link
Member Author

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. 😃

@2TallTyler 2TallTyler closed this Apr 24, 2022
@2TallTyler 2TallTyler deleted the breakdowns branch November 14, 2022 02:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants