[StationWhere]

Hello.
Often I had taken this little road wich cross severals tracks. Untill today where I try to accross with the release X3633. One barrier was up, the other was down! Oh my God!
-----------------------------------------------------------PHASE 1 ALL IS NORMAL----------------------------------------------------------------------------------------
http://nsm08.casimages.com/img/2016/09/30//16093006464921372314527356.jpg

-----------------------------------------------------------PHASE 2 ALL IS UNBELIEVABLE ------------------------------------------------------------------------------
http://nsm08.casimages.com/img/2016/09/30//16093006464921372314527357.jpg

Do Somebody can explain this situation to me?
Thank you

[edwardk]

Its possible the signal objects for both crossings are not even with each other. The signal object for the gate that is still up needs to be adjusted so that it is even with the other object. This can only be done via route editor.

Edward K.

[StationWhere]

Hello.
Thank you for your attention. But..... I never changed any parameters of the levelcorssings except for the invisibility. These levelcrossings are rightly Right and Left.

Under MSTS and corresponding to the first picture, the two barriers are down. Under OR they are up.
Under MSTS, corresponding to the second picture and when the train begin to run, the barrier of the right side move up and, after, move down (!!!). Under OR, only the barrier of the right move down.

I will change the path to accross the road by the other track. I Think that il will be the contrary..

Cordialement

[StationWhere]

Hello.
As I was thinking about, the crossLevel are not misplaced or with bad parameter. Because if I change the path as the picture below shows, they perfectly run.
It is not a problem with the Levelcrossing object but a problem in OpenRails about ROADS/TRACK(s)/LEVELCROSSING/CARSPAWNER!
http://nsm08.casimages.com/img/2016/10/01//16100106555321372314529209.jpg
Regards

[Jovet]

 edwardk, on 30 September 2016 - 11:42 AM, said:

Its possible the signal objects for both crossings are not even with each other. The signal object for the gate that is still up needs to be adjusted so that it is even with the other object. This can only be done via route editor.

I don't think that's the issue. And LevelCr markers cannot be moved. The object must be deleted and re-placed.

 StationWhere, on 01 October 2016 - 08:46 AM, said:

As I was thinking about, the crossLevel are not misplaced or with bad parameter. Because if I change the path as the picture below shows, they perfectly run.
It is not a problem with the Levelcrossing object but a problem in OpenRails about ROADS/TRACK(s)/LEVELCROSSING/CARSPAWNER!

I have noticed this problem myself. But I had decided it is a MSTS Route Editor problem, and not an Open Rails problem.

If a LevelCr object is placed on a switch, where the track paths are still very close to one another, then it seems MSTS doesn't place a marker on one of the tracks as it considers it a duplicate.

I noticed this behavior this past year, despite using MSTS for 10 years and never having noticed this behavior. It still strikes me odd that I would have never noticed this before.

What is interesting here is that the track paths are not that close together, and the shape that is affected would typically have been placed with the tracks further separated than the other barrier.

[eric from trainsim]

Looks like the untriggered signal isn't detecting movement on an adjacent track.

What's the Minimum Activation Distance set to?

MSTS seemed to detect within a radius of the LevelCr marker, not just along the track node. I have no idea how this is being implemented in ORTS.

[StationWhere]

Hello.

 eolesen, on 03 October 2016 - 10:53 AM, said:

MSTS seemed to detect within a radius of the LevelCr marker, not just along the track node. I have no idea how this is being implemented in ORTS.

You are close the right way. The distance (standard) of activation is 20m. One barrier was nearer than the other.
I pushed the beginning of the path few lengths back and there is no more problem.
http://nsm08.casimages.com/img/2016/10/04//16100406230721372314534783.jpg
I will parse some other situations following this idea. Perhaps it is the solution.
Thank you.