[eugenR]

German users have fond a difference in the semaphore-animation between MSTS and OR, in the Route German Railroad (GR) Rollbahn. The attached Testroute use the shape and parts of the signal-files of this Route. The activity Testgreen is using only the upper arm. The activity Testyellow is using both arms of the semaphore.

The semaphore-shape, which shows the problem, has two arms, “F1” =Arm1, “F2” = Arm2.
For each arm there are supplementary parts in the shape, as Blende, LBlende, Gewicht.
Blende are light-covers for the red/green/yellow lights.
LBlende are light-covers for the white lights at the backside of the semaphore
Gewicht are counterbalances for the arms (are showing as a hammer).
All parts of the shape are linked at the main-part “MAST”. There is no other hierarchy in the shape:

hierarchy ( 20 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 )

The difference between MSTS and OR is:
MSTS animate all Parts of the Arm1 and if is needed also all Parts of the Arm2.
OR animate only Part “F1” and if it is needed Part “LBlende2”.
“F1” and “LBlende2” are commanded by the sigcfg.dat:

SignalShape (
		"kngerHP_0_2s.s"
		"F 2s (HP0/HP1/HP2)"
		SignalSubObjs ( 2
			SignalSubObj ( 0
				"F1"
				"Head 1"
				SigSubType ( SIGNAL_HEAD )
				SigSubJnLinkIf ( 1 1 )
				SigSubSType ( "HP_0_2_NormalS" )
			)
			SignalSubObj ( 1
				"LBlende2"
				"Head 2"
				SigSubType ( SIGNAL_HEAD )
				SigSubSType ( "HP_0_2_Info_VarS" )
			)

Animation-Part of the shape:

	animations ( 1
		animation ( 2 30
			anim_nodes ( 20
				anim_node MAST (
					controllers ( 0 )
				)
				anim_node F1 (
					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 ( 3
							linear_key ( 0 0 8.0001 -0.18 )
							linear_key ( 1 0 8.0001 -0.18 )
							linear_key ( 2 0 8.0001 -0.18 )
						)
					)
				)
				anim_node BLENDE1 (
					controllers ( 2
						tcb_rot ( 3
							tcb_key ( 0 0 0 0 1 0 0 0 0 0 )
							tcb_key ( 1 0 0 -0.358368 0.93358 0 0 0 0 0 )
							tcb_key ( 2 0 0 0 1 0 0 0 0 0 )
						)
						linear_pos ( 3
							linear_key ( 0 0.088 7.75 -0.11 )
							linear_key ( 1 0.088 7.75 -0.11 )
							linear_key ( 2 0.088 7.75 -0.11 )
						)
					)
				)
				anim_node LBLENDE1 (
					controllers ( 2
						tcb_rot ( 3
							tcb_key ( 0 0 0 0 1 0 0 0 0 0 )
							tcb_key ( 1 0 0 -0.48481 0.87462 0 0 0 0 0 )
							tcb_key ( 2 0 0 0 1 0 0 0 0 0 )
						)
						linear_pos ( 3
							linear_key ( 0 0.17 7.7 0.104 )
							linear_key ( 1 0.17 7.7 0.104 )
							linear_key ( 2 0.17 7.7 0.104 )
						)
					)
				)
				anim_node GEWICHT (
					controllers ( 2
						tcb_rot ( 3
							tcb_key ( 0 0 0 0.382683 0.92388 0 0 0 0 0 )
							tcb_key ( 1 0 0 0 1 0 0 0 0 0 )
							tcb_key ( 2 0 0 0.382683 0.92388 0 0 0 0 0 )
						)
						linear_pos ( 3
							linear_key ( 0 0 8 -0.137499 )
							linear_key ( 1 0 8 -0.137499 )
							linear_key ( 2 0 8 -0.137499 )
						)
					)
				)
				anim_node GEWICHT2 (
					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 ( 3
							linear_key ( 0 3.79367e-005 4.61 -0.175 )
							linear_key ( 1 3.79367e-005 4.61 -0.175 )
							linear_key ( 2 3.79367e-005 4.61 -0.175 )
						)
					)
				)
				anim_node LBLENDE2 (
					controllers ( 2
						tcb_rot ( 3
							tcb_key ( 0 0 0 0 1 0 0 0 0 0 )
							tcb_key ( 1 0 0 -0.48481 0.87462 0 0 0 0 0 )
							tcb_key ( 2 0 0 0 1 0 0 0 0 0 )
						)
						linear_pos ( 3
							linear_key ( 0 0.17 5.70004 0.104 )
							linear_key ( 1 0.17 5.70004 0.104 )
							linear_key ( 2 0.17 5.70004 0.104 )
						)
					)
				)
				anim_node F2 (
					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 ( 3
							linear_key ( 0 0 6 -0.18 )
							linear_key ( 1 0 6 -0.18 )
							linear_key ( 2 0 6 -0.18 )
						)
					)
				)
				anim_node BLENDE2 (
					controllers ( 2
						tcb_rot ( 3
							tcb_key ( 0 0 0 0 1 0 0 0 0 0 )
							tcb_key ( 1 0 0 -0.358368 0.93358 0 0 0 0 0 )
							tcb_key ( 2 0 0 0 1 0 0 0 0 0 )
						)
						linear_pos ( 3
							linear_key ( 0 0.088 5.75004 -0.11 )
							linear_key ( 1 0.088 5.75004 -0.11 )
							linear_key ( 2 0.088 5.75004 -0.11 )
						)
					)
				)
				anim_node LAMPEN2 (
					controllers ( 0 )
				)
				anim_node PATRONEN (
					controllers ( 0 )
				)…………………

I have found the following Animation-Rule for MSTS.

MSTS animate with the Part “F1”, if there is no hierarchy given in the Shape, and also all other parts in the animation-block until the next, in the sigcfg.dat given name (here: “LBlende2”).
You can control this rule with the part “Gewicht2”, which is written in the animation-block before “LBlende2”!!! MSTS animate “Gewicht2” with arm “F1”, (what seems to be an error in this shape). With the part “LBlende2”, MSTS animate all following parts (“F2”, “Blende2”)

I don’t know if this is a regular animation-rule of MSTS, which is not implemented in OR until yet?

Regards
EugenR

Attached File(s)

•  CHSignaltest.zip (4.06MB)
  Number of downloads: 218

[Jovet]

The signal shape is not constructed correctly. That is not the correct way to setup signal animation.

[eugenR]

Jovet, on 19 March 2017 - 09:45 PM, said:

The signal shape is not constructed correctly. That is not the correct way to setup signal animation.

Hi Jovet,
I was thinking so, thank you.
But how I have to do, if a Signalarm has more then one part to animate with the same script (here Arm and Blende)?
If in gmax, I link the second part to the first, MSTS doesn't show the signal?
So I know only this way:
I make for every Part of the Arm a separate SignalSubObj in the sigcfg.dat.
Do you know an other method?

regards
EugenR

[Jovet]

eugenR, on 21 March 2017 - 07:51 AM, said:

But how I have to do, if a Signalarm has more then one part to animate with the same script (here Arm and Blende)?
If in gmax, I link the second part to the first, MSTS doesn't show the signal?
So I know only this way:
I make for every Part of the Arm a separate SignalSubObj in the sigcfg.dat.
Do you know an other method?

The solution is in the part hierarchy itself.

In the sigcfg.dat file, when you setup a SignalSubObj, you assign a single part/node in the shape's hierarchy which is made visible and which receives the assigned SignalType. Let's call that the specified node. If you want multiple parts to be animated with that SignalType, then those extra parts must be child nodes of the specified node. When the specified node is animated, all of the child nodes are animated in suite. On my semaphore signals having this situation, I assign the SignalType to a special non-animated part. The animated parts are then child nodes of that non-animated node, usually in a chain like your wrist animates from your elbow which animates from your shoulder. But disparate animation can take place by having multiple nodes that are direct children of the specified node as they will be all animated separately in their own little hierarchies. As long as a node is or is a child of the specified node, then it will animate when the SignalType is animated.

In Gmax you can assign each node a "SubObject ID" value from 0-63. All parts/nodes of ID #0 will always be visible on a signal. Using values other than zero allows for optional parts on a signal shape. If you want an optional semaphore arm, for example, then the specified node and all of its child nodes should have the same ID value. When the specified node is called for by the game, then all of the same ID nodes will also be turned on. This means that only one SignalSubObj entry is necessary, both for animation and show/hide purposes. But it is also possible to have child parts in your semaphore arm hierarchy be optional--an example of this might be a lens cover which can be turned on for a roundel on an arm that never changes aspect. This can be a distinct ID value and will require its own SignalSubObj entry to turn on. And this means that those separate parts can be turned on when the signal arm itself is not visible, which is just something the route author needs to avoid doing.

I apologize that this is kind-of hard to explain in just text, but keep in mind the key points: 1) Each SignalType on a signal SignalSubObj entry only gets one specified node; 2) That specified node and all of its child nodes are animated together; 3) multiple animated parts for things like a semaphore arm need to be children of that specified node; 4) all of the nodes for that specified node hierarchy should have the same "SubObject ID" in Gmax. If you still have questions, PM me and we can trade some example source files or something.

