[steamer_ctn]

I have just added some code to calculate the allowable speed limit around curves.

For some background, the benefits of traveling within the relevant speed limit are briefly described in this article and this one (article across 3 pages).

As suggested in these articles, the benefit of remaining within the allowable speed limit is to reduce rail wear, ensure passenger comfort, and prevent derailing or overturning of the train.

The allowable speed around a curve will often be less then the posted speed limit for the route or line, and as a general rule the tighter the curve, the slower the train will need to go, to safely negotiate it.

As suggested in these articles, there are a number of different formulas that have been developed that permit the calculation of the speed (though they are derived from a common base). The speed will be determined by consideration of a number of factors, including rail superelevation, cant deficiency or the unbalanced superelevation value, weight of stock, track gauge, radius of curve, etc.

The new model will calculate two speed limits:
i) Allowable speed around the curve, based upon normal operation,
ii) and the speed at which a train will overturn due to excessive centrifugal force.

Currently only alarm messages will be presented to the user if these speed limits are exceeded.

Track gauge values can be entered into the wagon section of the WAG and ENG file, otherwise it will default to "standard gauge - 4' 8.5"

Examples of some of the permissible format for trackgauge are:

ORTSTrackGauge ( 4ft 8.5in )

Or

ORTSTrackGauge ( 1.435m  )

Wagon Centre of Gravity will be read from the default CoG statement. If the CoG statement is not present, then default "standard" value will be used.

Cheers

Peter

[dennisat]

steamer_ctn, on 28 February 2014 - 05:39 PM, said:

...The speed will be determined by consideration of a number of factors, including rail superelevation....

The problem at the moment is that superelevation is visually very poor except in a very few track systems. Look at UK Finescale routes for instance, any dynamic track is displayed as standard MSTS giving jarring transitions.
Will this feature be user selectable until the superelevation track textures for systems like UK Finescale have been developed? I think I would prefer a visually good route to the realism of falling off curves (or receiving continual overspeed messages) because there is no superelevation.

Dennis

[roeter]

In my view, there should be no messages or warnings if the train is within the speedlimits as set by the route speedposts or signals - whatever the calculation may yield.
Setting proper speedlimits must be done by the routebuilders.
Also, it should be remembered that the route is just an approximation of the reality - for all kinds of reasons, the curves in the simulator might be quite a lot more thight than at that same location in reality. And as mentioned above, superelevation is not yet properly available for all types of routes either.
At best, this implementation should be an experimental option only - default OFF.

Regards,
Rob Roeterdink

[Matej Pacha]

For now, it has nothing to do with the visual feature of superelevation. The superelevation is computed differently - based on the curve radius, speed limit, etc. The main problem is that most of the routes, including those by MSTS (KUJU), introduces some kind of simplification of track routing. Thus, many curve radiuses are too small to be ok for given speed limits. Until we solve this issue, you may notice a warning message "The speed is too high for this curve..." or similar, even if the speed limit in the F4 HUD view is higher.

Matej

[Matej Pacha]

roeter, on 01 March 2014 - 01:48 AM, said:

At best, this implementation should be an experimental option only - default OFF.

You are faster than me :sign_thanks:

Agreed. Will be implemented as an option.

[steamer_ctn]

dennisat, on 01 March 2014 - 01:39 AM, said:

The problem at the moment is that superelevation is visually very poor except in a very few track systems. Look at UK Finescale routes for instance, any dynamic track is displayed as standard MSTS giving jarring transitions.

The feature that has been added, as suggested in one of the above posts, is not based on the visual (train tilting) representation of superelevation. The visual method uses a single superelevation value regardless of the curve radius, whereas the speed calculation is based upon different published values of superelevation for different curves.

In future they could be linked and use the same reference superelevation values.

roeter, on 01 March 2014 - 01:48 AM, said:

In my view, there should be no messages or warnings if the train is within the speedlimits as set by the route speedposts or signals - whatever the calculation may yield.
Setting proper speedlimits must be done by the routebuilders.

