[gpz]

I can confirm, disc's timetable still doesn't work, however something has been changed, since the exception now occurs at loading time, not at mid-game. (The error can be reproduced with train 2117.) The good news is that the temporary workaround with commenting out the "break" in SearchPassingPaths function still applies. By logging the nextElement variable received from SetTrainDetails for train number 0 I can see, that there are still two -1 values are received at the beginning of its path as the first two values, and the real non-negative nextElements follow only these ones.

[roeter]

This was indeed very much a brother of the first bug - a twin brother, in fact, for the problem was in the same method, and very much the same type of error - incorrect return of state 'end of path reached', which meant that any following passing paths were not processed.
However, the situation in which this now occured is something which, admittedly, had never crossed my mind : it happened when a train starts within a passing path area. Personally, I would never set up such an arrangement, but it is ofcourse possible and allowed.
Version 2809 is now clear of this little beastie.

Let's hope that bug does not have a whole nest of further siblings ... :wallbash:

Regards,
Rob Roeterdink

[pmoser]

Rob,

Version 2809 seems to have fixed the problem. I've run every test were I used to have problems before and everything works perfectly now. I even checked "Location-linked passing path processing" in Experimental options and everything runs fine. Before, when I checked that option, it would effect a lot more paths then without it checked.

You mentioned about starting a train within a passing path as one of the causes of this problem. I'm not aware of any of my paths doing this and I don't know how you can even set that up as I think the only way to set a passing path is to go through it unless I misinterpreted your statement. Thanks again for your work in resolving this bug and for the timetable concept in general.

I've noticed another minor (cosmetic) bug which is not related to this, but since it would affect only timetable operation, I figure I would use the same thread. At the beginning of the day, I stage four Coaster commuter trains at Stuart Mesa for the morning rush. All these are playable services vs. inbound moves. If you select either "C630" or "C636" for the player train, the trains behind it (C634 and C638 respectively) will run up and into whichever train you are running. If the computer is running those trains, this does not happen as viewed on the dispatcher screen. You can see this if you select either "C630" or "C636" and look at the back of your train.

Phil

[disc]

 roeter, on 22 January 2015 - 09:57 AM, said:

This was indeed very much a brother of the first bug - a twin brother, in fact, for the problem was in the same method, and very much the same type of error - incorrect return of state 'end of path reached', which meant that any following passing paths were not processed.
However, the situation in which this now occured is something which, admittedly, had never crossed my mind : it happened when a train starts within a passing path area. Personally, I would never set up such an arrangement, but it is ofcourse possible and allowed.
Version 2809 is now clear of this little beastie.

Let's hope that bug does not have a whole nest of further siblings ... :)

Regards,
Rob Roeterdink

OMG it works now :spiteful: Thanks!

So you say that error error caused not by the running train but a starting one? Then i looked the opposite direction all time ;) i watched the intercity, but the error is caused by a starting regional train?


Edit: not everything works :furiousPC: the crash when the player is following an AI train still there, at same place.

