[Csantucci]

I have a case in route SUD-ITALIA_01 where an AI train stops at a small station (Favazzina) and does not restart. It continously changes status from STA to ACC to BRK(I believe they are these three), but stays there. Signal is cleared. Path ends before next station.
Here a screenshot (it is train 34):

Here the chectrain file:
 checktrain_Favazzina.zip (42.74K)
Number of downloads: 276
Here the logfile:
 OpenRailsLog_Favazzina.zip (3.38K)
Number of downloads: 253
Here some route files just in case:
 SUD-ITALIA_01.zip (766.74K)
Number of downloads: 274
Here the path file:
 ORAP_Reg12654.zip (883bytes)
Number of downloads: 255

[roeter]

Well, the train certainly wants to restart but somehow finds itself back at the station again. For some strange reason, the stop is not removed from the list after the train departed.
I noticed there is a waiting point earlier in the path. Could you please remove that waiting point and test if the problem still occurs?
Waiting points for AI trains are processed as station stops, but perhaps the existance of a waiting point somehow corrupts the station stop list.

Regards,
Rob Roeterdink

[Csantucci]

I made some tests.
If I remove the end point, therefore lengthening the path, the train stops for the correct time and restarts (even leaving the WP, that is two stations before). Here the working path:
 ORAP_Reg12654_endless.zip (1.97K)
Number of downloads: 241
If I instead replace the waiting point with a station stop, and leave the path ending at the original point, the train does not restart from Favazzina. Here the non-working path without WP:
 ORAP_Reg12654_noWP.zip (865bytes)
Number of downloads: 258
Looking at other paths, I only slightly increased the length of the path to the next signal section, and this path works correctly:
 ORAP_Reg12654_aftersignal.zip (878bytes)
Number of downloads: 257

So it seems that it is what is after Favazzina that causes the problem at the station stop.

[Csantucci]

I provide also the checktrain file for the last path above (working), so that a comparison can be done with the original checktrain file (nonworking). It is a path without WP, but as verified above the problem does not lay there.
 checktrain_Favazzina_OK.zip (53.37K)
Number of downloads: 246

[Csantucci]

What I have noticed is that immediately after the end of the station platform there is an end of speed reduction post immediately followed by another speed reduction post. No signal between end of platform and this couple of speedposts.

[Csantucci]

I write also here what I found in my debugging.
The problem is due to the fact that the if at line 1664 of AITrain.cs, that is

if ((PresentPosition[0].RouteListIndex == (ValidRoute[0].Count - 1)) ||
                    (NextSignalObject[0] != null &&
                     NextSignalObject[0].TCReference == ValidRoute[0][ValidRoute[0].Count - 1].TCSectionIndex) ||
                    (NextSignalObject[0] != null &&
                     NextSignalObject[0].TCNextTC == ValidRoute[0][ValidRoute[0].Count - 1].TCSectionIndex))

gives a positive result because the last clause is true.
So removeStation is set to false because ProcessEndOfPath should have removed the station from the list.
Unfortunately ProcessEndOfPath decides that it is not at the end of the route, and so the station is not removed from the list.

If the path is extended beyond the signal in front of it, the above clause is false and so removeStation remains true and causes the removal of station from the list at line 1747.

After further investigation it seems to me that ProcessEndOfPath decides that we aren't yet at the end of the path because there is still a signal between train and end of path (check is in line 4650 of UpdateRouteActions)

                    if (!intermediateJunction && !intermediateSignal)  // no more junctions and no more signal - reverse subpath
                    {
                        endOfRoute = true;
                    }

So there is a contradiction: ProcessEndOfPath is called even if there is an intermediate signal, but then refuses to act because there is the intermediate signal.

So it seems that either the last part of the above if clause of line 1664 or the last part of the above if clause of line 4650 should be removed ??? Or is it more complicated?

[roeter]

Yes, it is more complicated.
Having two clauses (the pre-clause in station stop and the ProcessEndOfPath method) can always lead to problems.
Best way out is to alter ProcessEndOfPath to do all the work, and return two states : end of path, and train still exists.
Obviously requires changing all calls to this method.
Is now on my list of 'things to do' - will probably be completed next week.

Regards,
Rob Roeterdink