Monitor F4 and Signal Aspects

[seagoon]

The F4 Monitor displays signals ahead, on a clear track, in the following sequence:-

Clear (green), Advanced Approach (yellow/green), Approach, (yellow) and Danger (red).

When the player's train passes the Clear, then the sequence is repeated - what was Advanced Approach becomes Clear, what was Approach becomes Advanced Approach and so on.

Why is this so?

If there is no traffic ahead of the player's train, why are all the signals not at Clear?

[baldwin]

It is caused by the way OR treats the sigcfg.dat file, in particular the SignalNumClearAhead ( 4 ), some are even lower. I am using 6 as a working figure right now and unless the signals are close together or there is a conflicting AI move, I only see greens.

[seagoon]

So I take it, from your explanation, Mr. Baldwin, that it can change from route to route?

I might try and fiddle with it ....saving the default file first, of course!

[baldwin]

Yes. It is the difference in how MSTS and OR interpret that data. There are always more than one of those lines in the file as well.

[eric]

It changes from route to route, and signal type to signal type.

Each defined signal type can have a different value, and the behavior can vary based on how the scripts were written.

[rdamurphy]

When MSTS came out and folks started experimenting with the signals, it was quickly discovered that the SigNumClearAhead was only read once, assumedly the first time it was encountered in the script. So it was often set at ( 4 ) simply because that's what the default routes used.

In reality, all signals don't read ahead that far, and some read further ahead. For instance, on the BNSF, signals entering sidings (diverging head) only read STOP or APPROACH. When I asked a BNSF engineer why that was, he simply asked why you would want to take a train into a siding and right out the other end? Oddly enough, most sidings on the BNSF don't have train detection. On the ATC board, it doesn't show a train there. The dispatcher has to keep track of them.

I signal on high speed track may show up to six aspects or more depending on the system.

Theoretically, the SigNumAheadClear should equal the longest distance from the Permissive signal it's assigned to, to the next Absolute signal.

This is something that never really worked correctly in Explore mode in MSTS, since the signals also need to use the RouteSet() to "decide" if they should clear or not. You'll see this in an Activity, where the signals should not clear in the opposing direction as they do in Explore mode.

So, in effect, it was another one of those things the OR Team ran into, where people "fudged" or ignored certain things in MSTS that now work in OR. And the consensus among the team is not to introduce programming errors, or complex programming, to compensate for MSTS errors.

Robert

[seagoon]

.....And the consensus among the team is not to introduce programming errors, or complex programming, to compensate for MSTS errors.

Robert

And a damned good decision that is!

Thanks for the expansive information, Robert.

Bruce