Edit: Title change to reflect expanded discussion of shunting/orders.
No pakset, so far as I am aware, currently uses the vehicle fixed costs parameter. It has long been planned, and is still planned, to add this to Pak128.Britain-Ex as part of a general cost balancing exercise when that becomes practical. The fixed costs are an important addition to variable per kilometre costs, in that they represent the cost of labour associated with the running and some distance/use-intensity independent maintenance tasks (cleaning out a steam locomotive, for example, the frequency of which depends on time in steam rather than distance travelled).
However, two problems have recently occurred to me in relation to this: one rather niche, one of more general application. The niche problem is what to do about railway guards: I had initially thought to have a higher fixed cost in all full brake or rear brake vehicles to represent the presence of a guard, but then realised that players might want to have more than one full brake vehicle in a train, and yet in continuously braked trains, there would not need to be (or actually be) more than one guard in a train. The full brake vehicle would be the same nonetheless. One could in theory have a different front and rear full brake using the same graphics and which can be "upgraded" to the other for free, but this seems to be rather a clunky solution. Any other ideas as to how to deal with this would be appreciated. (For passenger brakes, there is already a front/rear distinction for most types, so this does not really matter so much).
The more significant issue is this: it might be necessary for goods or mail traffic in particular to run very low frequency trains. The famous
Night Mail, for example, ran once in each direction every night. There would be many occasions on which a mail specific train (as opposed to a passenger train with some mail carriages in it) would run only once or twice a day in each direction, as mail traffic did not demand any different. The
changes that I have recently made to mail generation and related matters make it far more likely that there will be incentive to replicate this sort of service pattern in Simutrans-Experimental.
The difficulty is this: a twice a day (as in, twice every 24 hours, or once every other game month at 22 bits per month and 125m/tile, which will be the settings of the next release of Pak128.Britain-Ex) train will spend most of its time doing nothing. This can be accommodated using sidings and scheduling, but players will still have to pay the full fixed cost: in other words, pay as if they are standing for four or five hours at a stretch with a fully paid driver, fireman (if applicable) and guard twiddling their thumbs and/or drinking tea. In reality, of course, the crew would only be rostered when they were needed. The locomotive (but not the carriages) would additionally probably be used for other activities during the day. The inability to simulate either of these things will cause significant economic distortions once fixed costs are introduced.
Two possible solutions present themselves. The first - the simpler - is to define some new concept of a layover, in which state fixed costs do not accumulate, or accumulate at a fixed fraction of their normal wait. Precisely how this might be done is not yet clear to me - perhaps any scheduled stop of over a particular duration could be considered a layover, with full fixed costs paid only up to that limit and not beyond.
The second, which would require some very significant programming work, and thus be unlikely to be done for a very long time, would be to permit dynamic reassembly of convoys, perhaps loosely following Cities in Motion 2's practice of having vehicles regularly visiting depots and only leaving them when some or other schedule demands that some vehicle leave the depot. The system would have to be more sophisticated than that in CIM2, however, and in particular, allow more control over which convoys are assigned to which lines. Another, possibly simpler, possibility would be to allow dynamic reassembly of convoys without depot visits, which would also allow dividing and combining of trains, locomotive changes and the like, which would have other uses. This way, a locomotive could run a mix of passenger and mail trains (although this would be less useful than in reality, as we do not have peaks and troughs of passenger demand throughout the day in Simutrans, so the demand for motive power for passenger trains would remain unchanged). The latter idea could be combined with the layover idea (which might be necessary for guard's vehicles - empty rakes of carriages do not need guards sitting in them waiting for them next to be used). However, the greatest problem with this is how to conceptualise where unused vehicles are being stored and where trains have to be to couple/uncouple vehicles from any given storage point. We can easily gloss over the actual shunting, but this more general problem remains. (Conceivably, I suppose, we could store them at a station, supposing some unseen siding - but should there be a limit to the number stored? How would the GUI for this work? How would this interact with vehicles in the depot? What if a player wanted to sell vehicles currently stored in a station, or send them to a depot, or assign them to a different convoy or in a different station?).
Any thoughts on the above issues and proposed answers (and issues in the proposed answers, and proposed answers to the issues arising out of the answers to the issues- etc.) would be most welcome.
Edit
Somefresh ideas have occurred to me as to how best to deal with the "shunting" aspect of things - that is, changing the assembly of convoys dynamically. The idea is based on orders in schedules. In addition to stops in a schedule, it ought to be possible to add orders. An order would be defined as an entry with a location of koord::invalid (this part will make sense to those who know the code). There would be three types of order: (1) lay-over; (2) add vehicles; and (3) detach vehicles.
Lay over
An order for lay over would place a convoy into a state of lay over immediately after its previous stop, without moving from the position that it occupied at that stop. A state of lay over would be a dormant state: the convoy would not move, load or unload, nor accumulate fixed costs. (In fact, fixed costs are deducted as a lump sum monthly, so what would have to happen is that a record of the proportion of any given month spent laid over or in the depot would have to be kept, and the fixed costs reduced accordingly at the end of the month).
Lay over would be a state that it would take time to enter and leave (which time ought to be set in simuconf.tab). There ought to be an option for a lay over to be timed or indefinite. In a timed lay over is one where the convoy would remain in its laid over state for a fixed time or until a scheduling interval, and then exit that state (perhaps beginning to exit the state sufficient time in advance taking account of the time taken to come out of lay over for it to start moving towards its next schedule item at the appointed time). It ought to be possible to assign the vehicle to a new line on exiting a lay over, and then specify which entry in that line's schedule that it should execute first.
It also ought to be possible to specify whether a convoy in a laid over state makes its vehicles available to other convoys, for the purpose of them adding vehicles, as outlined below.
Lay over ought only to be possible at stations (not waypoints). All passengers/mail/goods ought to have to disembark/be unloaded before the convoy enters lay over, and passengers/mail/goods ought not to be able to route past a lay over. Players would of course be able to schedule lay-overs in sidings which are part of stations.
Add vehicles
The add vehicles order ought to allow a convoy to add vehicles according to rules specified in the schedule entry to the convoy. The vehicles to be added must be in laid over convoys that allow their vehicles to be taken by other convoys at the same station as the convoy at the time when the add vehicles order is to be executed. The addition of vehicles would be simplified: there would be no actual shunting: the vehicles would simply be removed from the origin convoy and added to the destination convoy. There should be a particular time that adding vehicles ought to take, which ought to be able to be set in simuconf.tab. Multiple add vehicles order ought to be able to be stacked consecutively: when this is done, the time for adding vehicles ought to be counted only once.
Each add vehicles order ought to allow the player to specify whether the vehicle(s) are to be added to the front or the back, the minimum and maximum number of vehicles matching the rules to be added, and criteria for what sorts of vehicles can be added (for example: whether powered or unpowered, what traction types are permissible (steam, diesel, electric, etc.), a maximum axle load, a maximum weight, a minimum and maximum power, whether the vehicle needs to carry a particular type of load, the minimum and maximum capacity, a minimum comfort, a minimum and maximum catering level, whether the vehicle can be at the front or rear of a convoy, whether it has a rear driving cab, etc.). The schedule ought not to move beyond the add vehicles command if the minimum number of vehicles specified in the add vehicles order are not available at the station: the convoy ought to wait until such vehicles are available. Further, it ought automatically to prevent combinations of vehicles which are not permissible. If a number greater than the minimum number of vehicles for the order is available, then the greatest number of vehicles available ought to be added up to the maximum. The convoy ought not to wait for there to be enough vehicles for the maximum number specified.
The laid over convoy from which the vehicles are taken might be rendered in an undriveable state (for example, by the removal of a locomotive). This will not be a problem provided that the remaining vehicles are used for something else (in which case, the empty convoy will be deleted), or vehicles are added to the convoy by an add vehicle order immediately after a timed lay over order.
Detach vehicles
The detach vehicles command ought to allow a convoy to detach some of its vehicles and leave them at the station. As with the add vehicles command, this ought to take a certain amount of time and only be possible at stations. The detached vehicles ought remain where they were left by the convoy. It ought to be possible to specify which vehicles are detached by specifying a certain number from the front or the back of the convoy. If vehicles are detached from the front, then those vehicles ought to have to be moved (or move on their own accord, as discussed below) before the convoy left at the rear is able to move - the convoy ought to check whether all tiles to the next signal are clear of vehicles before moving if the last order is a detach vehicles order or the convoy is a newly formed one from detached vehicles (see below).
Detached vehicles ought to form a new convoy generated at the time of detachment. There ought to be two options as to what to do with this convoy: either have it immediately laid over indefinitely (the suitable option for loose vehicles), or have it assigned to a line straight away, and, in the latter case, to determine which schedule entry in the line from which it is to start. The latter will only be possible if the remaining vehicles can form a driveable convoy as in a detached multiple unit section, or the first entry in the line is an add vehicles command such that it will get into a driveable state by the use of that command. If the convoy is assigned to a line but is not driveable, an error message ought to be given.
General
This system ought to allow for considerable flexibility of operations (mainly with rail based vehicles), such as dividing and combining trains, changing locomotives, a pick-up goods service, banking, or even, if used in a sophisticated way, a completely dynamic allocation of stock to a whole set of lines. It would take some time to program, but could conceivably be implemented alongside long planned changes to the replacer so as to prevent the need for convoys to go to a depot to need to be replaced: the current plan is to allow convoys to be replaced at any time, but it might well be worthwhile allowing such replacement only at a lay over. Indeed, further thought about the interaction between this system and replacements generally might need to be considered - is the current concept of replacement necessary at all if we have this system of dynamic changes of vehicles in convoys?
Any thoughts on this proposed system and its interaction with other aspects of the game would be very much appreciated.