[Csantucci]

A revised version of the document is available in the first post.

[roeter]

From version 2203 onward, OR-specific sigcfg.dat and sigscr.dat must be placed in OpenRails subdirectory, and must not be renamed.
Note that the sigcfg.dat in the OpenRails directory must contain ALL signal definitions, and that ALL related sigscr files (as referenced in sigcfg.dat) must also be copied, in full, to the OpenRails directory.

Regards,
Rob Roeterdink

[Csantucci]

Rob,
to check the change I copied the OR-specific sigscr.dat and sigcfg.dat into an OpenRails subfolder within the route's folder (with their standard .dat extension), and renamed the ones in the route root folder to an unrecognizable name to OR, so I would be sure that it gets the ones in the OpenRails subfolder. I got a pop-up window telling that an essential file is missing (sigcfg.dat) and OR cannot continue. Must the MSTS version of sigcfg.dat be at its place even if it not used?

A new release of the guide is now available in the first post.

[roeter]

Hi Carlo,

Seems something has gone wrong in the update - it works in my testversion, but not in the updated version.
Looks like I missed out on one of the changes somewhere.
Will sort it out.

Regards,
Rob Roeterdink

[roeter]

Ah - I had updated all and everything for trains and signals and what have you, but it had slipped my mind that viewer also loads sigcfg.dat :whistling: .
Corrected in version 2204.

By the way - you can verify which sigcfg.dat is loaded in the log-file, for if the OR-specific file is used, it is shown as SIGCFG_OR instead of SIGCFG.

Regards,
Rob Roeterdink

[Csantucci]

That's OK now Rob, thank you.

[GTADon]

Is there a specific "Sigscr.dat" line or lines that can be added, so that MSTS activities can be run relatively trouble free? I know that there were some specifics that roeter has posted for specific routes. I am speaking now about the Surfliner2 route by Jeff Farquhar using signal scropt by Joseph Hoevet. The signal scripting seems over simplified when compared to some others.

While running activities on this route, I have encountered disappearing AI trains, a white signal (rather than Red or Yellow) and switches that only turn to the other route at the last minute. None of these seem to affect the activity to any great extent, the Player Train is still proceeding! :thumbup3:

[Csantucci]

In my experience in general no changes to sigscr.dat files are needed (of course there are exceptions, and I found one, but it is so peculiar that I'm sure it cannot be found in other routes). What could instead be needed to look at in sigcfg.dat files is shortly described in my guide.

Maybe Rob has something to add about changes to sigscr.dat.

[Csantucci]

Kindly following my request, JTang has committed a patch by myself showing service names instead of "AI" in the dispatch viewer (as also the MSTS AE does), as service names are how the trains are known by activity builders and are also more easily identifiable by players.
Here a screenshot of the modified dispatch viewer:

[markus_GE]

Quick question: Could this also be applied to how AI trains are called in-game? Currently, this also is "AI" for each car... what about calling the first car/locomotive in an AI consist"AI <serviename>", and the others simply "AI", as they are now? Could help a lot with activity debugging...

Cheers, Markus