[Jovet]

Coolhand101, on 08 August 2016 - 01:03 AM, said:

Yes that is correct. I was referring to Roeters update, which states the signal should control this.

It's my understanding that a NORMAL signal between the train and the level crossing at STOP will cause the LevelCr objects to not activate. Once the signal upgrades from STOP then the behavior is normal—the LevelCr objects will activate when the train moves towards them within the parameters with which they're configured. They will/should not automatically turn on unless the train is in the Minimum Activation Distance.

[Coolhand101]

jovet, on 08 August 2016 - 01:07 PM, said:

when the train moves towards them

Yes this is the behaviour i am getting, once the signal changes from start to proceed. However according to what i read from roeter, stating "The LC will close when the signal clears". This is not happening.

I was hoping that when my white flashing signal is activated( normal clear from stop ), the crossing will activate, either barriers or lights , if in the required distance. Roeter does state that the signal should not clear until the crossing is fully activated, but that requires a code change.


Thanks

[Jovet]

Coolhand101, on 08 August 2016 - 01:52 PM, said:

Yes this is the behaviour i am getting, once the signal changes from start to proceed. However according to what i read from roeter, stating "The LC will close when the signal clears". This is not happening.

I suspect you're reading too much into his wording. He said "will" but I bet meant "can." Short of being inside the activation distance, there's no reason for a LevelCr object to ever activate if there is no train moving towards its track marker. In other words, if you want the level crossing signals to activate the moment the wayside signal clears, then you need to (greatly) extend the Minimum Activation Distance of those LevelCr objects to include where the train is sitting, waiting for the signal.

Coolhand101, on 08 August 2016 - 01:52 PM, said:

I was hoping that when my white flashing signal is activated( normal clear from stop ), the crossing will activate, either barriers or lights , if in the required distance. Roeter does state that the signal should not clear until the crossing is fully activated, but that requires a code change.

Yes, realistic operation of those kinds of signals are functionality which OR just does not have yet. The closest you can get to duplicating it is by making a LevelCr signal shape and not using a true signal.

Similarly you should not want or expect a level crossing warning signal, which reports on the condition of the level crossing protection signals, to in any way itself control whether those signals activate or not in the game. So I hope (but it's not clear) that you're talking about two different signals in the scenario you're setting up.

[Coolhand101]

Some progress.

1. Approaching the crossing at the 20 mph required speed:

A double RP was used, to keep the white flashing( NORMAL ) signal at stop( no white flashing light ).

When i tripped the DRP, the signal was flashing ( Clear_2 ) and the crossing activated.

2. Approaching the crossing which requires a complete stop:

A waitpoint was used to keep the white flashing( NORMAL ) signal at stop. After the waitpoint expired, the signal was flashing ( clear 2 ). Although i was in the required distance for the crossing to activate, this did not happen until my train begin to move.

I will continue testing the crossing activation distance.

Thanks

[Coolhand101]

Increasing the distance made no difference!

Also i just tested another DRP for a different station and flashing signal.
This time i had to stop in the station before the crossing, as oppose to approaching the crossing first then stopping at the station after.

The DRP held the signal at danger. As i was coming into the station, the DRP tripped, the signal started flashing and the crossing lights and alarm sound came on. Success!!!.....

No, it was very short lived. As soon as i came to stand in the station, and well inside the activation distance. The crossing lights stop flashing and the traffic started to move. Moving a tad, then stopping, the crossing once more activated and stayed that way until my train passed.

Conclusion, it appears that if a signal before a crossing is showing a stop aspect, and that signal clears. The distance activation no longer works to that crossing unless the train moves slightly then stops, causing the activation distance to work again. Could this be a bug?

Also, the ( two ) red flashing crossing lights when not activated, one has a permanently lit steady red light. I would like this light not to displayed when the crossing is inactive. Any ideals?

Btw, your trick for the negative number in the RE crossing box worked 100%.



Thanks

[Jovet]

Coolhand101, on 09 August 2016 - 05:27 PM, said:

Increasing the distance made no difference!

Then it works differently than I was thinking. It seems to me that the Activation Distance should override whether a train is moving or not, and the Signal-At-Stop-In-between should override that. But I was also thinking that your station stop was before the crossing, too.

Coolhand101, on 09 August 2016 - 05:27 PM, said:

The DRP held the signal at danger. As i was coming into the station, the DRP tripped, the signal started flashing and the crossing lights and alarm sound came on. Success!!!.....
No, it was very short lived. As soon as i came to stand in the station, and well inside the activation distance. The crossing lights stop flashing and the traffic started to move. Moving a tad, then stopping, the crossing once more activated and stayed that way until my train passed.
Conclusion, it appears that if a signal before a crossing is showing a stop aspect, and that signal clears. The distance activation no longer works to that crossing unless the train moves slightly then stops, causing the activation distance to work again. Could this be a bug?

The game is designed to stop the LevelCr objects if a train moving towards the crossing stops and/or reverses before actually getting to the level crossing. I would expect the activation distance to take effect if it's large enough, but apparently it does not.

Not sure I'd call it a bug, (I am biased—I've been fine with how it works) but there's still may be room for improvement. You should ask Carlo and/or Rob about it, if they don't notice this thread.

