The overall plan with the
lines mod is to have a timetable scheduling system which is integrated with the other advtrains functions, especially the stop rails. This is the concept for it.
This is currently a draft, and subject to discussion before I will start implementing it. Please bring in your ideas, suggestions or criticisms. Just add them under the relevant headline and sign them with your name (use the “signature” button in the editor toolbar)
A timetable is a structure consisting of multiple “timetable items”. Every timetable item belongs to a Location and an optional Track code, and identifies one stop rail that the train should stop at or pass.
The timetable item holds:
* The stop modes should get better names — orwell 2021/04/19 22:11
All arrival and departure times in the timetable are relative to the initial departure time of any given train. That means, the timetable only defines after how many minutes/seconds after its initial departure at the first location it should be where.
Every timetable has an unique name and is saved globally.
In view of the timetable recording and travel time update functions, it would be good to implement it as follows:
When a timetable is assigned to a train, the train forms a Service of the line the timetable belongs to. The train then gets an instance of the timetable.
In the timetable instance, the relative times are replaced by the actual absolute railway times by adding them to the planned initial departure of the train. The lines in the timetable instance gain additional “computed properties”:
The “ready time” is determined from the expected arrival time. For a normal stop, this is the arrival + stop time, for “wait for departure” just the arrival time. When guaranteed connections are involved, they might affect the ready time too. For pass-through items, for which the departure time is only an orientation and the train never stops, there is no “ready time”.
At arrival and departure at every place, the expected arrival/departure times for this place become known and are saved, they are then called “actual departure/arrival time”. Every arrival and departure cause the subsequent expected arr/dep times to be recalculated.
This expected/real times system forms the base for departure displays both in trains and in stations.
This could use a better name — orwell 2021/04/19 22:11
At the first station in the timetable, trains “enter” the timetable and get timetable instances. For this, the timetable defines a service interval by means of two times:
For example, interval 05;00 offset 02;00 would result in a train every 5 minutes at minutes 02,07,12,17…
— orwell 2021-05-22 13:16
We call such a possible initial departure time a slot.
When a train arrives at the timetable entry point, it picks the next slot and constructs its timetable instance from it. If the first timetable item has a minimum stop time, this is taken into account too.
It may be considered whether to add a “late departure threshold”, say the train arrives a few seconds after a slot has passed, instead of waiting for the next slot, it departs at the previous slot and carries an initial delay then.
The system must ensure that each slot for each timetable has maximum 1 train using it. Slots may however be missed, in this case a departure display could display “train cancelled”. So, advtrains must somehow keep a mapping which train is assigned to which slot.
A train can enter a timetable in one of two ways: either as follow-up to another service (another timetable), or initiated.
For such a follow-up service, the end point of the old timetable should obviously be the same as the start point of the new one.
To save players the hassle of creating timetables by hand, there should be a Timetable Recording feature. Ideally, recording timetables should be straightforward when an automatic train line using stop rails is already present. Of course, the player can always alter the timetable after it is created.
Current automatic railway lines typically use stop rails to define places for trains to stop at. The timetable system will build upon this existing functionality for recording of the timetables, For example, the ARS rules in the stop rail determine whether a train will stop at any given stop rail; this can be directly translated to the stop mode in the timetable item. The correct routing of trains is already provided by ARS.
Recording the timetable relies on having an existing, working train line set up using stop rails
The timetable recorded this way then reflects the departure and travel times of the current line setup. The player can then adapt the timetable and/or the timetable of other trains to fit together and provide connections (most adaptions will probably made in the initial departure time of other lines so that no jams occur)
Probably, at one point or another, the travel times (times between stations) in the timetables will not be accurate anymore. This can happen when a line is rerouted, when more trains are added to a railway line and trains progress slower in overall, when there was a jam during recording which has been resolved afterwards, or other cases.
To remedy this, the trains which are instances of any given timetable can be configured to constantly measure and average the travel times on their line. Using the timetable editor, players can choose to apply the measured travel times to the timetable. This action will then change the arrival times at items in the timetable.
As for altering the departure times, there is to consider:
See also the notes on the timetable items in the section above.
The timetable system by itself does not interfere with the interlocking system in any way. ARS, in conjunction with the Line and Routingcode on the train, remains the primary way to route trains through the track network.
However, in conjunction with xatc, it may be useful to make departures dependent on certain conditions in the interlocking system that need to be met. A popular problem example is the deadlock situation that occured on LinuxForks with the S31 at Trisiston station when that service was initially inaugurated:
The solution using the timetable system would be to delay the train departure at Elders Valley until the platform at Trisiston is free. So, a “can_depart” xatc hook on the timetable would check whether the platform section at Trisiston is occupied by a train, and allow departure only after that train had left. This solves the problem on a higher layer than interlocking would, and this is how it's done in real life too (except that the dispatcher has the responsibility to tell the EV train or the EV signalman that it must wait).
The timetable system user interface will provide the following features:
For Timetable viewing/editing, the user should be able to select a slot (on a per-cycle basis with cycle-relative times), to get shown the real departure/arrival times instead of pure relative times, which can be confusing if the offset is not 0.
It would be nice to have a tabbed interface for the timetable UI: this way you could open multiple editors/viewers at once and quickly switch between them to validate the edits.
… to be continued …