[eugenR]

Jovet, on 21 March 2017 - 08:30 AM, said:

The solution is in the part hierarchy itself.

In the sigcfg.dat file, when you setup a SignalSubObj, you assign a single part/node in the shape's hierarchy which is made visible and which receives the assigned SignalType. Let's call that the specified node. If you want multiple parts to be animated with that SignalType, then those extra parts must be child nodes of the specified node. When the specified node is animated, all of the child nodes are animated in suite. On my semaphore signals having this situation, I assign the SignalType to a special non-animated part. The animated parts are then child nodes of that non-animated node, usually in a chain like your wrist animates from your elbow which animates from your shoulder. But disparate animation can take place by having multiple nodes that are direct children of the specified node as they will be all animated separately in their own little hierarchies. As long as a node is or is a child of the specified node, then it will animate when the SignalType is animated.

In Gmax you can assign each node a "SubObject ID" value from 0-63. All parts/nodes of ID #0 will always be visible on a signal. Using values other than zero allows for optional parts on a signal shape. If you want an optional semaphore arm, for example, then the specified node and all of its child nodes should have the same ID value. When the specified node is called for by the game, then all of the same ID nodes will also be turned on. This means that only one SignalSubObj entry is necessary, both for animation and show/hide purposes. But it is also possible to have child parts in your semaphore arm hierarchy be optional--an example of this might be a lens cover which can be turned on for a roundel on an arm that never changes aspect. This can be a distinct ID value and will require its own SignalSubObj entry to turn on. And this means that those separate parts can be turned on when the signal arm itself is not visible, which is just something the route author needs to avoid doing.