I also meant to mention above, you said that the crossing alarm sound stops. From what I can tell, that is a bug, which happens to me sometimes, but I have yet to identify the circumstances that cause it to happen. It does seem more prone to happening at some level crossings and not others, but I do not know why.

Coolhand101, on 09 August 2016 - 05:27 PM, said:

Also, the ( two ) red flashing crossing lights when not activated, one has a permanently lit steady red light. I would like this light not to displayed when the crossing is inactive. Any ideals?
Btw, your trick for the negative number in the RE crossing box worked 100%.

The flashing-light shapes have to be especially-designed to be animated as a LevelCr object like that. Animation frame #0 must have all lights be "off," for example. Additionally, there must be "all off" frames during transitions from one light to another so that the animation doesn't seem lop-sided (assuming that is not prototypical).

You can convert the appropriate .s file to Unicode and hack its animation parameters to achieve this, similar to what has been done to get the turntable shapes to work. At the end of the file where the animation information is, there should be a series of linear_pos groups. Each linear_key under that marks an animation keyframe which controls the animation at specific frame numbers (the first parameter). Since how the shape is specifically animated can vary, I can't walk you through further than that. But what you need to do is to figure out which key numbers mean which positions the animated objects and then arrange/add/remove them so they're correct. If you want to get serious about that, I suggest you start a new thread.

[roeter]

The behaviour that level crossings reopen (or remain open) for trains which are stopped was introduced in version 3433 (feb. 2016), by edwardk, for reasons of compatibility with MSTS. As ever, this behaviour is correct for some countries, but completely wrong for others.
Basically, the original MSTS definition for level crossings is far too limited to have proper working for all the various types of crossings, not to mention the large variety of ways of interaction between signalling and level crossings.

Regards,
Rob Roeterdink

[Coolhand101]

roeter, on 10 August 2016 - 01:12 AM, said:

The behaviour that level crossings reopen (or remain open) for trains which are stopped was introduced in version 3433 (feb. 2016), by edwardk, for reasons of compatibility with MSTS. As ever, this behaviour is correct for some countries, but completely wrong for others.
Basically, the original MSTS definition for level crossings is far too limited to have proper working for all the various types of crossings, not to mention the large variety of ways of interaction between signalling and level crossings.

Regards,
Rob Roeterdink

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

I can see two ways to get both desired methods:

1. If the train is stopped and is not within the crossing distance, ie 20 meters, then the crossing will deactivate. If the train is stopped within the 20 meters, then the crossing will remain close.
This both occurs if there is no signal or the signal is clear. This is the current behaviour in OR.

2. For a signal which is held at red by a waiting point or double reverse point. The crossing is deactivated regardless of the crossing distance. When the signal clears, the crossing remains deactivated until the train starts to move, again this is the current behaviour in OR.

For the latter, if the train is within the crossing distance, when the signal clears, the crossing will then activate. This can be implemented and still maintain MSTS compatibility.

Any thoughts on this ?

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

Thanks

[Coolhand101]

jovet, on 09 August 2016 - 08:15 PM, said:

You can convert the appropriate .s file to Unicode and hack its animation parameters to achieve this, similar to what has been done to get the turntable shapes to work. At the end of the file where the animation information is, there should be a series of linear_pos groups. Each linear_key under that marks an animation keyframe which controls the animation at specific frame numbers (the first parameter). Since how the shape is specifically animated can vary, I can't walk you through further than that. But what you need to do is to figure out which key numbers mean which positions the animated objects and then arrange/add/remove them so they're correct. If you want to get serious about that, I suggest you start a new thread.

Many thanks for the explanation. A slight adjustment and all is well.

I now have four crossing warning lights that actual work according to the condition of the 'open' crossing.

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.?

I'm going to make these flashing signals 'approach control' via the signal scripts. I'm getting some wierd pathing issues when using DRP and WP to control these signals, when using the same path ( single line ) both directions in an activity.

Thanks

[Coolhand101]

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

I'm going to make these flashing signals 'approach control' via the signal scripts. Thanks

Okay i'm normally good at scripts but i cannot get this to work 100%

sigcfg

ApproachControlSettings ( PositionYd ( 200 ) SpeedMPH ( 20 ) )

The approach control signal was clearing below 20 mph at any distance, but i've been going around in circles for a good while and i'm failing to spot my mistake. Help!

Edit

If i have no luck, i start a new thread.

I can get the approach control to work as abovem but here is the problem:

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.
Any ideals?

Thanks

[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.