[eugenR]

I have found two different animation-parts in Semaphore-shapes:
My semaphores produced by gmax have the following animation-parts:
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.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 7 0 )
linear_key ( 1 0 7 0 )
linear_key ( 2 0 7 0 )


In Shapes in German Payware-routes I have found:
anim_node VHEAD2 (
controllers ( 1
tcb_rot ( 2
slerp_rot ( 0 0 0 0 1 )
slerp_rot ( 1 0 0 -0.376271 0.92651 )

Does somebody know the differences of this animation-parts?

I ask because there is a different behavior in MSTS/OR
For the first animation I have to write exact the key-Number
in SemaphorePos(x) in sigcfg.dat for MSTS and for OR
For the second animation for OR I have also to use the exact key-number
In MSTS I can also use the SenphorePos(1 and 2) and the Signal will work correct,
but in OR I have to use exact the SemahorePos( 0 and 1)

Edit:
now I have found what MSTS is doing with the second animation-principle:
If I use as SemaphorePos ( 0 and 2 )
with SemaphorePos(0) the semaphore will be down
with the SemaphorePos(2) the Semaphore will open/close/and_open again !!

OR is using for both animation-principle the semaphorePos(x)
to address directly the corresponding key in the animationdefinition.

[Jovet]

I don't know the point of the difference between tcb_key entries and slerp_rot entries. But the first number in any of those groups is definitely the (key)frame number. Those are the numbers you need to specify in the sigcfg.dat file, yes.

MSTS will silently assume that you really mean frame #0 if you always start at "1" and never specify frame 0 in any of the SemaphorePos entries for that SignalType (or maybe the whole file). But frame numbers start at zero, so that is really the only correct way to enumerate them. Open Rails does not respect the "jury rig" that MSTS does, and I think that's just fine. The file should be corrected. Frame numbers are not something that should be ambiguous.

[eugenR]

Jovet, on 25 December 2016 - 10:55 PM, said:

I don't know the point of the difference between tcb_key entries and slerp_rot entries. But the first number in any of those groups is definitely the (key)frame number. Those are the numbers you need to specify in the sigcfg.dat file, yes.

MSTS will silently assume that you really mean frame #0 if you always start at "1" and never specify frame 0 in any of the SemaphorePos entries for that SignalType (or maybe the whole file). But frame numbers start at zero, so that is really the only correct way to enumerate them. Open Rails does not respect the "jury rig" that MSTS does, and I think that's just fine. The file should be corrected. Frame numbers are not something that should be ambiguous.

I do fully agree with Jovet.
But I have found in German forum's different rules to correct the sigcfg.dat and not all are realy clear for the user.
So I have started some investigations.
I was hoping to find by backward engineering the reason for this fanny behavior of MSTS.

For the moment I have found:
1) This behaviour exist only if the animation is made by slerp_rot entries (rotation animation) and not by tcb_key entries (linear animation).
2) If the shape has as expl. 5 slerp_rot entries with the Key-numbers 0...4, and in the sigcfg.dat the Numbers 4,5,6 are using,
MSTS is using the Key-numbers 0,1,2.
3) There exist also combinations where the semaphorearm is opening and closing several time for reach his end position??? MSTS is calculating several time "around the clock".

For the moment I can't find any sense in this behaviour of MSTS with the rotation animation???
What where the MSTS developers thinking, by realising this animation so complicated?

[jonas]

May be an answer, more than two years ago, I've been dealing with the semaphore-problem here in the forum. In my eyes it has primarily to do with an incorrect numbering of the SemaphorePos(...)-entries in the sigcfg.dat. In many routes, SemaphorePos (1) / (2) is used instead of SemaphorePos (0) / (1). Read more here: english or german There is something said about the naming of the keys too.
The thread of 2014 was this: Semaphores at signals don't move

Merry Xmas!

[Jovet]

eugenR, on 26 December 2016 - 06:47 AM, said:

But I have found in German forum's different rules to correct the sigcfg.dat and not all are realy clear for the user.

I hope I made it clear, above.
:acute:

