Hinton Route Issues

During the 1.5 hour run from Hinton to the Thurmond Engine House several Red signals were encountered where the train stopped and after less than a minute, continued. I could see no reason for this behavior. The route tested was the original commercial version purchased as part of the Silver Package. There my be a method to control signals through programmatic options but they are not obvious to me.

I have had the appearance of red signals, when there are no other trains in the system, on other routes. The 105096 version is based on a 1 week old fresh install (with updates) in an effort to eliminate any possible issue with the previous installation. I decided to run a clean route ( original Hinton) to see if the problem existed there - it did.

Report Submitted

boleyd said:

During the 1.5 hour run from Hinton to the Thurmond Engine House several Red signals were encountered where the train stopped and after less than a minute, continued. I could see no reason for this behavior.

Click to expand...

I am assuming that they continued because the red signals changed to green, again for no obvious reason?

Just a possibility, there are Trainz (and real world) signals that remain red until a train approaches to a set minimum distance before the signal turns green even when the block ahead is clear. Usually you can identify these signals by placing the mouse on the signal and the message "Waiting until train approaches" (or something similar) will appear.

Signals remain in the red-state by default in Trainz until a train approaches the signal. If there is no train nearby, the signal will show a "No train approaching". These red signals have always been the case except for recently when Jointed Rail made some changes to their code to allow for an approach-lit configuration.

After a dialog with N3V support, they conclude, and I agree, that it is a processing issue whereby the demands of the programing being required to "scan" its environment and set signals accordingly have hit a CPU limit. The extent, and details of that scan simply take precedence over train movement, for obvious reasons. The concurrency of "scanning process" places demands on my little 4-core CPU. More cores and more concurrency may reduce the occurrences or shorten delays. Now, if I add 4 more cores will N3V be able to efficiently take advantage of them? The possibility is high since the problem seems to be mine alone. Others may have it and find it acceptable as a reflection of the reality of activity elsewhere on the route, as it is.

One point - while the start default is RED, the approaching train usually does trigger a reset to current conditions. Bringing a train to a halt for about 45 seconds seems like a very long time to do a few thousand calculations, especially with no other dynamic events occurring. The old AI code may have some issue contributing to the delay. It is annoying, and a departure from the target - reality, but overall it still is a rewarding experience.

It tis the season so a fancy new computer is fully justified!:udrool:

boleyd said:

It tis the season so a fancy new computer is fully justified!:udrool:

Click to expand...

That's good thinking! My desktop is starting to show its age particularly with its 760Ti video card.