[James Ross]

pmoser, on 26 January 2016 - 09:31 AM, said:

Maybe I can shed some light on this for James. Edward is right in that MSTS would deactivate the crossing gates if a train came to a stop before reaching the crossing. Open Rails used to do this as well before it was removed long before version 1.0 and probably before version 0.8.

As the one who wrote the level crossing code, I know how it works (I also re-read the code when I made my earlier post). :)

What is at issue is why it's not matching up to MSTS (excluding bugs) - please see my earlier post on our current best understanding of the data and behaviour. "MSTS would deactivate the crossing gates if a train came to a stop before reaching the crossing" is a fine statement but we need to understand what is actually happening; is MSTS ignoring the minimum activation distance? Is MSTS only using that when the train is moving? Is it actually just a bug in MSTS?

Until someone actually tests what MSTS is doing with the parameters and finds something contradictory to the current understanding (in my earlier post), we're not changing anything.

[dennisat]

edwardk, on 24 January 2016 - 01:54 PM, said:

If the crossing sensors do not detect movement within a period of time, the crossing operation is cancelled.

Is that so? What is the time interval? As a UK road user and rail user I've frequently been held up (or seen others held up) by trains stopped at stations in close proximity to a crossing. It appears (to me) that once the train's path has been cleared (green signals) the crossing will not open until the train moves past it. I've sometimes waited around 5 minutes. I would have thought the only way the crossing could be cleared for road traffic is if a train finally goes through or the signaller opens the crossing, acting on sensor information, CCTV information and communication with drivers(s). The crossing being cleared just by a time interval seems to invite potential danger.

Dennis

[dennisat]

dennisat, on 26 January 2016 - 11:15 AM, said:

Is that so? What is the time interval? As a UK road user and rail user I've frequently been held up (or seen others held up) by trains stopped at stations in close proximity to a crossing. It appears (to me) that once the train's path has been cleared (green signals) the crossing will not open until the train moves past it. I've sometimes waited around 5 minutes. I would have thought the only way the crossing could be cleared for road traffic is if a train finally goes through or the signaller opens the crossing, acting on sensor information, CCTV information and communication with drivers(s). The crossing being cleared just by a time interval seems to invite potential danger.

Dennis

Ignore this - you probably already have! Upon more careful reading I realise this topic is not about real life!
Sorry.

Dennis

[edwardk]

pmoser, on 26 January 2016 - 09:31 AM, said:

Maybe I can shed some light on this for James. Edward is right in that MSTS would deactivate the crossing gates if a train came to a stop before reaching the crossing. Open Rails used to do this as well before it was removed long before version 1.0 and probably before version 0.8. Since I don't know how to look for changes before version 1.0, I can't search for when this had occurred. At least in the U.S., modern crossings that us AC track circuits will deactivate after a while if an approaching train has slowed down significantly or has stopped before the crossing. The crossing will reactivate once movement is detected and the minimum warning time is reached. Of course, MSTS has a flaw in that the crossing will not reactivate until you were almost in the crossing instead of activating once movement was detected and the minimum warning time (set in the level crossing properties) had been reached. The current behavior in OR is irritating if you are running a passenger train and your stopped at a station waiting on time and the gates stay down on the road crossing in front of you causing a massive traffic backup at the crossing.

Phil

If this behavior was working at one point, it would be important to see what was changed. I will check the older code to see what was changed.

Edward K.

[edwardk]

James Ross, on 26 January 2016 - 10:39 AM, said:

As the one who wrote the level crossing code, I know how it works (I also re-read the code when I made my earlier post). :)

What is at issue is why it's not matching up to MSTS (excluding bugs) - please see my earlier post on our current best understanding of the data and behaviour. "MSTS would deactivate the crossing gates if a train came to a stop before reaching the crossing" is a fine statement but we need to understand what is actually happening; is MSTS ignoring the minimum activation distance? Is MSTS only using that when the train is moving? Is it actually just a bug in MSTS?

Until someone actually tests what MSTS is doing with the parameters and finds something contradictory to the current understanding (in my earlier post), we're not changing anything.

James,

Since you are telling me that you wrote the code, let me ask you this. Have you run the activity I mentioned at the top of the post in both OR and MSTS? If you did, then you know what operation is missing. I also found a slight issue involving locomotives performing a reverse move through the crossing. As far as parameters from MSTS is concerned, you are using 2 which is fine, but what is missing are certain operations which is solved by changing the tests.

As of now, I have solved both with minimal change. If you want to review my changes, I will send you the updated code. There is also the option of you correcting it if that is your option. Let me know because if you do not approve of the changes, then both issues would have to be considered a bug.


Edward K.

[edwardk]

James,

You have mail.

Edward K.

[edwardk]

At this point, I have a candidate. After much testing, the interaction between player train and crossing is matching with MSTS.

After researching crossings, it appears that MSTS was duplicating the crossings using the smart motion detector system. Both OR and MSTS will allow a train to crawl up to the stop to a certain point while traveling under 11mph. I was wondering if MSTS was going to include the timing out of the crossing if the train is parked before the crossing, but my tests did not show this. OR though will deactivate the gates if the train is parked before the crossing, but it is not based on a time out method. The only thing to keep in mind is that it is the engineer's responsibility to know how to act around crossings :)

The only thing left of course is final approval?

Edward K.

[gpz]

I would like to ask to add this feature as a non-default option. In my country, and I think in many others, it is not the engineers responsibility to know how to act around the crossing, neither there is any kind of motion detector built into the railways safety system. Also, crossings are not deactivated at all, if a train is parked before the crossing. (Rather, it works quite the opposite: there is a timeout for auto-clearing, and if that doesn't happen, it will be locked in a closed state forever, or till manual interaction by the human dispatchers. But I don't expect this to be implemented.)

[edwardk]

Peter,

This is to match how MSTS is operating. Another post was bringing up MSTS features that are not yet covered under OR since depending upon what activities you run, you may or may not notice the differences in crossing operations.

Edit: You do bring up a good point. This just goes to show there are differences in crossing operations all over. Unfortunately there are many activities that start within range of a crossing and currently under MSTS, the gates are not activated at the start of the activity.

Edward K.

[conductorchris]

Seems like if the code exist both ways (ie, to simulate motion sensitive crossings and conventional crossings) that both options could be available, perhaps defined by a parameter in the route?
Christopher