RFSP route fails to load due to an exception in Signal.cs

[BB25187]

This has been a long standing issue: the french RFSP (Paris subway) route (http://funtrain.net/fr/simulateur-de-train/microsoft-train-simulator/lignes/add-on-12/) fails to load due to an exception in Signal.cs. The error report below was obtained with a revision #2194, but the situation is the same with more recent revision:

Error: System.NullReferenceException: La référence d'objet n'est pas définie à une instance d'un objet.
   à ORTS.SignalWorldObject..ctor(SignalObj SignalWorldItem, SIGCFGFile sigcfg) dans c:\Users\James\Documents\Coding\Jenkins\workspace\Open Rails Experimental\Source\RunActivity\Signals\Signals.cs:ligne 9874
   à ORTS.Signals.BuildSignalWorld(Simulator simulator, SIGCFGFile sigcfg) dans c:\Users\James\Documents\Coding\Jenkins\workspace\Open Rails Experimental\Source\RunActivity\Signals\Signals.cs:ligne 462
   à ORTS.Signals..ctor(Simulator simulator, SIGCFGFile sigcfg) dans c:\Users\James\Documents\Coding\Jenkins\workspace\Open Rails Experimental\Source\RunActivity\Signals\Signals.cs:ligne 111
   à ORTS.Simulator.Start() dans c:\Users\James\Documents\Coding\Jenkins\workspace\Open Rails Experimental\Source\RunActivity\Simulator\Simulator.cs:ligne 231
   à ORTS.Processes.GameStateRunActivity.Start(UserSettings settings, String acttype, String[] args) dans c:\Users\James\Documents\Coding\Jenkins\workspace\Open Rails Experimental\Source\RunActivity\Processes\GameStateRunActivity.cs:ligne 261
   à ORTS.Processes.GameStateRunActivity.<>c__DisplayClass6.<Load>b__3() dans c:\Users\James\Documents\Coding\Jenkins\workspace\Open Rails Experimental\Source\RunActivity\Processes\GameStateRunActivity.cs:ligne 149
   à ORTS.Processes.GameStateRunActivity.Load() dans c:\Users\James\Documents\Coding\Jenkins\workspace\Open Rails Experimental\Source\RunActivity\Processes\GameStateRunActivity.cs:ligne 190
   à ORTS.Processes.LoaderProcess.Load() dans c:\Users\James\Documents\Coding\Jenkins\workspace\Open Rails Experimental\Source\RunActivity\Processes\LoaderProcess.cs:ligne 121
   à ORTS.Processes.LoaderProcess.DoLoad() dans c:\Users\James\Documents\Coding\Jenkins\workspace\Open Rails Experimental\Source\RunActivity\Processes\LoaderProcess.cs:ligne 102
   à ORTS.Processes.LoaderProcess.LoaderThread() dans c:\Users\James\Documents\Coding\Jenkins\workspace\Open Rails Experimental\Source\RunActivity\Processes\LoaderProcess.cs:ligne 73
   à System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   à System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   à System.Threading.ThreadHelper.ThreadStart()

Actually, the TDB of the route may contain some inconsistencies, but the error should be captured by OR. I attach a patch that:
- detects that SignalWorldItem.SignalUnits is null before accessing it, thus avoiding the exception
-- emits a warning if SignalWorldItem.SignalUnits is null and continues the loading process
-- process SignalWorldItem.SignalUnits otherwise
With this patch, the route can be loaded and it works fine.

[BB25187 (bb25187)]

Reattach the patch with the proper flag

[r.roeterdink (r-roeterdink)]

Removing the crash does not sort the problem. That's why this has never been done before.
To know what is actually happening, a short detail of how signal data is formed.

Signal details in MSTS consist of two distinct parts :
 - TDB entry
 - World file entry

The only link between these two definitions is the TDB reference number.
When signal data is build, a list is made of all available TDB entries (a 'candidate' list), with the TDB number as reference. When a world entry with specific TDB reference is processed, it is linked to the TDB information to create a signal. The TDB entry is then removed from the 'candidate' list.
This processing assumes there is only one world-file entry which references this TDB entry.

This route, however, has a set of 'spurious' world files in the WORLD directory - those are world-files which are not actually part of the route, and contain data which is not contained in the route's TDB file.
These world therefor contain signals which have the same TDB reference as signals in other world files which are part of the route. The first signal world data with a specific TDB entry is linked with the TDB, but the second signal in another world file finds no valid reference and this causes the crash.
But which of these two is the actual valid signal to be linked with the TDB is not known. So avoiding the crash does not mean the signal data is now build correctly - far from it. If the TDB entry is linked to a signal from one of the invalid world files, the data can be completely wrong - the information could be set for a completely different type of signal, resulting in a complete mismatch of TDB and world-file information. Flag information (which is contained in the world file entry) would therefor not match at all, which at best would lead to complete incorrect signal behaviour, but at worst to a crash somewhere else in the program.

To sort the problem in full and make sure TDB and world data do match would require extensive changes to the data structure. This has been discussed in the past and it has been decided that this would not be done. The problem is in the route data, it occurs in very few routes and the work needed to change the program far exceeds the work required to clear the data.

As said, this patch does not correctly sort the problem and must therefor not be implemented. The only proper way to avoid the crash is to remove the incorrect data - that is, to remove the spurious world files from the WORLD directory.
This route has been mentioned before, I have downloaded it and cleared the files and it then works correct.

Regards,
Rob Roeterdink

[BB25187 (bb25187)]

Hi Rob,

Thanks for your reply and clarification. I understand your point.
I summarized your explanations on our forum. We will try to fix the files of the route too.
Besides this, I would like to thank you a lot for the work you did in OR code. The timetable looked very promising, and a much more flexible and powerful way to program scenarii than MSTS activities.

Regards

[r.roeterdink (r-roeterdink)]

OK, fine.
I had a look through the data and found this route also has another problem which causes the same crash.
This is a 'signal-which-isnt-a-signal' - a SIGNAL entry in a world-file which has no reference to a TDB signal entry at all.
This causes the same crash for very much the same reason, and here also just preventing the crash does not solve the problem as it leaves a signal with only half of it's data set correctly.
Changing the 'SIGNAL' entry to a 'STATIC' entry in the world-file solves this particular problem.

I have attached two files - one is the list of WORLD files which I now use for this route (worldfiles.txt), the other is the worldfile which I corrected for the invalid SIGNAL entry. Hope this helps you to sort the problem.

Regards,
Rob Roeterdink

[BB25187 (bb25187)]

Thanks Rob for the analysis of the route, for the problem you found in the world file and for the indications on a solution.
This will for sure help us keeping on fixing all the problems it contains.
Regards
Vincent