AG not changing STOP to permissive, AG not changing the sig file Options

[KQXZ]

Hello Folks,

I've got version 4.2.12 and when I try to make the STOP permissive - I get a message that it has backed up the sig file and that I can now proceed to go through the STOP signals.

The thing is -- When I try to do it -- I get the passed stop signal message and the activity ends.
MRW

[Guest_xxmikexx_*]

Hi Denis:
Thanks so much for the info.

David

MSTS uses a script file to control the signals. so I don't think it has anything to do with a cache file. When using the signal and switch changers in Activity Generator, the program basically rewrites the script file by changing some of the variables. In the sigscr.dat file, it changes Absolute (Stop and Stay) signals to Stop and Proceed. Now, there are some cases where AG can't change the file for some reason. One thing I have found if you must change the signals, you will need to do it before you pass that particular signal. Otherwise, you will have trouble getting the signal to allow you to pass, if you change it after the train went by it. I believe MSTS saves the signal state in the saved file, thus not allowing you to modify the file after the fact.

The issues with the Perm II route lie within the signal script files. That issue I ran into on the Boston & Maine route. AG was not able to change all the signals for some reason. However, since the B&M was not able to support AI traffic, I was able to modify the script file so it would never show a red signal to the player trains.

Jim

The script file controls the signals but the behavior of MSTS says that it does not contain the signal state. If a scenery cache exists, and the behavior of MSTS says that it does, then signal state has to be recorded in the cache or the caching scheme would do the wrong thing. If the state of the cached signal happens to be different from the state of the signal state contained in the static file, exactly the observed behavior would result.

I believe that it is the existence of the cache that causes the "back up before asking the dispatcher to clear you to proceed" strategy to not always work. If true, anything that force-flushes the cache will prevent the strategy failures, which unquestionably exist. (They'd been driving me crazy.)

Since the cache apparently is not cleared on activity restart (which is why restarts often are quicker than activity cold starts), the only certain way to clear the cache would be to fire up a different activity on a different route. Even restarting MSTS might not do it since the cache apparently persists across MSTS restarts, or at least that's my impression. (I haven't tested this specific point since these days I force-set switches/signals before ever running the route.)

xxxxxxxxxxxxxxxxxxxx

Anyway, I was getting failures before my new approach even though I was following the recommended procedures, and now I'm getting nothing but successes, so I don't plan to do things any differently. The cache viewpoint offers a plausible and complete explanation for all the symptoms. It exists with 100% certainty in MSFS; the behavior of MSTS strongly suggests that it exists here too.

By the way, the existence of a scenery cache is further suggested by the beneficial effects of hard drive defragmentation on scenery stuttering. The scenery prefetch algorithm (loads the cache) is able to operate more quickly on a marginal machine like mine, dramatically reducing the frequency with which a demanded tile is not in the cache when requested by the main application. For this reason I make clones by copying, then I defrag, and then I switch the clones (one per addon route) in and out of service via cut-and-paste rather than by copying.