Vehicle maintenance changes discussion

[AndrewTraviss]

Hi everyone. This game, and this branch of the game in particular are right up my alley, so I'm joining the project to write some code and knock some items off of the todo list. I'm tackling the maintenance stuff first. After looking over the existing systems and what's been proposed, here's how I think everything should end up fitting together.

Wear
Vehicles wear out through use, increasing maintenance costs and reducing resale value. Wear increases slowly at first, then quickly as major parts reach the end of their intended lifespans, and then slowly again. Wear is measured in kilometers. The properties of this S-shaped curve are defined in the pakset based on:
- the original maintenance costs / resale value
- a maximum maintenance cost / minimum resale value
- the number of kilometers of wear at which the maximum cost is reached
- the number of kilometers of wear where the greatest increase in cost occurs


Regular maintenance
Vehicles normally accumulate wear at a 1:1 ratio of kilometers traveled to kilometers of wear. If a vehicle is not maintained regularly, the rate of wear increases due to neglect. Vehicles must visit a depot for annual maintenance to avoid this penalty. Convoys will automatically visit a depot on their schedule once per year based on the following rules. All depot visits should use these rules, including visits triggered by clicking Go To Depot and future Upgrade orders.
- The rate of extra wear due to lack of maintenance should be universal, but configured by the pakset / potentially overriden by player configuration
- Each depot will only automatically service one convoy per line at a time
- Each depot has a maximum number of convoys that it can service at once
- To avoid convoys dumping loads of cargo on each depot visit, the decision to visit a depot (and reserving a spot) will happen each time the convoy skips a depot on the schedule, rather than at the last minute
- The length of time needed to service a vehicle is determined by availability % data for that vehicle in the pakset
- Maintenance time for a convoy is equal to the longest maintenance time out of the vehicles in the convoy


Overhauls
Vehicles which are not obsolete can be overhauled, which resets their wear kilometers to zero. The cost to do so must be less than the net cost of selling the vehicle and purchasing a new one. Whether overhauls occur automatically should be enabled/disabled on a per-line basis. If disabled, a message should be presented to inform the player that it's time for an overhaul. Automated overhauls/messages will occur at the time when maintenance costs are increasing at their greatest rate. Obsolete vehicles cannot be overhauled, as the necessary parts are no longer available. An obsolete vehicle must be upgraded to one that is not obsolete or scrapped. This eliminates the need for any explicit obsolescence penalty; the vehicle will reach its maximum maintenance cost and remain there naturally once it can no longer be overhauled or upgraded.

What does everyone think about this? I know there's been some concerns about requiring regular maintenance at depots, but I think this strikes the right balance between all concerns. There shouldn't be any micromanagement; all of the required decision making happens at the network planning and construction stages or during fleet management.

[Rollmaterial]

As to when a convoy should perform its depot visit, it should be done in a way that it goes to the depot after reaching a stop specified for that and resumes from that same stop. That would minimise the impact on service quality.

[AndrewTraviss]

As to when a convoy should perform its depot visit, it should be done in a way that it goes to the depot after reaching a stop specified for that and resumes from that same stop. That would minimise the impact on service quality.

Hmm, I can see why this would be very important on linear routes, but for a passenger/mail loop the extra backtracking might be more disruptive than just proceeding to the next station. In some situations you may have a loop that doesn't support contraflow traffic, in which case this would cause a lot of unnecessary trouble.

You could achieve this behaviour by setting up a schedule where the stop before the depot is also on the schedule immediately after the depot. Trains skipping the depot would ignore the repeat station while those visiting the depot would return to it after being serviced. This would retain the full flexibility to deal with the depot visits in the way that is most beneficial to your network, and also ensure that the schedule continues to honestly reflect the actual behaviour of convoys on that line.

[jamespetts]

Thank you very much for this: this is most helpful. You have clearly thought carefully about both the design and implementation of this, and most of this seems very sensible.

