Log In
Register Now!
Help
I read in a thread (unfortunately I can't find it any more) that there was a time in OR developement, when barriers at level crossings closed when a train approached and stayed closed, even when the train stopped before the crossing. (This would be the procedure in my home country at least). Now the barrier opens when the train stops and recloses when the train starts moving again. This would be the north-american way to do it, it was said in the thread, and therefore this was changed in OR, and I am not too happy about that. Would it be possible to put in both variants, and the user could chose the correct one for the used route?
Page 1 of 1
Level crossings with barriers
Rate Topic:
#1
- Fireman
-
- Group: Status: Active Member
- Posts: 161
- Joined: 10-October 17
- Gender:Male
- Location:Select State/Province
- Simulator:Open Rails
-
Country:
Posted 05 April 2022 - 02:50 AM
#2
- Apprentice
-
- Group: Status: Active Member
- Posts: 36
- Joined: 05-January 20
- Gender:Male
- Simulator:OpenRails, ZR
-
Country:
Posted 04 May 2022 - 08:54 AM
Standard MSTS type level crossings have two key parameters the warning time, the time a crossing should open before a train arrives (usually 60s) and the minimum distance (20m), the distance above which a stationary train can be ignored.
However there is another problem in that, under MSTS, the gates on either side of the rail track have a different set of track items. These are the nominal locations of the crossing which the computer search algorithm looks for - starting from the train. It is thus possible to have a situation where the track item for the gates on one side are within the minimum distance, so the gates are closed to traffic, and those on the other side are open. I attach an example from the zig-zag railway (https://www.zigzag.c...wcastle.com.au/) - with apologies to the authors as, in normal use, the problems seen here are not noticed.
But this raises a question of efficiency - as doubling the number of track items also doubles the cpu time spent searching for the track items - OpenRails does not look for both in the same scan.
In a simple system with a single train, doubling up the number of searches for level crossings may not be very expensive - given the power of modern chips. But is a multi-player system with many trains and crossings it may be expensive. So if anyone every thinks of improving the code - combining adjacent level crossing items would be a useful additional step. Combining all the present searches from each train into a single search along the track, might also be useful.
However there is another problem in that, under MSTS, the gates on either side of the rail track have a different set of track items. These are the nominal locations of the crossing which the computer search algorithm looks for - starting from the train. It is thus possible to have a situation where the track item for the gates on one side are within the minimum distance, so the gates are closed to traffic, and those on the other side are open. I attach an example from the zig-zag railway (https://www.zigzag.c...wcastle.com.au/) - with apologies to the authors as, in normal use, the problems seen here are not noticed.
But this raises a question of efficiency - as doubling the number of track items also doubles the cpu time spent searching for the track items - OpenRails does not look for both in the same scan.
In a simple system with a single train, doubling up the number of searches for level crossings may not be very expensive - given the power of modern chips. But is a multi-player system with many trains and crossings it may be expensive. So if anyone every thinks of improving the code - combining adjacent level crossing items would be a useful additional step. Combining all the present searches from each train into a single search along the track, might also be useful.
Attached thumbnail(s)
Page 1 of 1