[NF1-800]

This reminds me of something...
Remember Joseph when you told me to change the SemaphorePos values, it worked, quite even if the effect was viceversa in MSTS, but i don't mind it at all since i use Open Rails for driving. Instead i have a tiny problem with 1 entrance semaphore type that has 3 indications, the 3rd indication being for the exit signal in advance.
The problem with the 3rd indication is that it doesn't want to change aspect when the exit signal is on the CLEAR state.
For a much simpler explanation i made some shots with the situation. This was tested in explore mode in the latest experimental release (16.12.2016).
If you still have the semaphore package, check this line SignalType ( "SM_INTRARE_3i" or the shape file SM_INTRARE_3i.s

https://s29.postimg.org/6lngu3tqr/SM_STOP_STOP_DONE.png

https://s29.postimg.org/pht5dxvmb/SM_CLEAR_CLEAR_DONE.png

https://s29.postimg.org/vu8anryoj/SM_APPROACH_STOP_DONE.png

https://s29.postimg.org/nrepq73gz/SM_CLEAR_SIDING_CLEAR_DONE.png

https://s29.postimg.org/9try75g0j/SM_APPROACH_SIDING_STOP_DONE.png

[eugenR]

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

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

Jovet you have right, I didn't watch exactly by testing.
The tested signal has had 3 tcb_key entries and I has using the SemaphorPos 1(stop) and 2(clear).
Under this conditions MSTS does really NOT move the entry-numbers to 0 and 1.
But the reason for that are not the tcb_key's, it are the THREE entry's in the animation. sorry
EugenR

[eugenR]

jonas, on 26 December 2016 - 05:41 PM, said:

Is an additional code sequence in OR possible to correct signals with wrong not 0 based SemaphorePos-entries?

The Problem for OR is:
I think OR should not correct MSTS-errors.
How find a solution for all specific behavior's of MSTS in this case, with more than tree animation-steps, with the Shape with only 2 animation step, and so on.

The Problem for Pro Train is:
They didn't have resources to test and publish OR specific Modifications for all this routes.

The Problem for user's is:
Its Payware, it is not aloud to publish signalfiles with modifications!!!

Any Idea how somebody can help?
Perhaps can somebody realize a reliable tool, that produce such signalfiles and shapemodifications for 3 animation entry's, so that the routes are usable in both OR and MSTS?

EugenR

[Jovet]

NF1-800, on 26 December 2016 - 06:25 PM, said:

The problem with the 3rd indication is that it doesn't want to change aspect when the exit signal is on the CLEAR state.

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

Does this shape help your problem here any, out of curiosity?

Attached File(s)

•  SM_INTRARE_3i.zip (93.6K)
  Number of downloads: 235

[eugenR]

NF1-800, on 26 December 2016 - 06:25 PM, said:

This was tested in explore mode in the latest experimental release (16.12.2016).

Really experimentalmode not Manualmode?
In Manualmode carlo has fixed such a problem in Release X3718 from 26.12.2016

In Manualmode, Distantsignals at the same pole as the Mainsignal has never changed to Clear, if there is a switch between the Distantsignal and the next MainSignal.
http://www.elvastowe...in-manual-mode/

[jonas]

Are there bugs in OR running semaphore signals? - No!
Are there bugs in MSTS? - Yes, at least one bug: MSTS has a problem with 2-frame-animated semaphore signals. Those signal semaphores are "sticky" and need at first to be passed by a train before working right.

In MSTS times the signal designers were responding to this bug. Unfortunately they don't extended the animation sequence in the signals by one frame to prevent the "sticky" effect. Instead, they use not 0-based SemaphorePos entries. Both ways helps to solve the problem in MSTS, but the first one was not in the focus. For sure not an intended wrong decision as I suspect. The motto might be "What helps that helps"...and it helped. The "stickiness" of the semaphores were disappeared in MSTS. MSTS tolerates this non-0-starting count for SemaphorePos. Not a further bug of MSTS, even a tolerance.

But what does the users experience comming from MSTS to Open Rails when they starts some of the various ProTrain routes? In OR they see a lot of semaphore signals that show wrong signal aspects. What does they say then? They say Open Rails is'nt matured and would not work as well as MSTS, is still buggy.

This is an annoyance and unfortunately it stays attributed to OR, no matter how we argue here! That's why we should take it seriously. I believe no one in the discussion here in the forum believes that it is a bug of OR. And I also believe that no one wants OR to have doubtful code sequences, which emulate the bugs of MSTS or make OR unstable. But the statement from the website of OR says:

"OpenRails: free train simulator that supports the world's largest range of digital content."

This sentence contains the word "supports". And that's it what it is all about here!

In my eyes "support" means that OR should manage the problem. Neither an external tool should manipulate route signal files nor cryptic user instructions should be given how to manipulate the sigcfg.dat and all(!) involved signal shapes of a route subsequently. And certainly not the simple hint that it would be a bug of MSTS and therefore OR will not worry about it.
(If something would be written back into files, then again MSTS may have a problem. This is why I think an external tool or user instructions to change files is not the right way.)
Many users simply wants to drive and do not want to deal with the complexity of signals. They will consider this discussion here as academic and I am sure that it will always being seen as a problem of OR in the long run.

So no doubtful code, but a correction of wrong given signal data is still my proposal. It would certainly mean some effort, but it seems doable to me. When reading the route data, OR could do the following:

• Correct to 0 the non-0-based SemaphorePos statements in the SignalType entries of the sigcfg.dat.

Of course, nothing should be written back into any files and the whole thing as an option under "Experimetal". This seems the best way to me to solve it.

For me personally I'm not realy concerned. I can help myself by manipulate the route signal files and the signals I build are robust for both platforms MSTS and OR (0-based SemaphorePos and 3-frame signals).
I just do not want the "sticky" or "lazy" semaphores to be seen as an OR bug. For the above question "Are there bugs in OR running semaphore signals? - No!" unfortunately the answer by many users will be "Yes!".

The incorrect functioning of signals in a train simulation is always very irritating and will always attributed to the simulator software. This is how the users see it, I'm afraid.

A bit longer but thats my opinion.

Best regards
jonas

[James Ross]

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

I've just asked in https://bugs.launchp...et/bugs/1449839 and https://bugs.launchp...et/bugs/1214052 about whether reducing all SemaphorePos values, such that the lowest one is then zero, fixes those problems.

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?

If the above bugs come back positive, I would like to include such a fix in OR - but with a warning printed to the log (our standard behaviour when correcting for otherwise-odd inputs). This is a small and simple thing to do, since we can do it as we load each signal block, and the rest of the code need not know what's changed.

[jonas]

James Ross, on 27 December 2016 - 07:37 AM, said:

...
If the above bugs come back positive, I would like to include such a fix in OR - but with a warning printed to the log (our standard behaviour when correcting for otherwise-odd inputs). This is a small and simple thing to do, since we can do it as we load each signal block, and the rest of the code need not know what's changed.

That would be great, sounds good to me...

[eugenR]

jonas, on 27 December 2016 - 07:47 AM, said:

That would be great, sounds good to me...

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!

[jonas]

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

...
Is this rule correct:
Modify, if in the Signaltypedefinition are no SemphorePos( 0 ) AND
there is a semaporePos( +1) greater then the signalshape has Animationssteps for this Shapepart?

Yes, seems the right way for me. Supposed it's about semaphore signals that work fine in MSTS, it is only needed in OR to find SignalType entries where the lowest SemaphorePos is not 0.
To change the signal shape animationsequenz is not necessary in my opinion. The animation will work in both OR and in MSTS anyway.

IF it is a semaphore signal THEN
---> IF lowest SemaphorePos > 0 THEN
------> reduce all SemaphorePos of this signal by 1