Log In
Register Now!
Help
Not sure if this was brought to the OR Teams attention before, forgive me if it has. I just noticed I have been getting restricted signal indications in explorer mode on both MLT Kicking Horse Pass 2.0 and MLT Mountain Sub as well as 3DTrains Feather River route. I am running the latest X.1878 version but I have witnessed this happening in earlier versions. Long story short, this occurs while running in explorer mode running westbound from Ozada to Field. I start running into restricted signals just west of Exshaw. I also ran another test on the Mountain sub between Golden and Field and run into the same problem around Glenogle. I run the stock service paths that came with the routes. I also don't fool with switch alignments "G" key as the switches are already lined for the mainline for my movement. Just find it bizarre that I have no other traffic on the route just a straight shot and all of a sudden I encounter restricted signals. Curious to see if other people are having the same problem.
Page 1 of 1
Restricted Signal Indication Even When Path Clear
Rate Topic:
#2
- Superintendant
-
- Group: Status: Elite Member
- Posts: 1,849
- Joined: 25-November 11
- Gender:Male
-
Country:
Posted 30 November 2013 - 11:49 AM
One gets the same thing on the Footscray to Ballarrat route (Victoria,Aus) around the Melton area , from memory just before the double track ends, OR has been doing this for a while.
I assume its something to do with the signal config for the route as most routes do not have the problem.
Lindsay
I assume its something to do with the signal config for the route as most routes do not have the problem.
Lindsay
#3
- Vice President
-
- Group: Status: Elite Member
- Posts: 2,424
- Joined: 25-October 11
- Gender:Male
-
Country:
Posted 30 November 2013 - 12:28 PM
One of the possibilities here is an incorrect value for the SignalNumClearAhead value in the sigcfg.dat file for these signals.
There is an error in MSTS, such that the highest value of SignalNumClearAhead as defined for any signal is applied to all signals.
OR has not copied that error, but uses the value as actually defined.
Some signals have a too low value for SignalNumClearAhead, resulting in not enough signals clearing ahead of these signals for these to show the highest (expected) Clear state. Due to the forementioned error this never showed up in MSTS, but will show in OR.
Regards,
Rob Roeterdink
There is an error in MSTS, such that the highest value of SignalNumClearAhead as defined for any signal is applied to all signals.
OR has not copied that error, but uses the value as actually defined.
Some signals have a too low value for SignalNumClearAhead, resulting in not enough signals clearing ahead of these signals for these to show the highest (expected) Clear state. Due to the forementioned error this never showed up in MSTS, but will show in OR.
Regards,
Rob Roeterdink
#4 Inactive_TS_Craftsman_*
Posted 30 November 2013 - 01:57 PM
Thanks for the reply, I'll try uping the number from 3 to 5 or 6 and see what that does.
#5
- Superintendant
-
- Group: Status: Elite Member
- Posts: 1,849
- Joined: 25-November 11
- Gender:Male
-
Country:
Posted 01 December 2013 - 12:15 PM
Arrrrrrr..............
I will check it out and see what happens.
Many thanks,
Lindsay
I will check it out and see what happens.
Many thanks,
Lindsay
#6 Inactive_TS_Craftsman_*
Posted 01 December 2013 - 05:10 PM
I have tried setting the SignalNumClearAhead value to 5 and 6 on both KHP 2.0 and Rogers Pass route but I still run into the same restrictive signal indications even when the block ahead should be clear. Probably just boils down to the signal scripting in the sigcfg.dat and sigscr.dat.
Thanks again.
Thanks again.
#7
- Vice President
-
- Group: Status: Elite Member
- Posts: 2,424
- Joined: 25-October 11
- Gender:Male
-
Country:
Posted 06 December 2013 - 03:44 AM
Problem has been found.
The cause was the fact that the signal in question was 'automatic' - which means it would clear (to RESTRICTED) even if not enabled. The processing of the track route in explorer is such that it extends to the max. distance by default, except when a signal at danger is encountered. That signal is then 'requested to clear', a process which also properly enables the signal. The relevant signal was beyond the 'SignalNumClearAhead' of the first signal passed by the train, so it was not enabled through the signal logic. As it was not at STOP, the train path automatically extended beyond the signal so it was not enabled by the train either. As a result, it always showed RESTRICTED only.
The program will be changed such that a check is performed on signals along the train route to test if the signal is properly enabled, and if not a 'request to clear' will be send to that signal regardless of its state.
A commit will be done somewhere during the next few days - there is some more outstanding work to be completed first.
Regards,
Rob Roeterdink
The cause was the fact that the signal in question was 'automatic' - which means it would clear (to RESTRICTED) even if not enabled. The processing of the track route in explorer is such that it extends to the max. distance by default, except when a signal at danger is encountered. That signal is then 'requested to clear', a process which also properly enables the signal. The relevant signal was beyond the 'SignalNumClearAhead' of the first signal passed by the train, so it was not enabled through the signal logic. As it was not at STOP, the train path automatically extended beyond the signal so it was not enabled by the train either. As a result, it always showed RESTRICTED only.
The program will be changed such that a check is performed on signals along the train route to test if the signal is properly enabled, and if not a 'request to clear' will be send to that signal regardless of its state.
A commit will be done somewhere during the next few days - there is some more outstanding work to be completed first.
Regards,
Rob Roeterdink
Page 1 of 1