[beresford]

X2313

In this scenario you travel up a single track branch line performing shunting activities. The OR screen shot shows the train pointed in a forward direction in Auto mode. The direction of travel arrows are reversed. For some reason the point ahead is set to a siding (Chuck Wagon Industries) which doesn't feature in the activity (isn't Auto mode supposed to change points to match the path?).

So having dropped into Manual, set the point, and returned to Auto I drive past the siding, and soon afterwards, near a level crossing, I get the 'Off Path - Emergency Brake' schtick. So I drop into Manual, advance a small distance, the train icon turns white, and Auto mode can be used again. This is a straight piece of track with the 'path' running along it, as shown in the other attachment from the Microsoft Activity Editor.

Attached thumbnail(s)

• 
• 

[roeter]

Can you try and create a new path through this location and see what happens?
If that causes the same problem, there could be an error in the route data somewhere which causes this anomaly.
If that works correct, the problem could be that the present path has been edited, leaving a series of 'invalidated' points. A large number of such 'invalidated' points in a path definition can sometimes confuse the path conversion logic.

Regards,
Rob Roeterdink

[bennycdn]

I keep having the same problem with the Monon route.
I created a straight path from Wallace jct to Midland,hoping to work the mines
I put the train in manual,having advanced to mine area.I uncouple from train and back into siding,pick up 4 hoppers.
I come out of siding,throw switch and couple to my train.Pump up the air.
I put train into regular mode,start to advance forward.when I pass switch,train goes into emergency.End of story.

[markus_GE]

 roeter, on 23 June 2014 - 12:40 AM, said:

[...]

A large number of such 'invalidated' points in a path definition can sometimes confuse the path conversion logic.

[...]

Is there a way to remove such points? Or, asking it the other way round, how do such invalidated points in a path file look like?

If I know that, I might at some time implement a "path correcting" functionality (remove such invalid points) in my DPU program.

Cheers, Markus

[beresford]

 roeter, on 23 June 2014 - 12:40 AM, said:

Can you try and create a new path through this location and see what happens?
If that causes the same problem, there could be an error in the route data somewhere which causes this anomaly.

It's been a LONG while since I created anything using the Activity Editor, but after some fiddling I have some answers to the Great Question of Life, the Universe and Everything.... you're not going to like it though. :shock6:

The branch has a number of sidings and a reversing point at the end of it. As you said elsewhere, OR pulls the reversing point forward, which means that as soon as you reverse to do any shunting OR switches the 'polarity' of the Track Monitor and Switch Display and assumes you are on the way back. This is not only confusing but means that the Track Monitor does NOT show the track ahead of you and does NOT lock points red in their correct state.

Having driven up the branch without reversing en route and found that the 'Off Path' behaviour did NOT occur when I passed the Chuck Wagon siding, I performed the following experiment.

1. Reversed (actually just stopping does it) to get the Track Monitor in the backward state.

2. Advanced under Auto, stopped, entered Manual, changed the Chuck Wagon siding point in front of me to the wrong state, went back to Auto, started the train rolling, and saved the game.

3. Reloaded the scenario, stopped the train, entered Manual, changed the Chuck Wagon siding to the correct state, went back to Auto, and proceeded forwards.

As the REAR of the train (which OR thinks is the front) crossed the Chuck Wagon siding points, the 'Off Path - Emergency Brake' message appeared.

So there is some food for thought. From this you might be able to explain to me why none of the shunting I do on this branch is recognised by the Work Order window.

Regards

Beresford

[roeter]

Ah - that reversal point does explain it. The pathing logic has no knowledge of any 'workorders' - and even if it had, if these are off the path it would be very hard to link them to any position on the path.
So, as soon as you stop the train beyond the 'diverging' point, the reversal is activated and the new direction is set. If you then move on in the original direction, you are indeed heading off the path.
The only way the activity can be continued is to perform any further shunting etc. in the original direction of the path in Manual mode, and return to Auto mode only when you are done with shunting and actually are heading back.

I'm afraid I can't help you with working orders and such. That is part of the Activity processing, which I actually never have looked at apart from station stops. Admittedly, I never use work orders myself.

Regards,
Rob Roeterdink

[beresford]

 roeter, on 24 June 2014 - 04:20 AM, said:

So, as soon as you stop the train beyond the 'diverging' point, the reversal is activated and the new direction is set. If you then move on in the original direction, you are indeed heading off the path.


Regards,
Rob Roeterdink

