[Csantucci]

Within the last 75 bug reports there are nine (two are repeated)
https://bugs.launchp...or/+bug/1426297
https://bugs.launchp...or/+bug/1430530
https://bugs.launchp...or/+bug/1434971
https://bugs.launchp...or/+bug/1440532
https://bugs.launchp...or/+bug/1450661
https://bugs.launchp...or/+bug/1454124
https://bugs.launchp...or/+bug/1458178
https://bugs.launchp...or/+bug/1458511
https://bugs.launchp...or/+bug/1458611
reporting crash in the same code line (line 280 of Traveller.cs).
They refer to different routes. So this seems a bug that should be particularly investigated.
Accordingly to some JTang's posts in two of these bugs, this should simply be caused by a not complete GLOBAL folder (old version of tsection.dat?)

Unfortunately I have no know-how on the traveller software. Is there someone of the developers that could try to tell a final word on this issue? If the cause is the one indicated by JTang, maybe a better log indication could help players. I however I am not sure that it is simply that. Within the actual log string the startTrackNode.UiD should be shown. However, no UiD is written.

[roeter]

If a track section is missing from the tsection.dat information, there is little that can be done.
Perhaps it is possible to 'recreate' the physical dimensions of the missing track section using it's starting location and direction, and the starting location and direction of the next section, but that's something that does not yet exist.
Without the track dimensions, the traveller cannot calculate the position - and that's it.

Missing track sections are already reported in the log-file.

The fact that it occurs so often simply means there are a lot of routes with poor data. Often people are using an incorrect version of tsection.dat, sometimes routes have been updated and the route's own tsection.dat which holds the information on dynamic track sections is no longer correct or complete.

The situation isn't really that much different from when people try to run a consist without having the appropriate rolling stock.
That is considered to be a user error and not a program error, and so should this.

Regards,
Rob Roeterdink

[captain_bazza]

Would that be the old, and notorious, Broken Path?

Cheers Bazza.

[bobcoburn]

I have updated my personal copy to avoid this problem by calculating the geometry of the missing track. In fact, the tsection.dat files are only needed by Route Editor for geometry. How do I create a patch file to submit to Bug Tracker? After some additional testing it should be ready this weekend. One complication is determining the next track section between vectors and junctions and end nodes.

[Csantucci]

bobcoburn, on 01 June 2015 - 07:51 AM, said:

I have updated my personal copy to avoid this problem by calculating the geometry of the missing track. In fact, the tsection.dat files are only needed by Route Editor for geometry. How do I create a patch file to submit to Bug Tracker? After some additional testing it should be ready this weekend. One complication is determining the next track section between vectors and junctions and end nodes.

If you have Tortoise and have used it to have your copy of the SVN repository, you right-click on your modified file, select TortoiseSVN, then select create patch, answer to the questions and you get the patch. Or you can attach the whole .cs file.

Rob,
I said I have no knowledge on these issues. As you have a definite opinion about these not being bugs, you could mark them as invalid.

[copperpen]

The route ref file is only needed by the RE. The tsection.dat is essential to both the main game and the RE in MSTS, and OR will spit the dummy if there is no global tsection.dat present.

[roeter]

captain_bazza, on 01 June 2015 - 05:48 AM, said:

Would that be the old, and notorious, Broken Path?

Cheers Bazza.

No.
Broken Path is purely an issue with the path itself - most likely, something along that path has been changed, usually a switch has been edited, removed or inserted. It means the 'node' as defined in that path can not be found in the *.tdb, and that's it.

These errors in the traveller are caused by missing track section information. It will cause the OR to crash even if there is no path along that specific section, but, for instance, there are signals at that section, for in that case the program will try to determine the distance between these signals.

Regards,
Rob Roeterdink

[James Ross]

Csantucci, on 01 June 2015 - 04:56 AM, said:

Within the last 75 bug reports there are nine (two are repeated)
https://bugs.launchp...or/+bug/1426297
https://bugs.launchp...or/+bug/1430530
https://bugs.launchp...or/+bug/1434971
https://bugs.launchp...or/+bug/1440532
https://bugs.launchp...or/+bug/1450661
https://bugs.launchp...or/+bug/1454124
https://bugs.launchp...or/+bug/1458178
https://bugs.launchp...or/+bug/1458511
https://bugs.launchp...or/+bug/1458611
reporting crash in the same code line (line 280 of Traveller.cs).
They refer to different routes. So this seems a bug that should be particularly investigated.
Accordingly to some JTang's posts in two of these bugs, this should simply be caused by a not complete GLOBAL folder (old version of tsection.dat?)

