Red Signals - Only One Train on Route?

boleyd

Well-known member
AI on 95720 TR19: With only one train on an entire route why would that train, operating under AI Session Rules, encounter ANY red signals? There is no occupancy by engines/locomotives or cars/wagons. A logically sterile environment.

I have encountered this on all previous versions that I have used.
 
Not enough information. what does the route look like? is it straight track? a loop? junctions and sidings?

With the information given, the answer would be "any number of things".
 
The "any number of things" is what I am looking for. In my mind an empty route should have no red signals on a primary through route. Obviously a diverge has red indications. In this situation this is a moderately complex route by "mgsapper". No giant yards. Largest has 4 tracks plus single branches the support specific activities. The train moves unimpeded through several signals and then comes to a normal diverge. It creeps at 2mph, slows to 1 mph and eventually stops. At that time the signal goes green and the train proceeds. Prior to that it had passed several similar protected diverges.

To me, the appearance seems to be an effort to simulate "normal" railroad activity by stopping the train at some chosen signals (reason not obvious). Also, despite set speeds by speed signs, the speed of the train will vary. Again, this would correspond to an attempt to inject general actions.

My preference is to have complete control during an AI managed session. Unwarranted events only serve to subtract from the customer being able to setup their railroad they way they want.
 
I agree that an empty route should not have any red signals if all the switches are lined up and there are no breaks in the track anywhere. I would walk the route and check for broken spline points, disconnected tracks, tracks not connected to crossings properly, missing switch levers, etc.

What are the driver messages?

Are there any unable to plot route, or junction missing lever messages?

I had one of the unable to plot route messages come up the other day that took me a few hours to find due to the length of the route. It turned out I had a broken spline point. I had connected the tracks, but not really and they spline points were on top of each other and not connected. Using the height adjust tool, they connected and the AI were happy campers again.

I digress too... After blaming Harry and the crew for not running a particular stretch of track and backing up oddly, I found I had placed a road crossing but neglected to connect the track! Oops!

So yeah too many variables that can cause that problem that requires the process of elimination to find.
 
I would agree that missing, not connected, etc would be an issue but the Red drops and the train proceeds. I am going to test on the "professional" route that N3V provides....
 
I would agree that missing, not connected, etc would be an issue but the Red drops and the train proceeds. I am going to test on the "professional" route that N3V provides....

That's a good idea.

Did you hover over the signal?

There are message associated with the signals which can sometimes be helpful. No train approaching, for example, is tied to your own train approaching the signal. The most useful ones have been Direction Marker is facing against us, and junction lever is not set (something like that).

No train approaching can be caused by a couple of things I have found out.

- Incorrect signal setup where the AI will sit and stare at the signals, though he's at the signal and it remains red.
- The driver session has gotten bogged down or as I said once "tired". In this case pressing pause or exiting from the session and returning, after saving, will fix that problem. I've reported this one to the QA Team ages ago.
 
While the train might be alone, it is sharing the route with switches, signals and possibly trackmarks, direction indicators, etc. It takes a non-zero amount of time to calculate the correct local path and change any switches it needs. Since it only looks a few blocks ahead at a time, it has to do this continually as it proceeds to its destination. Depending on the complexity of the track the time might start to add up. Ideally there is only a single possible path. If there are other potential paths, they all need to be evaluated to find the best path each time it does the calculation. Adding other trains would just increase the complexity as they have to take each other into account. Another thing to look at is to ensure that the route is correctly signaled, (correct for Trainz). I'm testing a new route and still find places missing a signal that causes the AI to stumble.
 
After testing and observation one problem is that switches are not properly aligned at the atart of the route. From the yard the train must pass through four switches all abutting each other serving the yard tracks. I have noticed that sometimes the furthest switch from the train fails to set properly. At other times it is the one that just precedes it in the trains path. When all four align prior to the train moving there is no pause at any switches. However, there is a pause of variable time if a switch is not preset properly. The term of the pause varies. I guess I have to stop playing around and setup a simple five tracks (1 for the train) and four switches in series. With many threads running to keep the customers happy there could be some delay and the default is to accept the settings as they are and allow the train to proceed knowing that the switches will be set properly as the train approaches.
 
