[Sid P.]

I am running Timetable activities (using Rob's Timetable system) on the Monon-17 route. (X2439)
The trains include some passenger trains running on a main line, and one freight that is to enter from a path that intersects the main line path.
When the freight train is run as one of the timetabled trains, it waits for the main line trains to pass (it faces a switch that is set for the main line train), but its waiting position puts the front of the locomotive so close to the main line track that it intersects the passing trains. (If I run the freight as the player train, it starts on its siding well clear of the main line.)

I assume that this will be a problem in the future when collision detection is included in ORTS.

Is this related to any of the problems with "Waiting Points" discussed elsewhere? If not, then I think this may be a bug in the Timetable code.
Anyone else seen this?

I also noticed that the F5 display shows that the waiting train is switching momentarily occasionally between 'RSW" and "ACC", but I do not detect any actual motion forward

Cheers,
Sid.

Attached thumbnail(s)

• 
• 

[roeter]

Hello Sid,

this has nothing to do with waiting points discussed elsewhere - that relates to the "Waiting Points" as defined in MSTS activity paths - these "Waiting Points" are not even supported in Timetable mode.

There is a default 'clearance distance' which is used when a train is stopped for a 'reverse switch'.
There are two options here : or this clearing distance is not used properly, or the switch position is further away from the actual switch as one would expect. I know there are some track systems which, for whatever reason, put the 'switch' position well ahead of the 'physical' switch location.

What is interesting here to know is the actual 'switch' position - that is the position of the famous 'blue pole' as shown in the route-editor. It would also be possible to have a view on the switch-position using the dispatch window, but to see it properly it would have to be zoomed in as close as possible.
Would it be possible to upload a screenshot of either of those?

Edit : a further thought on this : was the waiting 'accidental' (i.e. activated by the signalling itself), or was it a defined '$wait' in the timetable? There is a difference in processing between this.
The attached picture shows a train which is held using a 'follow' command, also at a reverse switch without signals. As you can see, it is stopped well short of the switch.


Regards,
Rob Roeterdink

[Sid P.]

Hi Rob-
It was not a defined "$wait", it was created by the signalling, I guess.
I will try to get a better look at the switch and post a picture.

Sid.

[Sid P.]

Hi Rob-
Here are the expanded views of the dispatch window - max expansion and a little less. The red line is from an oncoming train on the main path.
I'm not very adept at the route editor - I'll have to see if I can get any more info.
BTW, as the train was approaching the stop, it went through a "SIGL" mode, and the distance went through zero into negative numbers, then blanked and switched over to "RSW" state and showed 34 yards.
In the dispatcher view, there was a red "X" over the switch as the train approached the main line, then it went away as the train stopped.

Sid.

PS - I managed to geta picture from the route editor:

Attached thumbnail(s)

• 
• 
• 

[vince]

Sid P., on 31 August 2014 - 02:00 PM, said:

PS - I managed to geta picture from the route editor:

re: RE view; it looks like the dwarf signal tripper on the diverge path is set on the switch, at any rate, a bit too close to the switch.

vince

[roeter]

That dwarf signal is indeed the problem.
It shows a 'restricted' aspect, so as the train approaches it is in 'signal' mode (there is a proper signal ahead of the train), and that signal is set to a state which allows the train to pass.
As soon as it passes the signal it finds the switch locked against it by the passenger train, and so the train switches to 'node' control mode and stops for the 'reverse' switch. But the distance between signal and switch is thus that it can never stop at the required 'clearing' distance.

Main question here : why does the dwarf signal show only a restricted aspect and not a full stop?
Looks like an error in the setup for the logic of that signal - it probably does not check on BLOCK_JN_OBSTRUCTED. There are quite a few signal scripts with that particular flaw.

Regards,
Rob Roeterdink

[Sid P.]

- Hi Rob and Vince-
Many thanks for the prompt diagnosis. I gather that the fix would be better done to the route, not ORTS.
( I had noticed some switching of modes as the freight neared the main line) - it looked like it had started to speed up, then tried to stop but did not have enough room.)

Modifying someone else's route's switching is a bit beyond me. Maybe route designers will note this problem.

Update later this evening:
1. I managed to figure out how to move the indicator further from the switch, and the stop now works fine; the train on the siding stops an additional 10 yards from the switch and clears the track nicely.

2. But: I mentioned earlier that the waiting train was cycling about every second or so through "ACC", "BRK" and "RSW". In my test timetable the train had to wait nearly 20 minutes before being allowed to enter the main line - by then it had crept 4 yards towards the switch! Perhaps the RSW state should take precedence so that there is no creep.

Cheers,
Sid

[roeter]

Sid P., on 01 September 2014 - 06:37 AM, said:

2. But: I mentioned earlier that the waiting train was cycling about every second or so through "ACC", "BRK" and "RSW". In my test timetable the train had to wait nearly 20 minutes before being allowed to enter the main line - by then it had crept 4 yards towards the switch! Perhaps the RSW state should take precedence so that there is no creep.

Yes, I have occasionally seen this cycle myself. It's not a matter of priorities - a train can be in one state only - but a matter of an illegal 'transition' from STOP state to moving (RSW is not the state as such, but the reason why the train is in STOP state). But I still have not found what causes this transition. And, ofcourse, if one starts changing the transition logic, there is a danger of removing a transition which is valid in other circumstances, and by doing so those trains will then be stuck in STOP state - and that's even worse.

Regards,
Rob Roeterdink