[Jovet]

Coolhand101, on 10 August 2016 - 05:30 AM, said:

Thanks for the explanation. I fail to see why a crossing activated by train gets deactivated when the train comes to stand.

Probably because 1) that's what happens commonly in the United States [though it is not just the US that uses grade-crossing predictors] 2) it's more realistic for vehicular traffic to proceed across a level crossing if the train is obviously stopped.

But like you, I would expect the LevelCr objects to deactivate only if the train is outside of the activation distance.

But I also realize this change was made to appease just this situation: Where a passenger station is immediately adjacent to a level crossing, the idea is that the crossing should not be activated when the train is stopped at the station, no matter what. I realize that is the effect you're after, but I would think that's more the exception than the rule.

Coolhand101, on 10 August 2016 - 05:30 AM, said:

Also are there any plans to reintroduce the 'Initial warning phase lasts' and 'More serious warning phase lasts'

I hope not. Those did not seem to serve any useful purpose in MSTS.

The CarSpawner traffic should stop when the LevelCr objects activate. They should resume when they deactivate. If you think this needs to be more complicated, please explain how and why.

Coolhand101, on 10 August 2016 - 12:04 PM, said:

Back to the signal 'protecting' the crossing. I'm getting some positive random results. If the actual signal shape is in front of the crossing and the signal marker is behind the crossing marker, then when i come to stand at the station, one of the barriers remain down. This is nearest barrier, and has a activation distance of 15 meters as well as the opposite barrier. Would it be wise to adjust the other barrier as i thought they both should have the same distance.?

They will not have the same distance if they are put into different road lanes. This is a common problem/misconception with setting up level crossings in MSTS. Most people setup level crossings so that the barrier for that lane of roadway is on that lane. But if the lanes are 3-5m apart, then the activation distance area will be slightly different for both shapes....I mean, think about it: the track markers are not at the same place on the track. Just that slight difference is enough for you to see they're operating differently.

The best way to setup a level crossing is to place all of the principal working equipment at the exact same place on the same "road" lane. This ensures that flashing lights remain in sync, and that the barriers/gates activate and deactivate at the exact same time. I personally accomplish this by picking a LevelCr object to place in the route with the MSTS Route Editor, and then clicking 2-12 into existence at the exact same place at the level crossing. You must then move all of the shapes to a unique spot before saving, or the RE will discard all the extra shapes in the same place as duplicates. I then save, and then modify the world file directly to change the shape filenames to the required shapes I actually want. In the process of editing the world files, I disable the extra crossing alarms (bells) as well. I then force the RE to reload the world tile, and then I position the shapes where I want them. At some point, I generally tend to select all the gate/barrier shapes and configure their parameters, and then select all the other shapes (flashing lights) and configure their parameters.

When you're all done with that, you will still have only one lane with LevelCr shapes. Other lanes will still need LevelCr shapes to stop CarSpawner traffic, but those simply get buried. I also tend to give them a little longer Activation Distances (depending on track marker distance from the main set of LevelCr markers) so that they will overlap enough. It isn't an exact science but I have had good luck with it. One additional thing: Since the barriers will activate/deactivate at the same moment, it often looks bad to give them the exact same animation length. I tend to try to slightly vary that between them so they behave more realistically. If I give one crossing gate an animation length of 7 seconds, I might give the other one of 7.2, or 6.7, or something.

[Jovet]

Coolhand101, on 10 August 2016 - 03:41 PM, said:

Distance, this seems to have no effect. If the train goes below the approach control speed of 20 mph, the signal(s) will clear from ANY distance.

That is how Approach Control signals are supposed to behave. The idea is to force the train to slow at or below a certain speed (ideally within a certain distance as prescribed by the rules) in order to coax the signal to behave normally.

I haven't messed with the enhanced abilities of OR (such as this) so I can't advise on the specifics of implementation in this regard.

[Coolhand101]

jovet, on 11 August 2016 - 06:49 AM, said:

Probably because 1) that's what happens commonly in the United States [though it is not just the US that uses grade-crossing predictors] 2) it's more realistic for vehicular traffic to proceed across a level crossing if the train is obviously stopped.

But like you, I would expect the LevelCr objects to deactivate only if the train is outside of the activation distance.

