[roeter]

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

[Csantucci]

Hi Rob,
thank you for the big work. From my viewpoint it is the biggest functional improvement in OR since some month. I have only a comment about following point:

roeter, on 24 January 2014 - 10:01 AM, said:

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.

Regards,
Rob Roeterdink

This restricts quite much the use of the option for passenger AI trains. As far as I understand, this limitation is due to the fact that there is no station indication within the train path.
However, as every platform is linked to a station, and as this is already successfully used in the "F8" pop-up window, I ask if it could not be possible for ORTS to recognize that the train stops at another platform of the same station. I would suppose it is possible, even if it for sure requires some implementation. And so your useful feature could also be fully used for passenger trains.

[roeter]

The present situation is only an 'interim' solution.
Once we can manage the definition of passing paths per location as is intended, such options will be included.
The changes to the code required for this are quite extensive, though.
For the player train, station stops are presently handled by the 'activity' processing which takes it's information directly from the activity definition.
That logic will have to be transferred to the 'train' processing with the information taken from both the activity and path definitions.
For AI trains station stops are allready handled by the 'train' control, but required changes here are also still quite considerable. The present logic inserts station stops based on the 'traffic' information, using the indicated platform location as reference data to find the part of the path where the stop is located. This process has to be 'reversed', as now the path data must be used to check if that part of the path is a stop location. Furthermore, the required exact stop position for the train for each platform (based on platform and train length) is presently calculated at the start of a session for all stops. As a train may take paths using different platforms which may have different lengths, that too will have to change.
So, in all it involves quite a bit more work than just checking station names.

Regards,
Rob Roeterdink

[railguy]

Thank you, Rob, for making this available. I plan to test it with an activity as soon as I have time to design one specifically for this option on a single track route. If it works as you describe, it should eliminate a lot of issues in designing paths, especially for AI traffic, as well as making meets have the ability to be more "dynamic"--that is, able to be adjusted by the AI dispatcher as an activity progresses.

As for passenger trains with station stops, I don't see this as a big issue. Typically a dispatcher will have the passenger train hold the track where the platform is located (obviously platforms on multiple tracks will complicate the issue). In single track platform situation, having the passenger train hold that track by not giving it a passing path makes sense. Possibly, giving the opposing AI traffic a passing path in that situation would work to make a meet possible there?

[Csantucci]

railguy, passenger traffic here in Europe is different. It is quite normal that passenger trains stop in a track different from the scheduled one because of meets or because of occupied tracks. So here it is an issue. And remember that train stops are used also to provide the train a precise schedule. If however train stops are skipped, the schedule is gone.

[markus_GE]

Csantucci, on 25 January 2014 - 09:46 AM, said:

It is quite normal that passenger trains stop in a track different from the scheduled one because of meets or because of occupied tracks. So here it is an issue. And remember that train stops are used also to provide the train a precise schedule. If however train stops are skipped, the schedule is gone.

Though I have never seen your first point happen here in Austria, it is quite possible passenger train stops are handled that way in other parts of the world.

What I find most important, however, is the possibility of OpR to also run Freight trains to a schedule. It greatly reduces the efforts one has to make to have trains run "to the minute". The new passing path processing would once more greatly reduce the efforts of activity creation, since one would not have to bother anymore where trains will meet. If, however, passing paths can´t be defined where there are stations to provide for the scheduling of trains, things get complicated again. So, how will that be handled with this new passing path processing?

Cheers, Markus

[railguy]

Csantucci, on 25 January 2014 - 09:46 AM, said:

railguy, passenger traffic here in Europe is different. It is quite normal that passenger trains stop in a track different from the scheduled one because of meets or because of occupied tracks. So here it is an issue. And remember that train stops are used also to provide the train a precise schedule. If however train stops are skipped, the schedule is gone.

