Crossing gates stay lowered too long

Bug #1432327 reported by James Bradley, Jr.
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Open Rails
Fix Released
Undecided
Unassigned

Bug Description

While playing the Alameda Belt Line route, I noticed that the crossing gates stay lowered well after the train has cleared the crossing. In some cases, the crossing gates never go back up. Unsure if this is a route-specific problem, or an OR issue. Currently using OR x2920.

Revision history for this message
James Bradley, Jr. (jbrad1974) wrote :

Ran a few tests for a separate crossing related issue, and found the following:

The version number of OR did not make any difference. Tested two different routes using the latest version of OR, and discovered some interesting facts about the crossings:

Alameda Belt Line v2:

Crossing signals stay steady/don't flash (not correct)

Train moving forward: gate arms on opposite sides of the street drop at different times (not correct), traffic stops (correct), bell continues ringing until crossing is clear (correct), gate arms raise after crossing is clear (correct) but at different times (not correct), traffic moves after crossing is clear (correct)

Train moving reverse: gate arms on opposite sides of the street drop at the same time (correct), traffic stops (correct), bell stops ringing even before crossing is clear (not correct), gate arms stay lowered after crossing is clear (not correct), traffic stays stopped at crossing after crossing is clear (not correct).

Surfliner 2

Crossing signals flash correctly

Train moving forward: gate arms on opposite sides of the street drop at the same time (correct), traffic stops (correct), bell continues ringing until crossing is clear (correct), gate arms raise after crossing is clear (correct), traffic continues to remain stopped after gate arms have raised (not correct)

Train moving reverse: gate arms on opposite sides of the street drop at the same time (correct), traffic stops (correct), bell doesn't ring (not correct), gate arms stay lowered after crossing is clear (not correct), traffic remains stopped after crossing is clear (not correct).

An interesting phenomenon occurs after reversing through a crossing. If you stop, then place the throttle in the forward position...any crossings that you reversed through will suddenly have the gates raise back up and traffic will move.

FINDINGS:

1)Flashing varies from route to route. Some routes work, others don't.
2)Crossing gates react differently depending upon direction of travel.
3)Crossing gates react differently from route to route.

Hope this helps.
--James

Revision history for this message
Joseph Hoevet (jovet) wrote :

James,

I ran across this thread and want to add my few cents. I've seen the same timing issue. It will only affect interactive crossing signals. On the Surfliner 2, for example, the flashing lights are not interactive--they're just animated shapes that flash all the time. It is only the gates that are interactive. Other routes may have both be interactive. Some routes (especially older) may have the interactive gates for different approaches placed onto different lanes of the roadway. This is what may cause the gates to not operate in sync with one another. Not desired behavior, but understandable if the track markers are not at identical spots....the slower the train, the larger the difference in activation times.

The problem I have noticed is that the interactive crossing signals staying activated too long may depend on the direction the controlled locomotive is facing, not the direction it's traveling. As mentioned above, if one reverses a locomotive through a crossing the signals may stay on for over a km past the crossing. But they do eventually turn off. This is contrasted to moving forward across a crossing where the signals will turn off almost immediately after. But driving a locomotive reversed across several crossings or a whole route works the same way. The game seems to treat the wrong end of the locomotives as the "leading" edge for activating/deactivating crossings. Ideally, each crossing is its own "island" and whether any rail traffic is moving towards it (and its speed) is what should matter.

Revision history for this message
James Bradley, Jr. (jbrad1974) wrote :

Thank you, Joseph. That makes perfect sense. Alameda Belt Line is an older route than Surfliner, which explains why the signals in Surfliner were reacting correctly and the ones in Alameda Belt Line weren't. I replaced the signals in Alameda Belt Line with those in Surfliner, and they appear to be reacting more realistically now.

As for the activation...we can add that to the long list of quirks that MSTS has. Perhaps in a future version of OR, they can correct the crossing interactive to interact with the leading edge of the locomotive, regardless of which direction it's facing or direction of travel.

Revision history for this message
James Bradley, Jr. (jbrad1974) wrote :

After testing multiple routes, it was determined that all signals react the same way. When a train moves forward through a crossing, the crossing clears almost immediately after the last car clears. However...when moving in reverse over a crossing, the crossing stays active for an additional 1-2 minutes after the last car has cleared the crossing. This creates issues with traffic blocking adjacent tracks, especially when performing switching maneuvers. I would recommend investigating why the signals clear differently moving forward as to moving in reverse.

Revision history for this message
James Bradley, Jr. (jbrad1974) wrote :

This issue appears to have been corrected, but will continue to monitor.

Revision history for this message
Joseph Hoevet (jovet) wrote :

Yes, it seems corrected in my book, too.

Revision history for this message
Edward Keenan (edwardk) wrote :

Leaving final message indicating that the latest work on level crossings fixed the above issue since the work was done without knowing about this report.

Edward K.

Changed in or:
status: New → Fix Released
James Ross (twpol)
Changed in or:
milestone: none → 1.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.