[Genma Saotome]

_o_OOOO_oo-Kanawha, on 13 March 2013 - 11:59 AM, said:

Just like in Railworks, where only the most recent routes are laid out with superelevation from the start.

But then, what are the chances of really new OR-only routes?

What track should they use? ScaleRail, DB Tracks? IMO these features make best sense with modern slim profile high detail track.
I haven't built any routes myself, so don't know for sure, but don't ScaleRail and DB Tracks only come in fixed pieces, much like a model railroad track set?

That way, an extra variable could define the proper amount of superelevation for each speed range. It will require cooperation from their authors.
The problem of easements in and out of the superelevated curves still persists but could perhaps be automated or set to a certain length of adjacent track.

Is there also a flex track equivalent in SR or DB? Then some automatic setting of the s-e parameter must be programmed into the route editor.

The short reply is none of the above (except for the phrase "It will require cooperation from their authors"). To do super elevation correctly will require track that is not created by using pre-defined shapes but instead produced from a pre-defined profile. So right there, toss out every MSTS route as they presently stand. It would be possible to code replacement track form the .tdb that could in turn have someone figure out where super-elevation is to go and to what extent the rail is raised and add those decisions to some file that would be read by OR. Whether anyone is willing to try and code that is one issue; whether any of the persons would built routes would return to the fold and make those decisions (or authorize someone else to do it) is another issue.

[Genma Saotome]

James Ross, on 13 March 2013 - 11:34 AM, said:

Absolutely agree; IMHO track should be defined purely from vectors with variable radius curves in 3 axes (yaw, pitch, roll) and then track profiles define the visuals from that.

Plus something that describes the rate of ascent/descent and its length going into/out of raised rail curve.

[_o_OOOO_oo-Kanawha]

So much for my layman's point of view :rofl:

As neither a builder nor a developer I think I have run through my arguments.
I will continue to follow this discussion and the development of OpenRails in this respect with great interest.

You do include a switch to set superelevation on or off? Just like a cabsway switch.

Keep up the good work and make OpenRails a better trainsim.

[steamer_ctn]

I totally agree with the concept that the most ideal and accurate way to implement superelevation would be on a piece by piece definition in the world files, as a route is being built.

However given the fact that we could be at least months (or years?) away from an OR editor, and, even when it becomes available, as has been suggested above, only new routes will take advantage of the feature, as not many authors will want to go back and convert their MSTS versions. Thus limiting the number of available routes with it.

I am wondering whether, just like in real life, a compromise needs to be made for those who would like to explore the superelevation option now? Given the fact that superelevation can be enabled/disabled this should allow those who are not comfortable with it to use OR without it.

Perhaps the "runtime" solution can be used for legacy routes and an "edited" world file solution developed for new routes in conjunction with the release of the OR editor.

Ideally in the "runtime" solution as many as possible of the issues raised above should be be considered, and dealt with if possible, however ultimately it needs to be understood that it will never be a perfect outcome. I think that the "runtime" solution does need to allow as much individualization as possible.

Hopefuly this approach will be seen as having merit.

[Csantucci]

I in principle agree with steamer_ctn' approach. If purists don't like the superelevation as it is now, they can continue to run MSTS routes withouth setting the superelevation flag, if they think it's more realistic, which would be an odd thinking in my opinion. Maybe the ORTS developers will be able to improve this dynamic superelevation, maybe not. To me, it is a great step forward without needing to change a bit in the vaste field of MSTS routes, which is genial and remarkable. And if the ORTS developers will in a near or far future develop a further solution to add superelevation in routes from scratch taking into account all railway engineering rules, that's OK provided that what has been developed up to now remains applicable to existing (and still to be developed) MSTS-compatible routes.

BTW: the step to provide also tilting to tilting trains should not be so wide now...

[Csantucci]

Here in our Trainsimhobby forum many tests are under way. Apart of the general high satisfaction two problems were pointed out:
- In narrow gauge routes (Bernina but not only) part of the tracks are replaced with standard gauge tracks, see image

- articulated trainsets, as well as some cars without bogies remain vertical, see image

The DMU can be downloaded here
http://www.trainsimh...902&file_id=923
and here is the consist  Minuetto_Diesel.con (1.32K)
Number of downloads: 323

A further thorough analysis by some forumers has given as result that any trainset with less than three axles does not tilt.
Here an example of a small 2-axle shunting engine that does not tilt
http://www.trainsimh...oad.php?did=345

[JTang]

Just committed a code to make elevation based on a formula from Wiki, and user can set max level (0: no elevation at all; 1: max elevation = 8cm; 10: max elevation = 17cm (European max).

It also works for long curves with several track sections.

Tilted train is supported by giving the consist a file name with "titled", for example "acela-tilted.con", max elevated degree is 8 degree.

There are some small issues except the two pointed out above, will continue to work on it next week.

[steamer_ctn]

Quote

Just committed a code to make elevation based on a formula from Wiki, and user can set max level (0: no elevation at all; 1: max elevation = 8cm; 10: max elevation = 17cm (European max).

Sounds good.

Without wanting to to sound ungrateful, is it possible as a further extension, to allow fuller user specification by allowing a table of values for different curve sizes? Possibly in the trk file as suggested above?

Thus superelevation variations, as shown in the jpg attachments above, could be possibly defined on a route by route basis. The nearest curve radius from the defined table could be used for the actual curve radius in the route.

Is it also possible to consider extending the superelevation properties to "encourage" speeding drivers to maintain speed limits through wheel flange climb and wagon overturning?

[Csantucci]

Hi JiJun,
what you have done with tilting is again a great gift, developed at maximum speed! I just tested it and it looks out very nice.
Only two concerns:
1) the 8 degrees maximum tilt have to be added to the track superelevation; I had the impression that it is not so, but maybe I'm wrong
2) I saw that at low speeds (on switches?) there is an oscillation, even if I did not set the oscillation function. Can it be disabled or at least reduced? It is a bit too wide for modern trains.

[JTang]

The tilting is added upon super elevation, only body will be rotated.

Attached thumbnail(s)

• 
•