[R H Steele]

 cjakeman, on 29 July 2021 - 08:34 AM, said:

Can we move on in the Simulation tab to look at the resistance options?

2021-07-29 17_28_44-MS Excel with extensions - Options.xlsx.jpg


These are all calculations which make the simulation more realistic.

Is there any need to turn them off?
Do they have a bad impact on the frame rate?
If so, do they affect every train or just the player train?

Curve dependent speed limit is ( from all I've read in the forums and from experience ) so poorly modeled as to be useless. Never have checked that box...I remember reading that it had to do with how the curved track pieces were laid in the MSTS RE...way beyond my understanding.

[Laci1959]

 Weter, on 25 July 2021 - 08:00 AM, said:

Most likely, Bill.

Hello.

The Curve dependent speed limit is a mistake I think. The speed that can be used for a given arc radius depends on the build speed of the track. If a line of local interest is designed and built at a speed of 40km / h, there is no speed limit. If a main line is designed and built at a speed of 160 km / h, however, a speed limit will be imposed if required due to the arc radius. Of course, it is the same arc radius in both cases.
I think that should be left to the track builders.

Sincerely, Laci 1959

[steamer_ctn]

Curve Dependent Speed Limit - has been developed based upon this paper, and others like it. In short, if a train goes too fast around a particular curve it is possible for it to leave the tracks (see pg 11 of the paper for an example).

Studying the paper it can be seen that the speed limit around a curve is based upon the curve radius, centre of gravity of the rolling stock and the amount of track superelevation. In addition the cant angle of the rolling stock is taken into account when considering passenger comfort. So the challenge for this to work correctly it needs all these elements to be set correctly by the route builder, and content builders. There are some defaults in OR, but for the most accurate representation they need to set to the actual route standards used by the relevant railway companies. All of these values can be configured into the current version of OR.

Typically a railway company may design a cheap route which tends to have lots of curves. In this instance the the route might have a general speed limit, but expect the driver to reduce speed at some curves in order to negotiate them correctly. Alternatively as is the case with more modern high speed routes the route is designed to a specific speed limit, for example 160mph. In this case only large radius curves would be included in the route so that the speed limit could be maintained for the duration of the route.

Considering the fact that it is impossible to derail a train in OR (no matter how hard you might try), it is important to have some checks and balances to advise a user when they are exceeding realistic boundaries, otherwise a user could expect to drive a train at any speed without consequence. This is not the reality in the real world.

I believe that it should remain, and possibly the best place for it is in the activity "setup" process.

In regards to the other three resistance values, they can be set permanently on in Advanced Physics, and off in Simple Physics.

[Laci1959]

Hello.

Sorry to contradict, but the AI trains are driven by the program, the player goes as far as he wants.
Whether it is on or not.
You would rather stay with the current option.

Sincerely, Laci 1959

[cjakeman]

 steamer_ctn, on 29 July 2021 - 08:17 PM, said:

In regards to the other three resistance values, they can be set permanently on in Advanced Physics, and off in Simple Physics.

Why would you turn them off in Simple Physics?

Are you trying to save CPU cycles and boost the frame rate?

[Genma Saotome]

WRT curve speed. IMO the disconnect between player and program comes down to the facts of (1) the routes we use rarely have posted speed reductions where such things might be relevant and more importantly (2) no route editor allowed the creator to assign a max super elevation, start and end of super elevation in any route. The later would be a typical start here, end there logical path with the max elevation value presumed to apply to the tightest radius within the curve. I assume that would give Peter enough information on ascent and descent for the other radii AND might even be enough to convey useful information to the player well before he arrives at the curve, as it does with speed limits now.

Of course we don't have that. My point is to suggest whatever decision is made presently should be done with what could and should be done with a route editor, even to the degree of contemplating a program that could construct such information for older routes. Yeah, a dream feature, but maybe someone, perhaps Peter, sees a way to make somet6hing like this happen.

In the beginning, as in the first week or so, it was understood the goal was to make a better simulator, not a better game. If that's still relevant in any way then figuring out how to make curve speed work better with the routes we have is, IMO, still important.

[steamer_ctn]

 cjakeman, on 29 July 2021 - 10:34 PM, said:

Why would you turn them off in Simple Physics?

Are you trying to save CPU cycles and boost the frame rate?

 steamer_ctn, on 15 July 2021 - 01:36 AM, said:

So as an example, looking at the physics, I think that we need to define two "standard" use cases (or options), and then merge the physics switches into each of these cases.

I think that we can simplify the physics selection by having a Simple and Advanced mode as follows.

Advanced Mode - enables all physics to apply to train operation. This mode is aimed at a serious user who wishes to run trains as realistically as possible. The majority of the advanced options would go into this mode.

Simple Mode - provides very basic physics. This mode is more aimed at the user who wants to see a train run, but doesn't care whether it operates in a realistic fashion. This mode can also be used to do some level of debugging. So few physics options would go into this mode.

So lets work out where we want to get to, and then what we need to do to get there.

It is based upon the above two tier model that I put forward earlier.

Simple mode in my mind is very basic, just enough to get the train moving.

We need to sort out the model at this level first, ie two, three, four, more tiers? What do each of the tiers deliver in terms of the physics?

Then we can work out what specific functions go where.

[roeter]

 Genma Saotome, on 29 July 2021 - 10:52 PM, said:

WRT curve speed. IMO the disconnect between player and program comes down to the facts of (1) the routes we use rarely have posted speed reductions where such things might be relevant and more importantly (2) no route editor allowed the creator to assign a max super elevation, start and end of super elevation in any route. The later would be a typical start here, end there logical path with the max elevation value presumed to apply to the tightest radius within the curve. I assume that would give Peter enough information on ascent and descent for the other radii AND might even be enough to convey useful information to the player well before he arrives at the curve, as it does with speed limits now.

 steamer_ctn, on 29 July 2021 - 08:17 PM, said:

Studying the paper it can be seen that the speed limit around a curve is based upon the curve radius, centre of gravity of the rolling stock and the amount of track superelevation. In addition the cant angle of the rolling stock is taken into account when considering passenger comfort. So the challenge for this to work correctly it needs all these elements to be set correctly by the route builder, and content builders. There are some defaults in OR, but for the most accurate representation they need to set to the actual route standards used by the relevant railway companies. All of these values can be configured into the current version of OR.

Typically a railway company may design a cheap route which tends to have lots of curves. In this instance the the route might have a general speed limit, but expect the driver to reduce speed at some curves in order to negotiate them correctly. Alternatively as is the case with more modern high speed routes the route is designed to a specific speed limit, for example 160mph. In this case only large radius curves would be included in the route so that the speed limit could be maintained for the duration of the route.

It looks to me as if this is one of those situations where there are significant differences between US and European practices. Furthermore, there are significant differences between different periods.
In most European countries, at the present time, all speed restrictions, including those for curves, are clearly signposted. This is also generally properly set up in most routes. But this was not always so. For instance, in the UK in steam days, there were many areas where there were no speedposts at all, only a list of speed restrictions in the related timetables. And, ofcourse, many steam engines did not even have speedometers.

In my view, though, the present setup of this function has severe limitations.
There are many aspects which this function does not take into account :

• The setup of the curves in the route may not be quite correct in relation to reality, due to the limitations in available curve radii in the availabe track systems.
  
• Proper setup of superelevation, which may vary per curve, is not possible.
  
• More severe speed restrictions then the radius would suggest due to counter curves (S-curves) is not taken into account.
  
• Differentation based on type of rolling stock is not possible. In some countries, there may be as many as five different speed restrictions applied to a section of line, based on type of rolling stock.
  
• The function does not have an advance warning, it only calculates the limit once the train is on that curve, which means that the train will only start to reduce speed once it is on that curve and not in advance as it should do.

A serious problem with this function as it is now is that it can have significant impact on the behaviour of AI trains. This may cause problems for timekeeping. Setting it as a general option, as now, may lead to some users switching this on while others keep it switched off, resulting in very different behaviour of AI trains and thus problems in running an activity or timetable. If this is to be maintained, then it would make much more sense if it was moved to either the .trk file, or the activity or timetable definition. Proper advance warning to the player train, and proper advance braking for AI trains would also need to be added.

One possible more proper use of the functionality behind this option which has been thought of is to analyse the track configuration on start-up of OR and let the program add proper speed restrictions as applicable, such that these are available for AI trains and visible to the user in the track monitor window as 'normal' speed restrictions.

Regards,
Rob Roeterdink

[Laci1959]

I just read into it a bit, I can’t find the section on running the overlift. In reality, the arc is divided into 3 parts
1 temporary arc
2 constant radius sections
3 transition arcs
The transition arc, i.e. the curvature transition, is a section in which the radius at the beginning is infinitely large, at the end it is equal to the radius of the constant radius part.
The overshoot follows exactly this. The overhang used for a given arc radius is always determined by the design speed of the track. The overlift is given to the designers in a table. At least with us.
I know this can't be modeled.

Quote

Why would you turn them off in Simple Physics?

Because users are not railroad professionals, my general experience is unfortunately that they either turn everything on, pull it to the maximum, or vice versa.

I know it’s hard to find the golden mean and meet all expectations.

[steamer_ctn]

 roeter, on 30 July 2021 - 12:06 AM, said:

A serious problem with this function as it is now is that it can have significant impact on the behaviour of AI trains. This may cause problems for timekeeping. Setting it as a general option, as now, may lead to some users switching this on while others keep it switched off, resulting in very different behaviour of AI trains and thus problems in running an activity or timetable. If this is to be maintained, then it would make much more sense if it was moved to either the .trk file, or the activity or timetable definition. Proper advance warning to the player train, and proper advance braking for AI trains would also need to be added.

At the moment this function only applies to the Player train, and not AI or TT trains. So I don't understand how it will have a significant impact on these types of trains.

On the player train it only provides a warning message if the train is exceeding the "safe speed" around the curve. It does not make any decisions or changes in regard to the train speed.

At the "overturning" speed of the car, it does brake an air hose to simulate a consequence. However this speed should be well and truly in excess of any realistic curve speed limit.

So apart from a "visual indication" to the player to make them aware of how they are driving, this function has limited control and impact upon actual train performance.