Always start with SemaphorePos(0) to define the states of signals in sigcfg.dat file!
But why instead found first states of signals as SemaphorePos(1) in some sigcfg.dat files?
SemaphorePos(1)-commands as first state of a signal found e.g. among these routes:
EuroTS_Ahrtal • LzSuO • PT_Berlin_Dresden_PT05 • PT_Berlin_Rostock_PT9 • PT_Berlin-Hamburg_PT04_TSP • PT_Berlin-Hannover_PT08 • PT_Karwendelbahn • PT_Nürnberg_Frankfurt_Spessartrampe_PT07 • PT_RR • VFL
In the original MSTS-routes you only find SemaphorePos(0) and SemaphorePos(1) entries. The 0 and the 1 name the Frame-Indexes of the animationsequence in the signal-shape-file.
Animationsequence of the signal shape file "UKSemaphore1.s" of the MSTS-Route "EUROPE1":
animation ( 1 25 anim_nodes ( 2 ... anim_node HEAD1 ( controllers ( 2 tcb_rot ( 3 tcb_key ( 0 0 0 -0.34202 0.939693 0 0 0 0 0 ) tcb_key ( 1 0 0 0 1 0 0 0 0 0 ) tcb_key ( 2 0 0 -0.34202 0.939693 0 0 0 0 0 ) ) linear_pos ( 2 linear_key ( 0 -0.069311 4.67425 -0.092896 ) linear_key ( 2 -0.069311 4.67425 -0.092896 ) ) ) |
 |
Animationsequence of a signal of the MSTS-Route "EUROPE2":
controllers ( 2 tcb_rot ( 3 tcb_key ( 0 0 0 0 1 0 0 0 0 0 ) tcb_key ( 1 0 0 -0.382683 0.92388 0 0 0 0 0 ) tcb_key ( 2 0 0 0 1 0 0 0 0 0 ) ) linear_pos ( 2 linear_key ( 0 0.05937 5.80925 -0.026609 ) linear_key ( 1 0.05937 5.80925 -0.026609 ) ) ) |
 |
Note that the rotation-keys (tcb_key) have 3 Frames: 0,1 and 2. The linear-keys have only 2 frames, whereby at the upper signal a linear-key it is indexed with 2 instead of 1. Maybe an inattention of MSTS (Kuju). Anyway, both signals working fine and are controled by SemaphorePos(0) and SemaphorePos(1) commands in the sigcfg.dat.
If you try to use a signal with an only-2-frame animation with SemaphorePos(0) und SemaphorePos(1) commands, MSTS will not draw the positions of the semaphores correctly.
A animationsequence like this...
animation ( 1 25
anim_nodes ( 2
...
anim_node HEAD1 (
controllers ( 2
tcb_rot ( 2
tcb_key ( 0 0 0 0 1 0 0 0 0 0 )
tcb_key ( 1 0 0 -0.382683 0.92388 0 0 0 0 0 )
)
linear_pos ( 2
linear_key ( 0 -0.069311 4.67425 -0.092896 )
linear_key ( 1 -0.069311 4.67425 -0.092896 )
)
)
...has indeed frame 0 and frame 1, but in MSTS the semaphore keeps lying horizontal at frame 0 since the signal is beeing loaded, despite another signalaspect is shown by the lights and the related semaphore position required frame 1. Only when the train is passing the signal the semaphore jumps briefly to frame 1 and then immediatley back to the frame 0 position to show the signal aspect STOP. At the start of the video you see the green signal lights despite the semaphore shows STOP.
This wrong effect probably caused some signal builders to control their only-2-frame-signals with SemaphorePos (1) and SemaphorePos (2) instead of SemaphorePos (0) and SemaphorePos (1). Because in fact, 2-frame-signals in MSTS work almost exactly this way, which is of course confusing, since now SemaphorePos (1) sets the frame 0 and SemaphorePos (2) the frame 1!
(By the way, such signal has the speciality that it change the semaphore-position only if "you look at it". If you stay in cabview while passing the signal the semaphore stays in the position you last have seen it. That means mostly the semaphores keeps showing the aspect "CLEAR", therefore frame 1. At the same time the lights shows the signal aspect "STOP". (Examined it is in a way more realistic concerning to semaphores, because in real life the dispatcher needs a few minutes to bring the semaphores in horizontal STOP position aspect. )
Conclusion: Ideal for MSTS and OpenRails
-use SemaphorePos(0)- and SemaphorePos(1)-commands in the sigcfg.dat
-signal-shapes should have 3 frames ( 0, 1, 2 ) in the animationsequence
Example of an ideal animationsequence for MSTS and OpenRails:
animations ( 1
animation ( 3 30
anim_nodes ( 2
anim_node SIGNAL (
controllers ( 0
)
)
anim_node HEAD1 (
controllers ( 2
tcb_rot ( 3
tcb_key ( 0 0 0 0 1 0 0 0 0 0 )
tcb_key ( 1 0 0 -0.34202 0.939693 0 0 0 0 0 )
tcb_key ( 2 0 0 0 1 0 0 0 0 0 )
)
linear_pos ( 3
linear_key ( 0 0 10.0001 -0.1 )
linear_key ( 1 0 10.0001 -0.1 )
linear_key ( 2 0 10.0001 -0.1 )
)
)
)
)
)
)
Known tollerances in MSTS and Open Rails
-in the line "animation ( 3 30 ": it don't had to be a 3 despite there are 3 frames. The number here doesn't matter in MSTS. The 30 is certainly needed and a must. For OpenRails both numbers are not important.
-it is enough, when only one controller has 3 Keys to declare the hole signal animationsequence as a 3-frame-sequence
-in MSTS the tag name for a key is irrelevant. For Example you can use "blabla" instead of "tcb_key". At least one sign it has to be. OpenRails expects here the exact names: tcb_key, slerp_rot, linear_key, tcb_pos etc.
----------------------------------------------------------------------------------------------------
To demonstrate the case a semaphore has more than 2 positions, I build a signal with 6 positions. This signal has consequently 7 Frames (7 Keys - Key 1 and Key 7 have the same values). If the semaphore of this signal moves from frame 0 to frame 6, MSTS draws all the positions in between:
6 frame related animationsequence:
anim_node HEAD1 (
controllers ( 2
tcb_rot ( 7
tcb_key ( 0 0 0 0 1 0 0 0 0 0 )
tcb_key ( 1 0 0 -0.382683 0.92388 0 0 0 0 0 )
tcb_key ( 2 0 0 0 1 0 0 0 0 0 )
tcb_key ( 3 0 0 0.382683 -0.92388 0 0 0 0 0 )
tcb_key ( 4 0 0 0 1 0 0 0 0 0 )
tcb_key ( 5 0 0 0.382683 0.92388 0 0 0 0 0 )
tcb_key ( 6 0 0 0 1 0 0 0 0 0 )
)
linear_pos ( 7
linear_key ( 0 0.05937 5.80925 -0.026037 )
linear_key ( 1 0.05937 5.80925 -0.026037 )
linear_key ( 2 0.05937 5.50925 -0.026037 )
linear_key ( 3 0.05937 5.20925 -0.026037 )
linear_key ( 4 0.05937 4.90925 -0.026037 )
linear_key ( 5 0.05937 4.60925 -0.026037 )
linear_key ( 6 0.05937 5.80925 -0.026037 )
)
)
)