AI Trains not starting

[Don6218]

I am running Allegheny Rails Activity "BLE_P_02b", the third in a series of activities for this fine route. In all of these acts, none of the AI trains are moving, they are all stuck behind red signals (semaphores) and not progressing. When I get to the end, or near the end, they are all bunched up behind one another at a red signal, or on the way I will pass a stopped train as if at a signal, but there is no signal, just the stopped AI, stopped before it has reached the signal which in some cases has been a "Proceed" (Amber). All the AI trains are showing up somewhere during the Activity.

How does OR start the AIs? Is it automatic when the Act starts or when the Player Train starts up? Is there a problem with the way OR sets up/selects the AI Paths on these older routes? Where can I start looking, I updated all the "StartingSpeed" to 10mph from 0mph, which cured a similar issue on another route.

Thank You.

[R. Steele]

Don, it could be the traffic paths were created with inventive moves to trick MSTS into proper AI traffic behavior, perhaps they are just not working in OR. If that is the case, you'll have to rework the activity until the traffic runs as it is supposed to.

It also could in the sigcfg.dat file, the SignalNumClearAhead. See the excerpt below from Elvas thread. Good luck.

http://www.elvastower.com/forums/index.php?/topic/27482-signals/[/url]
Could be the SignalNumClearAhead entries in the sigcfg.dat file. There have been several threads about signals where that has been brought up. If I remember the number is set too low, should be 4 or above. MSTS ignores this but OR uses the data as given.

Found this when searching SignalNumClearAhead: Robs' post #3
http://www.elvastowe...hen-path-clear/

" Posted 30 November 2013 - 01:28 PM (Post #3)
One of the possibilities here is an incorrect value for the SignalNumClearAhead value in the sigcfg.dat file for these signals.
There is an error in MSTS, such that the highest value of SignalNumClearAhead as defined for any signal is applied to all signals.
OR has not copied that error, but uses the value as actually defined.
Some signals have a too low value for SignalNumClearAhead, resulting in not enough signals clearing ahead of these signals for these to show the highest (expected) Clear state. Due to the forementioned error this never showed up in MSTS, but will show in OR."

Regards,
Rob Roeterdink

and from Carlo Santucci in post#4:
"There is a cleaner way to do that: you have to add a SignalNumClearAhead line before each existing SignalNumClearAhead line. This one is used by OR and the second one (the original one) is used by MSTS. That is explained in paragraph 10.14.1 of the manual.
There is an even cleaner way, which is explained in paragraph 10.14.2."

[Don6218]

Yes, Gerry, that was in the back of my old mind. I was trying to remember what I did to get this corrected a while ago in another older route. That will be my next step, thanks again.