-
Contents
- Overview
JGR's patchpack contains some very powerful additional functions which can be used to create realistic timetables. That does not just simplify managing vehicles on a single line, but also allows coordinating timetables across multiple lines to optimize for fast train changes. When following through with that concept (which admittedly then turns into a lot of fiddly work), one can even create an integrated schedule.
Overview
In order to understand what is going on here and what we're trying to achieve, we need to to talk about terminology:
A clock-facing (or cyclic) schedule means that a vehicle on a line always runs at a fixed interval for a given station. For example trains might leave a station at minute 42 in every hour, and not like one at 4:37, the next at 5:48, the third at 6:43 and so on. Same minute in every hour. Or maybe every 30 Minutes and then always 3 minutes past (so at x:03 and x:33). Or every x minutes, with x being a number that divides 60 minutes (e.g. every 30, 20, 10, 5 minutes). In some weird cases you might also run across timetables where a vehicle runs every 4 hours or every 45 minutes. In any case, the time interval between vehicles is fixed and chosen in a way that it is easy to remember for users (i.e. passengers) - unless we talk inner-city travel like metro systems, where you just go to the station and take the next train, because they're running every five minutes anyway.
Integrated schedule
A clock-face schedule only covers individual lines. That is all nice and well, but most of the time passengers will need to switch lines to get to their destination. And then it's paramount to have good connections and not having to wait a long time because the schedules of the lines have not been coordinated. I've often been in that situation where I could wave my "connecting" train goodbye when I was entering the station in another train, just because it left three minutes before the other train arrived. And that was the actual timetable, not a result of delay (which happens way too often where I live, but that's a different problem).
The goal of having an integrated schedule is the optimal coordination of the different schedules of as many lines as possible, so that changing lines is simple and reliable, without forcing passengers to stand around somewhere in the wilderness on a platform without shelter from bad weather. One of the most well-known examples for such an approach is the integrated schedule done in Switzerland, where basically everything runs on a coordinated schedule: not just trains and trams, but just about any kind of public transports, including excursion steamships and cable cars. One can easily change lines and modes of transportation at just about every station with really short transfer times, without it turning into a stressful situation (Germans on vacation will already get a pulse from reading "three minutes to change trains", but typically it's just getting out of the train, crossing the platform and entering the train waiting on the other side, so at most 30m to walk, which is no problem even with bigger luggage). In Germany it's often much more of a problem even with a transfer time of 10 minutes, as you might have to get from one end of the station to the other end. And don't get me started on the issue that the whole concept will only work if trains are on time...
Admittedly, Switzerland has been improving their integrated schedule since 1982 when it was introduced. Since then, they concentrated on improving the schedules by making things more stable or by adding new possibilities for switching lines, not so much by making a connection between two places faster. One can read about that approach in the article Rail 2000 on Wikipedia. Germany is at least planning that kind of approach, although it has been postponed many times and is always threatened by lobby groups advocating for cars (a very important industry in Germany after all). The main difference of the approach in Switzerland (or the planned "Deutschlandtakt") is the way of planning the schedules: Instead of looking at the infrastructure and then developing a fitting schedule, it's the other way around: A schedule is defined and then it's being checked what improvements need to be done in the network to be able to run the schedule.
That was now quite a bit of theory, whether one implements it that way in the game is up to the player. At least all the necessary functions are provided in JGR's patchpack to actually develop such an integrated schedule for all lines.
The most important patch to use here is "scheduled dispatch". That patch allows for an easy creation of clock-face schedules for a line. It can be used to e.g. model trains leaving a station exactly every 60 minutes, at the same minute every hour. Or in whatever other interval you want them to.
Another helpful patch is the clock-display, as vanilla OpenTTD can only show days or seconds or ticks (which are a couple of milliseconds). A human player may want to have a schedule based on hours and minutes, so that you can really have an hourly operation on a line, and not something like every two days or every 420 seconds or some such. As one can also configure the actual speed (i.e. how long does an in-game day take and how fast is an in-game second) one can adapt the game to personal preferences.
The clock display can be activated in the game settings and is then shown on the bottom left next to the date display. The clock runs independently from the date, so an hour of that clock may take several in-game days. That may sound confusing, but just enable the setting, sit back for a while and watch how both clock and date behave. The clock display is only meant for managing timetables and has no other influence on game progress whatsoever.
The example is based on an x-shaped network with five stations. In the middle of the X there is a hub station, the other four stations are at the outer spokes of the X. On this little network one could run four lines (one per spoke), or two lines (for example from bottom-left to center to top-left and back again) - or some other setup, it does not actually matter. I chose to run two lines, which run on the left and right part of the X. In any case, the important part is that the trains should be scheduled in such a way that they meet in the hub station, wait there for a bit to allow passenger transfers and then all leave at the same time.
That already defines an important requirement for the network: The hub station has to have at least four platforms, as trains from all four directions are to meet there at the same time. The lines themselves are single-tracked, as are the terminal stations at each end of the X, as only one train should run there at a time. One could imagine the network like an old-style billboard: At first, the center is lighting up (when all trains meet there), then the light moves along to the outside and back into the middle, as the trains are moving. The lines themselves do not need to be equally long, neither in terms of number of tiles traveled nor in terms of travel time. The trains just need to be able to complete their tours in the time frame dictated by the schedule frequency so that everything runs on time.
Preparation: Define the lines and have trains running
In this step there is no scheduling in any way, it is just about setting up two trains for the two lines. This is standard OpenTTD-gameplay, just configure the order list. In this example we'll have one train running Station A to Station D and back, the other one Station B to Station C and back. Of course they all stop at the hub station. The order list therefore very unsurprisingly looks something like this:
The other train has similar orders, it just has exchanged "Station B" with "Station A" and "Station C" with "Station D".
The timetable button on the top right of the order window may now show an exclamation mark, so lets take a look:
The auto separation feature of JGR's patch pack has an issue: We do not have any timetabled times, so auto separation will not work. Since we do not need auto separation we can simply turn it off by clicking the "Auto Separation" button. That also nicely resolves the exlamation mark. In cases where we want to have auto separation you need to ensure that all entries of a timetable are properly timed (so all travel times between stations need to be there, as well as the waiting times at the stations).
Step 1: measure travel times
The first thing to figure out is the total travel time of a train on a line. That is exactly the same thing as with vanilla OpenTTD, just get the timetable filled out by the game.
The easiest way to do this is to press "Autofill" and start the train. It will then run according to the order list and the timetable will be filled. Once all times have been collected, "Autofill" will turn itself off. Note that the autofilling will start with the first order, if your trains are already running and are in the middle of the order list, they will first run to the end of the order list as usual and only start collecting timetable data once they reach the first order list entry.
In this case there are two lines, we need to get the travel times for both of them. The results show that the trains need about 40 to 50 minutes for their line. That is almost perfect for a clock-face schedule, with a bit of waiting time and some slack one can easily get to a 60 minute interval including a good buffer for potential delays.
The travel time should always be a bit below that schedule interval. For an hourly schedule the travel time should be at about 50-55 minutes, for half-hourly schedules it would be something around 25 minutes and so on. With a travel time of say 57 minutes and a planned interval of 30 minutes that would mean that two trains are needed to run the planned schedule, which will then meet somewhere along the line. A travel time of about 65 minutes however would be really bad, as it kills an hourly schedule for a single train, whereas using two trains would introduce lots of breaks where the train would just stand around and wait for the next departure. This should be solved by improving the travel times - faster vehicles might be an option, or an improved track layout with less curves if possible.
Step 2: Set up the scheduled departures
Scheduled dispatch is set up via a button in the timetable window. This opens up a new window where all the intervals and times can be configured. These are then assigned to an entry in the timetable, so that we can configure departures at the hub station.
Initially, the schedule is empty of course. In order to set up the first schedule we first need to enable the whole feature by clicking the "Enable" button.
This changes the content of the menu slightly, as shown. The exclamation mark will be dealt with later, first we need to actually set departure slots. A departure slot is simply the time(s) when a train should depart the station. In our example we want to have the trains departure every hour, the easiest way to do so is to set up departures at the full hour (but every other time would work equally well, the important part is that it is the same minute every hour).
Adding departure slots is done by clicking "Add Slot". Since it would be very cumbersome to enter departure times for each hour of the day by hand (not to mention all the possible departure times if you want to run a service every 10 minutes...) it is advisable to hold "Ctrl" while clicking "Add Slot". That will then allow setting a whole series of departure times.
Setting the departure times is done in hours and minutes. The first entry is repeated based on the given interval until the end time is reached. In this example we set a departure at 0:00 (midnight), which is then repeated every 1:00h until we have reached 23:59h (at which point time will roll around to 0:00, which is the first entry). So this will give us 24 departure entries, one per hour of the day.
One can configure a plan for 24 hours, which is then repeated, or one that is only relevant from 6 to 9 (morning commute) or in whichever ways it is needed. For the sake of simplicity the schedule here will be active for 24 hours and is simply repeated every day.
With that in place, the scheduled dispatch window now contains 24 departure times.
In case we want to change departure times, "Adjust Slots" is our friend. It will change ALL departure slot times! There is no way to change a single slot time, as that would totally defeat the purpose the clock-face schedule. If you really need to change a single entry, you'll have to remove it and add it again with a different time.
One very important detail of the scheduled dispatch is the delay setting. A train that runs late, will normally try to get back on time by reducing waiting times at stations. This is different with scheduled dispatch! A train will only try to catch up if the delay is below the threshold configured here. If it is delayed by a bigger margin, it will keep on waiting at the station and then use the next departure time. For example, if a train may have a delay of 10 minutes and is eight minutes late, it will try to catch up and leave early. If it has 11 minutes delay, it will wait at the station for 49 minutes and only leave in the next timetabled departure slot. That can of course result in further problems, as it blocks the platform which might be needed by other trains. Also, the next train on the line can now not run at the scheduled time, because the previous one is now running in that slot. One has to really think about what kind of delay setting makes sense or how long the trains should possibly wait. It is also very advisable to make the stations larger to have enough free platforms. One could also come up with really complicated orders including jumps, so that a delayed train might just unload and then head for a siding in order to get back into the service at a later time.
The easiest way is to set it up in such a way that trains should wait for a really long time and still try to catch up on delays. No matter what you do, at some point in the schedule there should be a large enough buffer, preferably in a depot, so that even huge delays can be buffered, especially for long lines crossing half the map.
The last step to make the whole scheduled dispatch departures work is to assign them to the actual timetable:
Just mark the timetable entry you want to the schedule attached to and choose the correct schedule from the drop-down-menu. Right now we only have one schedule, the list menu will contain all schedules that have been configured.
Adding scheduled dispatch to the timetable will change the timetable entry to state that scheduled dispatch is enabled for that stop. This now also solved the exclamation mark stating that a schedule has not been assigned to the timetable. Congratulations, you just finished setting up your first scheduled dispatch.
For now, the train will use scheduled dispatch on the stop at the hub station when going towards station C. After repeating all the stops for the other train as well (there is no way to share scheduled dispatch setups across lines with different timetables), both will now be synchronized and depart the hub station at the same time when going south bound. Just let the game run a while and see what happens and how the entries in the schedules and timetables are updated.
As can be seen, both trains have arrived at the hub station, the next departure time slot is at 16:00, so in 13 minutes. Passengers should have enough time to change trains now. At 16:00 both trains depart the station, exactly as planned.
However, that now only works for departures in one direction, in this case the departures in the Southern direction. That does not help anyone who needs to change trains to get from south-west to north-east. These passengers have to wait for half an hour at the hub station, because changing lines in that direction has not been planned so far.
Step 3: Connections in all directions
The solution is to use two trains per line instead of only one. These run in such a way that they all meet at the hub station at the same time, allowing passengers to change from any direction to any other direction. This is done by simply cloning the departure settings for scheduled dispatch and adding them to the second stop at the hub station. Each train then goes from one end of the X to the hub station, waits for the full hour and then continues.
Cloning a scheduled dispatch schedule is done via the "Manage Schedule" on the bottom right. There you can duplicate schedules. Switching between the schedules is then possible via the "Previous" and "Next" Buttons which had been greyed out so far. After duplicating the schedule we only need to assign the new second schedule to the other stop at the hub station.
That looks quite better, but there still is an issue left: Now that there are two trains on each line, the hourly schedule is nonsense. The trains are actually meeting not just once per run on the whole line, but twice. To word it differently: Doubling the number of trains halves the scheduled interval. So instead of hourly, we now want to actually run half-hourly.
This half-hour interval is simple to set up, just hold Ctrl and click "Add departure slot", add departures every 30 minutes and the game will figure out the rest. That of course needs to be done for both lines and all stops at the hub station. The result roughly looks like this: Every full hour, four trains meet at the hub station and leave at the same time into the four directions. For each leg of the X they need 20 to 25 minutes game time, then they meet again at the hub station, and leave at the same time, this time at half past the full hour.
As can be seen, the trains meet had met at the hub station - four trains going into four directions, allowing passengers to freely change trains to wherever they need to go. The trains all leave at the same time. In the real world that would be somewhat different due to available tracks and infrastructure, the trains would most likely start one at a time, so that the first one has already cleared the tracks in front of the station when the next one departs. In this example it is easily possible to have all trains depart at exactly the same time since the lines are sufficiently independent. It will become more complicated if the trains have to go through some big junction in front of the station, or if they share a bit of the tracks before the different lines really diverge (which is often the case in real world central stations in the middle of the city where the lines are bundled together until they reach the outskirts and then branch out into the different directions).
Once that system is understood by the player, setting up such a clock-face schedule is really easy. One can also do weird things with that: On the web there are examples where people have build bus schedules simulating commuter traffic in the morning and evening, where buses run every five minutes, while during the day only a basic service every 20 minutes is run. The buses are then stopped in a depot during the day and run commuter services in the evening again. One can do that, there are also extensions available to simulate extended passenger generation in the morning and evening. I do not use such extensions in my game, I just use a fixed interval which is run the whole day, as the clock time display has no connection to the date in the game anyway.
One can use scheduled dispatch also on depot orders. Each vehicle should have such an order somewhere in the list anyway. Using scheduled dispatch one can then define that a train should only be dispatched from the depot to the neighboring station 15 minutes before the planned departure. Trains that for example have a scheduled service break of 40 minutes are then idling in the depot and do not block platforms in the station. That also helps if the travel time really does not fit the schedule interval and cannot be improved. Alternatively one can build sidings to "park" trains if they have such waiting times. One can really get creative with all these things.