[beresford]

The semaphore signals on the 'Just Trains' West Somerset route are showing a green light while the arm is horizontal. X2417.

[roeter]

Sounds rather like the well-known problem of semaphore position count mismatch. In that situation, the values defined for "semaphore position" in sigcfg.dat do not match the defined animation positions in the related s-file.
Often this problem can be solved by adapting the semaphore position values in sigcfg.dat, e.g. if these now are "0" and "1", try changing these to "1" and "2" (0 -> 1, 1 -> 2).

Regards,
Rob Roeterdink

[beresford]

Went back and tried the activity in MSTS and the signals were fine, so I am reluctant to start editing data files. Ironically the activity is titled 'Signal Training'.

The first signal encountered shows a correct aspect but something else is odd, the Track Monitor seems to be showing both the Home signal AND the dummy. The previous picture is at the other end of the platform and thereafter all non-distant semaphore signals show green and horizontal.

Attached thumbnail(s)

• 

[markus_GE]

I´ve just been asked to look at a similar problem on a German forum, and personally had no clue, but somebody else came up with the solution: You really need to edit the files, but it will not break anything for MSTS - remarkably, MSTS makes it to slip over the actual data error, that ORTS actually does not find.

Cheers, Markus

PS: Info found here originally (German): http://www.tssf.eu/f...p?topic=10546.0

[Rogue]

markus_GE, on 18 August 2014 - 03:33 PM, said:

PS: Info found here originally (German): http://www.tssf.eu/f...p?topic=10546.0

Hello beresford,

I am the one who placed this topic in the a.m. german forum.
Therefore I want to give you a rough translation of the solution so that your signals show the correct position again.
It's already explained in roeter's answer: the problem lies within the sigcfg.dat (you'll find this one in the main routes file).
The signal position is defined in the parameter "SemaphorePos". The number in every bracket must be identical to the number in the above parameter "SemaphoreDrawState".
Furthermore, the numbers must count from zero onwards.
Here's an example of a correct entry:

SignalType ( "bs_hpla_hp1_100"
SignalFnType ( NORMAL )
SignalFlags ( ABS )
SignalLightTex ( "ptsi_sigtex" )
SignalDrawStates ( 2
SignalDrawState ( 0
"Hp0"
SemaphorePos ( 0 ) <---- starting with zero
)
SignalDrawState ( 1
"Hp1"
SemaphorePos ( 1 )
)
)

Here's an example of an INCORRECT entry.
The numbers in the SemaphorePos are not in order and do not match the numbers in SemaphoreDrawState:

SignalDrawStates ( 4
SignalDrawState ( 0
"Aus"
SemaphorePos ( 0 )
)
SignalDrawState ( 1
"Vr0"
DrawLights ( 2
DrawLight ( 0 )
DrawLight ( 1 )
)
SemaphorePos ( 3 )
)
SignalDrawState ( 2
"Vr1"
DrawLights ( 2
DrawLight ( 2 )
DrawLight ( 3 )
)
SemaphorePos ( 1 )
)
SignalDrawState ( 3
"Vr2"
DrawLights ( 2
DrawLight ( 1 )
DrawLight ( 2 )
)
SemaphorePos ( 2 )
)
)


You can open this file with a text editor or Notepad++ and change all the entries into the correct order.
Alas you have to do this by hand....I have not found a proper formular who could solve this matter in an automatic way.

Cheers
Boris

[beresford]

Thanks for your assistance. This business of parameters that are ignored by MSTS and are suddenly revealed as wrong in OR is getting to be a real pain.

You will be telling me next that one of the answers to my WSR Manor thread which nobody replied to is that the reason the brakes are ridiculously slow to come off in OR but fine in MSTS is that MSTS ignores the MaxReleaseRate parameter in the ENG file. :rotfl:

[Note: I found that the BA Manor has a Release Rate almost twice that of the WSR Manor).

[beresford]

As I understand it roeter's explanation is NOT the same as that of rogue. Rogue cites incorrect case number sequences in the sigcfg file whereas roeter cites a mismatch between the case numbers in sigcfg and the s-file. Presumably MSTS just uses the ordering of the cases rather than correlating the numbers.

I believe that the attached sigcfg file (zipped to get round some restriction about what I am allowed to upload) doesn't show any discrepancy in the sequences for the semaphore-type signals, and therefore roeter's explanation must apply.

Any takers for why the Track Monitor is showing red AND green in the second picture? Ironically this semaphore seems to be the only one which works correctly.

Attached File(s)

•  sigcfg.zip (3.58K)
  Number of downloads: 186