If you’re in the computer business, you probably know about some natural laws, for instance, there is no such thing as a last software bug – if you think you found the last possible one, there is another one around yet to be discovered.
Another rule is – and that is probably true for any business that delivers products and services – if everything is perfect and the customers love it, you do a re-design.
And we’re going to do just that. Not the whole thing, mind you, but for CTC’s routing feature.
Since CTC’s inception in 1999, we have used “dynamic routing”, which determines the best path from start to finish every time you selected start and finish. There were no pre-determined fixed routes.
But this is not how real systems operate. Especially for train routing, you have a fixed set of routes that you have to choose from. Paths that are possible but are not covered by this set cannot be used for train routing. With no eligible route the exit signal cannot be cleared, and the only way to let a train go on its way is issuing a train order.
On more advanced system the above is even true for switching as well. There are different rules for switch routing than for train routing, and switch routing is usually more flexible and less strict. On the other side they are limited to shunting moves within a station.
So we started by adding new tables for routing, one for train routing and another for switching. Of course, we wanted to keep the capability for the system to find the best route from start to finish, even if it is from one end of the layout to the other.
With the existing route search algorithm it would mean that you have to try to match a path to a set of fixed routes. This turned out to be quite time consuming. On a big territory like Copenhagen-Ringsted on an old XP machine it took several seconds to figure out the best path for a long route, if we use fixed routing.
So we asked, would it not be better to look at fixed route sections first?
There are certain advantages doing it that way: for instance the estimated time to travel a particular route section can be calculated once at system start time – with possible updates when slow orders are changed (right now calculated every time a route is laid). The status of a route section – whether it can be used right now, or the reason why not – requires more frequent updates. But even with that (and there might be still some optimization possible) Copenhagen-Ringsted is reasonable fast enough with the new method and definitely better than to adapt dynamic routing to use fixed route sections.
We don’t want to maintain code for route selection methods based on both fixed and dynamic routes, so we decided to eliminate dynamic routing. The only dynamic function is now the selection of fixed routes to create a larger route. The selected route sections then become active route sections – previously the larger route was divided into smaller active route sections created on the spot [active route sections have been around for quite some time now].
So, what happens to territories that don’t have fixed route sections. Wouldn’t that make routing impossible for them, you’d ask.
Well, you can let the trains pass red signals. Of course, we can’t be serious about that.
For all territories that don’t have fixed route sections defined in their database CTC will generate fixed route sections automatically. With this little thing you can continue to use such territories with this change. You can even continue a saved game after an CTC upgrade – at least we can’t see any reason why not.