[R H Steele]

I was running an explore path (north to south, complete length of route) on the CSX Western and Atlantic Sub and I decided to give it a little more interest and added a traffic path running the opposite direction (also the whole length of route). I used 6 different Traffic trains, same path for each, starting about 20 to 30 minutes apart. Did not plan anything and I did not know how it would work. The route is mostly single track with some long sidings and yards. It worked fine. I had to stop in a yard at Junta, for two AI's to move through, got the green, then about six miles past the yard got a red and had to hold for an AI passenger. Long story short -- Open Rails did a fine job of running the signals and deciding which train (AI or Player) to hold or give the green to. I don't quite understand how it works yet, there is the "3 signal" rule in Rich Garbers activity manual, and I assume some preference is given to position on the route vs signals and available points at which to stop. It was fun, and much more interesting than running the route with no traffic. Just wanted say thanks to the OR team. Nice work fellas. Cheers, rhs (aka gerry)

[eric from trainsim]

Maybe I'm missing something, but how do you enable traffic in an Explore mode?

[R H Steele]

 eolesen, on 22 November 2013 - 10:06 PM, said:

Maybe I'm missing something, but how do you enable traffic in an Explore mode?

You're not missing anything, I wasn't clear enough. I just laid out a path for the player from North to South on the whole route using the mainline all the way from one end to the other and called it "explore". Then I laid out a path in the opposite direction and called it traffic. The traffic path made use of sidings and yards where possible to give the traffic trains places to stop. The whole line except for sidings and yards is single track. Then I made 6 traffic trains and started the first the same time as the player, and others starting about 20 minutes apart. Nothing timed or planned. I then ran this "explore activity" and Open Rails handled all the signals. I expected to go through on the green all the way, but was stopped to let two traffic trains pass in a yard, and once more to let a traffic train pass. The other times the traffic trains had the red while I got the green. No problems running the path and I had lots of traffic coming in the opposite direction. I'm assuming that if I changed the timing and amount of traffic trains I would get a different result. I don't know if it was possible to this in MSTS, my experience is primarily with Open Rails. In this case it was as if there was a dispatcher or CTC controlling the whole run. I didn't get stuck, no cornfields, or strange behavior, just a straight run with correct signaling. I was careful to keep speed at optimum and obey all posted speeds.