Logically this business of moving the reversal point is not beneficial, since the scenario author could have placed it at the diverging point if he thought it was a good idea. Is it a case of not knowing how Kuju got their reversal points to stick where the designer put them, or is it a deliberate change due to some extra feature of OR?

I also miss the points symbol that appears on the MSTS Track Monitor to tell you when you are leaving the main line, it is a little (virtually) disconcerting to be travelling at high speed and be suddenly switched sideways without warning.

[roeter]

There are three major issues with reversal points in MSTS :

• MSTS requires the train to cross the reversal point, but at the same time often 'moves' this point to the end of a tracknode.
  As a result, there were many occasions when one was carefully creeping up to the reversal point which was located right in front of a buffer stop or signal, making sure one could stop immediately when crossing this point without passing the signal or buffer, while the train was actually already well clear of the 'diverging' point.
  
• When a reversal is required, the reversal point must be placed such that the train is completely clear of any switches, even if these switches were passed in the same way in both in- and outbound paths.
  By the way : this means that your remark on placing the reversal points is not true. Very often the reversal point could not be placed at the location where the rear of the train is clear of the diverging point as at that location the train was still over other switches. This often made it necessary to move the reversal point quite far away from the diverging point.
  
• When a reversal point was crossed but the train was somewhere still over a switch (regardless of having cleared the diverging point), the reversal point 'moved ahead', but from that moment on kept on moving ahead of the train. It was never activated - that therefor was the end of the activity.

All three points above were rectified in OR, which obviously lead to a different overall logic.

Regards,
Rob Roeterdink

[beresford]

 roeter, on 25 June 2014 - 06:14 AM, said:

There are three major issues with reversal points in MSTS :

• MSTS requires the train to cross the reversal point, but at the same time often 'moves' this point to the end of a tracknode.
  As a result, there were many occasions when one was carefully creeping up to the reversal point which was located right in front of a buffer stop or signal, making sure one could stop immediately when crossing this point without passing the signal or buffer, while the train was actually already well clear of the 'diverging' point.
  
• When a reversal is required, the reversal point must be placed such that the train is completely clear of any switches, even if these switches were passed in the same way in both in- and outbound paths.
  By the way : this means that your remark on placing the reversal points is not true. Very often the reversal point could not be placed at the location where the rear of the train is clear of the diverging point as at that location the train was still over other switches. This often made it necessary to move the reversal point quite far away from the diverging point.
  
• When a reversal point was crossed but the train was somewhere still over a switch (regardless of having cleared the diverging point), the reversal point 'moved ahead', but from that moment on kept on moving ahead of the train. It was never activated - that therefor was the end of the activity.

All three points above were rectified in OR, which obviously lead to a different overall logic.

Regards,
Rob Roeterdink

While you were writing this I have resorted to reading the manual. It seems that one problem is that OR didn't anticipate that some branches wouldn't actually have any signals. Another problem is that if you are shunting OR can't possibly 'know' what the size of the train will be when it reaches the diverging point. How can you represent a train like the 'Stourbridge Donkey' (a railcar which just goes up and down on a single track between Stourbridge Town and Stourbridge Junction?

It's a ticklish problem isn't it, I have given myself a headache thinking about it. On reversal, two things are done:
1. OR starts projecting authority for the train in the other direction.
2. The Track Monitor and Switch Indicator get reversed.

IMHO the second step shouldn't be necessary, up screen should always be in the direction the cab is facing.

When the train reaches the nominal reversal point, OR 'knows' how long it is and could refuse to recognise change of direction unless the train has passed the next switch behind the train that OR needs to change to create the new path.

[markus_GE]

Currently, ORTS seems to reverse the path as soon as the diverging point is passed, which obviously leads to problems.

Obviously, automatically switching direction upon stopping of the train is no good idea. Waiting for the reverser to be moved to backwards position before switching direction would allow for stops, but no shunting movements. But: As MSTS places the reversal point somewhere on the track, away from the diverging point, the tracksection between diverging and reversal point must somehow be defined as part of the path.

Thus, one could check if in that "appendix" of the path after the diverging points any switches are located. If there are none, change direction as soon as the train stops clear of the div point. If there are some, check if there are work orders defined on tracks that can only be reached from the "appendix" of the path. If that is impossible to implement, or if such work orders are not present, one could simply ask the user to reverse direction, or clear the backwards path by using some sort of interface, as soon as the train clears the div point.

Would that solution work?

Cheers, Markus