[Csantucci]

David, no, I'm not aware that it would be impractical. You don't need to advance the reverse point up to the end of next section, it's enough to advance it just at its beginning. The train will be enabled to reverse when the first car enters this next section, so few meters farther than with the RP in preceding section, but with the advantage that, if you run too fast, you can (but not must) roll further up to the end of this next section without going off path.

[copperpen]

Having looked at the RP situation at Milford using the OR trackviewer, the RP in question is not too far from the siding switch, and there is a clear portion of track between it and the RP that collects the brake later for the return trip. With the RP moving until the consist is clear of track nodes, this causes a relatively long reverse movement which in real life would just never happen. RPs are placed for a reason and should never be allowed to move under any circumstances.

[Csantucci]

copperpen, on 14 January 2019 - 01:42 PM, said:

... With the RP moving until the consist is clear of track nodes, this causes a relatively long reverse movement which in real life would just never happen.

No, it does not work so. The consist may be on track nodes (points) at the moment of the reverse. No one of these points, however, may be the diverging point, and this seems obvious.
Can you post a picture of the path around this critical RP? Is is in the already posted picture, and if yes, which RP is it in such picture?

[copperpen]

If you look at the screenshot at the top of the previous page, it shows the area in question. The action takes place on the route diverging right. player proceeds along the path to a reversing point and then backs up over the crossover to the first RP seen from the top side of the shot. Stopping at this RP places part of the consist over the crossover which is where the reversed path goes to the next RP that sets the path back into the curved siding in the aluminium factory. I do not use MSTS now, but that first RP does not move, however, in OR you have to chase it down the track until it stops which should not happen. Regardless of what type of node the consist is actually on, that RP should stay fixed, divergent point included.

[Csantucci]

So, if I understand you correctly, the first RP starting from top of the picture is moved downwards by OR, which, in fact, from the point of view of the diverging paths, should not occur. When I have time I shall check if OR wants also that the whole train passes the upper signal before reversing, which might be a not always valid criterium.
Probably I should now be able to build a simple test path on USA1 or USA2 to check the hypothesis.

[Csantucci]

Okay, it's so.
In the case shown OR moves the upper RP down to the point where the rear of the train passes the upper signal.
This could probably be modified for activity mode, achieving two advantages:
- activity behaving in a MSTS compatible mode
- activity behaving as activity builder expects (train enabled to reverse where he put the RP).
There might be a drawback on activities expressedly written for OR, which could behave differently with this modification.
So, before trying to insert this modification (only for activity mode), I'd like to read opinions on this.

[dforrest]

Csantucci, on 15 January 2019 - 01:39 AM, said:

Okay, it's so.
In the case shown OR moves the upper RP down to the point where the rear of the train passes the upper signal.
This could probably be modified for activity mode, achieving two advantages:
- activity behaving in a MSTS compatible mode
- activity behaving as activity builder expects (train enabled to reverse where he put the RP).
There might be a drawback on activities expressedly written for OR, which could behave differently with this modification.
So, before trying to insert this modification (only for activity mode), I'd like to read opinions on this.

I am obviously in favour of such a modification being made to the way Open Rails handles reverse points. Without it, such a simple shunting/switching modification as I have replicated in the activity being considered, could not be implemented in Open Rails.

[dennisat]

Hi,

This problem has reminded me of an activity in Briscard with 4 reverse points crisscrossing an extensive yard at the start. I never succeeded in getting out of the yard because some reverse points would just vanish. One of them could be activated if you stopped at the instant the reverse point vanished and then went into and out of Manual mode. However, you then came up to a red signal which would not clear. If you cleared and passed it in Manual Mode, OR would not let you return to Auto signal despite being on the path defined in the Activity. I never finished that activity and spent a while trying to debug the problem. I soon gave up because of my lack of familiarity with OR signalling code and also I was working on other more interesting (to me) patches at time.

I'll be interested to see if the solution to the current problem will fix the Briscard one as well.

Dennis

[Coolhand101]

I had something similar with an activity on the MEP+ route( Manton to Worksop Trip ). I had to move one of the RPs to avoid this problem!

Thanks

[Csantucci]

Here is a quick and dirty solution that does not move the RPs in activity mode, when a signal is on the path there.
The files may be replaced in x.4334 or (I believe it works too) in the first git-based OR solution (X1.3.1-6etc).
 Orts.Simulation_noRPmove.zip (1.25MB)
Number of downloads: 314