[PerryPlatypus]

I have noticed a number of ways Open Rails is handling speed zones incorrectly. I discovered this issue when trying to configure speed limits on my Mullan Pass route, but I would have the speed limit randomly change while midway between speed zones, increasing when they should decrease, etc. For a test comparison, you can run a short passenger train on the freeware Surfliner 2 route, starting at Fullerton heading southbound (towards San Diego) on right-handed running (the westernmost of the 2 main tracks).

A correctly functioning speed reduction: The change from 75 to 40 MPH when travelling southbound about 0.25 miles south of Fullerton station

An incorrectly functioning speed increase: The change from 40 MPH to 75 MPH when travelling southbound about 0.5 miles south of Fullerton station.

A correctly functioning increase in speed: The change from 40 to 75 MPH when travelling southbound, about one mile before Santa Ana station.

An incorrectly functioning speed reduction: the change from 75 to 50 MPH when travelling southbound about 0.5 miles before Santa Ana station. (Open Rails does not recognize the reduction until the whole train has passed)

As noted, when increasing speed, the limit should not take effect until the rear of train has cleared the speed sign. And when decreasing speed, the limit should take effect immediately after the head end passes the sign. If you run a longer train, you may run into even more strange issues, where speeds increase when they should decrease, or vise versa. Having multiple speed zones in relatively close proximity seems to increase issues.

I wonder whether this has something to do with whether the signs are on "flipped" pieces of track (pieces that have been inverted in the Route Editor by pressing the T key)? I have come across this issue in multiple recent releases, including the most recent "unstable" release X3549.

[Csantucci]

Have you noticed that in activity mode or in explorer mode?

[PerryPlatypus]

 Csantucci, on 28 May 2016 - 09:11 AM, said:

Have you noticed that in activity mode or in explorer mode?

I noticed the behavior in Explorer Mode, but I can test out if it occurs in Activity Mode or not. The good news is it is not sporadic, if you or someone else runs the mentioned stretch of track on the Surfliner 2 route, the speed limits change in the same way each time, which once again leads me to believe it might have something to do with whether the track pieces are "flipped", both at the location of the speed change and in between speed changes.

[Csantucci]

If you could test this in activity mode that would be nice, thank you.

[PerryPlatypus]

 Csantucci, on 28 May 2016 - 11:00 AM, said:

If you could test this in activity mode that would be nice, thank you.

It does appear this functions correctly in Activity Mode! Thank goodness :) I suppose in Explorer Mode, the simulator has a harder time keeping track of the direction of the train's movement since it does not have a set path? (I suspect Manual Mode may produce similar results)

[Csantucci]

I'd like to ask you another question: could you test if the problem occurs also with OpenRails 1.0?

P.S.: in the meantime I checked and found a test case (speed limit reduction active only when the whole train has passed by) also in the Marias Pass route; the problem occurs also with release 1.0.

[Mike B]

I think I (and others) mentioned this issue back in pre-1.0 days. At that time, ORTS consistently changed the speed limit display in the F4 window only when the last car passed the speed post, regardless of up or down. Some routes were somehow able to work correctly (Cuesta Grade iirc) but most including the MSTS defaults didn't.

As the poster here notes, the standard reaction to speed posts should be to change immediately at the head end when the speed limit decreases, and change at the last car for speed limit increases. MSTS works that way, reliably.

Somewhere between 1.0 and 1.1, ORTS started working correctly most of the time. But for some reason not consistently; some speed posts, even in routes that otherwise work correctly, still behave incorrectly - in particular, waiting for the last car on decreases. I've been running Rollins Pass recently, for instance, and in Explore Mode a few speed posts work wrong but most are correct. Not sure if or how that's route-related, as compliance with standard practice was before 1.0, but the fact that it's now only occasional (for me) suggests that something route-related is involved even if, technically, the fault is in ORTS for not interpreting the speed post properly. For now, I just ignore any glitches (which don't consistently appear) and run like I should ...

[Csantucci]

I've committed a fix in x.3550. I hope it covers all cases and that it has no drawbacks.

[Jovet]

 Mike B, on 30 May 2016 - 05:34 AM, said:

MSTS works that way, reliably.

That's news to me... I don't remember MSTS doing anything other than the speed limit changing when the leading end passes a speed limit marker. Did I miss something?

[Mike B]

 jovet, on 31 May 2016 - 08:14 AM, said:

That's news to me... I don't remember MSTS doing anything other than the speed limit changing when the leading end passes a speed limit marker. Did I miss something?

OK. MSTS works that way for me, reliably. Is it something in the routes? Main issue with ORTS was that it was unreliable - worked sometimes, not others. Recent builds have been much better. Consistency - the hobgoblin of little minds and rulebooks.