The last couple of releases were addressing issues in schedules changes, i.e. when a train finishes a schedule at a station and takes over another schedule. This includes splits and merges. Believe it or not, there still was one error affecting trains in a block just a little bit larger than the train length, and the scheduling calls for a split. We’re not aware of such a problem in an officially released territory, but it came up during testing of one or our upcoming territories. The correction is verified and will be in 3.17.
Another thing is that we want to allow schedule changes outside the territory. There is one upcoming territory, where the dispatcher controls most of the tracks – except the tracks leading the end station for most schedules, because that station is handled by another dispatcher as part of another territory. So the trains would leave the territory to get to the end station, only just to come back for their return trip.
There are two ways to address this (similar to TDP): either create multiple entries, which means you put both trips into one schedule – which will make the stop list quite large if the train needs to stop at every station, or you let the train leave the territory which finishes the schedule, and the return trip would be just another independent schedule. This, however, is not realistic: when a train is late and has not left the territory yet, the return schedule may be activated and you get a new train coming onto the territory. Now you have two trains running when you really should have only one.
If you allow a schedule change outside the territory, this would fix this problem. The database structure permits such a setup, the checks have been modified to allow contents like this. Now we just need to setup a schedule and see how it works out.
Splits and merges would be allowed, too. There is no reason not to, but the handling is different if you deal with this within the territory or outside.
The numpad function is now complete and will be available in 3.17. The numpad function is another convenient way to setup routes by typing something like “123-456” into the numpad section of your computer keyboard.
Also in 3.17 we added the trigger function (aka buzzer function). It is not complete yet, as we have not added to play the sound yet. Furthermore, while the triggers are configurable, we haven’t added yet the saving and loading of the configuration data. We decided to keep that separate from the normal game status, since we believe it makes more sense to store it on a territory bases. That way whenever you start a new run (select date and time) you don’t need to re-configure the triggers again. We will also add (visible) automatic signals there and favored directions of entries/exits. The time factor will be added there as well, but it will be effective only in asynchronous mode.
Finally, we added a TDP-style running time if you cancel a route manually. This is done technically by extending the response time from the signal to 1 minute (visible signals will flash during the time), during which a route cannot be created that would be in conflict with the route just cancelled.