r5571 - Pre-signal failure

[Ters]

I suddenly got this jam at a junction that has worked flawlessly for several game decades. The track towards the upper left continues a few more tiles into a dead-end station. Its entrance is guarded by a two-way normal signal. The track towards the lower left carries on for several tiles before joining some other tracks. It is guarded by a two-way normal signal just below the edge of the picture. The dual tracks in the upper right also carry on for some distance. The signal below the rightmost stucked message is a one-way pre-signal.
The errer seems to have happened when loading. The locomotive hauled passenger train was waiting at the pre-signal when the game was loaded, while the red and white DMU had left the station heading back towards the junction. If I press pause immediately upon loading the game and scroll over to the junction, I can see that the locomotive has reseved the route up to the normal signal, but not any further. The DMU has only reserved the tiles it is on and is displaying moving block behavior. The final result can be seen in the cropped screenshot.

[Dwachs]

can you upload this savegame please?

[Ters]

Here: http://simutrans-germany.com/files/upload/Ters_4_-_Kopi_(3).sve

The jam occurs east of Hillstead Oilfield yard.

[Dwachs]

It seems that after loading the train does not reserve correctly. Attached is a minimal example that shows this.

In Ters' savegame the train does only reserve the tiles it is on after loading...

[TurfIt]

Also see https://sourceforge.net/apps/phpbb/simutrans/viewtopic.php?f=3&t=99
The problem is that after loading, the convoi has lost the information that it last passed a pre-signal (or choose signal). Without that info, the block reservations cannot be properly restored.

Upon loading, only the tiles under the convois current position are re-reserved. The convois then all start moving, and upon reaching the tile edge perform a normal reservation attempt. Which leads to possible deadlocks after loading, despite an otherwise deadlock free signal arrangement.

The convois will have to carry around extra info on how many signal blocks are currently reserved so the tile reservations can be correctly fully recalc'd on loading. Or, simplest fix is just explicitly saving the reservations IMO.

[omikron]

And the fact that the tile on which the convoy is situated has a pre-signal on it won't help things? Is that a more time consuming check than the proposed additional info for each convoy?

omikron

[Ters]

As long as the train is on a signal, it should not be a problem. I think what Dwachs found is what happens when the train has passed the signal. When the game is loaded, the train does not know that it had reserved two blocks, and only reserves one.

I don't quite see how this caused my jam, though. Will a train waiting at a signal also drive into the next tile before reserving? Otherwise, it should be able to see that it was waiting that a pre-signal and that the second block was partially reserved, even if it wasn't reserved the way it should have been.

[TurfIt]

My first reply more addresses what Dwachs brought up, which looks the same as I encountered last August in the linked message.

The problem in Ters game is specifically caused by train 73 being on the same tile as the signal upon loading. It appears that causes the signal to be ignored. Any signal - doesn't need to be a presignal. Since train 73 doesn't see that first signal (492,394), it reserves up to the next signal (491,396). Now train 844 (which is processed after the lower ID 73) tries and fails to restore its reservation to (491,396), and ends up in that "moving block" mode.

The call to block_reserver() from waggon_t::set_convoi() is resulting in this. Adding an extra -1 to the start_index param in the call fixes this issue, but I'm sure breaks many other things. Needs more investigation...

Why

Code Select Expand

if(route->position_bei(start_index)==get_pos()  &&  reserve) {
start_index++;
}
in block_reserver() ?

[prissi]

The trains remembers, if is passed a choose signal or not; however, most simply might be indeed a flag to indicate on how many block to reserve in advance.

The other bug with ignoring signals on tiles during loading seems to be a hydra: It keeps reoccurring.

EDIT: Ok, I submitted a fix; This needs a savegame bump. Please test this, but be adviced that this could cause severe errors and non-reoverable test games!

[Ters]

I've done a little bit of testing with r5576 and not seen anything wrong with it. Am I right in assuming that it is saving and loading that needs to be tested? That reservation gets loaded with the right state?

[prissi]

Every convoi now saves the next possible stop (either signal or crossing) and the next point until a route has been reserved (usually a signal) and restores during load. I did test it with the usualy games and it worked, but this is a very severe change, so I expected usually some oversights on my side. (Such  contributions from me are usually only correct in the 2nd attempt ... )