Results 1 to 4 of 4

Thread: Atlanta Macon Piggyback Problems

  1. #1

    Default Atlanta Macon Piggyback Problems

    I tried to set up this route about 10 years ago and never could get it right. Recently I tried again and all went well until about 30 minutes into the route. My first problem occurred as I was on a siding facing a red board. Nothing seemed to help but finally dispatch gave me permission to pass the red signal. It wasn't 10 minutes later until I ran into another red signal. I think my final solution was to use the dispatch window and manually change the signal. The final straw was a situation where I was on the main track, had a red signal and then saw I was facing a train ahead on the main track and another on the passing track. I figured I took the wrong track somewhere. My question is have others faced this problem and what did you do. I really like this route and judging from the large number of post on the route a lot of others seem to agree. Any ideas? Thanks,

  2. #2
    Join Date
    May 2018
    White Pigeon


    i dont Know What you mean by This Whats the PC Specks if theres a Problem just reply

  3. #3
    Join Date
    Jun 2013


    You'll have to excuse the raft of questions, but...Dispatch Window? I assume you're using Open Rails? If so, does the log say anything odd (probably not, but I have to try). Also, if this is an older activity on an older route, the activity may have to be reworked to work well in OR

  4. #4
    Join Date
    Feb 2013
    known universe


    First, I certainly agree with Travis:
    Also, if this is an older activity on an older route, the activity may have to be reworked to work well in OR
    Most often, AI traffic usually has to be reworked, also OR has location-linked passing path logic, something unknown to MSTS.

    But, just in case it is something with the signal scripts, try the following -- this is from the manual ... required reading
    Make up an OpenRails folder, copy both the sigcfg.dat and sigscr.dat files into explained below.
    10.14.2 Location of OR-specific sigcfg and sigscr files
    By simply copying the original sigscr.dat and sigcfg.dat into a subfolder named OpenRails created within
    the main folder of the route, OR will no longer consider the pair of files located in the route’s root folder,
    and will interpret the (single) SignalNumClearAhead () line as defining the number of signals cleared. So
    OR interprets sigscr.dat in a different way, depending whether there is a copy of this file in the OpenRails
    subfolder or not. In this way the problem of too few signals cleared for satisfactory train operation is
    usually solved.
    If however this single line standard sigscr.dat doesn’t behave satisfactorily even counting signals (a reason
    has been described in preceding paragraph), it will have to be optimized for OR by modifying the
    parameter SignalNumClearAhead () for the unsatisfactory signals; if preferred the line can stay as it is,
    and an optimized line can be added before the existing one, and it will again count signals. In this case
    the sigscr.dat file behaves the same as if it would if located in the route’s root folder.
    Sigcfg.dat must keep its name, while the sigscr files can also have other names, provided that within
    sigcfg.dat there is a reference to these other names.
    Also, go through the sigcfg.dat file in the OpenRails folder and make sure all the "SignalNumClearAhead" values are 4 or above, 4 should do it.
    After you've made both these changes, try the activity again.

    Some screenshots example of the OpenRails folder for Routes...this can also be used to clear trees off the's in the manual.

    bandicam 2019-09-06 18-44-24-443.jpg
    Last edited by R. Steele; 09-06-2019 at 11:05 PM.
    Cheers, R. Steele [Gerry] It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts