[DirtyRam]

 Laci1959, on 30 July 2021 - 01:27 AM, said:

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.


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.

Good day, They are spiral easements and are between the straight track and the constant curve radius. They are infinate radius, so to speak. The superelevation starts here and carries through the curve and when coming out of the curve its the same back to the straight track. The "s" curves, or reverse curves need to have at least a straight length of the longest piece of equipment that will be run on that section of track. At least 100 feet for multi-levels.

Mike

[Aldarion]

Until a couple of decades ago, the Cubic Parabola was the most used easement curves between straight and curved track and superelevation changes.
Since the beggining of High speed track in europe the Clothoid was adopted. I think that all new railtracks now use colothoids for easement.

i cant give information, equations and aplications of superelevation calculations if anyone is interested. ( i see this being moreusefull to Goku for TSRE5... i'd love to get the dynamic track laying to calculate aumtomatically the easements. )

[cjakeman]

I didn't intend to start a discussion on both the 3 resistance options and the speed limit option together. That was clumsy of me because the two issues are now intertwined in this thread. Sorry and do please carry on.

 steamer_ctn, on 29 July 2021 - 10:53 PM, said:

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?

If I can return once more to the 3 resistance options, it seems that Peter (who coded them - thanks Peter) wants to turn them on for Advanced Physics and off for Simple Physics, so I guess these are questions for him.

Why do we need an option for these at all?
What is the harm in having them always on?

[steamer_ctn]

 cjakeman, on 30 July 2021 - 10:59 AM, said:

If I can return once more to the 3 resistance options, it seems that Peter (who coded them - thanks Peter) wants to turn them on for Advanced Physics and off for Simple Physics, so I guess these are questions for him.

Why do we need an option for these at all?

As far as I am concerned the options can be removed.

 cjakeman, on 30 July 2021 - 10:59 AM, said:

What is the harm in having them always on?

I personally don't see any harm in leaving them always on, but the same can be said for a lot of other features. So it comes back to the question of what is a "Simple" feature, and what is a "Advanced" feature?

So sorry to be a pain, but what is your definition of a "Simple" physics mode. (Does it align with my view?)

What are the criteria for the types of physics features that should be included in it?

For example, should they be hard or easy to configure (either from an understanding perspective or ascertaining of appropriate prototypical information)?

Should they make driving less demanding as the driver doesn't needs to pay as much attention to driving, hence allowing them to focus more on viewing the train, or other activities such as easily keeping time on a timetable, shunting, etc?

By only having a simple physics, the train should move under almost any circumstances, and thus the user could confirm that the train is moving. Thus the difference between Simple/Advanced could be used as part of a debug process for stock that doesn't seem to move.

Are there any other criteria?

Once we have identified the criteria for what physics features should be in/out of Simple physics mode, we can then asses each feature against these criteria, and make a call as to whether they are in/out.

 Aldarion, on 30 July 2021 - 06:26 AM, said:

i cant give information, equations and aplications of superelevation calculations if anyone is interested. ( i see this being moreusefull to Goku for TSRE5... i'd love to get the dynamic track laying to calculate aumtomatically the easements. )

In regard to curve speed limit, is there value in setting up a test scenario using real world information to see how accurately it can perform against real world situations? My CTN test route has a number of different radius curves (see the Curve Branch) that could be configured with the "appropriate" superelevation values, and we could then run a test train through these curves to determine how close to reality OR is performing.

If there is a level of interest in this, can somebody start a new thread so that we don't overload this thread with "off topic" information.

[cjakeman]

 steamer_ctn, on 30 July 2021 - 03:15 PM, said:

As far as I am concerned the options can be removed.

Thanks. So that's another 3 controls we can remove.

 steamer_ctn, on 30 July 2021 - 03:15 PM, said:

What are the criteria for the types of physics features that should be included in it?

. . .

Should they make driving less demanding as the driver doesn't needs to pay as much attention to driving, hence allowing them to focus more on viewing the train, or other activities such as easily keeping time on a timetable, shunting, etc?

That's my view. An alternative labeling to "Simple v Advanced" might be "Assisted v Proficient"

 steamer_ctn, on 30 July 2021 - 03:15 PM, said:

By only having a simple physics, the train should move under almost any circumstances, and thus the user could confirm that the train is moving. Thus the difference between Simple/Advanced could be used as part of a debug process for stock that doesn't seem to move.

I would like to see some sort of help along the lines of "This train is under power but isn't moving because . . ." and I've added a Trello card for this.

[steamer_ctn]

 cjakeman, on 31 July 2021 - 05:08 AM, said:

That's my view. An alternative labeling to "Simple v Advanced" might be "Assisted v Proficient"

Thanks for the feedback.

 cjakeman, on 31 July 2021 - 05:08 AM, said:

I would like to see some sort of help along the lines of "This train is under power but isn't moving because . . ." and I've added a Trello card for this.

This concept of providing more information and help on configuration details will need to considered when looking at the option "Verbose ENG/WAG configuration messages" under the Data Logger TAB.

My concept with this option was to provide the user with more information about what OR is actually reading and then using as it's base information for calculations. This confirms that the user has correctly entered the required information.

Another example where a more detailed confirmation of the data read by OR is needed is in this thread. Being able to see what information has actually been read from an Include TRK file for example would be very helpful to the user to confirm that everything is working correctly (or whether it is ignoring the Include file).

So again the big picture question - what information do we wish to make visible to the user to assist in a debug process? Should we use a verbose approach across the board, or do we do it area by area? For example, ENG/WAG files, TRK files, etc.

Should these messages contain a tip or reference point to point the user to an explanation of how to fix the error?

I believe that the more user helpful that we make OR the more users will stick with it, rather then being deterred by an issue, and not knowing how to correct a problem.

[Laci1959]

This will be very useful for a layer, or maybe layers. The average user will hold his head but that should be his problem.
Maybe if this feature was off, could it be turned on? Off by default.
I'm just thinking out loud.

[Aldarion]

 cjakeman, on 31 July 2021 - 05:08 AM, said:

I would like to see some sort of help along the lines of "This train is under power but isn't moving because . . ." and I've added a Trello card for this.

How would something like this work with scripts like a TCS or circuit breaker? and what impact would it have in scripting so it would be compatible with such a feature?
A developer that implements heavy scripting to a locomotive should probably be able to provide instructions and even schematics for troubleshooting. (talking about myself,I would easely provide a manual, but not a troubleshooting schematic. I would, easely and rapidly make available a video in youtube with the correct procedures via life streaming, for example.)

[cjakeman]

 Aldarion, on 01 August 2021 - 02:42 AM, said:

How would something like this work with scripts?

Good question. I've never written a TCS script, so I can only speculate.

I have used state-machines and C# software which helps you define state-machines. If a script was created by using such C# software, then it could be interrogated by Open Rails.

Just a thought.

[cjakeman]

Moving on to the next control in the Simulation tab:



The text in the Manual reads:

This option allows running (in a non-prototypical way) electric locomotives on non-electrified routes.

According to the code, this setting overrides the one that detects whether a route is electrified or not. To run an electric loco on a non-electrified route, I'm guessing the player still has to turn on the power and raise the pantograph as though the overhead supply was in place.

I puzzled over the label which refers to line-voltage:

"Override non-electrified route line-voltage"

and would suggest something like this instead:

"Run electric locos on non-electrified routes"

Any thoughts on this?