I have found on some of my routes that even as I place signals in Surveyor, they go red instantly and stay that way until I go into Driver mode. Then, the signals will come to life and show green IF there aren't any hinderances to forward travel.

Bill
 
AI trains can only see 3 switches ahead while moving and once they stop at a red signal they then look ahead. They do have issues with pathing sometimes. Like when the switch it is currently trying to align does nothing to change the signal head's aspect because another further on isn't aligned either. The thing then has a seizure and flips the switch back in forth constantly trying to fix the problem, but it never does. The only thing that can describe the system sometimes is "crap".
 
Yes, they do set properly when entering Driver mode - sometimes. I made simple test one track with 4 switches branching from it. At start of driver some switches remained at the wrong position until the engine hit some trigger as it approached then they aligned. Usually two good and two bad if they started misaligned. So, I assumed it had to do with load. Therefore I made a similar track in Hinton (builtin route). There the switches all aligned at start of driver. Sent a train between towns and then ran my test with the running train as a load. Same thing all aligned at start.

Went back to my route and it now works every-time. Theory - there has to be significant previous activity for the failure mode to occur. I doubt there is a resource issue since the alignment is mostly computational and only my train was running on my test route. However, the elements used to compile the route may need to be found and sorted prior to assembly of the route. Prior activity may have the data needed for the routing spread about. Who knows... I am confident that I have found the root of the delays at some switches. The reason for the length of the delay is undetermined. That delay occurs when the switches are not placed in alignment at the start of Driver, nor during the approach of the engine (2 separate opportunities). Then the engine is stopped until the switches are set (probably also the compilation of the next route segment). Why this takes several seconds is not understood. Need to test more for the theory that the degree of prior activity has a bearing on the problem.
 
Another instance - Train approaches a switch that allows access to a short length of parallel track. For some reason N3V chooses the short parallel path. There is also siding switch from the parallel track. All switches are set properly. The exception is where the short parallel track rejoins the main line. That switch is not set properly. Thus the train stops until the switch is properly set. After the usual almost minute 2/1/0 mph creep you can see it switch to the proper direction and magically the train proceeds at speed.

The problem may lie in the logic that presets the switches. There is also an issue with the train approaching a junction that is not properly set. At some distance from the switch/junction a proper setting should take place. It does not. Instead the long pause logic is triggered and at the end of that sequence, the code for setting on approach is executed. All now proceeds as planned.

Reported...
 
But all the presets are assigned in Surveyor by the route designer. If they are all aligned for the mainline, a simple Drive command will easily go from end to end or endlessly in a circle if the route is made that way. Any built-in diversions disrupt this simple routing and the train could end up in some dead end siding. If the train is under AI control with appropriate commands, every switch position has to be calculated as it comes into view. This has to be done on the fly otherwise the whole path could be locked long before the train arrives causing endless frustration to other trains. Meanwhile, depending on how complex the route is, it can take time to calculate the best path so the train has to prepare to stop in case the calculation is not finished by the time it reaches the switch. We may know the best route from experience but the AI has to figure it out each time.
 
This quirk has existed for a while quite a while now. Leaving routing to the 'AI' is a recipe for disaster, signals or not. Because the AI depends on what direction the track is laid in surveyor, strange things occur when it is lain haphazardly. It also uses the shortest route to a given position if left to it's own logic.

Track marks are there for a reason. I've always gotten into the habit of setting up routes with them in a track block arrangement, signals or no signals. At either end of a siding pointing towards the switches.. At both ends of the mainline between the siding(s) pointing toward the switches. At the ends of spurs. Between sidings on the main, etc. Driver commands are given to follow the appropriate track marks in succession and direction for a given train. This minimizes the need for meticulously constructed routes in which the track is put down in the suggested directions.

The signals are merely there as a safeguard to keep more than one train from occupying the same block unless otherwise instructed by the dispatcher: me!. This also drops the need for dwarf signals on every track of a yard. The trains enter the yard without signals as long as the path to the authorized track mark is clear and the switches are aligned correctly by the yardmaster: again me!.