I apologize that this is kind-of hard to explain in just text, but keep in mind the key points: 1) Each SignalType on a signal SignalSubObj entry only gets one specified node; 2) That specified node and all of its child nodes are animated together; 3) multiple animated parts for things like a semaphore arm need to be children of that specified node; 4) all of the nodes for that specified node hierarchy should have the same "SubObject ID" in Gmax. If you still have questions, PM me and we can trade some example source files or something.

Hi Jovet,
to close this thread for the public,
the red text was the hint for my problems.
In many German Railroad (GR) routes they didn't found this solution.
The have defined in the sigcfg.dat for every animated part "specified nodes", all with a similar script in the sigscr.dat
thank you so much
EugenR

[Jovet]

eugenR, on 21 March 2017 - 11:32 PM, said:

to close this thread for the public,
the red text was the hint for my problems.
In many German Railroad (GR) routes they didn't found this solution.
The have defined in the sigcfg.dat for every animated part "specified nodes", all with a similar script in the sigscr.dat
thank you so much

Glad I can help and that you got it sorted out!

There are times when multiple SignalTypes can keep things flexible—for example, I would want to keep the semaphore arm and the separate Vorsignal disc separate, so the Vorsignal disc SignalType can be used on its own, too. But that's me.... and having a bunch of extra SignalTypes would not be a happy solution for me, since I like things efficient.