Unfortunately I have no know-how on the traveller software. Is there someone of the developers that could try to tell a final word on this issue? If the cause is the one indicated by JTang, maybe a better log indication could help players. I however I am not sure that it is simply that. Within the actual log string the startTrackNode.UiD should be shown. However, no UiD is written.

I tag these crashes (and some others) with the tag 'content' which means they are (probably) caused by invalid content in some place - in this case, tsection.dat is the primary suspect.

A possible fix for such a type of crash is to identify somewhere earlier where we can perform light validation - e.g. checking that all the TDB section indexes exist in the tsection.dat data - and report issues from there. We can report those as warnings or fatal errors depending on how we thing it'll survive; for things missing from tsection.dat, currently, it should be a fatal error because we crash hard if we ever encounter that section.

If a fix is developed for this group of bugs, either a fatal error in the log indicating the problem with the data or code to avoid the crash entirely, we'll mark all the bugs as duplicates of whichever one gets the fix.

[JeroenP]

There are two things that confuse me

• In all of the log files, there is not a single one where the trackNode.UID is given in the error message

  throw new InvalidDataException(String.Format("Track node {0} could not be found in the track database.", startTrackNode.UiD));

  If I understand the traveller code at that point correctly, it is trying to place a traveller at a certain tracknode. In case the tsection.dat is incomplete, this will fail. But why then is the trackNode.Uid not given at all? Is there not something wrong then even before calling this method?
  
• There are already quite some warnings like

  Warning: Skipped track section 38917 not in global or dynamic TSECTION.DAT

  . Currently this is a warning. But is James then not proposing to make this a fatal error (to prevent crashes later?)

In any case, a more extensive error message and perhaps guidelines on how to fix it (meaning updating to the latest tsection.dat) might prevent similar bugs to be posted. Currently there is simply no message guiding the user on a crash. In other words, I know we have the message "This error may be due to bad data or a bug." But in this case, apparently, we already know that it is likely bad data and we even know what kind of data is most likely the culprit. Perhaps we should even have a exception class that gives a different kind of message on these kinds of data issue to the user.

Regards, Jeroen.

[roeter]

James Ross, on 02 June 2015 - 08:38 AM, said:

A possible fix for such a type of crash is to identify somewhere earlier where we can perform light validation - e.g. checking that all the TDB section indexes exist in the tsection.dat data - and report issues from there. We can report those as warnings or fatal errors depending on how we thing it'll survive; for things missing from tsection.dat, currently, it should be a fatal error because we crash hard if we ever encounter that section.

That could be a bit too harsh.
As we all know, MSTS Route Editor does sometimes mess up the .tdb file. In doing so, it might leave references to route-specific tsection.dat entries which referred to dynamic track, which are 'caught' in node-sections which actually are redundant and cannot be accessed by any active path. Just look around - there are many routes which have one or two short sections of track away from the route - very likely tdb left-overs which cannot be removed in the RE because of missing node references at either end.
So, having a track section in the tdb with a reference which does not exist in the tsection.dat need not always be fatal.
The warning is there, if it is fatal the crash within the traveller comes soon enough.

Quote

If I understand the traveller code at that point correctly, it is trying to place a traveller at a certain tracknode. In case the tsection.dat is incomplete, this will fail. But why then is the trackNode.Uid not given at all? Is there not something wrong then even before calling this method?

If I'm not mistaken, there are some methods that use the traveller which are protected by an overall try & catch construction - it might be this 'higher' try which fails and reports the error.

Quote

In any case, a more extensive error message and perhaps guidelines on how to fix it (meaning updating to the latest tsection.dat) might prevent similar bugs to be posted. Currently there is simply no message guiding the user on a crash. In other words, I know we have the message "This error may be due to bad data or a bug." But in this case, apparently, we already know that it is likely bad data and we even know what kind of data is most likely the culprit. Perhaps we should even have a exception class that gives a different kind of message on these kinds of data issue to the user.

Well, we're already doing a lot better than MSTS which just reported 'error loading trackdatabase' :discuss_gathering: .

Problem is that many users do not realise the complexities of tsection.dat and, moreover, it needs some careful checking and proper knowledge of the system to identify whether it is the overall tsection or the route's own tsection which has the error - and in the latter case you do have to know the route and the way it is set up (e.g. multiple patches) to know what happened to that data.
Users who know how it works can already identify the problem due to the earlier warnings in the log file, for many of those who do not know how it works, extended error reports will probable mean just as little as the present warning.
Furthermore, if it is an overall 'try' which catches out the error it would be difficult to identify exactly what went wrong.

Regards,
Rob Roeterdink