Another thing that I've seen affect routing is the lack of an a.cabback attachment point. For some reason, if it's not there, to get to a certain point on a siding, the train will bypass the intended switch, run all the way to the opposite end of the siding and enter that way to get to the mark.
 
It also uses the shortest route to a given position if left to it's own logic.
Of course it does, it's supposed to do that.

As for the track direction, that might have been true in the early days of Trainz but all it does now is dictate which side of the track trackside objects like signals, switches, etc., are inserted.

I also use trackmarks but only when the logical path is not the one I want the train to use because of the track layout. I could use track direction markers to block but if I ever intend to send a train to that track, it would not work. Two track direction markers, back to back, work great to keep AI out of by-pass tracks and other manual only tracks that only exist for my use.
 
If Trainz is laying out the route on the fly, I have seen that. I have also seen the switches set when entering driver mode which is probably indicative of the train being with the the "calculate" zone already. My routes are heavily treed with a full complement of assets to fit the functional need of a town based upon its size.
So, accepting all of that the remaining question is why does the train go through such a time consuming ballet of slow to 2mph, then 1 mph, then 0 and GO. Is this just a bit of theater to mask what might be a 2 or 3 second stop while the program catches up with route calculation.? Surly it does not take 30 seconds to calculate through to the next switch, or set of switches, if they are within the "to be calculated" zone. While the behavior is annoying and unrealistic at least it tell me that to maximize my $70 investment I need to spend several hundred dollars to have it perform properly. Since my "stuff" is about 5 years old I need to take the hint. Thanks for the insight.
 
There is also siding switch from the parallel track. All switches are set properly. The exception is where the short parallel track rejoins the main line.

On passing sidings, for me, this works the best.
0ehIb9s.jpg
[/URL][/IMG]
The siding is greatly foreshortened so as to fit in the picture.


  • The Track Direction Markers ensure proper passage through the siding.
  • The approaching signals are USA 02Ls [Left is Diverging since I want to trains to always go to the Right].
  • The internal signals are USA 04s. I'm not sure why, or even if, they are required, since two trains cannot approach the junction from the same direction - but it works, so I use them.
  • The Default setting for the Junctions are set to facilitate exiting the passing siding. For some reason, based on trial and error and my observations, the AI can more easily set a junction for the diverging process than for the converging process. For a train exiting the siding, the Default setting of the junction is correct. For a train approaching the siding the AI needs to flip the junctions to the opposite direction and then set the signal appropriately.
 
Surly it does not take 30 seconds to calculate through to the next switch, or set of switches, if they are within the "to be calculated" zone.

Surely it should not - I agree. But yet it does and even much longer. However, we cannot see what trains are way up the line and what and how the "brain" is trying to reconcile everything.



While the behavior is annoying and unrealistic at least it tell me that to maximize my $70 investment I need to spend several hundred dollars to have it perform properly. Since my "stuff" is about 5 years old I need to take the hint. Thanks for the insight.

The problem still exists in the latest TANE SP3. So, if solving this problem would be your only reason for upgrading, don't. However, there are a lot of other reasons to do so.
 
On passing sidings, for me, this works the best.
The siding is greatly foreshortened so as to fit in the picture.


  • The Track Direction Markers ensure proper passage through the siding.
  • The approaching signals are USA 02Ls [Left is Diverging since I want to trains to always go to the Right].
  • The internal signals are USA 04s. I'm not sure why, or even if, they are required, since two trains cannot approach the junction from the same direction - but it works, so I use them.
  • The Default setting for the Junctions are set to facilitate exiting the passing siding. For some reason, based on trial and error and my observations, the AI can more easily set a junction for the diverging process than for the converging process. For a train exiting the siding, the Default setting of the junction is correct. For a train approaching the siding the AI needs to flip the junctions to the opposite direction and then set the signal appropriately.
This arrangement will not work if you have 2 trains traveling the same direction and if you wish the faster train to overtake the slower one. Personally, I use track direction markers sparsely, because they tend to make my routes less versatile.
 
Back
Top