[Jovet]

Open Rails X3586.

I have created and programmed a special semaphore signal. It works as designed in MSTS but in Open Rails it does nothing. I have other semaphores that work just fine, and the same shape is in use in other roles and works fine, just the programming is new.

The name of the SignalType is pretty long ("JJHSemLQ2PosShdProtHomeRG1"). Does OR have a limitation with that? The code is there and works fine in MSTS but OR acts like it does not see it. The signal sits at its first SignalDrawState and never changes. This is a NORMAL type signal but as it is a special signal, its SignalNumClearAhead is set to 1 and it doesn't ever get !enabled.

If any more information is needed to assist in diagnosing this, just let me know.

http://msts.jovet.net/files/images/Semaphore1-MSTS.jpg
In MSTS the signal works correctly. It changes to Stop when the switch behind it is thrown, otherwise always indicates Clear.


http://msts.jovet.net/files/images/Semaphore1-OR.jpg
In Open Rails, the signal is always dark with a lowered blade (its SignalDrawState #0) and doesn't respond to the switch or ever light up. The code, route, and path is the same.

Attached File(s)

•  OpenRailsLog_SemaphoreBug $mod.txt (13.63K)
  Number of downloads: 201

[copperpen]

The US Upper Quadrant intermediates have a similar problem in OR. They will show a clear green, but after the train should have tripped the signal to Stop red, the arm remains raised and no light is visible.

[eugenR]

@Jovet

Can you upload Sigcfg.dat, sigscr.dat and the Signalshape, please

EugenR

[Jovet]

copperpen, on 28 June 2016 - 02:40 AM, said:

The US Upper Quadrant intermediates have a similar problem in OR. They will show a clear green, but after the train should have tripped the signal to Stop red, the arm remains raised and no light is visible.

All of my other semaphores work perfectly in Open Rails. At least, last I checked. That's what is strange.

Actually that's not completely true. I have noticed a few particular signals on a route have an unresolved problem. Being dark is not one of those problems, even though all of my signals are setup to have their #0 SignalDrawState be dark.... which is what is occurring here. But those signals are programmed in a slightly peculiar way, and I always chalked it up to that.

[Jovet]

eugenR, on 28 June 2016 - 03:55 AM, said:

Can you upload Sigcfg.dat, sigscr.dat and the Signalshape, please

Diagnostic files can be downloaded from here.

[eugenR]

jovet, on 28 June 2016 - 08:59 PM, said:

Diagnostic files can be downloaded from here.

Thanks for the file.
But I can't find any Problem with your signal?
I have installed the Semaphore as follow the strait path is linked to the semaphore:


I Start the Activity directly before the Signal, it shows approach_1 because the next Signal is closed (SignalNumClearAhead ( 1 )


Then I switch to Manual-Mode: The Signal shows STOP


Now I throw the switch, the Signal stay on STOP


Now I clear two Signals with two times TAB-Key, The Semaphore stay at STOP, but the next Signal will be cleared:


Now I throw the switch back to strait and clear Signals with zwo times TAB-Key
]

Does I have something not understand correctly?
Do You use the Folder OpenRails for the Signalfiles, and do you have there the same files as in the Main-Folder?

[Jovet]

eugenR, on 29 June 2016 - 07:10 AM, said:

Does I have something not understand correctly?
Do You use the Folder OpenRails for the Signalfiles, and do you have there the same files as in the Main-Folder?

How many signals do you have on the route? Using only one signal, it doesn't work. The signal doesn't even show up on the Track Monitor. It doesn't matter what the SignalNumClearAhead value is, either. If I put more signals on the route, they all seem to work fine. They do change to Stop after the train passes them, and that is absolutely NOT correct behavior, but that is how the OR signaling framework works right now. I suspect not linking them to a route will have them work correctly (essentially stay Clear all the time).
Edit: These signals need to work on otherwise-unsignaled lines, so a lone signal by itself not working correctly isn't acceptable.

I do not use any OR-specific signaling features, as I am still honoring MSTS compatibility with my signaling. I "expect" my signaling to work in both programs equally well.

[eugenR]

jovet, on 29 June 2016 - 08:51 AM, said:

They do change to Stop after the train passes them, and that is absolutely NOT correct behaviour, but that is how the OR signaling framework works right now. I suspect not linking them to a route will have them work correctly (essentially stay Clear all the time).
Edit: These signals need to work on otherwise-unsignaled lines, so a lone signal by itself not working correctly isn't acceptable.

You have right!
There is a different behavior between MSTS and OR for the Signaltype NORMAL! when the Train is passing such a Signal
route_set(): in MSTS it stay all Time THRU, in OR it switch to FALSE when the Train is passing the Signal
Block_State(): in MSTS it switch from BLOCK_CLEAR to BLOCK_OCCUPIED, in OR it switch from BLOCK_CLEAR to BLOCK_JN_OBSTRUCTED

For most of the Signals Type NORMAL this make no difference, because they are closed by !ENABLED:
But Your Signal is now closed twice by !ROUTE_SET() and by BLOCK_STATE ==# BLOCK_JN_OBSTRUCTED

I think you should make a Bugreport! Or shall I do it?
regards
EugenR

[Jovet]

eugenR, on 29 June 2016 - 02:02 PM, said:

You have right!
There is a different behavior between MSTS and OR for the Signaltype NORMAL! when the Train is passing such a Signal
route_set(): in MSTS it stay all Time THRU, in OR it switch to FALSE when the Train is passing the Signal
Block_State(): in MSTS it switch from BLOCK_CLEAR to BLOCK_OCCUPIED, in OR it switch from BLOCK_CLEAR to BLOCK_JN_OBSTRUCTED

For most of the Signals Type NORMAL this make no difference, because they are closed by !ENABLED:
But Your Signal is now closed twice by !ROUTE_SET() and by BLOCK_STATE ==# BLOCK_JN_OBSTRUCTED

I think you should make a Bugreport! Or shall I do it?

My signal only checks route_set() and block_state() if the route author linked the signal to a track beyond it. This is completely optional, as the signal should generally stay Clear all of the time. This is a protection signal, but MSTS and OR cannot simulate a rock slide or bridge failure, so the signal is fine being Clear all the time. The problem is the signal—when by itself—doesn't work at all no matter which options are set on it. It doesn't even register on the Track Monitor.

[Jovet]

The signal showing APPROACH_1 was an error on my part. It should only do that in the event that the signal has a Distant arm attached which is showing caution. I have updated the link to the .zip file in the post above to provide the corrected programming.

As an aside, and since it's my topic, I'll point out some of the other semaphore trouble I've had. It was mentioned above that permissive/intermediate semaphores have had issues. Mine are generally working fine—it's the absolute ones that have a few quirks. I've had some non-semaphore signals have similar quirks, though.

This is the main junction signal at a spot on a route I've re-signaled:

http://msts.jovet.net/files/images/Semaphore2-OR-medium.jpg
Click for larger image.

This signal works perfectly in MSTS, but is very problematic in Open Rails.

If the signal is not enabled by the dispatcher, nothing is wrong. If the signal clears, especially to the diverging route (shown) then the entire signal system seems to start fighting itself. This signal, and the following signal (barely visible in the distance) are constantly trying to alter aspects. Both the signal lights and the Track Monitor flicker a lot. This signal shows a green light but the second arm never drops (pictured), and the subsequent signal (a different signal system) shows Approach (Yellow/Red/Red) instead of its usual Slow Clear (Red/Red/Green). Once the train passes the signal to drop it, the signal system stabilizes and the surrounding signals behave correctly. Permissive semaphores of these types that deal with sidings do not work correctly, either. The rest are fine. The two home semaphores for the opposite direction at this particular switch never clear in OR, either. Though, I swear they used to, at one point. I haven't time-traveled out some older versions to check yet, though.

This is all in Explore mode, I do not have any Activities setup for this route. Pretty bizarre, though.