I believe that this is another instance where MSTS sacrificed reality for expediency. It is possible for the route to have a posted speed limit value of say 85km/h, but for curves along the route due to their radius to require a reduction in speed to a value less then this. In some intsances they may be sign posted with the speed limit, in other instances the driver was expected to learn them as part of his route knowledge and adjust his speed accordingly.

An analogy might be a town centre, where for cars there is a common speed limit of say 45mph, but the car driver wouldn't expect to turn from one street to another at the signposted speed limit, but rather they would slow down to safely negotiate the corner.

For a train to go around a 400m curve at 85 km/h (52 mph), a balanced superelevation value of 200mm (7.9 in) would be required. This is well above the maximum recommended value. It would not be unusual for some curves to have an even tighter radius, down as low as 100m, which would need an even higher value of superelevation, again well outside the suggested bounds.

Superelevation values are determined at the time of track design, and will take into account whether it is a high speed track, low speed track and whether both freight and passenger traffic are using it.

roeter, on 01 March 2014 - 01:48 AM, said:

Also, it should be remembered that the route is just an approximation of the reality - for all kinds of reasons, the curves in the simulator might be quite a lot more thight than at that same location in reality. And as mentioned above, superelevation is not yet properly available for all types of routes either.

This would depend upon the accuracy of the route, but it shouldn't necessarily be a reason to not strive for some degree of realistic operation of OR above what MSTS could deliver.

I would be interested to see how many routes that this might apply to, and whether it is likely to cause major problems or not.

I agree that some of these types of features may challenge us. For example, the way that we drove a train in MSTS may not be the same as how it needs to be driven in OR.

I suspect that it will be a while before individual curves could have superelevation values inserted into the track database file.

As an alternative the following section could be included in the trk file to allow input of superelevation information on a route by route basis:

ORTSSuperElevation ( 5
                        ORTSCurve ( 100m  100mm )
                        ORTSCurve ( 300m  75mm )
                        ORTSCurve ( 500m  50mm )
                        ORTSCurve ( 1000m  25mm )
                        
                        )
ORTSUnbalanceSuperElevation ( 75mm )

This could also be used by the visual superelevation (train tilting) code as well.

roeter, on 01 March 2014 - 01:48 AM, said:

At best, this implementation should be an experimental option only - default OFF.

Given that OR is still in beta, and it seems that a lot of new features are included almost on a daily basis, without necessarily being considered "experimental", can you assist me to understand the criteria used to determine when a feature is experimental or otherwise?

Thanks

[Csantucci]

In general (with some exception in both directions), at the moment experimental features are those not present in MSTS.

[James Ross]

steamer_ctn, on 01 March 2014 - 11:38 PM, said:

Given that OR is still in beta, and it seems that a lot of new features are included almost on a daily basis, without necessarily being considered "experimental", can you assist me to understand the criteria used to determine when a feature is experimental or otherwise?

Experimental covers a few kinds of features:

• Anything where it is known to be unstable or crash.
  
• Anything which is known to be incomplete in some way.
  
• Anything which is might seriously impact playability of activities/etc.

We're also not agreed that we should be adding this feature in the first place, judging by some of the comments. ;)

[Csantucci]

I've just run release 2070 getting these warning strings about overspeed in curves. I find them annoying, as in reality that's not something the driver receives in that way, if it ever receives such warning. And moreover, I was driving a tilting train, that is allowed to run faster in curves. So I ask to remove such strings or at least to allow to disable them.

Edit: I've seen that the speed warning has disappeared in version 2071. Thanks Peter for that!
I see a possible use of the curve speed limit feature for AI trains.

[roeter]

Csantucci, on 02 March 2014 - 09:15 AM, said:

I see a possible use of the curve speed limit feature for AI trains.

Not the way it is setup now.
The train is tested when it is in the curve. Starting to brake at that moment generally means the train will have attained the correct speed only just as it leaves the curve - and thus can immediately start accelerating again. But it will never run through the curve at the required speed.
The only use I can see at the moment is for route-builders : they can run test-trains using this feature to check if the correct speedlimits have been set.

Regards,
Rob Roeterdink