One of the major
tasks that lies ahead is altering the vehicle/convoy cost model to take into account the need for regular maintenance and overhauls, as well as time spent in maintenance. It is also necessary, in order to make full use of fixed costs, to allow for a convoy to be in a state of lay-over, in which it is static, with no passengers/goods on board, in which it is not incurring any fixed costs (e.g. because there is no driver in the cab, as it is awaiting its next turn of duty).
Another task that will need to be done at some point is allowing convoy re-combination: for example, allowing locomotive changes on railway trains. This is particularly important for railways, for which the ability to change locomotives in service was very important throughout most of their history (although has become much less important in recent years).
That latter task in particular is likely to be extremely complex to implement (more complex than signalling, and signalling took well over a year to complete and there are still a number of bugs even now that need to be resolved).
I had planned to undertake both of these things at the same time so that, for example, a locomotive could be separated from its carriages to be maintained/refuelled. However, given that the game is really only suitable for sandbox play until balancing occurs and that the convoy recombination task is likely to be gargantuan, I have wondered recently whether it would be sensible to split the two projects. That requires a maintenance/overhaul/availability system that will work properly without convoy recombination but that can readily be adapted to work with it.
I have devised the following system, which I will set out in outline below. I should be grateful for any considered feedback on this scheme.
All vehicles would have an availability percentage. This would denote the time that those vehicles are not spending being maintained. There would be two options (settable in simuconf.tab) as to how to handle this: (1) the simple option, more suited to sandbox play; and (2) the realistic option, more suited to economic play. In the simple option, the vehicle's capital cost would be multiplied by one divided by the availability percentage. So, for example, a vehicle with an availability of 75% would cost 25% more to purchase in the simple model. This would be intended to simulate the cost of having to buy extra vehicles of the same type to cover the period that the vehicle in question is being (notionally) maintained. The actual maintenance would not be simulated directly. This would be the default option for loading existing saved games.
The realistic option would not adjust the purchase price, but would instead mandate that every schedule have a depot of a suitable type for that convoy as an entry. A schedule without a depot would not be valid. Each depot entry in a schedule would have parameters determining (1) the frequency of the visit (i.e., how many times would the convoy pass the depot before visiting); and (2) whether the visit is for maintenance or whether the vehicle is to go to the depot for storage (the current default behaviour). Depending on the length of the route and the vehicle's availability percentage, there would be a minimum limit on the frequency of depot visits in the schedule.
Because at present a convoy entering or leaving a depot triggers a re-run of the path explorer, this would have to be altered so as only to run the path explorer when entering a depot for storage, not for maintenance. The path explorer would ignore depot visits for the purpose of calculating routes.
The maintenance time in the depot would then be based on the availability percentage and the time since the vehicle last visited a depot. For example, if the vehicle had last visited the depot exactly an hour ago and its availability percentage were 75%, the vehicle would spend 1/4 of an hour being maintained before becoming available again. This time would be based on the vehicle in the convoy with the lowest availability percentage. (It will thus be seen that convoy re-combination would allow players to make more efficient use of their resources in the case of trains).
Further, convoys should be able to enter a state of layover at any stop, as set by the schedule: but this would require discharging all of the passengers/mail/cargo at that stop, and have a minimum dwell time for putting the vehicle into a state of layover. During a layover, no fixed maintenance costs would be charged.
As vehicles accumulate distance since they were first bought, their per kilometre cost would increase based on settings in their .dat files. It would be possible to reset this increased cost by overhauling the vehicle. This would be done on a visit to the depot. There would come a point in time (defined in kilometres since purchase or last overhaul, except for aircraft, where it would be defined in number of takeoffs) where the vehicle would have to have an overhaul in order to continue running at all. This would be set in the vehicle's .dat file, as would the cost of an overhaul. By default, vehicles would be overhauled at the point in time when it is compulsory to do so, but players should be able to set a convoy (or a whole line) to overhaul early on their next depot visit. The default cost of overhaul in the absence of being specified in the .dat file would probably be something like 1/5th of the purchase cost (although I should be interested in any data).
The vehicle replacer would continue to work largely as it does now, except that the replacement would occur on the next scheduled depot visit rather than
ad hoc as at present.
Until convoy re-combination can be implemented, it will be assumed that all vehicles can refuel/replenish without visiting the depot or discharging their cargo. However, this should now take a minimum amount of time. This would be implemented as follows: when the schedule is created/amended, a set of range stops will be calculated. These are the stops on the schedule (ignoring the depot and any waypoints) where the vehicle needs to refuel/replenish. For example, suppose that a vehicle with a range of 100km had 10 scheduled stops, each 30km apart: it would have to make one range stop every 100km, so stops 4 (after 90km, the next stop being 120km) and 8 (after 180km, the next being 210km) would be range stops, where the convoy would wait longer than at other stops. It could continue to load/unload whilst replenishing, so this would just increase the minimum loading time, and might not affect at all the loading time for vehicles, such as ships and aircraft, that take a long time to load. This would not alter the convoy's state. The range stops should be marked on the schedule.
I should be grateful for people's views on these ideas, which are aimed at expediting the balancing of the game, which has been seriously delayed to date.