Error: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
   at System.ThrowHelper.ThrowKeyNotFoundException()
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at ORTS.DeadlockInfo.GetEndSection(Train thisTrain) in e:\Documents\Coding\Jenkins\jobs\Open Rails\workspace\Source\RunActivity\Signals\Signals.cs:line 12616
   at ORTS.DeadlockInfo.CheckDeadlockPathAvailability(TrackCircuitSection startSection, Train thisTrain) in e:\Documents\Coding\Jenkins\jobs\Open Rails\workspace\Source\RunActivity\Signals\Signals.cs:line 12127
   at ORTS.SignalObject.getBlockState_locationBased(TCSubpathRoute thisRoute, TrainRouted thisTrain) in e:\Documents\Coding\Jenkins\jobs\Open Rails\workspace\Source\RunActivity\Signals\Signals.cs:line 9869
   at ORTS.SignalObject.getBlockState(TCSubpathRoute thisRoute, TrainRouted thisTrain) in e:\Documents\Coding\Jenkins\jobs\Open Rails\workspace\Source\RunActivity\Signals\Signals.cs:line 9594
   at ORTS.SignalObject.checkRouteState(Boolean isPropagated, TCSubpathRoute thisRoute, TrainRouted thisTrain) in e:\Documents\Coding\Jenkins\jobs\Open Rails\workspace\Source\RunActivity\Signals\Signals.cs:line 9243
   at ORTS.SignalObject.requestClearSignal(TCSubpathRoute RoutePart, TrainRouted thisTrain, Int32 clearNextSignals, Boolean requestIsPropagated, SignalObject lastSignal) in e:\Documents\Coding\Jenkins\jobs\Open Rails\workspace\Source\RunActivity\Signals\Signals.cs:line 9175
   at ORTS.SignalObject.propagateRequest() in e:\Documents\Coding\Jenkins\jobs\Open Rails\workspace\Source\RunActivity\Signals\Signals.cs:line 9465
   at ORTS.SignalObject.Update() in e:\Documents\Coding\Jenkins\jobs\Open Rails\workspace\Source\RunActivity\Signals\Signals.cs:line 8620
   at ORTS.Signals.Update(Boolean preUpdate) in e:\Documents\Coding\Jenkins\jobs\Open Rails\workspace\Source\RunActivity\Signals\Signals.cs:line 546
   at ORTS.Simulator.Update(Single elapsedClockSeconds) in e:\Documents\Coding\Jenkins\jobs\Open Rails\workspace\Source\RunActivity\Simulator\Simulator.cs:line 500
   at ORTS.Viewer3D.Viewer.Update(RenderFrame frame, Single elapsedRealTime) in e:\Documents\Coding\Jenkins\jobs\Open Rails\workspace\Source\RunActivity\Viewer3D\Viewer.cs:line 534
   at ORTS.Processes.GameStateViewer3D.Update(RenderFrame frame, Double totalRealSeconds) in e:\Documents\Coding\Jenkins\jobs\Open Rails\workspace\Source\RunActivity\Processes\GameStateViewer3D.cs:line 122
   at ORTS.Processes.UpdaterProcess.Update() in e:\Documents\Coding\Jenkins\jobs\Open Rails\workspace\Source\RunActivity\Processes\UpdaterProcess.cs:line 128
   at ORTS.Processes.UpdaterProcess.DoUpdate() in e:\Documents\Coding\Jenkins\jobs\Open Rails\workspace\Source\RunActivity\Processes\UpdaterProcess.cs:line 108
   at ORTS.Processes.UpdaterProcess.UpdaterThread() in e:\Documents\Coding\Jenkins\jobs\Open Rails\workspace\Source\RunActivity\Processes\UpdaterProcess.cs:line 74
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

This happens with train 2117 on same route and timetable shortly after the second passenger stop, when passing a signal. Only happens if the train is driven by player.

Edit2: funny... this error happens even if the player not following any AI train. The only trains around are going to the opposite direction, on the other track.
Here are two a saves (revision 2811):  save.zip (4.97MB)
Number of downloads: 187 shortly after loading them the crash will happen.

[gpz]

Disc, have you restarted the game from the beginning with the latest revision? The database is built up at game start, so if you reload a game saved with the older revision that contained the affected code, then the error will appear again, because the wrong database is just reloaded from disk in this case.

Edit: Yes it happens to me too. The startup exception has gone, but the in-game remained. Looks like the family of this bug is quite large. :)

[gpz]

Logging again the usual nextElement in SearchPassingPaths of train with trainNumber 0 I can see the following values respectively: 4, -1, 42, 72, 98, 132, 180, 209.
So the first wrong -1 has gone at the beginning, but the second one remained. The remaining of the real path is following the 2nd -1, as before. The usual workaround still works: commenting out the "break".

[disc]

Ok, but commenting out the break is not the best solution, and that won't be in releases :crazy:
What i don't understand is why this error happens even if i remove all passing paths at that area?

[gpz]

Yes, I'm writing that commenting-out thing to Rob only, so that he knows where to start searching for the bug. :crazy:
Probably removing passing paths is of no help because the bug is no more with wrong passing path detection, it must be something close but different thing.

[disc]

But why this isn't happen if the train is driven by AI? That's an X-file for me.

[roeter]

Further corrections made to the search for matching paths logic (version 2818), which at least removes one further member of this rather obstinate family of bugs.

@disc : the way this error worked was quite complex. The problem was not at the location where the crash occured, nor was it fully caused by the train which caused the crash. And the sequence in which the trains were processed also affected the outcome.
The problem was basically that at least one train had a path which partially overlapped an alternative path as defined for another train.

Regards,
Rob Roeterdink