[edwardk]

While running BNSF_Seligman2, the log indicated 2 duplicate signal shapes.

Skipped duplicate SignalShape SLI_H2_APP_GANTRY.S in F:\Train Sims\Microsoft Games\Train Simulator\ROUTES\BNSF_Seligman2\sigcfg.dat:line 1111

Skipped duplicate SignalShape SLI_H2_APP_GANTRY.S in F:\Train Sims\Microsoft Games\Train Simulator\ROUTES\BNSF_Seligman2\sigcfg.dat:line 1129


This is how the signal shapes are being used.

SignalShape (
"SLI_H2_APP_GANTRY.s"
"H2 APPROACH GANTRY"
SignalSubObjs ( 2
SignalSubObj ( 0
"HEAD1"
"Signal Head 1"
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "H2_ADV_TOP_TL" )
)
SignalSubObj ( 1
"HEAD2"
"Signal Head 2"
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "H2_ADV_BOTTOM_TL" )
)
)
)
SignalShape (
"SLI_H2_APP_GANTRY.s"
"H2 APPROACH GANTRY LUNAR"
SignalSubObjs ( 2
SignalSubObj ( 0
"HEAD1"
"Signal Head 1"
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "H2_ADV_TOP_TL" )
)
SignalSubObj ( 1
"HEAD2"
"Signal Head 2"
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "H2_ADV_BOTTOM_TL_LUNAR" )
)
)
)

The first use of this shape is of course further up the sigcfg.dat. The final message in the log is I am missing 2 shapes. Evidently MSTS was able to work with this and OR is unable to. Is there a way to fix this because it is apparent that the above definitions are not being used in the route(or are they actually being used as defined)?

Edward K.

[roeter]

Hello Edward,

you missed the first use of this shape, at line 1017 - that's why it's reported twice : the same shape is used three times.
The problem is that when a signal is processed, it is required to know which 'heads' and 'flags' it can have or is supposed to have. If the same shape refers to multiple signal definitions, this can no longer be properly determined.
To sort this out by 'back-reference' using the tdb-entry is quite difficult and far from fail save. If some heads are optional, the combination of actual heads could be similar for different types of signals. But other items, like flags, could be different.

What actually happens when this error occurs depends largely on the signal definition.
The sigcfg info is used for the signal shape in the world file mainly to determine the use of the flags as defined in the world file entry. This defines optional heads and flags. These shapes will now always use the same signal-type which may result in incorrect interpretation of these flags. But if there are no flags (as is the case here), the error will actually not effect the proper working. The relation between the signalhead and the required script is not taken from the information in the sigcfg.dat but from the tdb file, this is not affected by this error.

To sort this is quite tricky.
First, make copies of this shape-file and rename these according to the signal type names.
Next, you will have to go through all world-files looking for these (original) signal-shapes.
When found, check the related tdb-entries for the type of signalheads and, from this combination, determine the actual type of signal. Rename the world entry according to this type.


In all, such multiple use creates problems and is best avoided. To do so when creating a route is really no trouble at all, as the shapes can just be copied and given a different name. So, this multiple use is a false economy which saves the route builder about 1 minute and would take days or even weeks of programming to sort out.
Moreover, this is what it says in the original MSTS techdoc on signal definitions :

Quote

There should only be one signal shape definition for each signal object .s filename, since the shape filename is the unique identifier used. If a different shape definition is required for the same shape (e.g. with the ABS flag) then create a copy of the .s file and rename it as appropriate.

So the use of multiple definition with one shape as in this case is simply incorrect.

Regards,

Rob Roeterdink

[rdamurphy]

This probably works in MSTS because Kuju used the name of the signal, i.e. "H2 APPROACH GANTRY", and then referenced the shape file to it, rather than using the shape file itself to identify the signal.

I do know that if you have to signals with the same name, it will crash MSTS without so much as a "phone home" message. (BTW, anyone but me still click on those to send the info to MS? LOL!)

I'm not sure that solution will work, though? Rob's the expert on the signal files...

Robert

[R H Steele]

rdamurphy "I do know that if you have to signals with the same name, it will crash MSTS without so much as a "phone home" message. (BTW, anyone but me still click on those to send the info to MS? LOL!)"

I'll fess-up, when I started some months ago (pre Open Rails for me) MSTS crashed and after an interminable wait the "phone home" message popped up and I bit. Still LOL Cheers, rhs (aka gerry)

Thanks for the excellent work to the development team! Need sandwiches or beer?