[Coolhand101]

Adding the sidings signal arm on the main signal to type 'shunting' allowed the distant to be 'off', when all the main signals are cleared. But when the shunt arm is off, the main signal shows on, which is correct, but also red on the track monitor and the train emergency brake applies when the signal is passed.

If it's a script problem, this should also apply to the distant when the siding signal type is 'normal' under MSTS. I will try this on MSTS next.

All works 100% in MSTS, distant off with sidings arm as type 'normal'. Also with signals that have Home and branch heads as well.

Thanks

[Jovet]

Coolhand101, on 18 February 2016 - 04:08 AM, said:

Adding the sidings signal arm on the main signal to type 'shunting' allowed the distant to be 'off', when all the main signals are cleared. But when the shunt arm is off, the main signal shows on, which is correct, but also red on the track monitor and the train emergency brake applies when the signal is passed.

Yeah, I guess that could be a problem. LOL My suggestion wasn't a very good one. Well, it half-worked. That behavior is exactly as it should be, and doesn't solve your problem.

Coolhand101, on 18 February 2016 - 04:08 AM, said:

All works 100% in MSTS, distant off with sidings arm as type 'normal'. Also with signals that have Home and branch heads as well.

I've created a formal bug report about this issue. http://bugs.launchpa...or/+bug/1547013
I've known about it for a while, so I probably should have sooner. One of these days I'll get around to some more rigorous testing to see if anything else not quite right is lurking. I know it would sure be nice to have my signals working at 100% in OR. It's close—OR has certainly come a long way on that front already.

[Coolhand101]

jovet, on 18 February 2016 - 05:13 AM, said:

I've created a formal bug report about this issue. http://bugs.launchpa...or/+bug/1547013
I've known about it for a while, so I probably should have sooner. One of these days I'll get around to some more rigorous testing to see if anything else not quite right is lurking. I know it would sure be nice to have my signals working at 100% in OR. It's close—OR has certainly come a long way on that front already.

Many thanks for the formal bug report!

My next goal is to use the new 'approach control' scripts. I had no ideal that waitpoints now only clear the signal, once the train has stopped, like the double reverse point in MSTS.

Thanks

[Jovet]

Coolhand101, on 18 February 2016 - 05:52 AM, said:

Many thanks for the formal bug report!

You're welcome.

The irony is, of course, that earlier today I observed a situation which I believe should have been affected by that "bug" but didn't appear to be. I was going to go check it in the RE and MSTS formally but haven't yet. Go figure.

[Coolhand101]

Are there any more updates on this matter? I've starting using the cambrian coast 1 in OR. This route is all semaphore signals.

I have notice that the distant signals are behaving much better in this route. The only problem is junction signals, regardless if the mainline home signal is 'off', along with the following home signals, that distant will not clear. Or if the there are two main line junction signals along with two distant junction signals, the latter will not clear.

Also, if there is a home(starter)+distant combined, the distant is 'on' even if the following home signals are clear.

I would assume, that if there is a home signal with a shunt(switch)signal and that signal is set for the mainline, that distant will also not clear.

This all still seems to point to a signal with more than one HEAD in the sigCFG, causes the distant to stay 'ON'.

There is bug report already filed but maybe this post should be moved to the bug section ?

Thanks

[Dogbert]

UK Semaphore Distant and combined Home\Distant signals.

Do not function correctly in routes, Thames - Trent v1 & v2, S&DJR, or Bristol - Birmingham.

[Jovet]

Coolhand101, on 17 April 2016 - 05:02 AM, said:

Are there any more updates on this matter? I

Unfortunately I am not sure anyone has noticed it yet. I still think this bug is the main thing keeping my signaling from functioning 100% in Open Rails, though.

[James Ross]

jovet, on 22 April 2016 - 02:18 PM, said:

Unfortunately I am not sure anyone has noticed it yet. I still think this bug is the main thing keeping my signaling from functioning 100% in Open Rails, though.

Noticed, yes, but not able to help. The signalling code is very opaque to me so I cannot even confirm whether the analysis in the bug in matches the code. :(

[Jovet]

James Ross, on 23 April 2016 - 06:56 AM, said:

Noticed, yes, but not able to help. The signalling code is very opaque to me so I cannot even confirm whether the analysis in the bug in matches the code.

The thought has bounced around my head a few times to try and track it down myself. I doubt the signaling code can be any more "opaque" to me than the rest of the source code. Which could be good, or bad.

[roeter]

Please try version 3538.
However, please note that there remains an important difference between the working of this function in MSTS and OR.
In MSTS, if no next signal of "type 2" is found, the function returns state CLEAR_2, or the state as found, I'm not quite sure on that.
But either would be wrong and inconstistent with the intention of the function. The intention is to only clear a distant if all 'normal' signals between that distant and the next distant are cleared. If no next distant can be located - either because there is none, or because it is not within the train's path - then the function should take the save approach, which is to return STOP. That is what OR does.
Note that this is NOT an error, but very much intentional.

Regards,
Rob Roeterdink