Topic: Bug? TI&T train sticking / odd reservations / trains allowed in from both ends.

[AP]

A couple of issues with Time Interval & Telegraph single line working I'm afraid. This is a different test file than previously, with a single track line with two loops.

1. Eastbound passenger train departs West Terminus and reaches Halfway Loop, where it gets stuck on the entry turnout for no apparent reason.
It appears it gets stuck at the point where the reservation changes from red to blue, but I'm not sure why it does so at this location. Also, the train reserves ahead to the Twothirds Loop before it has entered the Halfway loop (although not the entire block section in between the two loops - see images).

The eastbound passenger train remains stuck until it is caught from behind by the later (slower) eastbound freight, at which point it  (for some reason...) decides to resume its journey. It travels to Twothirds Loop, where it crosses the westbound freight (which owing to the delay yet loop reservation aforementioned, has been waiting patiently for some time for it). The passenger train then carries on to the east.

Meanwhile...

2. Both the eastbound freight train, and the westbound freight train, are allowed to enter the middle block section, from opposite ends. Inevitably, they collide.

The "telegraph" component of "time interval and telegraph" should absolutely prevent trains being allowed to enter a block section from opposite ends simultaneously, even if both ends exceed the "time interval" parameter, yet it appears it does not.

It appears the westbound freight departs immediately the eastbound passenger train arrives at Twothirds Loop, suggesting there is no time interval consideration between trains in opposite directions, which seems correct as it would serve no purpose.

Thoughts?

[jamespetts]

As to 1, I think that I have fixed this error - I should be grateful if you could confirm.

In relation to no. 2, as described in the tutorial video, you need to use station signals at the stations, sidings or junctions along the single track section to obtain a directional reservation. Plain signals, as you use, assume double line working, and, as demonstrated in the video, only reserve up to the next signal facing in the same direction.

If you use station signals, then you will not need extra signals beyond the junction (although you may place them), as station signals, unlike other signals, do not reduce the speed limit when there are junctions beyond them.

Incidentally, when using a station signal at an actual station, you only need one signal for each pair of directions (as shown in the video), not one per platform as with other types of signal.

[AP]

I'm away from my pc but will retest later, assuming the latest nightly features the update required.

Incidentally, when using a station signal at an actual station, you only need one signal for each pair of directions (as shown in the video), not one per platform as with other types of signal.

Conversely, for a loop that is not an actual station, is it therefore still one Station Signal for each direction?


Out of interest, is there a reason Stop Signals cannot make directional reservations? For everyone's convenience, might there be an argument in favour of adding that additional functionality to them also? The new signalling options being complex, if it reduces "mistakes", perhaps it could be worth considering. There may be a counter-arguement that I'm unaware of, of course...

[jamespetts]

The fix will indeed be in the latest nightly version.

As to the station signals, the reason that having only one will not work properly on a loop that is not a stop is that the stopping point for a station signal is the station itself, not the location of the signal. If there is no station, then the stopping point becomes the signal itself, and that will only be on the one tile, which will be the track facing in one or the other direction but not both directions on the loop, so the train passing in the other direction will not detect or be affected by the station signal. You could get around this, however, by making both lines of the loop into a siding (which is very cheap in Pak128.Britain-Ex) and then having just the one station signal in the middle of the sidings.

In relation to altering the function of stop signals, the idea is that station signals are the things whose functionality is necessary for single line working. It is explicitly stated in the time interval with telegraph tutorial video that station signals are necessary for single line working, and that it is they that are needed to create the directional reservation; it is also explicitly stated that stop signals (being not station signals) do not reserve beyond the next signal. It would be very confusing for players if the functionality were different to what was shown in the tutorial video. Most working methods require different sort of signals for single line working than double line working.

[AP]

I have corrected the loop signalling to rectify problem (2).  Your signal rationale is clear, no sense re-making videos when there are doubtless better tasks to push forward. Whilst the videos are good, some of us learn/remember better by doing than listening, and videos are not text-searchable when you have a question. I'm sure we'll all pick it up soon enough!

I have then re-tested, and as you will see from Savegame J attached, the passenger train does not 'stick' any more at Halfway Loop entry points (so 1 is also solved)

However, incidental to this two more issues have arisen. The first (3) is probably a bug, but not a signalling one, so I can put it in a new thread if you prefer? The second (4) is a signalling matter, but may or may not be a bug...


3. See savegame revision J (and image 3). Eastbound freight should depart 3 minutes behind the eastbound passenger (according to schedule) but actually 5 minutes (held by signal at danger). However, at the designated time, it actually lurches forward several tiles, then begins reversing, for no reason I can see. It should reverse, if necessary, during its time in the station. However, as it came from the depot and is already facing the correct way, it shouldn't reverse at all. The additional reversing time throws the schedule out of synch.


