twpol
commented
9 years ago Imported from https://bugs.launchpad.net/or/+bug/1449839/comments/1
| Property | Value |
|---|---|
| Posted by | James Bradley, Jr. (jbrad1974) |
| Date posted | Wed, 29 Apr 2015 04:01:51 GMT |
Closed twpol closed 2 years ago
twpol
commented
9 years ago | Property | Value |
|---|---|
| Posted by | James Bradley, Jr. (jbrad1974) |
| Date posted | Wed, 29 Apr 2015 04:01:51 GMT |
twpol
commented
9 years ago | Property | Value |
|---|---|
| Posted by | James Bradley, Jr. (jbrad1974) |
| Date posted | Wed, 29 Apr 2015 04:03:55 GMT |
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.
twpol
commented
9 years ago | Property | Value |
|---|---|
| Posted by | James Bradley, Jr. (jbrad1974) |
| Date posted | Wed, 29 Apr 2015 04:05:47 GMT |
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.
twpol
commented
9 years ago | Property | Value |
|---|---|
| Posted by | James Bradley, Jr. (jbrad1974) |
| Date posted | Wed, 29 Apr 2015 04:10:56 GMT |
Monon signal file #1
twpol
commented
9 years ago | Property | Value |
|---|---|
| Posted by | James Bradley, Jr. (jbrad1974) |
| Date posted | Wed, 29 Apr 2015 04:11:28 GMT |
Monon signal file #2
twpol
commented
9 years ago | Property | Value |
|---|---|
| Posted by | Rippstein (ch-signale) |
| Date posted | Sun, 03 May 2015 21:35:54 GMT |
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 )
twpol
commented
9 years ago | Property | Value |
|---|---|
| Posted by | r.roeterdink (r-roeterdink) |
| Date posted | Sun, 03 May 2015 22:12:29 GMT |
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 :
} 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.
twpol
commented
9 years ago | Property | Value |
|---|---|
| Posted by | James Bradley, Jr. (jbrad1974) |
| Date posted | Fri, 15 May 2015 08:16:47 GMT |
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 ( "USLQto.s" "Bidirectional Train Order Signal" SignalSubObjs ( 4 SignalSubObj ( 0 "HEAD1" "TO Head Front" SigSubType ( SIGNAL_HEAD ) SigSubSType ( "TOhead" ) ) SignalSubObj ( 1 "HEAD1R" "TO Head Rear" SigSubType ( SIGNAL_HEAD ) SignalFlags ( BACK_FACING ) SigSubSType ( "TOhead" ) ) SignalSubObj ( 2 "USER1" "Front TO head Stop" SigSubType ( USER1 ) SignalFlags ( OPTIONAL ) ) SignalSubObj ( 3 "USER1" "Rear TO head Stop" SigSubType ( USER1 ) SignalFlags ( OPTIONAL BACK_FACING ) ) ) )
This is the entry in the sigcfg file:
SCRIPT TOhead
// 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;
else
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.
Thanks, --James Bradley
twpol
commented
9 years ago | Property | Value |
|---|---|
| Posted by | James Bradley, Jr. (jbrad1974) |
| Date posted | Sat, 16 May 2015 22:58:43 GMT |
I found the original file on TrainSim.com. 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.
twpol
commented
9 years ago | Property | Value |
|---|---|
| Posted by | r.roeterdink (r-roeterdink) |
| Date posted | Mon, 18 May 2015 09:16:17 GMT |
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.
twpol
commented
9 years ago | Property | Value |
|---|---|
| Posted by | James Bradley, Jr. (jbrad1974) |
| Date posted | Fri, 28 Aug 2015 20:48:26 GMT |
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.
twpol
commented
9 years ago | Property | Value |
|---|---|
| Posted by | James Bradley, Jr. (jbrad1974) |
| Date posted | Fri, 28 Aug 2015 20:53:26 GMT |
twpol
commented
9 years ago | Property | Value |
|---|---|
| Posted by | James Bradley, Jr. (jbrad1974) |
| Date posted | Fri, 28 Aug 2015 20:58:45 GMT |
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.
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | James Ross (twpol) |
| Date posted | Mon, 26 Dec 2016 22:05:10 GMT |
James, what happens if you replace the original:
SemaphorePos ( 1 ) SemaphorePos ( 2 )
With:
SemaphorePos ( 0 ) SemaphorePos ( 1 )
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | Joseph Hoevet (jovet) |
| Date posted | Tue, 27 Dec 2016 22:40:40 GMT |
"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.
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | James Bradley, Jr. (jbrad1974) |
| Date posted | Wed, 28 Dec 2016 23:27:23 GMT |
James Ross...let me test the changed values and get back to you.
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | James Bradley, Jr. (jbrad1974) |
| Date posted | Thu, 29 Dec 2016 00:05:08 GMT |
James...adjusting the SemaphorePos (1) with (0) and (2) with (1) appears to correct the problem, as does reversing the 1 & 2.
Imported from https://bugs.launchpad.net/bugs/1449839
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)