[Jovet]

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.

I'm certain one of us could whip something up. I can envision such a route pretty easily.

[eugenR]

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.

I have one from PT6, with only one Signal with two arms (3 aspects, stop approach, and clear) and a switch behind. I will send this to you by Mail.

EugenR

Route is sent by Mail.

I have tested shapes with 2 and 3 entry's with and without aditional "end-key".
I have found, MSTS calculate the Semaphorpos( ) only down, if there are only 2 Animation-entry's in the shape and if there is no end-key as 3. key in the animation-block.

[jonas]

A test route for download with 4 signals, 2- and 3-key animated, each with SemaphorePos 0/1 and 1/2.

Next to each signal, the corresponding script as a transfer texture.
 SemaTestMSTSvsOR.zip (1.88MB)
Number of downloads: 271

Use key 7 in MSTS to fly with the free cam.
Hope it helps to illustrate the diiferent behaviors of the signals in MSTS and OR.

[Jovet]

jonas, on 28 December 2016 - 07:14 AM, said:

Hope it helps to illustrate the different behaviors of the signals in MSTS and OR.

It does. OR is consistent, and MSTS is not (i.e. buggy).

I've started on my own test route, which I have intended to test a few other things, such as multi-armed semaphores.

[James Ross]

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

For me and for many users of PT-Routes also, but we must carefully find exact the cases where MSTS modifies the SemaphorePos().
otherwise we can destroy working signals!

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 ).
see my Post #12!

The rule I am considering is this: subtract the minimum SemphorePos from all SemphorePos entries in each signal type entry.

That means 0,1 -> 0,1 and 1,2 -> 0,1 and 3,4,5 -> 0,1,2.

An alternative rule is that the values are only shifted by 1 at most; that would mean 0,1 -> 0,1 and 1,2 -> 0,1 and 3,4,5 -> 2,3,4.

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

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

It is hard for me to follow this description of the SemaphorePos values. Please can you list them numerically instead? Is this 0,1,2?

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

Like above, I have no idea what SemaphorePos values you are describing here.

[jonas]

James Ross, on 28 December 2016 - 08:44 AM, said:

...
That means 0,1 -> 0,1 and 1,2 -> 0,1 and 3,4,5 -> 0,1,2.

An alternative rule is that the values are only shifted by 1 at most; that would mean 0,1 -> 0,1 and 1,2 -> 0,1 and 3,4,5 -> 2,3,4.
...

For the simple basic question below, supposed the animation sequence of a 3-state signal looks as follows:

					controllers ( 2
						tcb_rot ( 3
							tcb_key ( 0 0 0 0 1 0 0 0 0 0 )
							tcb_key ( 126 0 0 -0.3 0.9 0 0 0 0 0 )
							tcb_key ( 287 0 0 0 1 0 0 0 0 0 )
						)

If then the appropriate SemaphorePos entries would be:

SemaphorePos (0) - SemaphorePos (126) - SemaphorePos (287)

or

SemaphorePos (0) - SemaphorePos (1) - SemaphorePos (2)

In other words, is it a relative or absolute mapping of SemaphorePos <-> tcb_key-line in OR?

[eugenR]

James Ross, on 28 December 2016 - 08:44 AM, said:

It is hard for me to follow this description of the SemaphorePos values. Please can you list them numerically instead? Is this 0,1,2?

Like above, I have no idea what SemaphorePos values you are describing here.

Hi James,
Sorry for not have explicate exact.
I have made the explications in pink in Post #24
I hope this explications will help
Regards
Eugen

[Csantucci]

I also had started working. Here is my proposal for the modified runactivities to be replaced in x.3720

and here ist the patch


I tested it with Eugen's test route and with Jonas' route, with positive result, except for Jonas' first signal, that I think shows a real malfunction of MSTS that shouldn't be imitated in my opinion (neither I think it is used). It's the case with two animation steps in the .s file and with the use of a 0 and of a 1 as SemaphorePos in the sigcfg.dat. In this case MSTS uses for the 0 the second animation step and for the 1 the first animation step. I don't think this is used in reality, and it's not a case that is intended to be covered by the patch.

It would be nice if this could be tested by people having some of the routes with the problematic signals.
I will be able to read comments only tomorrow :)

31/12/2016: Attachments deleted because new release with information string available

[eugenR]

jonas, on 28 December 2016 - 07:14 AM, said:

Hope it helps to illustrate the diiferent behaviors of the signals in MSTS and OR.

For me yes, thank you for the clear presentation!

I compare the signals in MSTS and ORTS:

SignalNr...1..........2........3........4
MSTS.....stop(*)..clear...clear.....stop
ORTS.....clear......stop....clear....stop

(*) This signal is hanging in MSTS. It open and close if you pass this signal, if you are rolling back, this signal is showing clear, the same state as in ORTS.

I found, there is only one Difference by signal 2, here calculate MSTS the SemaphorePos(1,2) down by -1, ORTS is using (1,2)
This Signal has two animation-entry AND no end-entry (same as entry 0)in the animation-block, AND it use semaphorePos( 1,2 )

[jonas]

Csantucci, on 28 December 2016 - 01:02 PM, said:

...I tested it with Eugen's test route and with Jonas' route, with positive result, except for Jonas' first signal, that I think shows a real malfunction of MSTS that shouldn't be imitated in my opinion (neither I think it is used). It's the case with two animation steps in the .s file and with the use of a 0 and of a 1 as SemaphorePos in the sigcfg.dat. In this case MSTS uses for the 0 the second animation step and for the 1 the first animation step. I don't think this is used in reality, and it's not a case that is intended to be covered by the patch.
...

Of course not imitate the funny jumping of the first signal in MSTS of my test route! :-)) Sorry, may be a misundestanding, I didn't mean to make the behavior in OR exact the same like in MSTS. I have only wanted to show all 4 possible cases technically. By the way, the first signal is working fine in OR, so no need to patch it.