4. Stop Signals in single track working, seem to actually adversely affect (or enhance!) block reservations if they occur after the Station Signals.

See the test game version h attached (and image 4) in which the east terminus has a Stop Signal after its pointwork when departing - because I forgot to delete it like the rest.

In this case, owing to that extra Stop Signal, the slow westbound freight reserves the middle block section right from its initial departure, long before it gets close to the Twothirds Loop. This means when the passenger train arrives at the block, it is reserved, when it should be free. If the Stop Signal is not present, it only reserves to the first loop.

Interestingly also, when that reservation is made, if I use the "b" tool to see the reservations, and manually clear the middle loop reservation, a single tile remains reserved by the westbound freight , unable to be cleared.

[jamespetts]

Thank you for your report in this respect. Looking first just at no. 3, the problem appears to be that the positions of the vehicles of train no. 2 have been saved incorrectly, so that, when the positions are corrected, the train is positioned in front of a signal. In order to try to fix this, I am going to need to recreate the situation in which a correctly positioned train before saving becomes incorrectly positioned after saving and loading, which is likely to be tricky.

If you are able to assist by giving clear steps reliably to reproduce this state of affairs many times over from a specific saved game, that would help me enormously in trying to fix this, which I suspect has been an issue for quite some time.

Edit: As to 4, I cannot reproduce this: it might be that my other signalling fix to the problem that you reported on a different thread has also fixed this. Would you be able to re-test with the nightly build available to-morrow (Sunday, the 7th of May)?

[jamespetts]

Incidentally, I think that I may have solved issue 3 when solving another bug; would you be able to re-test this also? I should be grateful.

[AP]

I just retested with the latest nightlies.

"4" is solved.

"3" persists.  I've re-made a better save game, attached, showing the same behaviour (saved at a slightly earlier timestampt relative to departure but with the vehicles in the correct position when loading. When the second train's schedule releases it from West Terminus  (but the signal would prevent it's departure owing to the preceding train having only recently left), the second train jumps ahead then reverses, both for no reason, rather than waiting for the time interval to elapse.  (Since the reverse time exceeds the time interval, when the reverse is complete it departs).

[jamespetts]

Thank you for that report. The problem appears to be caused by the state in which the relevant train is to be found when loading, that is with the vehicles forming the train incorrectly compressed into one tile rather than distributed behind the locomotive in the normal way.

I will need to have a way of reproducing the train getting into this state in the first place in order to be able to fix this issue. Are you able to find a way of reliably reproducing this? It may well be a load/save issue.

[AP]

There are three trains on the line, all at the terminii.

I believe if you simply send all 3 to depot before they depart, then once they are in their local depot, start all three again (i.e. to the first station on their line, being the same termini they were at before), it should recur. That's all I did last time. 

They will likely all then begin a rather long wait until departure (having all just missed their slot), but you can of course fast forward.

[jamespetts]

I am having trouble reproducing this, I am afraid: I send the freight train to the depot, start the freight train again, wait for it to reach the station, save the game, and load it again, and the train is not compressed onto a single tile, but is spread out correctly. Do you get a different result from those exact steps?

[AP]

If I send only the offending freight train (2) to the depot as you say (ignoring the other two trains, which depart as normal meanwhile) then no, those steps do not yield the result of stacking the train onto a single tile.

I note that all trains in depot change their lines to "individual schedule" and this must be changed back to their line name before they are manually restarted.

If however I send first the passenger train(3)then the freight (2) and then freight (4) all to depot , and then after all have arrived, restart them in the reverse of that order (ensuring all are set to their named lines and the closest termini before pressing start for each, especially the passenger train as I wasn't quick enough in sending it to depot before it departed), then the problem of "stacking on one tile" does indeed recur for freight train (2).

This was tested on v 12.1 r47a563c using file 1_k attached.

[jamespetts]

I am afraid that I am still unable to reproduce this following the exact steps mentioned. May I ask whether this is the same 1_k as in your other thread?

[AP]

Yes, it's the same file.

[jamespetts]

In that case, it is not at all clear to me why I cannot reproduce this. I send the passenger train to the depot, then send the freight train at West to the depot, then send the freight train at East to the depot, then re-start the passenger train (having changed its schedule to the line and set it to stop first at West), then start the freight train from West, then start the freight train from East, then fast-forward until the freight train from West stops at the station, then save the game, then reload the game, yet the freight train from West is not compressed on the same tile.

Can you check to see whether there are any other precise steps that need to be repeated in order to reproduce the compression on re-loading?

Edit: Added "you" between "can" and "check" above, originally omitted in error.