There have been some questions about automatic and hidden signals, what it means and how they work in CTC.
Let me start there by referring to Train Dispatcher (TDP) on how it is handled there, since CTC is somehow modeled after TDP.
A regular block there (not a connector-only or dummy block) needs to have something at either end. If it is not an entrance/exit, you’re going to have some other track element, e.g. another block, a switch or a diamond. You can also place a signal there which would act as an exit signal out of the block. You don’t have to. It is your choice, but if you don’t, TDP puts a hidden, automatic signal there anyway. At the end of the day, you will have an exit signal at either block end, either a regular, visible or a hidden, automatic one, unless it exits the territory or the block is connector-only.
Note: It is not relevant for this discussion that the Track Builder (TB) 3.x forces you to place a regular signal between an entrance and the first switch. This wasn’t enforced in TB2.x – you could have all signals hidden between entrance and the first switch – in TB3.x one of them needs to be visible.
As far as we can tell, the hidden/automatic signal feature is a function in TDP. There is no evidence of them in the track definition file. TB apparently doesn’t know anything about it, and you cannot list or search for them. The main purpose is, of course, the capability to divide a long stretch of track into smaller blocks with automatic signals between them, and you can send trains into that stretch when trains are still on other blocks on that stretch. TDP makes sure all of them head into the same direction. The automatic signals cannot be controlled by any means except by the train movements. In fact, you control the traffic direction up to the next regular signal.
In CTC we have a different concept. First of all, we handle all signals the same way, hidden or not. The only difference is that regular signals (signal type S) are visible on the territory diagram, while hidden signals (signal type H) just don’t show up. Furthermore, there is an automatic attribute defined for signals. It is set to “true” for hidden signals and cannot be changed, and configurable for regular signals. That means, regular signals can be made automatic as well. When running trains, CTC looks at the signal attribute among other things, but not for the signal type. In other words, signals of type S are just for show – and of course you can click on them on the main screen to invoke certain functionalities.
When we adapt TD2/TD3 territories for CTC, we create actual real signal objects for each assumed hidden signal. So for any non-connector block we have a signal at either end, type S or H, unless the block leads to an exit.
Now, the automatic signalling in CTC is really what we call an automatic route extension. In a nutshell it works by checking if an automatic signal can be cleared for the path aligned ahead. There is a difference here with TDP if the path ahead leads across some switches.In TDP all switches have to be aligned to a valid path if you set a route from a signal to the next (or exit) including sections passing a hidden signal, otherwise it will complain about an “open switch”. And you cannot throw switches if they are protected by automatic signals if you have a route active approaching that signal laid in. In CTC you can throw those switches directly any time, as long as the signal protecting it is red. It doesn’t matter whether the signal is regular or hidden.
In CTC, routes that have been set via the automatic route extension can be cancelled like any other route. The cancellation logic makes sure that the route is not again re-established via automatic route extension by removing the scanner that looks for the automatic signal. In TDP you cannot cancel that way. The only way there is to stop the train and command it to revers (this by the way would not cancel in CTC).
On the other hand, CTC does not have “fleeting signals” like TDP has. The reason is that fleeting signals are in support of how routing is done in TDP, e.g. setting the switches and then activate the signal. Fleeting clears the signal automatically if the path ahead is clear (and you cannot throw switches ahead if a fleeting signal is not cleared yet). The philosophy here is that signals control the routes. In CTC routes control the signals, so fleeting signal doesn’t make much sense here. However, you can think of regular automatic signals as fleeting signals – it is in fact very similar, but in CTC you have the flexibility to change the route if the signal is indicating “stop”. Also, if there is no train approaching the signal and you don’t have any route laid in towards that signal, a route past the automatic signal is not set (of course you can lay it in yourself).
Just for completeness: there are a few more things that are unique to CTC:
In CTC it is possible for regular blocks not to have exit signals at all. You can have blocks with exit signals only on one side – this way you can design tracks where the block signals are spaced farther apart for on direction than the other.
Signal objects provide also other functionality, e.g. they may represent distant-only signals (repeaters) and triggers. They may not have traditional signal functionality at all.
The feature proceed-after-stop is tied to automatic signals but the routes being extended to cannot have switches, crossings or draw bridges in their path. You can set this feature to apply to invisible only, all automatic signals, or not at all.
All of the above applies to train signal types. As you may know, we have also signal types of switching-only or both. These are signal types unknown to TDP. Automatic signalling does not apply to switching signals, even if they are hidden, The automatic route extension is designed to work only for regular routes, not to switching routes. This is also true for proceed-after-stop.
