[PerryPlatypus]

Csantucci, on 30 May 2016 - 09:41 AM, said:

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

Thank you very much for this fix! :) I just tested version X.3551 on the Surfliner 2 route with a short passenger train and my Mullan Pass route with a long freight train, and everything so far is behaving as it should be. :)

[charland]

I found another issue with speed limits, put in a bug report three weeks ago that hasn't been looked at.

On the DAR if an activity starts on the signaled CN trackage at Bedford, then enters the DAR at Windsor Junction, the speed limit is reduced to 25 mph which is correct. After rounding the wye there is one last signal, then the DAR becomes dart territory for the next 120 miles. The speed limit in this section of the DAR should go to 50 for freights and 60 for passenger, and it works fine in MSTS, but in OR the speed for both remains at 25 for the rest of the 120 miles.

Paul :-)

[Csantucci]

Is this a freeware route? Where can it be downloaded?

[Mike B]

I think "DAR" is this route: Dominion Atlantic Railway - http://www.trainsim....lle-Subdivision

See also: http://www.dardpi.ca...title=Main_Page and scroll down to "The Digital DAR".

Correct?

[Csantucci]

Mike,
thanks for the useful link.

Paul,
I checked the problem. However in my opinion the problem is not at the OR side, but at the MSTS side, even if this seems quite strange to me.
The last signal keeps the max speed at 25 mph, as it is in approach state and for such state max speed is 25 mph. As I just tested with a test route, MSTS in general (and OR too in activity mode) keeps this max speed, even if there is a speedpost raising the speed after the signal. To raise the speed a signal raising the speed is needed.
In this particular case instead MSTS raises the maxspeed with the speedpost, even if the maxspeed was kept lower by the signal.
As a first thought I think OR should not follow this MSTS exception, which is the first time I find.
Or is there something wrong in my analysis?

[Jovet]

Csantucci, on 07 June 2016 - 08:13 AM, said:

As a first thought I think OR should not follow this MSTS exception, which is the first time I find.
Or is there something wrong in my analysis?

MSTS maintained three separate speed limits:

• The absolute speed limit defined in the .trk file.
• The speed limit imposed by the most-recently-passed, least-restrictive signal head, if any.
• The speed limit imposed by the most-recently-passed speed post, if any.

The actual speed limit of the train at any time is the lessor of these three. So yes, in MSTS, only another signal could cancel a low speed limit imposed by a signal.


In Open Rails this is not the logic that is followed. I'm not really sure what the logic is. But I tend to prefer what MSTS did versus what OR does.

[eugenR]

charland, on 03 June 2016 - 12:55 PM, said:

The speed limit in this section of the DAR should go to 50 for freights and 60 for passenger, and it works fine in MSTS, but in OR the speed for both remains at 25 for the rest of the 120 miles.
Paul :-)

That the MSTS does so, is a well known exeption:
The MSTS doesn't recognize the Speedreduction of the last Signal (Type NORMAL) until to the end of the track.
And here it is so!
So MSTS can here rise the speedlimit with speedplates, because he has not recognize any Signal-Speedlimit.

[Csantucci]

jovet, on 07 June 2016 - 02:17 PM, said:

MSTS maintained three separate speed limits:

• The absolute speed limit defined in the .trk file.
• The speed limit imposed by the most-recently-passed, least-restrictive signal head, if any.
• The speed limit imposed by the most-recently-passed speed post, if any.

The actual speed limit of the train at any time is the lessor of these three. So yes, in MSTS, only another signal could cancel a low speed limit imposed by a signal.


In Open Rails this is not the logic that is followed. I'm not really sure what the logic is. But I tend to prefer what MSTS did versus what OR does.

OR in activity and explorer mode uses the same logic.

[Csantucci]

eugenR, on 07 June 2016 - 03:29 PM, said:

That the MSTS does so, is a well known exeption:
The MSTS doesn't recognize the Speedreduction of the last Signal (Type NORMAL) until to the end of the track.
And here it is so!
So MSTS can here rise the speedlimit with speedplates, because he has not recognize any Signal-Speedlimit.

Thanks Eugen, so you confirm that there is an exception in how MSTS manages signal speedlimits. I don't think OR should follow this exception.

[Railcat]

Csantucci, on 07 June 2016 - 09:17 PM, said:

OR in activity and explorer mode uses the same logic.

Though I think this logic is quite right, I don't know why it is not used in timetable mode. Because from the manual:"In timetable mode if a speedpost sets a limit which is higher than that set by the last signal, the limit set by the signal is overruled and the allowed limit is set to that as defined by the speedpost."