Clearing routes into segments with a number of blocks

[tve]

It seems that the program does not fully support the proper sequence of route clearing, when there are a lot of blocks.

Normally, with a mouse, I clear a route into single line section by first selecting the starting block and then the next available block into the direction of the route (that way I don't have to whisk the cursor across the screen). Doing this will eventually clear all the blocks into the direction of movement, but this happens slowly and may take several seconds when running in 1:1 time scale. If there are a number of blocks between the two locations, it is possible to clear opposing routes.



The above two examples are not trickery. The route becomes cleared block-by-block, and there is ample time to set opposing routes. In real life, this would not be possible since the signal systems will not allow it to happen: when a route command is sent, all opposing routes become blocked before any route is allowed to clear.

Also, when two trains are following one another, the blocks ahead of the second train will not clear immediately after the first train has left them, and in this case it is possible that an opposing stored route gets cleared before the block is cleared for the second train, and two trains are heading towards one another, head-to-head. The simple fix is to specify that any route already set should always take precedence over stored routes.

So if you could rectify the situation by preventing the possibility of opposing commands into a line with a number of blocks. The simplest of ways is to clear the route immediately (in one 'swoop') up to the next visible signal.

(In TD3 it is possible to clear routes this way, too. You would select two opposing signals when setting an entrance-exit route. TD3 cleared the full available route immediately.)

[DPump]

This is the effect that stored routes take precedence over routes being extended via automatic signal - this is also the reason that it takes time to fully extend the route. I had the feeling I should do it in cases where route extensions interfere with routes I would like to run earlier, for instance on diamonds where routes are extended across diamonds and you have to wait until that train passes before you can run the train that you wanted and could have run across the diamond earlier.

I haven't encountered the effect of resulting two trains heading towards each other, as you described - maybe because I know it would happen so I didn't put a conflicting route in there to begin with.

Maybe we could extend the routes immediately if the only conflicting route would be the one coming into the destination block from the opposing end. The latest feature, stop and permissive proceed, works also only under the same condition, so that would appear a reasonable approach for a solution.

[DPump]

Just to put a note here:

In another post I talk about to add some kind of directional control on a sequence of block where there are no switches between them, with just automatic signals between them. There are some things to consider, like diamonds and drawbridges, and how to handle automatic signals that are visible - or create some attributes that would define and limit a stretch with directional control.

So there is not a definite solution with all the details yet. But we're working on it.

[DPump]

With CTC 3.21 we have now implemented a change as outlined in a previous response. it will have the effect that you cannot set a route into a stretch of blocks which are free but are subject to automatic route extension due to automatic signals which hasn't completed yet. Think of it like a reservation marker. It will stay until the last train has left the stretch. Instead of "<=>" you will see "<=<' or ">=>" in the directional information of the affected blocks.