[NF1-800]

Jovet, on 27 December 2016 - 05:52 AM, said:

I remember, and I never really ever understood why it would still not work properly in MSTS.

Wait, in MSTS the signal works properly, the problem with the 3rd indication occurs in OR.

[Csantucci]

Jonas and Eugen, you're saying two different things. Accordingly to Jonas you must simply reduce by one the animation step indicated in sigcfg.dat for semaphores in the case the lowest one is 1 and not 0.
Accordingly to Eugen, instead, if there are three animation steps in the .s file, the signal works correctly even if the lowest animation step indicated in sigcfg.dat is 1; only signals having only two animation steps in the .s file, and having the lowest animation step indicated in sigcfg.dat equal to 1 don't work correctly. So the reduction by one in sigcfg.dat is subject also to a check into the .s file.

This, if I understood correctly. So, which one is the correct version?

[jonas]

I am sure that a reduction of all SemaphorePos by 1 for a signal with the minimum value "SemophorePos(1)" solves the problem for OR. For MSTS this would have further consequences, one would then also have to consider the animation frames in the shape file and, if so, change it. However, no files should to be changed, instead of only a virtual correction of the SemaphorePos when loading the sigcfg.dat in OR.

Conclusion for me: For OR it is sufficient only to virtual change the SemaphorePos in the sigcfg.dat.

But Eugen is right if someone will solve the problem for both OR and MSTS by changing files I think.

[eugenR]

Csantucci, on 27 December 2016 - 12:45 PM, said:

So the reduction by one in sigcfg.dat is subject also to a check into the .s file.
This, if I understood correctly. So, which one is the correct version?

I am not Shure if the check in the .s file will be the right solution,
but I have found for the Moment two results where MSTS doesn't move the SemaporePos-Numbers

first:
Shape with 3 entry's (0 to 2), entry 2 is equal 0 and two Semaphorepos( 1,2) the Signal is showing correct the Pos 1 and 2
Better exblication:
Tested shape has had 3 entry's (two+end-entry equal the first entry)
In Sigcfg.dat was written SemaphorePos 1 and 2
The Signal in MSTS has shown the Semaphorearm correct corresponding to Pos 1 and 2 (equal Pos0)
So I have found, with this animation-block MSTS doesn't calculate the semaphorePos down by -1


second:
Shape with 6 entry's (0 to 5), entry 5 is equal 0 and three Semaporepos(1,3,4) the Signal is showing correct the Pos 1,3 and 4
Better explication:
Tested shape has 6 entry's (5+endentry equal to the first entry)
In Sigcfg.dat was written SemaphorePos( 1,3,4)
The Signal in MSTS has shown correct corresponding to Pos 1,3,4
Also here MSTS doesn't calculate down the SemaphorePos. by -1


So we can't calculate down all Numbers if the SemaphorePos(0) in the Sigcfg.dat is missing!
We have to find a second limit for this movements, other ways we will disturb other (working) Signals!

EugenR

[jonas]

eugenR, on 27 December 2016 - 01:47 PM, said:

...
second:
Shape with 6 entry's (0 to 5) entry 5 is eaual 0 and three Semaporepos(1,3,4) the Signal is showing correct the Pos 1,3 and 4
...

I don't know this signal, thats why I ask, is this example from a real used signal, Eugen?

A requirement for simply reducing the semaphores by 1 is, of course, that the indices of the animation key lines in the signal shape file are continuous. And the number of keys is equal to the number of SemphorePos()-entries. Perhaps the simple reduction of SemaphorePos values by 1 should only be applied to 2-key animated signals. Two keys with the value 0 and 1. This would correct the most wrong working semaphore signals.

[Jovet]

eugenR, on 27 December 2016 - 01:47 PM, said:

Shape with 3 entry's (0 to 2) entry 2 is equal 0 and two Semaphorepos( 1,2) the Signal is showing correct the Pos 1 and 2
Shape with 6 entry's (0 to 5) entry 5 is eaual 0 and three Semaporepos(1,3,4) the Signal is showing correct the Pos 1,3 and 4
So we can't move down all Numbers if the SemaphorePos(0) is missing!
We have to find a second limit for this movements, other ways we will disturb other (working) Signals!

Are there other SignalTypes in the same file as those you mentioned which have SemaphorePos( 0 ) entries?
It could be that MSTS considers all SignalTypes in the entire file, and if none of them employ any SemaphorePos( 0 ) values, then it lowers all of them.... but if just one "0" value is present then it does not internally lower any of them.

[jonas]

eugenR, on 27 December 2016 - 08:23 AM, said:

...
Is this rule correct:
Modify, if in the Signaltypedefinition are no SemphorePos( 0 ) AND
and the Animationpart in the shape which correspond with this Signaltype has only 2 steps ( not 3 or more ).
...

Finally, I see it now the same way. I agree.

[eugenR]

Jovet, on 27 December 2016 - 02:46 PM, said:

Are there other SignalTypes in the same file as those you mentioned which have SemaphorePos( 0 ) entries?
It could be that MSTS considers all SignalTypes in the entire file, and if none of them employ any SemaphorePos( 0 ) values, then it lowers all of them.... but if just one "0" value is present then it does not internally lower any of them.

Yes there where been others with SemaphorePos(0), but I have now tested the case with 3 Entry's with all other Semaphorepos >=1 in the same Sigcfg.dat, same result. No Change of Number's in MSTS.

jonas, on 27 December 2016 - 02:37 PM, said:

I don't know this signal, thats why I ask, is this example from a real used signal, Eugen?
.....

No, this are Testcases, but I think we must carefully found the limits for the Design-Rules.
All feasible possibility are used by somebody!
Jovet has discussed in Post #5 about fanny phenomena with Semaphore-Animation. Things like that are certainly not used for Semaphores, but what will happens if somebody has used this for rotate colored parts instead of defined signallamps? This behavior will not annoy this lamps!

jonas, on 27 December 2016 - 02:37 PM, said:

This would correct the most wrong working semaphore signals.

Can You have a look, if we doesn't catch a case with my proposed Rule?
I think we should find with as many Tests a possible the correct Design-Rules

eugenR

[Csantucci]

My two cents. Here we are discussing about implementing an exception. Exceptions should be as limited as possible in application to avoid damaging correct working cases. If we are limiting too much, no problem: we already will have improved the situation, and we can always widen later the exception to cover uncovered cases.
So reading the interventions by the signal experts here I see that the most frequent case is the one of a signal with two animation entries in sigcfg.dat, that are 1 and 2, and with two animation steps in the .s file (0 and 1). What I say is coherent with Jonas' position in post #25 and with Eugen position that doesn't want to damage correct working signals.
So it would be nice if a test route with a signal with these characteristics were available, to test a possible patch.

[jonas]

Csantucci, on 28 December 2016 - 12:46 AM, said:

...
So it would be nice if a test route with a signal with these characteristics were available, to test a possible patch.

Is PT_RR (ProTrain Rasender Roland) available for you? The most signals works with SemaphorePos(1)/(2) there and have only two ani keys in .s file.
Or any other route listed in post #8, despite DK2000?
You see, I'm afraid a little the work to create a test route, but if you insists... :-)