[Jovet]

I seem to have identified at least one more signaling framework issue, causing a discontinuity in behavior between MSTS and Open Rails. It could be a problem with how my signaling code is being parsed by the game, as well. Maybe in the process of addressing this problem this issue can be looked at, too.

I have taken the appropriate signals from the route with the problem and put them onto a testing route. At this point, I will make the testing route available for download upon demand to those who want to triage/inspect/fix it.

This bug revolves around my signal code seeming to ignore control signals. The control signals are non-SIGFN_NORMAL signals that are placed beyond a regular signal which customize its behavior.

Screen shots from the test route:

Screen shot #1. Here we see the problem signal in MSTS. It is showing Lunar over Red, which is correct. The "shunt" control signal behind the dwarf signal, and the dwarf signal, are both ahead of the switch node. The control signal is linked to the straight-ahead track beyond the switch and causes the signal to display a "Restricting" aspect on the top-most head of the signal.

The diagnostic signals on the left show the critical states of the problem signal: The 2-high assembly shows the Least-Restrictive (Top) and Most-Restrictive indications that the dwarf signal is showing. It's showing RESTRICTING and STOP respectively, which is correct. The 3-high assembly shows the Shunting signal states that the problem signal is seeing. The topmost panel shows the dist_multi_sig_mr() state, and the second and third panels show the least-restrictive and most-restrictive states of the following signal (which should be the Shunt control signal) immediately beyond the problem signal. The dist_multi_sig_mr() state is currently APPROACH_1, which is correct.

Screen shot #2. When the switch is thrown, the problem signal will have two control signals in its "sights." The first one will no longer apply per dist_multi_sig_mr() since its linked route is not accessible. The second one is on the siding in the near distance. The problem signal now shows Red over Lunar, which is correct. The Shunting diagnostic signal on the left shows that the dist_multi_sig_mr() state has changed to STOP_AND_PROCEED, which is correct. (The problem signal's SignalTypes work together by both seeing the control signals and behaving accordingly.)

Screen shot #3. With the switch set to ahead, the problem signal in Open Rails shows Lunar over Red like it did in MSTS, and is still correct. Note that the Shunting diagnostic signal is not showing anything. All states are STOP. (This makes no sense, and is a deviation from observations on the original route.) But the signal is still correct.

Screen shot #4. With the switch thrown in Open Rails, the main problems are exposed. The signal should be showing Red over Lunar like MSTS, but it does not. The problem signal shows Yellow over Red "Approach" since there are no more signals down the diverging track. It's acting as if the applicable control signal is not there. But the Shunting diagnostic signal is showing a dist_multi_sig_mr() state of STOP_AND_PROCEED, which is correct. The other interesting thing is that the Shunting diagnostic signal does not see the near control signal at all, since it's showing STOP_AND_PROCEED on all three panels. This is a deviation of MSTS but not necessarily a bad one (for my signal system, someone else's might object).

[roeter]

It's likely that this is the problem :

Quote

If any encountered signal head with function type fn_type or end_type is linked, then this link is checked against the state of the linked switch - if it is not set as required by the link (see 'route_set' for further description) then it is ignored.

That's not implemented in OR. It just happened that I overlooked that line when building the signalling, and 'retro-fitting' is going to take a disproportionate amount of effort. Further more, due to the different way of handling 'route' state (a signal which is not enabled has no valid route), implementing this would likely lead to other problems. Also, given the way searching for signals is handled, it would be a quite CP-intensive change as all signals along the way would need to be tested.
I fear this one will sit on the 'known bugs' list for some time to come.

Regards,
Rob Roeterdink

[Jovet]

 roeter, on 19 January 2017 - 06:49 AM, said:

That's not implemented in OR.

Actually, Rob, since the additions of X3538 (for https://bugs.launchp...or/+bug/1547013 ) and X3679 (for https://bugs.launchp...or/+bug/1647433 ), I believe that functionality is working correctly. The diagnostic signal shows that dist_multi_sig_mr() seems to be working correctly. It also indicates that next_sig_lr() [et. all] might also be ignoring linked signals that do not have their linked track active, which is incorrect—only dist_multi_sig_mr() has that behavior, but it should not affect my signaling. I believe this problem to be different, and quite possibly improper parsing of my code (which I admit is pretty complex). I have not checked whether OR mimics the MSTS diagnostic functions debug_header(), debug_out(), and debug_out2(), but if it does it would help me investigate what is going on. I have not yet tried an OR build with signal tracing turned on either, but if I get bored with a lot of time one of these days I just might.

[roeter]

If next_sig_lr is also affected by the routing, then that's indeed wrong. If so, it's a change which was made after I split off my 'personal' version, so it should be fairly easy to find.
OR does not support the script debug functions, but it has a very extensive debug function of its own, implemented in SIGSCR.cs. It provides a 'dump' of every step in the script, and even has additional information from within functions, e.g. as to which signal is found, its state etc.
It requires a recompilation, though - I don't know if you can compile the program. If not, I can send you a special version with the debug switch set on. Please send me a PM if you want to use this function to check things out.

Regards,
Rob Roeterdink

[Jovet]

Thanks Rob. I will work on getting that accomplished.

Until then, I've also had another thought: When the game is looking down the track and looking at signals, and finds one of the correct Type, an finds that it's linked but its linked route is not selected... does it just give up looking for any more signals? The pattern I've noticed regarding this thread has to do with control signals that are in front of other control signals. The nearer control signals should be ignored, and a further one should be active. But that does not appear to be happening.