One or two small things: firstly, I am not convinced by the need to prevent overhauls of obsolete vehicles. I am not convinced that this is entirely realistic (overhauls of thoroughly obsolete vehicles are regularly performed by teams of amateurs on preserved railways, for example), and it might make things unnecessarily awkward for players who might find it hard to predict whether their setting for automatic overhauling of a vehicle would be carried out because it would be hard to predict whether the overhaul would fall before or after the obsolescence point. (One thing that needs to be borne in mind when developing these sorts of features is that the design intention is for this game to be played on very large multi-player maps on a persistent server where players will log on for at most a few hours per day; even though the game will be paused when nobody is logged on, it will still be running when others are logged on, so it must be serviceable for a player to leave the game running for hours at a time unattended without anything going significantly wrong, if the player's finances are in good order).

As to Rollermaterial's suggestion and the response to it, it would be more intuitive, I suspect, to have a specific setting for a depot visit whether a convoy should return to the previous stop or continue to the next stop after visiting the depot. Consideration would also need to be given to implementing a mechanism to stop goods/passengers/mail from loading onto the vehicle if they are bound for a stop beyond the depot point.

In any event, this is very encouraging: thank you again for your contribution. I should be interested in anyone else's views on these ideas, too.

[AndrewTraviss]

To focus on the issue of obsolescence first: perhaps the better solution is to have overhaul costs increase over time after a vehicle becomes obsolete, rather than completely preventing overhauls?

This would require two new vehicle properties to set the maximum overhaul cost and how long it will take to reach that maximum cost. This way, there's no increase of running costs above and beyond the maximum cost specified for the vehicle, but it takes longer for an overhaul to make financial sense as the vehicle ages. We accurately represent the fact that overhauling an obsolete vehicle is generally possible, just increasingly expensive as the necessary parts become more rare.

[HarrierST]

I am not convinced by the need to prevent overhauls of obsolete vehicles. I am not convinced that this is entirely realistic (overhauls of thoroughly obsolete vehicles are regularly performed by teams of amateurs on preserved railways, for example), and it might make things unnecessarily awkward for players who might find it hard to predict whether their setting for automatic overhauling of a vehicle would be carried out because it would be hard to predict whether the overhaul would fall before or after the obsolescence point.

In fact the older something is the easier it is to maintain. Learning and using older and basic practices is easy - even by amateurs 

It is when you get to the mid 1950's, when things start to change - a lot of experimental cutting edge features were around. Which are hard to replicate today.

To give an example - you can still see 'WW2' planes (i.e. Spitfires etc.) flying at airshows etc.  Basic techno. that can easily be replicated today to produce new parts.

But recently the last 1950+'s bomber - Vulcan (there was one still flying) was grounded. It needed an Airworthiness certificate every year.

The reason being at the time it was new cutting edge technology.  Which is now obsolete. The companies that made the components for the plane,  no longer have members of staff who can make them.  The last few, retired recently. To existing staff - it is a mystery (60 year old  technology).

[jamespetts]

This is somewhat economically complex: the older equipment (generally, things that needed little or no precision engineering) can readily be built and maintained by people with more modest skills and requiring only basic equipment, but is generally more labour intensive. More modern equipment tends during its economic lifetime to be less labour intensive, but requires specialist skills and equipment that may be lost over time. Does anyone have any idea where one can find real life data by which such chronological obsolescence based increases in overhaul costs can be calibrated with a reasonable degree of accuracy?

On the subject of aircraft, incidentally, I am reminded that a furhter refinement of overhauls for aircraft in particular was recently discussed: the interval between overhauls for aircraft should be based, not just on the distance flown, but on the number of takeoffs (either as well as or instead of the total distance flown), as, in reality, aircraft fuselages experience a great deal of stress on pressurising/depressurising (although I wonder whether that should therefore apply only to pressurised aircraft and not the older, unpressurised type, which would, of course, require a further parameter in the .dat files).

[AndrewTraviss]

This is somewhat economically complex: the older equipment (generally, things that needed little or no precision engineering) can readily be built and maintained by people with more modest skills and requiring only basic equipment, but is generally more labour intensive. More modern equipment tends during its economic lifetime to be less labour intensive, but requires specialist skills and equipment that may be lost over time. Does anyone have any idea where one can find real life data by which such chronological obsolescence based increases in overhaul costs can be calibrated with a reasonable degree of accuracy?

Ok, but this is a problem that falls to pakset authors, correcft? The system can already reflect this dynamic by allowing the maximum overhaul cost to be defined per vehicle.

On the subject of aircraft, incidentally, I am reminded that a furhter refinement of overhauls for aircraft in particular was recently discussed: the interval between overhauls for aircraft should be based, not just on the distance flown, but on the number of takeoffs (either as well as or instead of the total distance flown), as, in reality, aircraft fuselages experience a great deal of stress on pressurising/depressurising (although I wonder whether that should therefore apply only to pressurised aircraft and not the older, unpressurised type, which would, of course, require a further parameter in the .dat files).

We could add one more parameter for "wear km per takeoff" that only aircraft use.

Speaking of special cases per vehicle type; horses should probably be exempt from the entire maintenance system, although their trailers would not be.

[jamespetts]

Ok, but this is a problem that falls to pakset authors, correcft? The system can already reflect this dynamic by allowing the maximum overhaul cost to be defined per vehicle.

This is correct to an extent - but I do not want to have implemented in the code a system for which I am unable to find data then to implement in the pakset, making it impossible to calibrate. The idea is for code and pakset development to be undertaken with one another in mind so as to produce a well balanced complete product. Edit: On the other hand, if the system were to allow, as you suggest, a range of overhaul costs, pakset authors could simply choose to what extent to use that system, I suppose.

We could add one more parameter for "wear km per takeoff" that only aircraft use.

That is one way of doing it. I wonder how to calibrate this again; from what I understand, the data that one can find comprise the number of takeoff/landing cycles that an aircraft may endure before needing an overhaul.

Speaking of special cases per vehicle type; horses should probably be exempt from the entire maintenance system, although their trailers would not be.

Horses do need to rest: one can perhaps conceptualise sleep as maintenance, and one can conceptualise selling a dead horse for knackering and purchasing a new one as an overhaul (and price an overhaul at the same cost as a new horse, minus a small amount for the value of its carcass).

[AndrewTraviss]

I believe real world overhaul costs will not translate directly into Simutrans very well, as the economics of maintenance in the simulation are quite different from the real world for two main reasons:

1. No vehicle ever falls so far into disrepair that it cannot continue to operate, even if it is never overhauled.
2. There are no safety or reliability concerns with skipping regular maintenance, you are only balancing running cost vs overhaul cost in deciding whether it's worth doing.

I suspect that real world overhaul costs/frequency would end up being much higher than the economics of the simulation will bear if you do get the data together; this may be something that needs to be balanced manually.

[jamespetts]

One of the principal aims of the various changes being made to Experimental currently (and of the design of Experimental overall) is to be able to use real world data for calibration and balancing purposes. A synthetic balancing system would be fantastically difficult to calibrate so as to cause players to behave maximally realistically because of the unimaginably enormous number of possible variations, each of which would have to be tested, which number of variations increases exponentially with the number of variables.

As to the two reasons given:

(1) it is important that players are not able to avoid all maintenance for ever; however, would an overhaul, as such, rather than more frequent, longer and more costly repairs ever be strictly necessary to keep any vehicle running?; and

(2) we do not simulate safety, but we can approximately simulate (un)reliability simply by reducing availability.

[AndrewTraviss]

One of the principal aims of the various changes being made to Experimental currently (and of the design of Experimental overall) is to be able to use real world data for calibration and balancing purposes.

Yes, I understand this goal and it is a very reasonable approach to minimize balancing work. However, we have multiple historical data points to work with and we should think carefully about which to use and which to discard. If our goal is to replicate the historical frequency of overhauls. We should use that figure to determine the overhaul cost, rather than using historical costs directly, as the historical costs are not likely to produce historical behaviour in this simulation, even with some of the modifications you suggested.

I don't think it would be very difficult to calculate reasonable values given running costs, availability % and expected overhaul frequency. All that's necessary for players to exhibit the historical behaviour is for that to be the most cost-efficient way to play by a sufficient margin that it's worth the extra effort to think about. If you already have overhaul/increasing running cost data for vehicles in the expanded British pakset, I can put a sample together. Or if you can point me towards the types of sources you typically use for this data I can find it myself.

[jamespetts]

Hmm - a synthetic back-calculation of overhaul costs based on frequency of overhauls? That might conceivably work: it might need some careful thought, however.

As to the sources of information as to the costs of things, they come from a variety of sources. It has been my practice to put all information that I can find in this thread.

The increase of a vehicle overhaul cost after it becomes obsolete in the way that you suggest might work, on reflection, although careful thought would need to be given to pakset balancing of obsolescence. That mechanic has been neglected for years in the pakset, so much may need recalibrating. As you will note from the coding projects thread, I am planning to add inflation of various kinds. This will include inflation of labour costs that makes overhauling simply built but labour intensive vehciles more expensive in modern times than in later times. This would leave only modern (post 1950 or so) vehicles needing an obsolescence increase in their overhaul costs. However, I wonder whether this is even necessary: many vehicles are maintained for decades after they have stopped being produced (think of the 707s flying in Iran until a few years ago, for example), and whether spare parts are produced for them tends to depend on whether they are continued in service. There may be only a very limited amount to simulate with any remaining obsolescence mechanism. However, if, in spite of that, you think it worth coding, and it can be omitted or limited in practice by pakset choices, then, since you are planning on coding it, I shan't seek to dissuade you any further from doing so. It may be relatively simple to code that part.

[AndrewTraviss]

Ok,you make a good point, there. I will remove the current obsolescence multiplier for running costs and leave obsolescence handling out entirely for the time being. It is probably best to see how the new maintenance system performs without it before considering a design, anyway.

[jamespetts]

Ok,you make a good point, there. I will remove the current obsolescence multiplier for running costs and leave obsolescence handling out entirely for the time being. It is probably best to see how the new maintenance system performs without it before considering a design, anyway.

That seems sensible. We should try to be parsimonious with these things: all the features that make enough of a difference to matter, and none that do not. (Of course, there is plenty of scope for debate about what is enough of a difference to matter, but that is another thing).

In any event, once again, thank you very much for your contribution, which is much appreciated.

[AndrewTraviss]

That seems sensible. We should try to be parsimonious with these things: all the features that make enough of a difference to matter, and none that do not. (Of course, there is plenty of scope for debate about what is enough of a difference to matter, but that is another thing).

In any event, once again, thank you very much for your contribution, which is much appreciated.

You're welcome! I'm planning out the implementation details for the first step now. I'll make a post in the development boards once I'm ready to get started. I'll open a fresh discussion about depot visit behaviour once the progressive maintenance cost itself is implemented on my fork.

[jamespetts]

Splendid!