adding multiple signal systems in a route

[johnnyboy99]

I'm curious, because I want to have both my work in progress routes make use of just about all of Travis Ebner's signal systems.
I think how it works is that you insert the lines from the signalscript and signalconfig files into your route's existing sigscr and sigcfg files. Am I getting it right?

[CSRX]

This is something I am curious about too, as I tend to keep screwing it up somehow with combining the B&M Speed Signal files and the switch stand files of Travis'.

[CSXT Q-317]

Yes you can. I have done it a few times. But making sure the scripts are all combined as one can be a tedious thing.

[johnnyboy99]

i've tried adding them to the sigcfg and sigscr files and they don't seem to show up in TSRE. Am I doing it wrong?

[ebnertra000]

So I finally sat down and wrote up this very simple tutorial for merging multiple signal sets into one:

I generally don't offer that much advice for merging signal systems, especially if someone is fairly new to signal files, just because of how easy it is to mess things up. So this tutorial should only be used if you have some familiarity with signal files.

There are a couple ground rules for editing signal files.

1. Before you start, back up all files to be merged. If you do not understand the importance of this, go no further.
2. Ensure that there are no duplicate scripts, signal type names, or anything else, for that matter. OR does not like having two or more things with the same name, and will cause a variety of problems depending on what got duped.
3. (sigcfg only) Each section of the sigcfg has a line at the top of it with a number at the end. (ex. LightsTab ( 8) That number indicates the total number of items are in that section. If that number does not match the actual total, things start breaking. Whenever the number of items in a section is changed, it is absolutely critical that that number is updated. This is a crucial step in every section of the sigcfg.

We'll start with the easy one, the sigscr file. All you need to do is copy the contents of one sigscr into the other, making sure there are no duplicate scripts (read: sripts with the same name. This is relatively rare in my signal sets, but others may not have been so careful). No, really, that's it. Contrary to what you might think, the sigscr file is much easier to work with than the sigcfg, as we will now find out.

Now for the fun part...

We'll do this from the top down. Start by checking that you have all the light textures that you need. The sim will still work if you miss this step, but some of your signals will have a blank square texture for lights.

LightTextures ( 2
LightTex ( "ltex" "TEM_SigLight_1.dds" 0 0 1 1 )
LightTex ( "USS_ltex" "TEM_USS_SigLight_1.dds" 0 0 1 1 )
)

If you have to add light textures, make sure the count in the "LightTextures (" line is updated to match the number of textures present (in the example above, there are 2).

Now check the LightsTab of each file to be merged. Make sure the final file has one each of every light type you will need. Update the count when finished.

LightsTab ( 8
LightsTabEntry (
"SL Red Light"
colour ( 200 227 1 73 )
)

...

If either of your signal sets uses ORTSSIgnalFunctions (all of mine do, but most others probably don't), add those in. Update counts on the off chance they change.

ORTSSignalFunctions ( 4
ORTSSignalFunctionType ( CONTROL )
ORTSSignalFunctionType ( CONTROL2 )
ORTSSignalFunctionType ( CONTROL3 )
ORTSSignalFunctionType ( CONTROL4 )
)

See all that stuff above, that was the easy part. Now we descend into hell.

You must now merge the SignalTypes sections together. Remember that there can be no signal types with the same name. Care must be taken to not accidentally add or cut off brackets. Keeping count of the total number of types will be a bit more difficult than before, just because of how much larger and more inconsistently sized signal types tend to be. All of my sets have comments with the total count every five types. This will get you through the first set, but subsequent sets will need to be counted manually. I suggest msking your own comments to aid in counting.

SignalTypes ( 79
SignalType ( "TEM_Dummy"
SignalFnType ( DISTANCE )
SignalLightTex ( "ltex" )
SignalLights ( 0 )
SignalDrawStates ( 0 )
SignalAspects ( 0 )
)

...

The last step is merging the SignalShapes sections. Again, this is a bit bulkier of a section, though likely less so than the SignalTypes section. Just like the SignalTypes section, I recommend inserting comments at regular intervals to aid in keeping the totals straight. Again, make sure no brackets get added or cut off.

SignalShapes ( 48
SignalShape (
"DNE_Ctrl_Signal_1.s"
"DNE Ctrl. Signal"
SignalSubObjs ( 21
SignalSubObj ( 0
"SIGNAL"
"Select only one"
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "DNE_Ctrl_Sig" )
)
SignalSubObj ( 1
"SIGNAL"
"Link Routes"
SigSubType ( DECOR )
SignalFlags ( OPTIONAL )
)

...

This should work. If it doesn't, you might need to just post the files here

[slipperman]

Hi Travis,
Thank you for that tutorial on merging multiple signal sets into one.

You mention that duplicate signal types and script names should be avoided. I'd like to suggest that my sigcfg_Checker utility (file ID 87608) will identify such entries. It also reports on any discrepancies between the entries in the sigcfg.dat file, all sigscr.dat files and the route's .tdb file.
Currently, the program doesn't check that the open and close brackets within each section balance, but it is something I would consider adding.

Cheers,
Ged

[johnnyboy99]

I tried it with the 1966 ATSF signals and... IT WORKED!!! thanks Travis!

[johnnyboy99]

Also I have a question about your signals ebnertra000: Are they supposed to not have a link button in their subobject settings? Do they work automatically unlike some other signal systems?

[ebnertra000]

Also I have a question about your signals ebnertra000: Are they supposed to not have a link button in their subobject settings? Do they work automatically unlike some other signal systems?

The signal shapes? Any signal that needs routing information checks the state of a separate 'control' signal that is used to set them. Depending on layout, links may not be necessary, but it is possible to set them anyway.

I think you'll find there's a document in each set which explains this functionality, along with a test route that demonstrates it

[johnnyboy99]

Yeah I tried out the route I put them in and it crashes when I move the camera to a tile with them in ORTS. Somehow it doesn't happen in TSRE
Did I not do it right?
OpenRailsLog.zip

[ebnertra000]

Umm...how many signal sets are you adding to this route? It looks like there's probably a syntax error somewhere, but I couldn't tell you where for sure

[johnnyboy99]

I tried adding alot of them, but in hindsight maybe I should have added just 1 or 2