[roeter]

Hmm. Interesting.

My first reaction is that such a combination ( startSectionDLReference < 0 and endSectionDLReference >= 0 , or startSectionDLReference >= 0 and endSectionDLReference < 0 ) is not possible.
Let me explain.

Basically, pathing paths areas are always one of three possible combinations, see diagram below.


In a 'single path' situation, finding an existing start-point (A) always leads to the existing end-point (Z), so having a valid start-reference but an invalid end-reference is not possible.

In a 'multi path' situation, it's a bit more complicated. But, all sections between the start and end have a reference set to the passing area of which they are a part.
For a 'multi path' situation (and let's assume is has two paths - there can be more), there can be two sequences for the way in which the passing area is defined.
First sequence is that A1 to Z1 is defined first. If, for another train, the path definition A2 to Z2 is to be processed, the program finds that A2 is within an existing passing path area, and will therefor extend the passing path back from A2 to A1. Similarly, the path will be extended from Z2 to Z1. Again, as with single path, if an existing area is found than both start and finish will be found.
If the first sequence is A2 to Z2, then, on processing the definition for path A1 to Z1, the program finds that there is an existing passing area within this path, and the existing area will be extended to run from A1 to Z1 as well. In this situation, again finding a start reference will always automatically lead to an end reference.

The third situation is overlapping passing paths - these cannot be handled (that would be very complex indeed). But you excluded that these occur in this route.

But on regarding this, I realise there is a flaw here, a flaw which admittedly has never occured to me.
That flaw is : what happens if a train has defined a path which terminates within a passing path area (see diagram below)? Could it be that, in such a situation, the end reference is not found because it is not within the train's path?


I think it is worth while to check if that situation does occur in the activities where this problem arises, and to check what happens in that situation.

If that situation does not occur, but indeed there is an instance where either the start or the end reference is not found, then this is another symptom only - the heart of the disease must then still be somewhere else.

Regards,
Rob Roeterdink

[disc]

roeter, on 10 January 2015 - 05:54 AM, said:

PassingPaths2.jpg
I think it is worth while to check if that situation does occur in the activities where this problem arises, and to check what happens in that situation.

This situation can easily happen, when a train is on the main path, and the following train (which will cause the game crash), is directed to a passing path around the first train, but there is another train ahead of them which blocks them both. But that's a quite common situation on railroads.
However the same error happens at another part of the route, where this situation can't happen as the trains are following each other in same direction hourly.

[roeter]

I'm not with you here. I'm not talking about a train which is stopped, but who's route path ends within that passing loop.
In the situation that you describe - one train stopped for an oncoming train, another train following - the passing path logic will not send the second train to the loop, but will keep it waiting behind the first train - otherwise there would be a definitive lock-up of all trains.
Also, your statement that the train which is following is the one that causes the game crash contradicts the statement above that the crash is always caused by the player train.

By the way, using passing path logic in areas where trains can terminate or reverse is not something I would recommend. I think such combinations will definitely confuse the logic. There is a limit to what situations the deadlock processing can cope with.

Regards,
Rob Roeterdink

[disc]

roeter, on 10 January 2015 - 11:56 AM, said:

I'm not with you here. I'm not talking about a train which is stopped, but who's route path ends within that passing loop.
In the situation that you describe - one train stopped for an oncoming train, another train following - the passing path logic will not send the second train to the loop, but will keep it waiting behind the first train - otherwise there would be a definitive lock-up of all trains.

All trains going to the same direction, so it can't be lock-ups just waits. (trains from other direction using other tracks, with other loops, and no overlapping. As the lines are double tracked, with additional loops at the stations.

roeter, on 10 January 2015 - 11:56 AM, said:

Also, your statement that the train which is following is the one that causes the game crash contradicts the statement above that the crash is always caused by the player train.

Not always. On one route it always happens with player trains. On another part of the route it happens both if driven by AI or player.
The "following" can be controlled by player to (as it's a timetable), so i don't understand why this contradicts with the statement above.
There are no reversing points and path ending points where the crashes happen. All trains have 30+ kilometres of path ahead, just stopping for passenger pickups.

[gpz]

Progress report: After a lot of tracking work now I am able to provide a quick-fix:
In Train.TCRoutePath.SearchPassingPaths there is a code piece:

                        if (thisSection.DeadlockReference > 0)
                        {
                            DeadlockInfo thisDeadlockInfo = orgSignals.DeadlockInfoList[thisSection.DeadlockReference];
                            int nextElement = thisDeadlockInfo.SetTrainDetails(trainNumber, iSubpath, trainLength, thisSubpath, iElement);

                            if (nextElement < 0) // end of path reached
                            {
                                break;
                            }
                            else // skip deadlock area
                            {
                                iElement = nextElement;
                            }
                        }

Currently it is not true that if nextElement < 0, the end of path is reached. So by commenting out the "break;" there everything starts to work normally, at least in my simpler reproducible case. I don't know the exact reason yet, but in my test case there are two extra maybe-false-positive DeadlockReferences added to the beginning of the subpath, compared to an other train with this same path 1-2 hours later. This "break" resulted that the passing path search was skipped for the real path after these two elements.

Disc, if you can compile the code, could you please test if this solves your more complicated case with the intercity trains too? Please note you have to start the game from the beginning, it is not enough to just reload a saved state, since these data would be just reloaded from the disk instead of being recalculated, which would obviously lead to the same crash even with the corrected code.

[gpz]

Rob,

I have checked, the false-positive DeadlockReference is not because of the FindDeadlockInfo method would not work correctly. It finds only the relevant deadlocks. However I am wondering, is it possible that the relevant TrackCircuitSection.DeadlockReferences were set by a prior FindDeadlockInfo running, for an other path? Afterall the TCS objects are not handled on per-path basis, they are handled globally.

[disc]

gpz, on 11 January 2015 - 08:24 AM, said:

Disc, if you can compile the code, could you please test if this solves your more complicated case with the intercity trains too? Please note you have to start the game from the beginning, it is not enough to just reload a saved state, since these data would be just reloaded from the disk instead of being recalculated, which would obviously lead to the same crash even with the corrected code.

The intercities does not crash there if i comment the break, but it seems other problems are introduced such as:
Information: Train 127 is removed for out of control, reason : OUT_OF_PATH
Warning: Train 145 passing signal 6177 at 54516.9 at danger at 15.80
Information: Train 145 is removed for out of control, reason : SPAD

These numbers seem to be the trains on line 70 (it would be better if the timetable train numbers would be printed to log, and not the internal train numbers)... the intercities from/to szeged seem to work now without problem.

But i have some modified signals too.

Here is the full timetable with the paths and consists:  timetablehossz.zip (46.48K)
Number of downloads: 175

PS: with original signals, SPADs do not happen, however OUT_OF_PATH still there.

[pmoser]

Rob,

I'm the one you were referring to who was also having this problem with the Surfliner2 route (post #15 in this thread). I had mentioned it under Bug report 1402854, however it was unrelated to that particular bug. I could send you the timetable and paths, but unfortunately I have modified this route fairly extensively, so you would have to fix most paths. Like the original poster to this thread, getting rid of passing paths in a particular path is the only fix for me. Strangely, other paths that are almost the same do have passing paths defined and have no problem. I'm certain that the path itself is fine, since they were all created in Trackviewer and it won't let you save an invalid path. All I have to do is add a passing path to a problem path and the error happens every time. Let me know if you want the files or if I can provide more information.

Phil

[vince]

Do you see any failures on unmodified routes? Has Route_Riter been run on the routes & stock with the problem?
Specifically the [CHECK ROUTE] , [ACTIVITYS] & [ICHK] tests.

regards,
vince

[disc]

!!! out of paths are happening when using the original openrails too. So it's a new independent issue.