[PerryPlatypus]

The 500 meters I suggested would just be the absolute maximum distance that OR would "search" along the path, it would not be a fixed value for every case. If a signal was encountered at any point before that 500 meters, then the route would clear as soon as the train has cleared that signal, which could vary from just a few meters past the clearance distance all the way up to the 500 meter max. I chose 500 meters because I think there are switches on high speed routes where it needs to be able to account for distances much larger than 150 meters from the node (the red line in the Route Editor).

[Jovet]

PerryPlatypus, on 03 June 2016 - 02:19 PM, said:

The 500 meters I suggested would just be the absolute maximum distance that OR would "search" along the path, it would not be a fixed value for every case. If a signal was encountered at any point before that 500 meters, then the route would clear as soon as the train has cleared that signal, which could vary from just a few meters past the clearance distance all the way up to the 500 meter max. I chose 500 meters because I think there are switches on high speed routes where it needs to be able to account for distances much larger than 150 meters from the node (the red line in the Route Editor).

My concern with that great of a distance is that signals which are not interlocking signals are going to treat non-interlocked (hand-throw) switches as if they are interlocking signals. I've observed this with the current signaling framework.

[PerryPlatypus]

"are going to treat non-interlocked (hand-throw) switches as if they are interlocking signals"

Could you please explain this? Is this a typo, or are you actually saying that the code could mistake a switch as a signal? Or are you referring to when route makers have used signals (using the "Distance" parameter) to work as switchstands?

A stipulation could be made in the code that Open Rails only apply this whole procedure (measuring out 500 meters) to switches which have a signal linked to them, and that signal must be of the "Normal" type, so as to not have conflicts with the switchstand "signals" I mentioned beforehand.

[Jovet]

PerryPlatypus, on 03 June 2016 - 02:51 PM, said:

"are going to treat non-interlocked (hand-throw) switches as if they are interlocking signals"
Could you please explain this? Is this a typo, or are you actually saying that the code could mistake a switch as a signal? Or are you referring to when route makers have used signals (using the "Distance" parameter) to work as switchstands?
A stipulation could be made in the code that Open Rails only apply this whole procedure (measuring out 500 meters) to switches which have a signal linked to them, and that signal must be of the "Normal" type, so as to not have conflicts with the switchstand "signals" I mentioned beforehand.

No typo. I have observed that permissive, intermediate signals that are in rear of a (hand-throw) switch show their most-restrictive aspect when no train route is lined passed the signal. The AI dispatcher seems to treat those signals as interlocking signals when they should remain fully automatic. The distance to the switch currently does not matter. It isn't a huge deal to me, but I've noticed it all the same. If I had the ambition at the moment I would draw up a diagram to show what I mean more clearly.

Signals linked to a switch don't apply to me, either, as my signal systems do not rely on that.

[PerryPlatypus]

I'm sure it would require a very length explanation, but I am curious how you have been able to create signal systems where interlocking signals are not linked to a switch and yet still function correctly with multiple trains being routed through, switches being thrown automatically, etc. This seems like it would be very prone to issues, especially when you throw Open Rail's adaptive, artificial-intelligence-dispatcher into the mix.

Important thing to remember is that this could be only an Experimental Option, and not a forced function that could screw up already-existing operation.

[roeter]

jovet, on 03 June 2016 - 03:02 PM, said:

No typo. I have observed that permissive, intermediate signals that are in rear of a (hand-throw) switch show their most-restrictive aspect when no train route is lined passed the signal. The AI dispatcher seems to treat those signals as interlocking signals when they should remain fully automatic. The distance to the switch currently does not matter. It isn't a huge deal to me, but I've noticed it all the same. If I had the ambition at the moment I would draw up a diagram to show what I mean more clearly.

That's by design, partly because that is again one of those situations which vary per country, partly due to how OR clears a signal. A third reason is that it avoids having to 'reset' the signal (change from cleared to danger) when the switch needs to be thrown - in many countries, resetting a signal from clear to danger is only allowed as extreme measure in very specific circumstances.
As for the OR limitation : a signal needs a 'path' to clear. A switch which is not in a train's path has no set position, and therefor the signal has no path. Only when a train clears a route through that switch does the signal have a valid path and so can be cleared.

Regards,
Rob Roeterdink

[roeter]

PerryPlatypus, on 03 June 2016 - 03:11 PM, said:

I'm sure it would require a very length explanation, but I am curious how you have been able to create signal systems where interlocking signals are not linked to a switch and yet still function correctly with multiple trains being routed through, switches being thrown automatically, etc. This seems like it would be very prone to issues, especially when you throw Open Rail's adaptive, artificial-intelligence-dispatcher into the mix.

Important thing to remember is that this could be only an Experimental Option, and not a forced function that could screw up already-existing operation.

