The next release will address some issues that have come up, and also improve some performance.
One thing we didn’t get right is how to deal with schedules that run through midnight. It turned out that stops scheduled after midnight were handled as if the stop should have occurred the day before. This and also the difficulty how to deal with schedules that last even longer than 24 hours has lead us to introduce the relative time schedule. In short, for each schedule you have a reference time, and any other time information is relative to that. For instance, the reference time is 8 am. A scheduled stop at 8 am on the next day would be stored as 1440 – the number of minutes after the reference time. A stop at 9 am the same day would be stored as 60, and 9 am the next day as 1500.
Schedules for commuter lines quite often are separated into several tables like one for Monday through Friday, one for Saturdays, and one for Sundays – with a note that times after midnight belong to the previous weekday.
So in our scheduling we set the reference time to 23:59 (24 hr notation) while the train actually runs after midnight. It is listed in the Saturday schedule even though it would be Sunday already.
Another thing – not scheduled yet – is the possibility to set the reference time a little bit earlier than the arrival time on an entrance. Right now train are created from schedule and “activated” at arrival time, but with that there is no easy way to have the train running at full speed when entering the territory, which is a problem if the block is short and the signal at the end shows “stop”. With a reference time a little bit earlier, the train can be made “alive” then, and we have a better handle on the train dynamics even before the train arrives on the territory.
Speaking of scheduled stops with departure time: the status line will now contain time information, if the next scheduled stop has a departure time. It will show in relative time when the departure is supposed to take place – a positive number if it is still in the future and you’re good, and a negative number if you’re already to late and you haven’t even arrived yet.
One of the features that will be used in territories to be released soon is the schedule change while the train is on the territory, including splits and merges. Some of the issues we had here will be also addressed.
A little bit further into the future we will add the buzzer function which was suggested by a customer in our forum. We have already started to make some changes: the signal function will be enhanced to include additional functionality, one of which is the notification when a train passes that point. The signal function was chosen because signals are tied to the direction a train passes, and the signal display fits nicely for the new notification indication. And you can acknowledge the notification by clicking the signal. Another additional function will be to feature distant-only signals, including repeater signals.
As you can see, there are quite a few things to come, which makes CTC different than just being another Train Dispatcher or one of it’s clones.