[Genma Saotome]

Hamza97, on 08 September 2018 - 07:58 PM, said:

Actually I got this message in an opposite situation. I was just driving around in Free Roam mode when I took a diverging switch at 50kmph instead of permitted 20km/h. Even then I got this message of traveling to slow for this curve.... Pretty Ironic... :rotfl:

As a trial balloon, sure, anything goes. As a real feature as implemented it made no sense. Consider a route traveling along a river... it's all curves, some of which may be very broad and others quite sharp with transitions and short tangents in-between, all due to the terrain. Go slow enough to head into the sharp curves safely and the message you are going too slow pops up for that part of the train that happens to be on the wide curves. Enter the sharp curve and both too fast and too slow pop up one after the other. The engineer cannot possible control his train to deal with both simultaneously.

Clearly in the example above the actual cant would have been very low on the broad curves because the speed in the area was dictated by the sharp curves. Reflecting that in OR would mean no warning would have been issued.

The idea behind the message is fine and Peter can be commended for thinking this could be good; unfortunately it should (IMO) be based on the posted speed limit the train is controlled with consideration to what cant would have been built into the curves for that speed. Apparently that's a bit harder to accomplish.

[Goku]

For me, OR should choose such superelevation value for a curve, that it is save to stop there without derailment.

[Genma Saotome]

Goku, on 10 September 2018 - 06:23 AM, said:

For me, OR should choose such superelevation value for a curve, that it is save to stop there without derailment.

Yes. Within the context of the speed limit every curve will have it's own cant.

The display mechanism OR presently uses has to be different than what OR can do w/ physics. The former is a kludge, doing only what's feasible with existing track shapes, the later is applied to train physics and can be done completely correctly as-if the correct cant had been built into the route.

[steamer_ctn]

It should be noted that the OR visual representation and physics calculations for superelevation are independent of each other. (At some stage hopefully they will be integrated)

By default OR applies some level of superelevation to curves within a route by default.

The user can override these values by using the ORTSTrackSuperElevation (x y) parameter in the TRK file or an INC file. An example is provided here.

[Genma Saotome]

Peter... something I noticed while testing these past few days... the car number spite seen in the f7 display matches the UiD() values in the .con file... and I would assume the .act and .trf files as well. I believe the f5 displays you worked on recently show the same values. I want to say thanks for that, it was very helpful to me. I wish the other f5 displays did the same thing.

There was one thing tho.. the UoM on track radius and slack; I've seen plenty of U.S. track charts and all use feet as the unit, not yd or mi. as seen in the f5 display. For slack, always inches, not feet. Next time you visit that topic might you revisit those UoM's and change them over to what's in use here? Thanks.