© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
It depends on the function which is used to check the state of the next 'normal' signal.
If the script for this signal uses next_sig_lr to get the state, there is no clear reason why it should act differently wrt to MSTS.
But, if the script uses the function dist_multi_sig_mr, this could well result in a different state.
In MSTS, the function dist_multi_sig_mr returns "clear" if no other distant can be found while checking out the state of the normal signals. This is inconsistent with the way the function is supposed to work, so in OR this has been altered and if no other distant is found, the function returns "stop".
This difference in behaviour was justified as it was agreed that OR would be compatible with MSTS but would not copy actual MSTS errors - and this was assumed to be one of those errors.
If indeed the script uses dist_multi_sig_mr, the problem can be sorted by replacing this call by a call to next_sig_lr. The signal is indicative only (just a bit of eye-candy, actually), so this would not in any way affect the working of the signaling as such.