eugenR, on 26 December 2016 - 06:47 AM, said:

This behaviour exist only if the animation is made by slerp_rot entries (rotation animation) and not by tcb_key entries (linear animation).

I've never seen a slerp_rot entry before, and my signals are just as subject to this behavior.

eugenR, on 26 December 2016 - 06:47 AM, said:

2) If the shape has as expl. 5 slerp_rot entries with the Key-numbers 0...4, and in the sigcfg.dat the Numbers 4,5,6 are using,
MSTS is using the Key-numbers 0,1,2.
3) There exist also combinations where the semaphorearm is opening and closing several time for reach his end position??? MSTS is calculating several time "around the clock".

This is a separate phenomenon. Frame numbers virtually repeat infinitely in both directions.
Let's say you have a three position semaphore arm, with frame #0 at horizontal, #1 at 45°, and #2 at vertical. Virtual frame #3 is the same as frame #0, frame #4 is the same as frame #1, and frame #5 is the same as frame #2... ad nauseum. If you then tell MSTS to move from frame #0 to frame #5, you'll go through two cycles of animation and it will look pretty silly.

Another example: A semaphore or switchstand with two frames of animation. If it's setup to use SemaphorePos values of 1 and 2, then MSTS will (per above) assume that you really mean frames #0 and 1. But Open Rails will think you know what you're talking about and use frames #1 and #0. It uses #0 because frame #2 is a repeat of frame #0. This will cause the semaphore/switchstands to be in the opposite position of the correct one in OR as it is in MSTS!

eugenR, on 26 December 2016 - 06:47 AM, said:

What where the MSTS developers thinking, by realising this animation so complicated?

The only thing weird and quirky about MSTS animation is the 0-versus-1 SemaphorePos fluke outlined above. Everything else I've seen and stated should be pretty standard for rendering engines.

jonas, on 26 December 2016 - 07:53 AM, said:

May be an answer, more than two years ago, I've been dealing with the semaphore-problem here in the forum. In my eyes it has primarily to do with an incorrect numbering of the SemaphorePos(...)-entries in the sigcfg.dat. In many routes, SemaphorePos (1) / (2) is used instead of SemaphorePos (0) / (1). Read more here: english or german There is something said about the naming of the keys too.
The thread of 2014 was this: Semaphores at signals don't move

Yes. That's the "MSTS trying to help you out but really hurting you in the end" fluke described above. It took me a long time to figure out exactly what was going on back in the day, because it's just such a weird intentional-introduction of inconsistency. I don't know what Kuju was smoking at the time but I'm pretty sure it was a banned substance. I am convinced it was their attempt to make the file a bit more user friendly, probably for some internal manager or content creator's whim.

When to use ... SemaphorePos(1) / SemaphorePos(2) in the file sigcfg.dat?
Never! The first frame is always #0. Always start at zero.

[James Ross]

eugenR, on 26 December 2016 - 06:47 AM, said:

What where the MSTS developers thinking, by realising this animation so complicated?

For what it's worth, my experience with MSTS files and the game generally has found that the vast majority of it is actually really simple rules and logic, but sometimes multiple simple things interact in such a way as to make it seem complicated.

Always look for the simplest possible reason for behaviour in MSTS. :)

[jonas]

Jovet, on 26 December 2016 - 11:49 AM, said:

...
When to use ... SemaphorePos(1) / SemaphorePos(2) in the file sigcfg.dat?
Never! The first frame is always #0. Always start at zero.

Thanks for the hint to rework the sites. The question is not a question any more. So I changed the Headline: english or german

[jonas]

Is it possible to implement a correction for the "false" semaphore (1)/(2) signals when reading the sigcfg.dat and the signal shapes of a route in Open Rails?
A virtual correction of course, not back-written into the files. Maybe as an option under "Experimental".

There are a lot of Semaphore-routes affected. Some examples:

• DK2000 (deleted Dec. 28. 2016, a not affected route)
• 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

[Jovet]

jonas, on 26 December 2016 - 03:01 PM, said:

Thanks for the hint to rework the sites. The question is not a question any more. So I changed the Headline: english or german

