Interlocking Signal Error - Monon Route

Bug #1449839 reported by James Bradley, Jr. on 2015-04-29
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Open Rails
James Ross

Bug Description

When playing an activity on the Monon route, I noticed an error with every interlock signal, or signals protecting diamonds. The track monitor would indicate "CLEAR", but the trackside signal would indicate "APPROACH" or "STOP". This signaling error also appears to affect Order Board signals at stations. In MSTS, the Order Board signal will indicate "PROCEED", but in OR the same signal indicates "STOP FOR ORDERS".

I will be attaching three screenshots.

1)Signals as they appear in MSTS (correct)
2)Signals as they appear in OR (incorrect--notice difference between MSTS and OR, as well as difference between signal and track monitor.)
3)Second interlocking signal, as it appears in OR (incorrect--notice difference between track monitor and signal)

James Bradley, Jr. (jbrad1974) wrote :

Compare this same set of signals to those posted in the first picture. Notice both signals in OR indicate "STOP", but indicate "PROCEED" in both MSTS and in the OR track monitor.

James Bradley, Jr. (jbrad1974) wrote :

This is another location on the same route. Notice the track monitor indicates "APPROACH", but the interlocking signal indicates "STOP". This happened at two other interlockings (diamonds) on this route. They appear to display correctly in MSTS.

James Bradley, Jr. (jbrad1974) wrote :

Monon signal file #1

James Bradley, Jr. (jbrad1974) wrote :

Monon signal file #2

Rippstein (ch-signale) wrote :

I think, the Problems comes from the different interpretation of SignalNumClearAhead( ) in OR and in MSTS.

MSTS use the highest valor found by any signal placed in the route for all other signals
OR us for every signal his own valor from Sigcfg.dat.

In this sigcfg.dat I have found as example :
 SignalType ( "LQHome"
with: SignalNumClearAhead ( 0 )

r.roeterdink (r-roeterdink) wrote :

The SignalNumClearAhead may affect some signals, but the main problems here are caused because ORTS is more stringent w.r.t. the syntax of the sigscr.dat file as MSTS.
In particular, there are the following items in the sigscr.dat file which are causing problems :
- Definition of EXTERN, instead of EXTERN FLOAT
- Definition of a FLOAT followed by a definition of an EXTERN FLOAT, followed by the definition of further FLOAT variables.
OR expects all EXTERN FLOAT variables to be defined before the definition of a FLOAT variable.
- Placement of curly brackets ( { and } ) on same lines as the IF and ELSE statements, particularly the definition of lines like :

} else {

Attached is an updated sigscr.dat file which which has been altered to adhere to these more strict rules.
Changes are just w.r.t. the layout of the file, no actual syntax changes were made.

James Bradley, Jr. (jbrad1974) wrote :

The interlocking signal appears to be working correctly now, but the order board is still not functioning correctly. In MSTS, it displays "proceed", but in OR, it displays "stop for orders". Since the order board does not appear in the track monitor, I'm assuming it is not part of the signal system.

There is a reference to the order board in the signal script. Since I don't know anything about signal scripts, perhaps someone can read this entry and tell me how to fix this issue in OR.

SignalShape (
  "Bidirectional Train Order Signal"
  SignalSubObjs ( 4
   SignalSubObj ( 0
    "TO Head Front"
    SigSubType ( SIGNAL_HEAD )
    SigSubSType ( "TOhead" )
   SignalSubObj ( 1
    "TO Head Rear"
    SigSubType ( SIGNAL_HEAD )
    SignalFlags ( BACK_FACING )
    SigSubSType ( "TOhead" )
   SignalSubObj ( 2
    "Front TO head Stop"
    SigSubType ( USER1 )
    SignalFlags ( OPTIONAL )
   SignalSubObj ( 3
    "Rear TO head Stop"
    SigSubType ( USER1 )
    SignalFlags ( OPTIONAL BACK_FACING )

This is the entry in the sigcfg file:


// Semaphore Train Order Head.

 // Use SIG_EXTERNS 'macro' instead?..
 extern float block_state ();
 extern float route_set ();
 extern float next_sig_lr ();
 extern float sig_feature ();
 extern float def_draw_state ();
 extern float state;
 extern float draw_state;
 extern float enabled;

 float show_stop;
 float has_gradient_plate;
 float next_state;
 float has_approach_slow;

 show_stop = sig_feature (SIGFEAT_USER1);

 if ( show_stop)

  state = SIGASP_STOP;


  state = SIGASP_CLEAR_2;

 draw_state = def_draw_state (state);

I have verified in the ShapeViewer that the order board signal is animated. Please let me know if you can see why it works in MSTS but not in OR.

--James Bradley

James Bradley, Jr. (jbrad1974) wrote :

I found the original file on According to the ReadMe, the order board signal is listed as a distant signal, which is why it doesn't appear in the track monitor. I'm not sure how OR treats distant signals versus MSTS, but that may help solve why its not working.

I'll be sending an e-mail to Hank Sundermeyer, the creator of the signal, to see if he knows why it doesn't function in OR.

r.roeterdink (r-roeterdink) wrote :

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.

James Bradley, Jr. (jbrad1974) wrote :

I decided to do a little tweaking of the sigcfg.dat file to see if I could get the Train Order Board to display correctly in Open Rails. I tried adjusting several variables, but nothing changed. I then flipped the "SemaphorePos" flags for the green and red signals, and the Order Board now displays correctly in Open Rails. This leads me to believe that the "USER 1" settings in OR are reversed from MSTS. In MSTS, "SemaphorePos ( 1 )" returns a red, and "SemaphorePos ( 2 )" returns a green. In OpenRails, these are flipped. By changing ( 1 ) to ( 2 ), and ( 2 ) to ( 1 ), the Order Board now displays correctly in Open Rails, but reversed in MSTS.

James Bradley, Jr. (jbrad1974) wrote :
James Bradley, Jr. (jbrad1974) wrote :

Is "USER 1" defined in the signal logic for OpenRails? It wasn't supported with the original MSTS, and was only experimental with later versions. If "USER 1" isn't defined in OR, that could be another reason why the Order Board wasn't functioning correctly. Just something to look at for the future. In the mean time, I was able to create a temporary work around by flipping the "SemaphorePos" variables.

James Ross (twpol) wrote :

James, what happens if you replace the original:

SemaphorePos ( 1 )
SemaphorePos ( 2 )


SemaphorePos ( 0 )
SemaphorePos ( 1 )

Changed in or:
assignee: nobody → James Ross (twpol)
status: New → Triaged
importance: Undecided → Medium
Joseph Hoevet (jovet) wrote :

"Is "USER 1" defined in the signal logic for OpenRails? It wasn't supported with the original MSTS, and was only experimental with later versions. If "USER 1" isn't defined in OR, that could be another reason why the Order Board wasn't functioning correctly."

Yes, USER1 is a valid SigSubType value for both MSTS and Open Rails.

James Bradley, Jr. (jbrad1974) wrote :

James Ross...let me test the changed values and get back to you.

James Bradley, Jr. (jbrad1974) wrote :

James...adjusting the SemaphorePos (1) with (0) and (2) with (1) appears to correct the problem, as does reversing the 1 & 2.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers