Red and Yellow Signals for NO Reason???

The default state for railway signals is danger. They only go clear when a train is approaching.
 
Yes, all my signals show red with the only train on the system not moving. However, the train moves and is met with a Yellow because the next signal after it was preset to red by the ALL RED rule at session start. So until a train passes the red signals they will continue to influence proceeding signals to be yellow. Or, in some cases the red is not reset to green on approach and the FALSE stop occurs.
 
Last edited:
Is there a junction set against the train somewhere ahead? That can influence a line for many blocks if that's the case.
 
What you say is true and there is a signal setting ahead in a RED state, but so are all the signals on the route that have not been approached by a train. It seems that the adherence to a railroad real-world operation may also cause trains to pause when a local signal recognizes a RED state on a PRESET signal some distance ahead. ????

Is there a Clear All Signals To Green(or a specific signal) process available??
 
Last edited:
I believe you could only get all greens if, before your run, you set all switches appropriately. hummm.. I've never tried this. What would happen if you commanded your train in AI mode to nav to your destination, let it begin, then stop it. I wonder what the switch states would be? Of course, the AI does some weird things so who know how the switches would end uup.
 
So until a train passes the red signals they will continue to influence proceeding [sic] signals to be yellow. Or, in some cases the red is not reset to green on approach and the FALSE stop occurs.
Why do you regard this as a false stop? A signal would not go to Clear if the following signal is Stop. Or are you expecting it to go to Caution rather than Clear?
 
Default To Red - N3V Sets System-wide Stop

It is false because there is no reason for the red blocking the approaching train. It is the only train on the system.The real-life might be far different than N3V has implemented. N3V should create a rule that allows the customer to set up their system in a manner that matches reality.

If the "default state" is red under what conditions on a real railroad does the entire system go red?? Maybe when we see our national emergencies in the USA railroads are required to go red until they are authorized to set to green where appropriate.
 
It is false because there is no reason for the red blocking the approaching train. It is the only train on the system. -snip-

Signals are set based not only on whether there is other traffic in "your" block but also the next block. And not only traffic, whether moving or stationary, but also switch settings. There can be no other traffic and still, if switches are "against" your path, you can have have a red signal.

In your first post you said the next signal was red because of some "all red" rule... perhaps the switch in front of it was causing the red. I'm not sure I know this "all red" rule. If I make a loop and it has, say, four "blocks" and all the switches are set right, all signals will all show green. But if any one switch is "against" my loop then that block should be red and the preceding should be yellow. In fact, I have a "learning" route I made just to learn signals.
 
I'm not sure I know this "all red" rule.

Something I just learned from a post earlier that the program sets all signals to red to start the game. I checked and that is true. So, when you start a game the first signal you see will be red but as you get into some "approach zone" it will turn green automatically and you could have cared less that it began the game in a red state.

However, if there a signal further up the intended route, it would have also "started" red and remains in that state until a train "approaches" it. So, we have a situation that the first encountered signal remains red DESPITE a train entering its approach zone. The reason is - this other signal in the same block is set red. One or more signals, within the same block, will be red if any signal in the same block, and in the direction of travel, is also red.

I see this as a false circumstance. There is no functional reason for the approached signal to remain red except for one or more signals upstream, and in the same block, are artificially placed in a red state.

SOLUTION: Do not start a session with all signals red. Instead start with all green. Exception will be if any car or engine is within a block, the appropriate signals shall start red to protect that train element..
 
Last edited:
Do you have your consists wait a few seconds before running once a session starts?

I have found that letting the program cache and settle in first helps. If there are any consists on a clear route, the signals will set themselves to green and then the trains will start moving.
 
I'm not sure I know this "all red" rule.

SOLUTION: Do not start a session with all signals red. Instead start with all green. Exception will be if any car or engine is within a block, the appropriate signals shall start red to protect that train element..

If I understand your wish correctly, this goes against all rules of prototypical railroads. This all ties into the failsafe system. (Speaking U.S. only)
https://www.youtube.com/watch?v=tJpR93kp44I
 
In this case the train is 2 coal hoppers that first go to the loader, get coal loads, and then proceed to the power plant and encounter the odd signal on the way. I takes over 2 minutes to get from start to the odd signal. I eliminated all the signals in that area of the router except the signal at issue. No help. I changed it to a dwarf and same results.

I do not see an relevance to reality by starting a route on red. The "all red default rule" may only be relevant if control to a signal(s) is lost. Then setting all involved by DEFAULT would apply. If a railroad always shuts-down at dark then restarting at red, clear on approach, might have relevance in the context of the N3V application.
 
-snip-
I do not see an relevance to reality by starting a route on red.

The block you are in won't be red unless you a blocked ahead. When I start a session I have a mix of lights. Green, yellow, red, depending upon the consists involved and the way the switches are set. If no consists at all (I believe) all is red. As soon as I place a loco or consist I get green, yellow, or red depending on switch settings ahead.
 
I have repeatedly said that occupation will produce red as will the initial start of a session. Placing an active element (car, loco) on a track will cause a red in fore and aft directions with appropriate yellow green in signals further ahead or behind the element. Starting a session on red neither violates any railroad rules or obeys them. Unless a railroad turns off the electricity at night of course, then you have a brilliant red morning.There is no solution for my perceived condition short of starting a session on green for unoccupied blocks. It is just a 30 second delay and the signal is a nice decoration but has no functional purpose. I just thought there may be others who observed this but my situation has some unknown unique characteristic. Without the signal the route works ok.
 
Which signals are you using?

Some signals will not display a green unless you have a locomotive attached to a consist, and some signals will not display a green unless the front of the locomotive is facing the signal. The latter thing is annoying when switching freight cars.
 
Something I just learned from a post earlier that the program sets all signals to red to start the game. I checked and that is true. So, when you start a game the first signal you see will be red but as you get into some "approach zone" it will turn green automatically and you could have cared less that it began the game in a red state.

This is not entirely true. The signals will begin with an init message to update themselves when you begin. they then carry out the usual logic to set their state. that is, they look down the track in the direction they signal to see if a train is there. default game logic tells the signal to go idle (STOP) when the case of no train is found. If a train to signal toward is found, then the signal will look the other direction for obstructions or other signals. If an obstruction is found like an open switch or another train then it goes to STOP but not in the idle state. If another signal is encountered the search down the track continues for only a slight overlap and stops as that signal should be able to take over from there. There are also a few other catches for otherwise unreasonable set-ups, like if signals are too close together (inside that overlap). This is the basic logic path for any trainz signal. This process is carried out many many times as needed when the game thread calls for them to update, so there is no reason to think your signals are being set to one state and locked there - unless they have been configured to do so.

There is one default signal configuration type that I can think of that operates slightly-different and that is the "
always-controlled" signal that causes the train to stop at it before it can clear the path. I do not know a lot about these or where they should be used as they appear to follow a regional or special practice and there isn't any real information on the use of that tag.

Now addressing an issue like yours is difficult without actually being able to see the set-up, signals used, and potential problems on your line, but it seems like instead of looking for that solution you have arrived with many assumptions that you think are the problem that either do not actually exist, like the signals being intentionally set to a certain state, or there being NO reason for the behavior, when obviously there has to be some reason.



And just for clarity, While you could (and I have) produce signals that display CLEAR when in idle state, it does not change the basic function above, so once they detect a train they will carry out the same process as any other signal.
 
Last edited:
I too have issues with red signals for no apparent reason. Could somebody explain what this "all red" rule is, or what its actual title is, or "clear all signals to green" as I cannot find any reference to it on the DLS.
 
The "all red" rule is not a rule but just how railroads work... if there is no train in a block the signal is red. If you open a session that has no trains, the signals, I believe, will be all red (by USA standards anyway). Drop a locomotive on the track and the signal in front should go green or yellow (or possibly stay red) depending on what is in block ahead and switch (turnout) settings.

This video helps explain the red "failsafe" concept. If something fails you don't want lights to be green or yellow. So a signal is red unless forced green a yellow by a proper situation. The first 3 minutes explain hardware but failsafe and concept begin after that in this video:
https://www.youtube.com/watch?v=tJpR93kp44I
 
Last edited:
This is another example of internet information getting out of control.

There is no all red rule to find on the DLS or anywhere else. That was simply a misunderstanding of what is going on.
 
Back
Top