[Lindsayts]

Now the following error is being thrown in an old (1648) version of OR............

Mode       = Explore

Path       = C:1MSTSROUTESTA_VR_NE_1950sPATHSSeymour_SPST3.pat

Consist    = C:1MSTSTRAINSCONSISTSflying scotsman8.con

Time       = 12:0

Season     = 0

Weather    = 0

--------------------------------------------------------------------------------

Loading  TRK TDB SIGCFG DAT ACT RDB CARSPAWN SIGSCR

WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW

Error: System.NullReferenceException: Object reference not set to an instance of an object.

  at ORTS.SignalWorldObject..ctor(SignalObj SignalWorldItem, SIGCFGFile sigcfg)

  at ORTS.Signals.BuildSignalWorld(Simulator simulator, SIGCFGFile sigcfg)

  at ORTS.Signals..ctor(Simulator simulator, SIGCFGFile sigcfg)

  at ORTS.Simulator.Start()

  at ORTS.Program.Start(UserSettings settings, String[] args)

  at ORTS.Program.c__DisplayClass6.b__3()

  at ORTS.Program.Main(String[] args)

On the route in question OR did not like a particular signal at the end of the start platform a latter version of OR fixed the problem. Now the question is is it possible to say why OR through the
"Object reference not set to an instance of an object" on this signal.

Just curious, the reason for asking is I had this error on this route sometime back, at the time on posting a query on elvastower one of the devs did come up with an explanation which I can no longer find. Currently another Australian has come up with the same error and it sort of partly jogged the memory.

Lindsay

[roeter]

Hello Lindsay,

The error you mention is usually the result of some kind of mismatch between the TDB reference for a signal in the world file, and the signal references in the *.tdb file.

there are two situations which are the most common cause for such a situation :

• a "signal which isn't a signal" : a signal shape has been placed in a world file, all 'heads' on this signal are optional and none have been selected - so the signal has no signal-heads at all, and therefor no reference to a TDB entry.
  
• there are spurious world-files in the WORLD directory, which contain signal-entries that use the same TDB reference as signals in the 'proper' world-files.

Regards,
Rob Roeterdink

[PA1930]

I believe it's also the same error I get with Trat 321 [which problem was assigned to not be fixed recently on the bug tracker]. I have read on the Czech forums that the route did have some problems with signals somewhere so it might be why it does not work...

[Lindsayts]

 roeter, on 09 December 2013 - 01:24 AM, said:

Hello Lindsay,

The error you mention is usually the result of some kind of mismatch between the TDB reference for a signal in the world file, and the signal references in the *.tdb file.

there are two situations which are the most common cause for such a situation :

• a "signal which isn't a signal" : a signal shape has been placed in a world file, all 'heads' on this signal are optional and none have been selected - so the signal has no signal-heads at all, and therefor no reference to a TDB entry.
  
• there are spurious world-files in the WORLD directory, which contain signal-entries that use the same TDB reference as signals in the 'proper' world-files.

Regards,
Rob Roeterdink

Many thanks Rob, the first answer was the problem.

Lindsay

[Csantucci]

Rob,
as you see this incompatibility is not so uncommon.
You already brillantly managed e.g. to tolerate more than a signal light with the same name, which is an error by the route builder. Can't you do something so that OR checks Lindsay's case and avoids this exception? MSTS manages this correctly, and inserting a "signal" without selecting signal heads is not an "error".

[Lindsayts]

 Csantucci, on 09 December 2013 - 11:56 AM, said:

Rob,
as you see this incompatibility is not so uncommon.
You already brillantly managed e.g. to tolerate more than a signal light with the same name, which is an error by the route builder. Can't you do something so that OR checks Lindsay's case and avoids this exception? MSTS manages this correctly, and inserting a "signal" without selecting signal heads is not an "error".

Firstly the route does work correctly in the current version of OR, I assume latter versions of OR do not consider an object appearing in the world files but not in the TDB as a terminal item. It'd probably be nice that if possible the error message could print out the identity of the world tile item that caused the error in the first place.

The problem with trying to detect a specfic error is the number of these would almost surely be to high to consider. The error could be due to the route editor or a missunderstanding or simply an incomplete feature by the developer. In this case it apears to be an incomplete feature. The signal stand has three signals on it, this does not accord with the era the routes is in (1950's) at this time the stand had only two signals both of which function correctly in OR. For the third signal to work as the 1942 signal diagram say's it should requires the presence of at least one other signal.

The three signals on the head are 1 a semaphore, main line to next signal. 2nd item a disk signal, main line to number 2 road, both these signals work in the route. 3rd item a disk signal, Number 2 road to the next disk signal, this signal does not exist in the route or in the 1961 signal diagrams but it does exist in the 1942 diagram.
It is not clear which diagram the developer was trying to emulate assuming MSTS's signalling could do the job required.

Note, the signalling actaully used on the railway during the period concerned is 2 position semaphore, a signal idicating that a path has been set up and locked, ie its NOT speed based signalling which it appear MSTS and OR actually represent, so the represntation will always be a bit so so.

Lindsay

[roeter]

The problem with this part of the code lies with the data-structure. This is very rigid, and very minimal.
For instance, when there is a signal without a TDB-reference, which causes the error as mentioned, it is not possible to identify the world-position of that signal as, in that part in the program, that information is no longer available. Only the 'real' signal-data (tdb-reference and signal flags) is taken from the world-file entry and stored, using the tdb-reference that data is then added to the signal information from the tdb.
I have made some attempts to catch the error where it now occurs, but found that it then just 'moved', and the program crashed a bit further on in the code.
To sort this out would require some major changes to the data-structure, and that is not on the list at the moment with other work, e.g. signalling for multi-player and preparations for activity editor, having a higher priority.

Regards,
Rob Roeterdink

[Lindsayts]

 roeter, on 10 December 2013 - 01:23 AM, said:

The problem with this part of the code lies with the data-structure. This is very rigid, and very minimal.
For instance, when there is a signal without a TDB-reference, which causes the error as mentioned, it is not possible to identify the world-position of that signal as, in that part in the program, that information is no longer available. Only the 'real' signal-data (tdb-reference and signal flags) is taken from the world-file entry and stored, using the tdb-reference that data is then added to the signal information from the tdb.
I have made some attempts to catch the error where it now occurs, but found that it then just 'moved', and the program crashed a bit further on in the code.
To sort this out would require some major changes to the data-structure, and that is not on the list at the moment with other work, e.g. signalling for multi-player and preparations for activity editor, having a higher priority.

Regards,
Rob Roeterdink

Thanks for the inside look, Now being an interested programmer, in such circumstances, a known problem the will need to be work on probably at much latter time. Do you keep some decent notes so one does not have to research the whole thing all over again. An obvious way (which I use these days, and has been used in the Linux kernel) is to put some decent comments describing the issue at the apropriate spot in the source. In the past I used a "lab book", in fact I still do specially for preliminary design and bug fixing, worth its weight in both gold and platinum.

Lindsay