Perhaps, if this is possible (the OR team would know) it would be cool if you could lay out a player path, then just create traffic start times + start-stop points, no traffic paths and run the player train letting Open Rails move the traffic trains and run the signalling. Open Rails would have to know the whole track layout of the route to do this, OR would run the traffic based upon the players path, speed, and the route layout.... is that possible? Player would have to watch signals and keep to speed limits to run this "activity" which is not really planned at all. Maybe it's possible now and I just don't realize it. (I don't think so -- I think everything is still based on following a predetermined path).

Could Open Rails work with this information only:
Player Start Time, Path and Speed
Traffic start and stop points - path indeterminate - Open Rails could use any portion of route to get traffic from A to B, managing switching and signaling for all trains, including player.
Traffic start times and speed (speed determined by route specs or input)

Cheers, rhs (aka gerry)

[eric from trainsim]

OK, I thought there was a new feature to invoke traffic paths on Explore mode... which would indeed be cool.

[markus_GE]

@ eolesen: YOu can´t really enable traffic in a nexplore mode. All RHS did was created an activity very similar to an explore mode, jut running straight along the route, with some AI traffic in opposite direction. Not a real explore mode, but also no real "set up" activity.

If you have Trainstore, there is also an Option to use traffic from an existing activity for your "explore mode" (in the end, this will also create an activity, but I´m not sure about how the plaer path is set up... have not yet tried the Feature, just read about it).

Cheers, Markus

[PA1930]

Yes, TrainStore created an "Explorer Activity" and the path was stil the one you'd choose on the menu. The only thing Trainstore did was to add those loose consists you might have set on some activity. It also said that you could add AI trains to it but as far as I recall, no AI trains we added anyways.

[railguy]

 R H Steele, on 23 November 2013 - 12:50 AM, said:

You're not missing anything, I wasn't clear enough. I just laid out a path for the player from North to South on the whole route using the mainline all the way from one end to the other and called it "explore". Then I laid out a path in the opposite direction and called it traffic. The traffic path made use of sidings and yards where possible to give the traffic trains places to stop. The whole line except for sidings and yards is single track. Then I made 6 traffic trains and started the first the same time as the player, and others starting about 20 minutes apart. Nothing timed or planned. I then ran this "explore activity" and Open Rails handled all the signals. I expected to go through on the green all the way, but was stopped to let two traffic trains pass in a yard, and once more to let a traffic train pass. The other times the traffic trains had the red while I got the green. No problems running the path and I had lots of traffic coming in the opposite direction. I'm assuming that if I changed the timing and amount of traffic trains I would get a different result. I don't know if it was possible to this in MSTS, my experience is primarily with Open Rails. In this case it was as if there was a dispatcher or CTC controlling the whole run. I didn't get stuck, no cornfields, or strange behavior, just a straight run with correct signaling. I was careful to keep speed at optimum and obey all posted speeds.

Some questions: When you set up the paths, did you just run straight-line paths for both trains, with both running on the main? And, for one train or both, did you set up passing paths with or without optional path sections? While the passing paths and optional path sections are a necessity for many MSTS activities, they don't seem necessary for some OR activities and may even cause problems.

Thanks.

[disc]

I've never heard that optional paths are used by msts, but it is used by OR, else from where should the dispatcher know where it can send the trains?

[roeter]

 railguy, on 25 November 2013 - 03:39 PM, said:

Some questions: When you set up the paths, did you just run straight-line paths for both trains, with both running on the main? And, for one train or both, did you set up passing paths with or without optional path sections? While the passing paths and optional path sections are a necessity for many MSTS activities, they don't seem necessary for some OR activities and may even cause problems.

Thanks.

There are two ways of regulating traffic on single-track routes.
One is to make sure trains in different directions always use different paths through passing loops, e.g. all trains always keep to the right. This does mean, however, that trains often will be run through low-speed loops when not actually passing another train.
The other way is to define the main paths always straight on for train in both directions, but define 'passing paths', again for both directions. In this situation, trains will be run on the main route as often as possible, and the system will try to put the train which is to wait for an opposite train into the low-speed loop (the first train to 'claim' a path for that passing loop will be put into the loop - but if that train has a long way to go or is running on a low-speed section, it may happen that the train from the other direction actually arrives first).

The regulation of traffic on these single line sections is not done through the signals as such, but by a special process named 'deadlock prevention'. This process analyses the full path of a train the moment this train is started (or restarted after a waiting point or reversal), and searches for all possible sections of track where there is a conflict with a train running in opposite direction. Locations where these sections begin and end are determined (these are the 'deadlock traps'), taking into account the defined 'passing paths', if any. When a train passes such a 'deadlock trap', this trap is 'sprung', and the opposite trains for which this trap was set will be stopped at the opposite end of the related section. As these traps are defined for each pair of conflicting trains, trains can be stopped in different places according to the defined paths and possible passing places. When a train passes the 'far end' of such 'traps', the traps are removed.
Additional checks are performed when trains approach a deadlock trap, e.g. when alternatives paths are defined but this track is allready occupied, a second train from the same direction will be stopped on the main line before the passing loop, so as to keep one track clear for the train from the opposite direction.
Also, when a train is stopped for a sprung 'deadlock trap', it will spring it's own traps to make sure it will have it's proper turn over the single track section and is not held 'forever' as trains from the other direction stream passed, always getting a clear path (this can happen in MSTS if trains are running fairly close together).

Because the analyses is performed for the full path when the train is started, this process is not performed for 'free roam' trains (explorer mode or manual mode), as the process would have to be repeated each time the path is changed, either by reversing or by setting a manual switch. Combining manual mode and AI trains on single track sections can therefor lead to deadlocks.
For that reason, 'free roaming' AI trains can not be implemented either.

It certainly took some effort to get it all sorted properly but, admittedly, combined with 'passing paths' the process does work pretty well - better than expected, actually.

Regards,
Rob Roeterdink

[railguy]

^I assume, then, that a player train which is taken out of "automatic" mode and put into "manual mode"--say, to do some switching or set out or pick up cars--could screw up the dispatching "plan" and lead to deadlocks.

Also, when defining the passing paths for OR use, is it necessary to highlight and selects as "optional path sections" the sections of track immediately before, after, and inside the passing path section--or just make the siding a passing path for the player and/or the AI train(s)?

One of the ways that I thought a simulator dispatching system could be set up is for the activity designer to assign each train a numerical value based on that train's superiority by right, class, and/or direction. Then, as each train approached a passing path section, the "dispatcher" would mathematically evaluate which train would be superior at that point and choreograph the meet accordingly. I even thought about the idea of the activity designer being able to alter the trains numeric "seniority value" somewhere in the activity, so that, for example, a "hot" intermodal could run fine for the first part of an activity, then start "getting stabbed" by other traffic in the later part. Or, that a train could have its numeric priority change over time--for example, a train being given a zero priority for a couple of hours on a siding, allowing traffic from both directions to have superiority over it. Just like real railroading can happen.

Thanks.