That's not difficult at all. In fact, to allow multiple routes for trains through complex interlockings needs no links between signals and switches at all. The only reason for linking signals and switches is to set specific signal aspects for specific routes. But that can just as easily (and often indeed much more easily) be done using 'dummy' signals (e.g. INFO type) placed on the tracks beyond the interlocking.

As for the proposed function itself : it can only be done properly if linked to a signal, e.g. the signal in question needs some variable indicating it requires a train to be fully passed the signal to clear the interlocking. It could never be done as a 'blanket' rule per route, and most certainly not as a default OR setting. There are far too many variations on how situations like this are treated in real life to make it a default form of operation.

Regards,
Rob Roeterdink

[PerryPlatypus]

Very well, I think that is fair, and it would reduce or eliminate the chance of side effects occurring with signals that we do not wish to be impacted. :) I would like to advocate then for such a parameter that can be added to a signal in the Sigcfg.dat file, that defines a signal as protecting an interlocking. I will leave it up to one of the programmers to decide on the name for this variable, such as "SignalProtectsInterlockingAhead" or whatever is deemed the best name to describe this. Since there is already the implementation of using a Sigcfg.dat in an "OpenRails" subfolder within a route in order to modify the SignalNumClearAhead values and other things without it impacting MSTS, then it could be stipulated in the Open Rails manual that this new parameter must only be used in Sigcfg.dat files that are within this subfolder.

It would also be nice to see a sub parameter that would accompany the one mentioned above, that would stipulate that the route change cannot be made through the interlocking until XX number of seconds have passed after the train has cleared the signal protecting the interlocking.

A concern of mine, however, is when multiple routing options are available, such as with crossovers. In such a case, the protecting signal would protect more than just whatever the next switch is after the signal.

In the simple diagram I have attached, there are signals at A, B, C, and D. The switch points are at 1, 2, 3, and 4, with a crossover from 1 to 3, and another crossover from 4 to 2.

An eastbound train is waiting at Signal A while a westbound train crosses over from C to B. Signal A should not clear for the eastbound until the rear of the westbound train has negotiated both switches in the crossover and passed Signal B.

This means that if the parameter "SignalProtectsInterlockingAhead" is active for all 4 signals, then Open Rails would have to be smart enough to follow backwards from signal B through the crossover from switch 4 to switch 2, (along the route that the westbound train has just followed), and not make changes to any of the switches along that route, back as far as signal C, assuming signal C also has the "SignalProtectsInterlockingAhead" parameter activated.

Attached thumbnail(s)

• 

[Jovet]

PerryPlatypus, on 03 June 2016 - 03:11 PM, said:

I'm sure it would require a very length explanation, but I am curious how you have been able to create signal systems where interlocking signals are not linked to a switch and yet still function correctly with multiple trains being routed through, switches being thrown automatically, etc. This seems like it would be very prone to issues, especially when you throw Open Rail's adaptive, artificial-intelligence-dispatcher into the mix.

Nah, I'm pretty good at explaining it. ;)

The system uses special non-NORMAL signals (termed "Control Signals") to tailor the operation of any placed signal. One control signal allows for diverging aspects (normally what the linking does) to be shown, another allows for almost any other aspect to be shown, etcetera. The control signals themselves can be linked to a switch/track, but they usually do not need to be. Their presence in the path of the train beyond a signal is enough.

[Jovet]

roeter, on 04 June 2016 - 12:00 AM, said:

That's by design, partly because that is again one of those situations which vary per country, partly due to how OR clears a signal. A third reason is that it avoids having to 'reset' the signal (change from cleared to danger) when the switch needs to be thrown - in many countries, resetting a signal from clear to danger is only allowed as extreme measure in very specific circumstances.
As for the OR limitation : a signal needs a 'path' to clear. A switch which is not in a train's path has no set position, and therefor the signal has no path. Only when a train clears a route through that switch does the signal have a valid path and so can be cleared.

Yes, I've always assumed as much, and while it isn't prototypical here, I haven't considered it a huge problem. At least, not something worth complaining about.

Though I did see something in PerryPlatypus's log yesterday that did give me a bit of alarm:

Warning: sigscr-file line 581 : Invalid statement syntax : DRAW_STATE++

Warning: sigscr-file line 866 : Invalid statement syntax : DRAW_STATE++

Warning: sigscr-file line 991 : Invalid statement syntax : DRAW_STATE++

Warning: sigscr-file line 1465 : Invalid statement syntax : DRAW_STATE++

MSTS recognizes those operators just fine, but Open Rails, apparently, does not. I haven't gotten around to filing a bug report about this yet.

I also see I fat-fingered a few parameters in the sigcfg.dat file of that route, but that's my fault and not OR's.