I would think, in that situation, the activity designer could have the passenger hold the track that is designated for its stop and have the AI train path(s) shunted to another track. That would solve the issue. That would also be prototypical for most timetable passenger operations (well, except for Amtrak in the good ol' USA) in that passenger trains are usually given timetable superiority over other traffic--that traffic has to get out of the passenger train's way. If one is trying to choreograph meets between opposing passenger trains, then things get a little dicier. Still, with a timetable passenger operation, the activity designer should know where the passenger trains should meet and set their paths accordingly. Under timetable operation using train orders, an opposing train must respect the passenger train's schedule and clear for it--even if the passenger train is known to be running late. Nor can the passenger train leave a scheduled stop ahead of its scheduled departure, unless it secures permission from the Dispatcher to do so. The opposing train can't advance against the passenger train's schedule (if, say, the passenger train is delayed) unless the Dispatcher issues train orders to BOTH trains authorizing it. Under track warrant control (TWC) or centralized traffic control (CTC), things do work differently.

I think that the key is not giving the passenger train a passing path where it absolutely has to hold the track designated in its own path. Maybe Rob can answer what happens in a situation where the player train has no passing path designated for it, but the AI train does. From what I read in his description, the AI train would have to hold its path when meeting the player train if the player train has no passing path designated in its path. If I understand Rob's description, designating passing paths for AI traffic would have little effect on the activity, except when opposing AI trains are meeting each other--then they could utilize that option. Am I correct about that, Rob?

I think that main emphasis in the new code was to allow more "dynamic" handling of meets between trains on single track lines. At some point, I still think it would be beneficial for the activity designer to be able to give each train in an activity a "superiority code", say 0 to 100, that would determine how each train would be choreographed in the activity. If no code was designated for the trains in the activity, the AI dispatcher would designate meets according to what makes the most "sense" based on the trains' paths--pretty much what happens now. But if the superiority codes were different, then the AI Dispatcher would choreograph meets to give the superior train rights over inferior trains. For example, a train with a 100 superiority code would have rights over everything on the railroad (except another train with a 100 superiority code) and opposing traffic and slower traffic traveling in the player's train's direction would have to get out of the way for it. At the other end of the scale, a train with a superiority code of 0 would have to get out of the way for any train that had a higher superiority code. The dispatch program could mathematically evaluate the superiority of trains as the activity progressed in a similar way to how it has to evaluate train length for sidings in the code that Rob just released. In real world dispatching, this "choreography" of superior vs. inferior traffic goes on all the time. For example (using Union Pacific slang), fast long-distance trains ("shooters") are given priority over slower manifest or local trains ("pickers") as both traverse the railroad. So, the dispatcher givers priority to shooters and makes pickers get out the way for the higher priority traffic. The logic in the CAD (computer-aided-dispatching) system helps the Dispatcher do this, but he/she can also override it when necessary.

Anyway, all fun stuff. Thanks again to Rob for his efforts.

One unrelated question: If I go through the brain damage of downloading the updated X1955 or greater versions from the SVN server, is there a RunLAA version included or can I use the one in X1954? I generally have problems running some of my complex activities unless I'm running the LAA version. I apologize for my ignorance about this--I seldom use the SVN server and usually just wait for the weekly release, but I'm chomping at the bit to try this new code out.

[markus_GE]

railguy, on 25 January 2014 - 10:41 AM, said:

I seldom use the SVN server and usually just wait for the weekly release, but I'm chomping at the bit to try this new code out.

You could simply use James` site, where he also has automatic builds of OpR done everytime new code is submitted: http://james-ross.co...jects/or/builds

Cheers, markus

[railguy]

^Awesome. Thanks.

[roeter]

As ever with signalling - the problem is that the way things are run differs greatly between countries and perhaps even within countries.
What happens in OR depends on what train is what and how things are defined.
If the player runs a passenger train, no pathing paths should be defined through stations where the train is booked to stop. Passing paths can be defined for oncoming AI freight trains - and those trains will, in that situation, take a path different from that of the player train. The program always checks which paths are available to either train and will ensure there is a proper path for both - if not, trains cannot pass at that location.
Oncoming AI passenger trains should also not be given passing paths through locations where they are booked to stop - one can either define a different path as for the player train, or one can accept that passenger trains cannot pass at that location.
If the player runs a freight train, things get more complicated. If passing paths are defined for the player train, any oncoming passenger train may also be routed on these paths and thus miss their booked stop.
To allow passenger trains to take alternative paths and still properly keep to their booked stop will probably one day be implemented - but it will take time. What I could perhaps do at short notice is, at least for AI passenger trains, to check for any possible path if it would take that train away from a booked platform stop and then invalidate that option. It would mean that certain locations are not available for passing, but it would keep AI passenger trains to their timetable.

As for passing paths specifically defined for AI trains : if these are the same as the main path or defined passing path for the player train they have no effect. If these are different though, these paths can be used by that train thus creating even more options. Ofcourse, the severe limitations on creating a passing path in the MSTS editor (it must be a straight path from one end to the other) means that there are very few locations where multiple passing paths can be defined in this way. But in one of my tests I did have such a location and I created a proper triple meet.

And an unrelated answer : you could check James Ross' site. I think he generates both normal and LAA versions.

Regards,
Rob Roeterdink