Problem with Amtrak #3 Activity on "ATSF La Junta & Pueblo Subs" route

[OmenRotcod]

I wonder if anyone has tried to run the "Amtrak #3" Activity on the "ATSF La Junta & Pueblo Subs" route and found that it crashes immediately you start?

This is the error message in the log file:—

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(T Key key)
at Orts.Simulation.Signalling.DeadlockInfo.GetEndSect ion(Train thisTrain) in C:\Jenkins\jobs\Open Rails Stable\workspace\Source\Orts.Simulation\Simulation \Signalling\Signals.cs:line 14865
at Orts.Simulation.Signalling.DeadlockInfo.CheckDeadl ockPathAvailability(TrackCircuitSection startSection, Train thisTrain) in C:\Jenkins\jobs\Open Rails Stable\workspace\Source\Orts.Simulation\Simulation \Signalling\Signals.cs:line 14376
at Orts.Simulation.Signalling.TrackCircuitSection.IsA vailable(TrainRouted thisTrain) in C:\Jenkins\jobs\Open Rails Stable\workspace\Source\Orts.Simulation\Simulation \Signalling\Signals.cs:line 6035
at Orts.Simulation.Signalling.TrackCircuitSection.Can PlaceTrain(Train thisTrain, Single offset, Single trainLength) in C:\Jenkins\jobs\Open Rails Stable\workspace\Source\Orts.Simulation\Simulation \Signalling\Signals.cs:line 7412
at Orts.Simulation.Physics.Train.CalculateInitialTrai nPosition(Boolean& trackClear) in C:\Jenkins\jobs\Open Rails Stable\workspace\Source\Orts.Simulation\Simulation \Physics\Train.cs:line 5901
at Orts.Simulation.AIs.AI.AddToWorld(AITrain thisTrain) in C:\Jenkins\jobs\Open Rails Stable\workspace\Source\Orts.Simulation\Simulation \AIs\AI.cs:line 1009
at Orts.Simulation.AIs.AI.AIUpdate(Single elapsedClockSeconds, Boolean preUpdate) in C:\Jenkins\jobs\Open Rails Stable\workspace\Source\Orts.Simulation\Simulation \AIs\AI.cs:line 663
at Orts.Simulation.Simulator.Update(Single elapsedClockSeconds) in C:\Jenkins\jobs\Open Rails Stable\workspace\Source\Orts.Simulation\Simulation \Simulator.cs:line 878
at Orts.Viewer3D.Viewer.Update(RenderFrame frame, Single elapsedRealTime) in C:\Jenkins\jobs\Open Rails Stable\workspace\Source\RunActivity\Viewer3D\Viewe r.cs:line 746
at Orts.Viewer3D.Processes.UpdaterProcess.Update() in C:\Jenkins\jobs\Open Rails Stable\workspace\Source\RunActivity\Viewer3D\Proce sses\UpdaterProcess.cs:line 132
at Orts.Viewer3D.Processes.UpdaterProcess.DoUpdate() in C:\Jenkins\jobs\Open Rails Stable\workspace\Source\RunActivity\Viewer3D\Proce sses\UpdaterProcess.cs:line 108
at Orts.Viewer3D.Processes.UpdaterProcess.UpdaterThre ad() in C:\Jenkins\jobs\Open Rails Stable\workspace\Source\RunActivity\Viewer3D\Proce sses\UpdaterProcess.cs:line 74
at System.Threading.ExecutionContext.RunInternal(Exec utionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionCon text executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionCon text executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

However, just above this message the following warning appears:—

Warning: Multiple passing paths at the same location, without common branch out, or return switch. Check the passing paths for Train name: W-HUNW (number: 166), and other train's paths, which have passing paths at the same locations

So, there appears to be a conflict with other paths. I haven't had time to examine all the paths to discover where the passing paths over-run one another.

However, removing the Service "W-HUNW" allows the Activity to start. I can't say whether that is the only problem with the Activity since I haven't run it all the way through. Maybe it ran okay in MSTS? At any rate, it doesn't seem to be a bug in OpenRails which perhaps considers the potential conflict a "game-ender".


David

[wmuzeke]

There is a patch for this activity, which might resolve the issue. I ran the activity a while ago and remembering that it worked okay.

[OmenRotcod]

Thanks for pointing that out about the patch. I had missed it. It certainly looks like the offending path, so I'm going to put it back into the Activity and re-run.

David

[OmenRotcod]

I was hoping that installing the patch would enable the Activity to run, but it comes up with the same error. Barry LeBoeuf, the author, tested and corrected the path using ORTS version 1.3.1.4328. I am using version 1.51 (stable).

I created a new path to replace "xhutnew.pat" (with no passing paths) but that didn't work either; ORTS came up with the same warning/error.

As I get the time I will check further on this and see what I can do.

Does anyone have any thoughts on this problem?

David

[amtrak115]

I'll go back and look at it....I believe someone else had a similar problem when I first released that activity....I'll have to go back and check my notes to see "why" I put out the patch...

Barry

[OmenRotcod]

Thank you Barry.

I like the way the business coaches get coupled on to the end of the train. The GP30 sure gets out of there in a hurry, doesn't it? 😊

David

[R. Steele]

I don't have the route or activity, but looking over the thread and the log error messages....my inclination would be to check out any passing paths on the path that Service W-HUNWN uses. Make sure they aren't in yard areas or other areas where the reconnection could be confusing to the logic. Check closely for broken nodes, sometimes the path may run okay, but there could be a broken node on a passing path segment.

[OmenRotcod]

The TrackViewer program doesn't indicate any errors and I can't see any myself. As I said, I created a new route from the same start and end points and without any passing paths but the same error came up. I even gave the new path a new name and used that in the W-HUNW service, but it still came up with the same error message. Perhaps one of the other paths interferes?
Will have to take a look at them one-by-one - remove them all except W-HUNW service, add back the services one at a time and see what happens.

Yards could be a problem, but I've noticed that if an AI train goes through a siding with a loose consist in it, the AI will just couple up the the LC and keep going.

David

[wmuzeke]

Check your Open Rails settings - under Options-->Simulation. Under Activity Options on the right, make sure that Location-linked passing path processing is unchecked. I was able to replicate your error when I checked this box. It runs okay for me when it's unchecked.

[OmenRotcod]

Okay, that works. Thank you.

I'm curious about why that happens though. Would be interested in an explanation because that is the first time I have encountered that situation.

David

[amtrak115]

David, having checked my notes...this (unchecking Location-linked passing path processing) corrected the problem. I could never figure out how Location-linked passing path processing worked to enable the activity to work. If I'm not mistaken this was like the 4 segment of my activity and I had not run into any issues before this one. I thought, it had something to do with the yard but again I could never figure it out. Unchecking Location-linked passing path processing seemed to fix the issue. I also started providing a list of settings in the distribution zip file so that users knew how and what settings I was using when defining the activity.

"I like the way the business coaches get coupled on to the end of the train. The GP30 sure gets out of there in a hurry, doesn't it? 😊" This was the first time I tried to do this in an activity...so it scooting out of the way was not planned but it just happened....

hope you enjoy the ride....

later

Barry (aka amtrak115)

[R. Steele]

Would be interested in an explanation because that is the first time I have encountered that situation

Rob Roeterdink ( roeter ) introduced new passing path logic for OR in January 2014. This is the opening post of the thread. A link to the thread is at the bottom of my post.

Release X1955 introduces new "passing path" definition and processing.
Passing paths can be used to allow trains to pass one another on single track routes. The required passing paths are defined per train path in the MSTS Activity Editor.

This present version is an 'intermediate' stage leading to complete new processing. The data structure and processing have allready been prepared for the next stage, when 'alternative paths' (so not just a single passing path but multiple paths through a certain area) will be defined per location, and no longer per train.

This version, however, is still based on the MSTS activity and path definition, and therefor still based on definition of alternative paths per train.

The setup of this version is as detailed below :

• Passing paths defined for the player train are available to all trains - in both directions.
  The 'through' path of the player train is taken to be the "main" path through that location.
• Each train can have definitions for additional passing paths, these will be available to that train only.
  Note that this implies that there can be more than one passing path per location.
• When possible passing locations are determined for each pair of trains, the train lengths are taken into consideration.
  A location is only 'valid' as a passing location if at least one of the trains fits into the shortest of the available passing paths.
• The order in which passing paths are selected :
  • If no train is approaching from the opposite direction (through route) :
    • Train's own path.
    • "Main" path.
    • Any alternative path.
  • If train is to pass another train approaching from the opposite direction (passing route) :
    • Train's own path (if not the same as "main" path).
    • Alternative path.
    • "Main" path.
    However, in the situation where the train does not fit on all paths, for the first train to claim a path through the area, preference is given to the paths where the train will fit (if any).

The setting of the 'deadlock' trap (the logic which prevents trains from getting on a single track from both directions) has also been changed.
In the 'old' version, the trap was 'sprung' as a train claimed it's path through a possible passing area.
However, this often lead to quite early blocking of trains in opposite direction.
In this version the trap is 'sprung' when a train actually claims it's path in the single track section itself.
One slight flaw in this logic is that this can lead to the train which is to wait will be allocated to the "main" path, while the train which can pass is directed over the "loop". This can happen when two trains approach a single track section at almost the same time, each one claiming it's path through the passing areas at either end before the deadlock trap is actually sprung.

One word of warning : if a passing location contains platforms and there are passenger trains which are booked to stop there, passing paths should not be used for that location. A passenger train directed onto an 'alternative' path will miss it's station stop and, for AI trains, it means it will also miss all further station stops as the missed stop is not removed from the list, and further station stops are therefor not processed.

This new logic can lead to considerable changes in the behaviour of trains on single track routes - and behaviour that is certainly significantly different from that in MSTS.
Therefor, this new behaviour is introduced as 'experimental option' - the option can be set in "options", tab "experimental"; the option is named "Use location linked Passing Path processing".

Regards,
Rob Roeterdink

Original Discussion at Elvas Tower >>> https://www.elvastower.com/forums/in...th-processing/

[OmenRotcod]

Thank you, Gerry, that's quite an explanation and is going to take some thinking about.

So, it's the existence of a passenger service in the Activity being discussed that is the source of the impasse if the new logic is employed? There must be logic in ORTS to detect this situation and raise a warning?

Will we see the "next stage" as mentioned in the second paragraph soon? How will it affect existing Activities? The discussion at Elvas Tower is raising all kinds of issue. Are dark routes also dealt with in this way?

I'm not demanding that you answer these questions, Gerry 🙂; they are just some of the questions running through my mind and I will try to keep following the discussion at Elvas Tower.

Nevertheless, any enlightenment anyone can throw on this subject would be welcome. 😊

David

[OmenRotcod]

As you mentioned, Gerry, these posts were from 2014. Makes my thoughts on the subject seem a bit off the mark. 😕

Do you know if there has been any further development?

David

[R. Steele]

Do you know if there has been any further development?

Afaik, development is complete. For all routes/activities I keep the "location linked passing path" option checked --- because the logic is superior to MSTS and provides more prototypical behavior. For those MSTS activities where it causes problems with AI traffic I fix or repair the paths as needed.

OF course for those who don't wish to find more work for themselves, it's good the see if unchecking this option will solve their problems....with this activity it appears this is the case.

The newer OR routes - SP Shasta for instance --- tells the user to check this option ( location linked passing path ) for the activities to work correctly.

The above quoted thread was to give you historical context and also if you delved into the whole thread you would see the entire development history.

I won't presume to explain the feature or how it works....best person for that is Rob.