Open Rails does not follow player path file

[csantucci]

I post here part of paragraph 10.5 of the OR manual, that may be of interest (I haven't written this part, neither have I implemented this functions):
"
Further rules for the use of alternative paths :
 Trains from both direction must have the same main path through the area.
 If only one train has an alternative path defined, and the trains are to pass, that train will always use the alternative path; the other train will always use the main path regardless of which train arrives first.
 If both trains have an alternative path defined, and the trains are to pass, the first train to clear its route will take the alternative path. Note that this need not always be the first train to arrive - it could be that the train which first clears its path takes much longer to actually get to the passing loop."

Another sentence that is not clear to me is contained in paragraph 10.1.1 of the manual:
"
If the player path requires a switch to be aligned both ways, the alignment that is the last on the path is used. If an AI train crosses the player path before the player train gets there, the AI train will leave the switches aligned for the main route (the default setting for most switches)
"


I was able to reproduce the Orin issue on the Marias Pass route. In the attached activity there is a meet in Bison. The player train has as main path the diverging route, and as passing path the straight away route. The meeting AI train has the opposite path (main on straight away route). However the meet occurs with the player train on straight away route and AI train on diverging route.
Testpassing_far.zip

One way to force the path is of course the one of removing the passing path within the train path.



I have asked for clarification in the ET forum.

[gpz]

@geepster775, Haven't you forgotten to fix the SignalNumClearAhead() lines in route's sigcfg.dat file? Remember, MSTS finds the max number in the file, and applies that number everywhere. While OR uses the specified number at each signal type. So if one wants higher MSTS compatibility, he must modify this file for the route he is playing with.

[muskokaandtahoe]

I'm beginning to fear that much of the code development in this application is being conducted by those who lack first hand knowledge of US heavy haul operations....

IMO this is a generally correct statement. The composition of the active programmers has been almost exclusively non-North American for a number of years now. IMO their heart is usually in the right place -- make it right for everywhere -- but personal interest and expertise is often parochial. Sometimes this is pretty obvious... most of the time the effect is very subtle. I don't know about the demographics of end users but I suspect North America is under-represented as well.

Also, please note that the specific issue raised in post #1 may -- or may not -- be a result of the facts mentioned above.

There are many fewer active programmers now than this time last year. If you want to see the North American perspective at the table then best find some coders willing to volunteer... I'm pretty sure their arrival will be welcomed.

[lateagain]

You may be right Dave but I have to tell you that there are more issues with most UK stuff in OR than there are with US stuff. Dare I suggest that maybe there's a parochial "lack of interest" in UK stuff in the US?

The reality is that I'm not alone in being interested in Rail from ANYWHERE ....but I would suggest that US heavy haul operations are an Era specific problem rather than a parochial one?

Back when US railroads were interesting, which BTW is when MOST rail systems were interesting, there may not have been such wide differences in operations?

IMHO there's been far too many "Johnny come Lately's" too ready to sneer at how bad MSTS was but it can still do stuff that newer Sims can't? It was obviously flawed but maybe, just maybe they got some stuff right and some backward research and development might aid development?

I'm not a coder but I was a technician. If you have a fault that has no obvious cause you start looking at what works and why in other areas. Sometimes that triggers a path in fixing the original problem that isn't in the manual?

[roeter]

IMO this is a generally correct statement. The composition of the active programmers has been almost exclusively non-North American for a number of years now. IMO their heart is usually in the right place -- make it right for everywhere -- but personal interest and expertise is often parochial. Sometimes this is pretty obvious... most of the time the effect is very subtle. I don't know about the demographics of end users but I suspect North America is under-represented as well.

Also, please note that the specific issue raised in post #1 may -- or may not -- be a result of the facts mentioned above.

There are many fewer active programmers now than this time last year. If you want to see the North American perspective at the table then best find some coders willing to volunteer... I'm pretty sure their arrival will be welcomed.

The problem has nothing to do with knowledge of USA railroading or not. It is a much more basic limitation in the deadlock processing which is causing this.
This is what happens. If a train has 'alternative' paths defined, it will use such a path when it finds that the main path is not available. Generally, that will be the case if a train is coming from the opposite direction. But it can also happen when a train is following another train in the same direction. What happens, for instance in the case of the Feather River example, is that when the train tries to clear its signals ahead, it finds its main path still occupied. So, the deadlock pathing logic kicks in and selects the alternative path which is available. All that is according to the logic.
What is missing is a set of further checks in the (allready very complicated) deadlock pathing logic which checks on the direction of the train in that section, whether it has clear signals etc., and perhaps, in the situation where the two trains have the same direction, 'hold' the selection of the path until the train is much nearer.

Any volunteers?

Regards,
Rob Roeterdink

[eric]

This may be a justification for considering defining class of the train and applying that as a factor in the deadlock logic.

In real life, a Class 1 that deadlocks with a Class 3 should push the Class 3 over to the alternate path over the Class 1.

Also, it might be worth considering clearing a longer path for a Class 1 or Class 2 than for a Class 3.

For backward compatibility, you might have to use Timetable mode to for the class definitions.