But I also realize this change was made to appease just this situation: Where a passenger station is immediately adjacent to a level crossing, the idea is that the crossing should not be activated when the train is stopped at the station, no matter what. I realize that is the effect you're after, but I would think that's more the exception than the rule.

Yes i do mean level crossings in front of a station. It just seem very odd to see the barriers go down for the train, then open once the train has arrived at a station. The activation distance can fix this!

Quote

I hope not. Those did not seem to serve any useful purpose in MSTS.

The CarSpawner traffic should stop when the LevelCr objects activate. They should resume when they deactivate. If you think this needs to be more complicated, please explain how and why.

Ahh i see. In MSTS, i thought these gave more control for the traffic approaching the crossing, where the traffic slows and stops before the barriers went down via them settings.

Thanks

[Jovet]

Coolhand101, on 11 August 2016 - 07:21 AM, said:

Yes i do mean level crossings in front of a station. It just seem very odd to see the barriers go down for the train, then open once the train has arrived at a station.

I don't think it's that odd. (Again I am biased—it's pretty common in parts of the US, especially light rail lines.) It may be usual in some locales, but that may be there is a different trigger arrangement for the level crossing signals. The red signal exclusion that Rob did is a good idea, since a Starter signal at Danger can prevent a level crossing just past the station from activating until the train is actually ready to proceed. But if your line isn't using Starter signals I am not sure what to tell you, until OR gets more sophisticated in this regard.

Coolhand101, on 11 August 2016 - 07:21 AM, said:

In MSTS, i thought these gave more control for the traffic approaching the crossing, where the traffic slows and stops before the barriers went down via them settings.

It does. But that is not realistic. If CarSpawner traffic is stopping before the LevelCr activates, then the LevelCr object is configured incorrectly. I think you'd be hard-pressed to find any automobile driver who wants to slow down or stop for a railway crossing signal that isn't on. It's hard enough to get them to stop when it is on!
:o

[Coolhand101]

jovet, on 11 August 2016 - 06:51 AM, said:

That is how Approach Control signals are supposed to behave. The idea is to force the train to slow at or below a certain speed (ideally within a certain distance as prescribed by the rules) in order to coax the signal to behave normally.

I know exactly how approach controls signals are suppose to behave. You have misread what i meant.

There are two approach controls methods in OR via the scripts. One is position and the other is position and speed. For reference, 200 yards and 20 mph.

I cannot get the position to work at all. The speed does work but at any distance, meaning if i put 200 yards in the script, and i'm 2 miles away and my speed falls below 20 mph, the signal will clear.

[Coolhand101]

jovet, on 11 August 2016 - 10:14 PM, said:

I don't think it's that odd. (Again I am biased—it's pretty common in parts of the US, especially light rail lines.) It may be usual in some locales, but that may be there is a different trigger arrangement for the level crossing signals. The red signal exclusion that Rob did is a good idea, since a Starter signal at Danger can prevent a level crossing just past the station from activating until the train is actually ready to proceed. But if your line isn't using Starter signals I am not sure what to tell you, until OR gets more sophisticated in this regard.

Again, i was referring to crossings that are tripped automatically via the train.

Automatic crossing at stations:
As in OR, these are tripped by distance( by the train ), so coming into a station with these crossings and seeing them reopen is odd.

Manual gate or operated locally crossings.
These are generally closed before the train arrives at the station. Again using the distance method, or if these crossings have a signal, the signal can be at red to keep the crossing open, until the train has stopped.

Crossings that reopen once the train arrives at the station.
I would assume these crossings have a small trigger distance between the station and crossing where they would remain open until the train leaves, so they should not close in the first place? Which is what i was mainly referring to from the start.

All this can be achieved from the distance activation level. I can get what i need from adjusting the distance activation to better suit these crossings.

It would be nice if the signal at red, to keep the crossing open, can close the crossing once the signal clears if in the required activation distance!

jovet, on 11 August 2016 - 10:14 PM, said:

It does. But that is not realistic. If CarSpawner traffic is stopping before the LevelCr activates, then the LevelCr object is configured incorrectly. I think you'd be hard-pressed to find any automobile driver who wants to slow down or stop for a railway crossing signal that isn't on. It's hard enough to get them to stop when it is on!
:o

Crossings with barriers, should sound an alarm before the barriers go down.

I'm 99% sure this happens in MSTS with the correct parameters. So the traffic will stop then after a short time the barriers will go down. In OR, the crossing sound activates as soon as the barriers start to close giving no warning to the traffic.

Crossings with just warning lights, as in OR, the sound activates as soon as the lights start to flash, in MSTS, adjusting them parameters also caused this.

As i said, im not completely sure as i havent used MSTS ( to check crossings ) in years.


Thanks

[Mike B]

As for the gates going down when the train enters the track circuit, then reopening if the train stops for some length of time before the crossing, that's standard in the U.S., not just on light rail lines. No sense keeping the crossing closed if the train's going nowhere, and might in fact be getting ready to back up (as in switching situations). The gates go down again once the train starts to move, with plenty of bell and whistle and moving slowly until actually occupying the crossing.

On light rail lines it's LESS likely to happen since the crossing gates are often triggered by signal circuits in addition to track circuits. Track circuits are mainly a backup for activating the gates when something goes wrong. An interesting model feature, perhaps, might be an indicator (flashing blue strobe light in my local system) mounted on the crossing equipment shack that lights when something is wrong with the crossing - signals down, damage to gates, local power out, lost communication with traffic signals, and the like. Train operators slow (perhaps in emergency if there's no warning before seeing it) to restricted speed for crossings when that light is flashing.

When a light rail train stops at a station in private r/w, modern practice is to hold the train at a red signal until several upcoming grade crossing gates are activated (preferably, all of them until the next station if it isn't too far away). For longer distances, there will be progressive gate closing based on the train's allowed speed, and the train may be released on a yellow indication after the first couple of crossings' gates are down. And if the tracks parallel a main street, the traffic signals are often interconnected with the grade crossing signals to allow cross-traffic to clear the crossing, then block it after the gates are down allowing the parallel street's through traffic to proceed. Various special traffic signals may also be present such as a no-turns indication while the crossing gates are active. In otherwise non-signaled areas, my local system also uses a small lighted-semaphore style signal at a station platform, which holds the train until at least the next couple of gates are down (horizontal bar to hold, diagonal bar to proceed). Finally, in the downtown area with street running, trains operate on "VFR" and the traffic signals have an extra light, timed as part of normal traffic signal operation, that allows the train to pass when lit; trains don't actually trigger it.

Because of the gate interconnect with the signals, I've seen cases where a light rail train can be stopped a long way from a grade crossing, but if it's visible to the signal system the gates will stay down indefinitely. That happened one morning when our train derailed at the switch where the line went from single to double track. Most of the train stayed on the track, and was of course visible to the signal system. So the next crossing gates on both ends of the train (one over a mile away) stayed down until the signal dept. could come and deactivate things. Took all day to clear up the derailment; we rode buses home...

Somehow, I suspect that MSTS can't handle those kinds of complications. Perhaps ORTS can.

[Coolhand101]

Mike B, on 12 August 2016 - 01:46 PM, said:

As for the gates going down when the train enters the track circuit, then reopening if the train stops for some length of time before the crossing, that's standard in the U.S., not just on light rail lines. No sense keeping the crossing closed if the train's going nowhere, and might in fact be getting ready to back up (as in switching situations). The gates go down again once the train starts to move, with plenty of bell and whistle and moving slowly until actually occupying the crossing.

Yes i can understand if the train is held for some length of time, certain crossings can do this. But as soon as you stop seems unrealistic to me. It would be nice to have this timed feature in OR though.

Anyhow, i can adjust certain crossing to suit the conditions required. And the first thing i did changed was the distance activation for automatic crossings at stations.

Thanks

[Jovet]

Coolhand101, on 12 August 2016 - 12:46 AM, said:

I know exactly how approach controls signals are suppose to behave. You have misread what i meant.

Nah, I didn't mis-read it. I was just thinking that OR will do speed or distance—but not both—on the same SignalType. Like I said, I haven't really looked closely at or experimented with the OR-added features.

Coolhand101, on 12 August 2016 - 01:22 AM, said:

All this can be achieved from the distance activation level. I can get what i need from adjusting the distance activation to better suit these crossings.
It would be nice if the signal at red, to keep the crossing open, can close the crossing once the signal clears if in the required activation distance!

I agree with you. I think that would be an improvement that makes sense and won't hurt anything.

One problem I see in general is that most LevelCr objects in MSTS/OR are not configured correctly. They get plunked down with the default values, which bear no relation to how any real crossing signal operates. So changing the behavior of MSTS LevelCr objects can have unintended consequences.

Coolhand101, on 12 August 2016 - 01:22 AM, said:

Crossings with barriers, should sound an alarm before the barriers go down.
I'm 99% sure this happens in MSTS with the correct parameters. So the traffic will stop then after a short time the barriers will go down. In OR, the crossing sound activates as soon as the barriers start to close giving no warning to the traffic.
Crossings with just warning lights, as in OR, the sound activates as soon as the lights start to flash, in MSTS, adjusting them parameters also caused this.

The LevelCr alarm sound starts the moment the LevelCr activates. If the LevelCr is a gate/barrier, then the gate starts moving at the same time.

You can duplicate the delay with careful configuration of the LevelCr objects. It's why above I advocated setting the Activate Early By setting for the gates to be 3-5 seconds after the lights when setting up both interactive gates and lights. I set one of the lights to sound the bell, so the lights and bell sound for a few seconds before the gates start to go down. This was not really possible in MSTS because its detection system was completely wonky, but OR works pretty well.

Mike B, on 12 August 2016 - 01:46 PM, said:

As for the gates going down when the train enters the track circuit, then reopening if the train stops for some length of time before the crossing, that's standard in the U.S., not just on light rail lines. No sense keeping the crossing closed if the train's going nowhere, and might in fact be getting ready to back up (as in switching situations). The gates go down again once the train starts to move, with plenty of bell and whistle and moving slowly until actually occupying the crossing.
Somehow, I suspect that MSTS can't handle those kinds of complications. Perhaps ORTS can.

Yes. Basically if the Predictor thinks the train is going to get to the crossing in under the constant-warning-time-number-of-seconds, then the crossing will activate. The fact that the train later stops before getting to the crossing only matters to the Predictor when the stop happens. In theory a train could sneak very slowly up to a station stop so as not to trip the Predictor, but this isn't a very efficient way to handle a train.

One thing is a Predictor will not usually time-out (shut off) an active crossing warning system when detection immediately stops. There's usually a delay to prevent (at the very least) intermittent detection from turning the crossing on and off over and over. OR is currently not effecting this delay. The delay varies by circumstance and might be anywhere from 10 to 120 seconds.

Unfortunately OR cannot handle all of these complications. It's still limited to MSTS standards of LevelCr parameters. But it does realize those parameters a lot better than MSTS did.

Ideally the OR Level Crossing system evolves into a much more sophisticated beast at some point in the future. It seems to me it should be able to define a level crossing as a unit, with (unlimited) detection controls and signal controls and CarSpawner controls that interface with that unit.

[Coolhand101]

Things are looking up to get the operation i need for the train has to stop before proceeding method. I have two options.

1. Signal and signal marker in front of the crossing marker, :-

The signal is at danger either by a waiting point or approach control script, the crossing is open regardless of the activation distance. However, when the signal clears, the crossing will not activate until the train moves. Ideally this mean you can stop your train without the worry of the barriers opening again.

The only downside is when the crossing signal( approach_1 ) flashes once the waitpoint time or AP point is reached, the crossing barriers are still open( crossing deactivated ) until the train moves.

2. Signal shape in front of the crossing and signal marker behind the crossing marker, :-

A waitpoint is used to keep the signal at danger. If well timed, the crossing will activate fully when in the activation distance and the signal will flash ( approach_1 ) there after. If the activation distance is long enough, and the train has stopped, the crossing should still remain close, with the signal flashing ( approach_1 ).

Again, the downside is stopping outside the activation distance, the crossing wll deactivate( barriers open) again.

If the activation distance is too long, then trains coming the other way, when clearing the crossing and stopping at the station, the crossing will still remain active( barriers down ), until the train clears the crossing activation distance. Ideally the crossing deactivates as soon as the train clears the crossing.

Any thoughts of improving these methods used ?



Thanks