Deleting one train staff cabinet does not remove staff.

[DrSuperGood]

When a one train staff cabinet is deleted, say because it was replaced with other signalling, then one would expect the staff to also be deleted if a train is currently in possession of it. The train must then resort to drive by sight until passing the next signal.

Currently any trains in possession of the staff will remain in possession of the staff after the cabinet is deleted, reserving blocks as required in a buggy/nonsense way. After passing a few other reserve behaviour signals and with a bit of manual block cancelling one can fix this. However it still is a bug as one should not need to as deleting the cabinet should implicitly cause the train to revert to drive by sight, at least after passing where the cabinet used to be located.

[jamespetts]

There is no direct representation of the staff in the game. The signalling works as follows: when a train passes a one train staff cabinet it (1) switches its internal status to one train staff working; and (2) reserves the whole track on the train's intended route from that point back to the same or an immediately neighbouring one train staff cabinet on the train's route. The train will then remain in one train staff mode (in which it will not unreserve any tiles) until it actually reaches the correct end one train staff cabinet, at which point it will (1) switch back to the drive by sight working method; and (2) unreserve all of the tiles that it reserved when entering the one train staff section.

Thus, there are no data held in one train staff cabinets that keep a track of which train has passed the cabinet and is imagined to have the staff waiting to return to the other cabinet. The only way of achieving what you suggest would be, on deleting the cabinet, iterate through every train in the whole map to see whether (1) it is in the one train staff working method; and (2) its previous signal position is, or is an immediate neighbour of, the one train staff cabinet being deleted, and, if it is, (1) revert to drive by sight working; and (2) unreserve all tiles reserved by the train. This would be likely to be excessively computationally intensive on a large map.

Also, it does not make much sense: how would the train drivers know that the one train staff cabinet many kilometres up the line had been deleted so as suddenly to start driving by sight instead of relying on having the staff? It makes sense to have to wait until a train has left the one train staff protected section before deleting the cabinet.

[DrSuperGood]

Also, it does not make much sense: how would the train drivers know that the one train staff cabinet many kilometres up the line had been deleted so as suddenly to start driving by sight instead of relying on having the staff? It makes sense to have to wait until a train has left the one train staff protected section before deleting the cabinet.

It does make sense because when they pass it they would notice it is gone and revert to drive by sight. Currently when they pass it they go all buggy until another block signal.

[jamespetts]

It does make sense because when they pass it they would notice it is gone and revert to drive by sight. Currently when they pass it they go all buggy until another block signal.

The trains do not store (or calculate) the location of the drive by sight cabinet that they are expecting to reach: as explained above, they only trigger the leaving one train staff routine when they actually pass a one train staff cabinet.

Also, as already explained above, the only way that I can think of doing this would be excessively computationally intensive (and pre-calculating and then storing the location of the one train staff cabinet just for the purposes of deletion handling even more so) - unless you can think of a more efficient way of implementing this suggested feature?

[ACarlotti]

and (2) reserves the whole track on the train's intended route from that point back to the same or an immediately neighbouring one train staff cabinet on the train's route.
...
and (2) unreserve all of the tiles that it reserved when entering the one train staff section.

This description suggests that it shouldn't be any more computationally intensive to store the end point of the reservation. But I suspect that the above description is misleading when trains reach a stop (and perhaps their entire schedule) in the one train staff section.

I think in practice it shouldn't be necessary to empty a one train staff section in order to upgrade the signalling in Simutrans. In real life, this is something that would be done overnight or during quiet period of a few days, and replacement busses would be offered. The time taken for the train to do a round trip would be very small compared to the time taken to resignal, so even if the train couldn't remain in the branch during the works, there would be little cost to having to take it elsewhere.

In Simutrans, things are quite different. For a start, there's no concept of 'overnight' or a quieter period, and replacement busses are unfeasible. But this is largely irrelevant, given that signalling upgrades can be instantaneous. More troubling is that the length of time it takes for a train to complete a round trip can be quite long in real time hours (an extreme example would be an infrequent freight train that only runs every couple of months). And temporarily removing the train from the branch could have a much longer-term effect than just the duration of the resignalling if this is done in a way that impacts the routing algorithm.