Unexpected behaviour with token block signalling

[Matthew]

I have run into a problem with token block signalling. It's probably a mistake on my part, but it might be a bug.

Steps to reproduce:
1. Open the saved game provided.
2. Use the Stop List to find Bexenchurch Berkingston Road Stop or Bexenchurch Football Club Tram Station.
3. Zoom in/out until you can see both stations.
4. Turn on block reservation view.
5. Fast forward.
6. Eventually you will see two of the trams enter the same block at the same time in opposite directions and get stuck (both from the Allied Transport Company's CCC North-South Line, which is the only line on this track), even though both entry points have token block signals.

I can't get this to reproduce at predictable times, but it usually happens within a few in-game hours; at most you should have to wait one game month.

I am not quite using token block in the recommended way, because the exits from this block are also token block signals. However, replacing the exit signals with absolute block signals does not change the (to me at least) unexpected behaviour. Surely the great strength of token block working is that a train should never enter the block while another train has the token? So this seems to be a different issue from the earlier discussion about how certain trains were not clearing reservations. In fact, the block reservation view shows that in this block, and only this block, the trams are reserving the track tile by tile, as though they were driving by sight, even though the Convoy Details window says that they are using Token Block, and the token block signals elsewhere on the network correctly reserve the track up until the next signal.

I realize that there is no actual token and this working method is being simulated by a mind-boggingly complex manipulation of the block reservations from Standard. I'm also aware that the conflict could probably be avoided by scheduling. However, it seems to me that this is not the expected behaviour, and if it can't be avoided, perhaps it should be noted in the help files.

I am using today's x64 nightly on Windows 7, though this problem has persisted on this same track since the beginning of this week, so it's not a new problem in that sense.

[jamespetts]

Thank you for the report. I have run the game until 2:22h in December 1896, and I am afraid that I cannot recreate any collisions. I should note that I am using the latest build from the master branch which incorporates some changes to token block signalling to fix the error that Ranran reported, so it might well be that this has now been fixed.

However, I also notice an error in the arrangement of token block signals: you have token block signals on both the entry and exit of the double track/passing loop sections: these signals should be only on the exit of these sections. Instead of a signal on the entry to these sections, you should have an absolute block (not token block) signal one tile before (rather than after) the junction at which the lines diverge into two.

I hope that this helps. Do let me know whether to-morrow's nightly build and/or reconfiguring your signals fixes this issue for you.

[Matthew]

Thank you for taking the time to look at this, James. I realize that waiting for a problem to appear after an unknown delay must have been a frustrating experience, but this does not occur after reproducible intervals (I guess that the small variations to loading times caused by passenger generation randomness are responsible??). It's easier for me to change my playstyle than for you to fix such an annoyingly untraceable bug, so thank you for correcting my signalling error. I think that the improvements that you have made to the signalling have been an educational experience for everyone!  I've waited a few days to test because of the problem with the nightly in which you tried to fix Ranran's report.

Unfortunately, the problem still occurs on this morning's nightly build, and it still occurs with the new signalling arrangement that you suggested. Neither setup made the conflict reproducible at a particular time, but they both occurred in December 1896. Using a schedule change to artificially pause a convoy in the block while the other is waiting for the schedule can help to create a conflict situation.

However, the new signalling setup did show something interesting. Previously, the convoys were only reserving the tile ahead of them and the ones behind them (similar to drive by sight), even though they were shown as token block. Both the old and new signalling have block reservations like this:





With the new signalling setup, they now reserve through to the next platform once they have sight of the absolute block signal before the passing/station loop:



I don't know whether that is what you expect to happen. My expectation is that they should reserve from the token block signal at the start of the block to the absolute block signal at the end of the block as soon as they enter it.

This issue does not prevent from enjoying this wonderful game at all, but if it surprises me, than it might surprise other people once Extended is ready for prime time.

[jamespetts]

Thank you for that. It is indeed fantastically difficult to find and fix any problem that cannot be reproduced reliably, as, in fixing the problem, I need to reproduce it dozens of times over and check in lots of places in the code what is happening until I find the problem, then reproduce the situation in which it happened previously many times over until I can confirm that the problem no longer occurs.

However, if the collisions are a consequential problem caused by a more fundamental symptom (e.g. incomplete reservations), then, if you can track down the more fundamental symptom, it might be possible to isolate a particular time and place where this occurs reliably even if it does not result in a collision so that I can diagnose and fix the problem.