Stable Version - Open Rails 1.0

[neyland]

Sorry, but it looks to me that you do not know how UK semaphore signals are supposed to work.
Approach Control : check rule 39A :
"For semaphore signalling, rule 39A applied which states that for a sequence of signals which had no intermediate or combined distant signal (generally, the sequence of signals as controlled by one box), if the last signal in this sequence could not be cleared, all preceding signals had to be kept at 'danger' at the approach of the train and could only be cleared if the speed of the train was sufficiently reduced."

Distant signals : usually, a box had only one distant signal, and this reflects the state of ALL signals as controlled by that box, so not just the home but up to the starter. Obviously, with rule 39 above, generally preceding signals could not clear anyway so neither could the distant. And, of course, there were many advanced distant signals making things even more complicated.

So the sequence Distant (on-caution) Home (off) Starter (off) Advanced (on) is fully correct - except that, likely, Home and Starter should be ON and cleared only on approach.

But - getting back to the topic - the sequence as shown is the result of what has been defined in the signal script. And yes, how OR interprets that may differ from what happened in MSTS - not least because of actual errors in the MSTS processing. The most obvious error in MSTS was incorrect use of SignalNumClearAhead - and it might well be that error which creates the difference in your example.
MSTS used the highest value for SignalNumClearAhead as defined for any signal in sigcfg.dat and applied it to all signals, whereas OR - correctly - uses the actual value as defined per signal. Clearly that makes a difference. But that is not an error in OR!
The problem this may cause is easily corrected by changing the SignalNumClearAhead values in sigcfg.dat. So, check your sigcfg.dat, set SignalNumClearAhead for all signals to the highest value as defined anywhere in that file, and the signals will work the same as in MSTS. Then, check the manual on how you can actually improve the working in OR.

Regards,
Rob Roeterdink

Rule 39a has bugger all to do with the incorrect function of semaphore signalling in OR.

That is a separate issue where the last signal in a block is held at danger, the preceding Home or Outer Home Signal is held at danger to facilitate a slowing of the approaching service.

It's a mechanical function operated purely by the signalman in that section. Nothing to do with colour light auto approach control.

With nothing in front of a player or auto control consist in OR, all the distant and home signals should clear as each block is approached.

But they don't because OR does not impliment the MSTS signal scripts correctly.

They work fine running the same route in MSTS. So the fault\incorrect implementation is obviously an OR problem.

If OR is supposed to be compatible with MSTS operation, then they should work exactly the same in both games.

I know nothing about scripting, so telling me i need to do this or that is a waste of both of our time.

So i would say you need to create a tutorial explaining exactly what needs to be done.

[northeastern292]

I've been using OR since the early days and my only gripe is that certain textures won't load (for instance Austin Yoder's Horseshoe route runs into an issue where the ground textures won't load and I think that's due to a ground tile size). And a good consist editor. MSTS's crashes on me now.

Otherwise, I'm very happy with the direction things are heading.

[scottb613]

Hi Folks,

If it weren't for ORTS - I wouldn't be here...

Regards,
Scott

[conductorchris]

I ran into the ground texture not loading issue on the FJ&G route. I found the same ground textures in another route, copied them into the FJ&G and everything was fine. Still not sure what caused the problem and why that fixed it, but it did. I might have been missing a file (I copied the whole folder). Or something with one texture file was corrupt and overwriting it replaced it?
Christopher

[baldwin]

Activity eval is not properly active in OR. The problem with freight handling and passenger levels is that one needs to see how that is handled in the MSTS code, which is not possible. Maybe sometime in the future someone may be able to devote some time to working out the puzzle and code it for OR.