Error in conversion from MSTS path to Node list

[r.roeterdink]

Occasionaly, the conversion from MSTS path to Node list (path as used internally). The error links an incorrect node into the path.
The error mostly occurs at the start or the end of a (sub)path, i.e. start of path or just before or after reversal point or waiting point.

Example :
Route : Surfliner2
Path : FF_LAX_SD (file is attached)
Activity : n.a. (affects any train, either player or AI, in any activity using said path)
Logfile : n.a. (no error reported)

Path is routed through Stuart Mesa yard, with waiting point just before yard exit.

Path is correct upto node 990.
Next sequence than is :

node 990
junction node 991
node 948
junction node 947

Path is correct again from this point onwards.

Error here is node 948 : this is not connected to 991. The correct node here should be 992, which is the node between junctions 991 and 947. Node 948 is connected to 947 but is the 'wrong' exit from this junction.

The problem does not lead to an error report or crash or anything.
Sometimes it causes the train to 'jump' tracks, often it remains unnoticed.
In the preliminary new signalling, it leads to a report that the train is off its allocated route.

[cjakeman (cjakeman)]

Hi Rob,

Can we mark this report as invalid, do you think?

Chris

[r.roeterdink (r-roeterdink)]

Chris,

the problem still persists, nothing has been changed as far as I know.
I fear, though, that there is little knowledge now left on how this particular method works, and it doesn't look as if anyone has enough courage to start meddling with this code.

Regards,
    Rob

[James Ross (twpol)]

I had a poke at this a while back (but obviously forgot to comment, sorry!) and IIRC the problem is that the location in the path is close enough to a second track that the Traveller's current (quite large for compatibility with other routes) error margin accepts it before finding the track it is meant to be on. It might not be an easy one to fix, without (for example) another rewrite of a fair chunk of the Traveller code to find all potential track sections and sort by errors.

[r.roeterdink (r-roeterdink)]

Fix commited in X1966.

[jeroenp (j-paasschens)]

Dear Rob.
I found an error in the code I created. The distance to the track is calculated using the 'lateral' distance. But I did not use the absolute value. So now it is possible that a point gives a 'negative' distance. In some unfortunate cases this leads to still selecting the wrong path. For example, a 'distance' of -1.2 should not be better than a distance of 0.004.
Therefore, I would suggest to change the last line in TryTrackSectionCurved (in Traveller.cs) from

return new TrackNodeCandidate(lat, lon, true);

to

return new TrackNodeCandidate((float)Math.Abs(lat), lon, true);

The same change has to be done in TryTrackSectionStraight but then with 'false' as last argument.

Sorry for the extra effort.

Best regards, Jeroen.

[Shane McLeod (supershane100)]

Will we have to do this for all of the path files in the route?

[jeroenp (j-paasschens)]

Dear all,
I checked in my proposed fix in 2067, with a small correction from Rob in 2073.

Shane,
I am not sure what you mean. Some of the rewrites I did will fix some of the broken paths (especially those were the point in the path is very close to a wrong track (e.g. close to a junction). In some cases there is nothing wrong with the path, but still ORTS will behave differently from MSTS for instance due to a small difference in speed of AI trains (see e.g. http://www.elvastower.com/forums/index.php?/topic/23146-problems-with-orts-starting-some-default-activities-for-default-marias-pass/).

Do you still have paths that are not working and are not related to AI trains?
Jeroen.