Paths: Best practices

[bprice]

I have been reading some of the path questions concerning the Cima route and I have a question about the best practices for creating paths.

I have used the passing path option in many cases but I find that often the player train keeps to the main track, even when the player train arrives at the meet a long time before the arrival of the AI. Other times the player train gets directed to the siding when the AI train is stopped on the main. It seems that these should be opposite. The first train to arrive should go to the siding and the other train would be cleared to the mainline.

With OR, it is better to use passing paths or to simply construct the main path and let OR direct the traffic?

I frequently use timetable mode. Is there a difference in how those paths are handled as opposed to an activity?

Thanks,

Basil

[roeter]

It's not really the first train to arrive which is send to the loop, but the first train to request a path through that area.
If there are significant differences in distances from the preceding signals to this loop, or in allowed speed on the approach sections, it may well be that the first train to request a path is not the first train to arrive. As yet there is no 'prediction' on which train will arrive first.

There are some small differences in processing between activity and timetable mode but these don't really show up if you just have two trains set to pass each other.

Regards,
Rob Roeterdink

[geepster775]

Both trains involved in the meet must be pathed to stay on the main. That differs from the MSTS era of having to path one of the trains into the siding on purpose.

If you still employ the MSTS way, and the player was deliberately pathed into the siding at a particular meet point, should the player be the first arrival, Open Rails will properly "diverge" it from the pre-established path to take the siding and keep the player on the main instead, resulting in the meet appearing 'backwards'.

[bprice]

Thanks, That Bakes sense.

[peterman]

Both trains involved in the meet must be pathed to stay on the main. That differs from the MSTS era of having to path one of the trains into the siding on purpose.

If you still employ the MSTS way, and the player was deliberately pathed into the siding at a particular meet point, should the player be the first arrival, Open Rails will properly "diverge" it from the pre-established path to take the siding and keep the player on the main instead, resulting in the meet appearing 'backwards'.

I have to politely disagree to a certain extent on this one. The only time that I can recall where you had to purposely diverge one of the trains into the siding was when there was a node between the start and end of the passing path. The node prevents the passing path from becoming complete and you ended up with the "Mexican" standoff. Funny enough, it seems that if there is more than one node... the passing path works fine. Otherwise, the trains would pass each other as per normal when passing paths without a node were used. Just my own observations over the last 16 years.

Something that I would like to see in Open Rails when there is a meet... is a code added to put the shorter train into the siding ( I'm sure we've all run into the scenario where a 70 unit coal train has to go into the siding while a single "fricking" Budd car is sitting on the main ), something like :

If Train 'A' 10% > than Train 'B' hold main, otherwise take siding.

Or something along those lines... might eliminate the need for passing paths altogether.

Just a thought...
Peter

[geepster775]

Something that I would like to see in Open Rails when there is a meet... is a code added to put the shorter train into the siding

I can't agree with that at all. It is somewhat over-stepping to think everyone else agrees with your principle that short trains always go in instead of longer ones to sufficiently justify that ever becoming a hard-coded reality. The way it is now, even with the 'first generation' logic, you can make a meet perform just about anyway you want it to, if you know how to.

I created this activity as a proof of concept. I used the MLT Cascade route, since it is a rare type of route that features a 60 mph mainline and 10 mph sidings. These 10 mph sidings can really throw a wrinkle at Open Rails achieving prototypical looking meets, but the wrinkles can all be ironed out, even with the Open Rails code we have today.

The northbound train is a double stack hotshot. The southbound is a typical land barge lumber freight. Traditional logic executed by Open Rails would place the meet at Fuego, requiring the hotshot, as the first arrival, to enter the 10 MPH siding. But any heads-up dispatcher will push the meet farther north, making the slop freight trundle into the low speed siding at Lenz instead. The speed differential between 60 mph and 10 mph allows the hotshot to tear up 90% of the railroad between Fuego and Lenz by the time the slop freight stops at the south end of the siding. This is how a forward thinking dispatcher doesn't delay the hotshot. This isn't a 'natural' meet execution in Open Rails by any means, it's a 'forced' situation. But at least it's forcible, as is, right now.







Siding train down to 10 mph




Hotshot finally passing Fuego

[geepster775]

Southbound halfway into Lenz.







By the time the southbound transits the entire slow speed siding and stops, the hotshot is only one signal block away.







The hotshot never breaks from full track speed.

[peterman]

I can't agree with that at all. It is somewhat over-stepping to think everyone else agrees with your principle that short trains always go in instead of longer ones to sufficiently justify that ever becoming a hard-coded reality. The way it is now, even with the 'first generation' logic, you can make a meet perform just about anyway you want it to, if you know how to.

I created this activity as a proof of concept. I used the MLT Cascade route, since it is a rare type of route that features a 60 mph mainline and 10 mph sidings. These 10 mph sidings can really throw a wrinkle at Open Rails achieving prototypical looking meets, but the wrinkles can all be ironed out, even with the Open Rails code we have today.

The northbound train is a double stack hotshot. The southbound is a typical land barge lumber freight. Traditional logic executed by Open Rails would place the meet at Fuego, requiring the hotshot, as the first arrival, to enter the 10 MPH siding. But any heads-up dispatcher will push the meet farther north, making the slop freight trundle into the low speed siding at Lenz instead. The speed differential between 60 mph and 10 mph allows the hotshot to tear up 90% of the railroad between Fuego and Lenz by the time the slop freight stops at the south end of the siding. This is how a forward thinking dispatcher doesn't delay the hotshot. This isn't a 'natural' meet execution in Open Rails by any means, it's a 'forced' situation. But at least it's forcible, as is, right now.

I'm not going to get into a spitting contest with you, nor will I say anything derogatory... but I will question this statement : "Traditional logic executed by Open Rails would place the meet at Fuego, requiring the hotshot, as the first arrival, to enter the 10 MPH siding."

Have a nice day!