Well, I wasn't trying specifically to hint that, since there's nothing wrong with rhetorical questions (especially as article titles). But the answer is definitely concise. A few other comments from that page:

Quote

Always use SemaphorePos(0) / SemaphorePos(1) in the file sigcfg.dat for two-stated signals!

Always start at zero no matter how many positions/states the semaphore has. It doesn't apply just to only 2-position signals. It's all of them.

Quote

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 a bug of MSTS (Kuju). Anyway, both signals working fine and are controled by SemaphorePos(0) and SemaphorePos(1) commands in the sigcfg.dat.

It doesn't matter since there's no linear animation. You'll notice that all of the linear_key coordinate values are the same. This is outside the realm of what would be called a bug, because it does nothing wrong and it's not the software iteslf that is coded as such. Those linear_key entries aren't even needed at all since they don't do anything. But there should not be any harm in them being there.

Quote

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.

I have observed this behavior at random and not ever correlated it to the internal design of the animated shape. It could be a contributing factor, I don't know. What is wrong is the initial pose of the animated shapes. Once the pose changes it should be fine. Personally, i've always constructed my 2-position animated shapes with a third frame that mimics the first frame. That also is how the default signal shapes work. I've never had an real problems. I have thought that there are a few bugs with how MSTS updates signals and that this is a symptom of it. It could also simply be that MSTS expects/assumes semaphore shapes (for example) to indicate danger at frame #0 and that this limitation has never been really confirmed.

jonas, on 26 December 2016 - 03:23 PM, said:

Is it possible to implement a correction for the "false" semaphore (1)/(2) signals when reading the sigcfg.dat and the signal shapes of a route in Open Rails?

I am not one who makes those types of decisions, but as I indicated above, I think that the route files should be corrected. While I do like seeing Open Rails perform signaling behaviors as closely to MSTS as possible, this is one case where MSTS is flat-out wrong and stupid, and such things should not be catered to. In my opinion.

As another kind of workaround, the files could be changed to use the values 2 and 3, which should behave the same in both games and which could ease the improper initial-pose bug mentioned above.

[jonas]

Jovet, on 26 December 2016 - 03:59 PM, said:

...Always start at zero no matter how many positions/states the semaphore has. It doesn't apply just to only 2-position signals. It's all of them.
It doesn't matter since there's no linear animation. You'll notice that all of the linear_key coordinate values are the same. This is outside the realm of what would be called a bug, because it does nothing wrong and it's not the software iteslf that is coded as such. Those linear_key entries aren't even needed at all since they don't do anything. But there should not be any harm in them being there...

Good hints. Not name it a bug anymore. Changed the sites accordingly.

Jovet, on 26 December 2016 - 03:59 PM, said:

Quote

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.

I have observed this behavior at random and not ever correlated it to the internal design of the animated shape...Personally, i've always constructed my 2-position animated shapes with a third frame that mimics the first frame. That also is how the default signal shapes work. I've never had an real problems. ...

I've always seen this behavior in MSTS with only-2-frame animated signals. To work around this I've former used to extend the value of the "vol_sphere" until I realized that a third frame, mimic the first, solved it. Since then I don't have any problem about it too.

Jovet, on 26 December 2016 - 03:59 PM, said:

I am not one who makes those types of decisions, but as I indicated above, I think that the route files should be corrected. While I do like seeing Open Rails perform signaling behaviors as closely to MSTS as possible, this is one case where MSTS is flat-out wrong and stupid, and such things should not be catered to. In my opinion.

Of course, it is a bug how the signal files are given, because it was not clear to the signal builders how it should be done. So I understand that this is in no case an error of OpenRails.
But to correct the various route files seems too demanding for many users. On the one hand, the semaphore entries must be corrected carefully in the sigcfg.dat; on the other hand, the animation sequences may have to be changed in the signal shape files.
The point here is that already published routes with buggy signals could / should work with Open Rails too. So my final question is still the same:
Is an additional code sequence in OR possible to correct signals with wrong not 0 based SemaphorePos-entries?