PDA

View Full Version : Superelevation



geophil
June 16th, 2015, 02:26 PM
Superelevation, high on the Kickstarter wish list and now one of the new features in T:ANE, does not appear to have gained that much attention yet. Is it because we don't know how to use it in practice?

For superelevation, also known as cant, we find two new Track Vertex parameters, Superelevation Degree and Superelevation Limit. I assume both values are in degrees and specify a banking angle. I also learned that there is some dynamics involved.

It's worth noting that you probably don't need to vary these numbers. The curvature is taken into account by the software.

Now I am trying to figure out how practical use might look like. Having implemented all the math for superelevation myself a couple of years ago I'd like to take the approach from that background and the DB (German railways) rulebook. However, as gravity is largely the same all over the planet, formulas won't be much different elsewhere.

Over here superelevation is measured in millimetres, not in degrees. That's not a problem, can easily be converted:

u = w * sin alpha

with

w: gauge [mm], but measured between centre of rail heads (where the wheels touch), 1500 mm for standard gauge.
alpha: banking angle
u: superelevation [mm]

Balanced superelevation – compensating centrifugal force – is defined as:

u = 11.8 * vd2 / r

in the German rulebook with

vd: designed track speed [km/h]
r: radius of the circular arc [m]
u: superelevation [mm]

So, superelevation is a function of track speed and radius.

On real track we will also encounter “cant deficiency”, a gap between fully balanced and actual superelevation. We simplify here and ignore that bit. There is also a maximum superelevation, with a value defined in the rulebook not to be exceeded. This absolute maximum in Germany is 180 mm.

The prototype does not employ splines. Its track geometry consists of straights, circular arcs and transition curves. Transition curves are often based on clothoids with the clothoid approximated by a Taylor series cut short after the third term, making it a cubic parabola. The transition curve or easement is there to reduce jerk (2nd derivative of speed) and to build up superelevation in a ramp. With a clothoid or cubic parabola, this ramp often has constant slope.

But we have splines in Trainz. One of the inherent advantages of splines is their ability to approximate any other mathematical curve, with and appropriate number and placement of control points. This, fortunately, includes those ugly transition curves.

The radius of a spline? Does not really exist. But we can compute the curvature for an infinitesimal short stretch of the spline at any given point, including the track vertices themselves. And from the curvature we can derive the radius of an equivalent circular arc for that particular point. This job will be handled by Trainz:


There is a superelevation ratio which is set per track vertex and which uses linear interpolation between these (with a few exception- we disable interpolation in the area immediately around a junction vertex, for example.) This is multiplied by the instantaneous* track curvature to determine the banking angle at any given location. The curvature is obviously not necessarily linear.

*: mathematically not really, for various reasons, but should be treated as such.


We have now identified the most relevant variables in this game and can compare to our two parameters for the Trainz track vertex.

My assumption is that “Superelevation limit” is the equivalent of the maximum value in mm. For 180mm we get (standard gauge) 6.9°. 180mm is quite a lot, it will usually be significantly less.

“Superelevation angle” is supposed to be applied in a dynamic way, based on curvature, that's what I understand. But here I start speculating. One could assume that the value we fill in here is for a predefined constant but yet unknown radius r0.

u0 = 11.8 * vd2 / r0

or, with the banking angle

w * sin alpha0 = 11.8 * vd2 / r0

Then for any other radius r we might be able to say:

sin alpha / sin alpha0 = r0 / r

or

sin alpha = (r0 / r) * sin alpha0

If this assumption is correct we would only need to know the value of r0 and could then happily apply the above formula for any given track speed in our route project.

TRam__
June 16th, 2015, 03:29 PM
I assume both values are in degreesThey are both in % of "maximum".

Superelevation Degree - the % of maximum angel at spline point it was setted.
Superelevation Limit - the % of maximum angel limit at track section. As you know, the spline has varying curvature, so you need to determinate the superelevation in most curved part of it (usually at its middle).



“Superelevation angle” is supposed to be applied in a dynamic way, based on curvatureAnd it is. If the curve radius is too small, you can get even overturn of a vehicle

http://i.piccy.info/i9/f5fb1be723097f8e81d4fd3ff072e6ef/1427393731/134035/854143/y6_800.jpg

WindWalkr
June 16th, 2015, 06:28 PM
The main superelevation parameter is a ratio of banking angle to track curvature. The more curved the track, the more banked it will be, with no change to this number required.

The superelevation limit parameter is the maximum banking angle in radians.

chris

martinvk
June 16th, 2015, 07:16 PM
For the rest of us, how about some reasonable minimum, average and maximum numbers for the two parameters based on Geophil's DB rule book?

geophil
June 17th, 2015, 01:02 PM
For the rest of us, how about some reasonable minimum, average and maximum numbers for the two parameters based on Geophil's DB rule book?I will have to do some systematic testing, probably write a test application to lay my track automatically, and then play with the parameters. In the ideal case, we might be able to take advantage of sin alpha ≈ alpha for small alpha and come up with a quite simple formula but that remains to be seen.

geophil
June 30th, 2015, 02:55 PM
If you are not interested in the mathematical background you can skip forward to practical use.

The Surveyor tooltip for the Superelevation Degree track vertex parameter says, it's bank degrees per degree of curvature. "Degree of curvature" is a track geometry concept you always come across in the US, but is unknown over here in Germany. As said earlier the DB rulebook uses radius (in metres) and measures superelevation in millimetres.

Therefore I dared to more or less ignore degree of curvature dc and made the assumption that the nominator in

(1) dc ≈ c / r

with c for chord and r for radius might actually be 1 and not 100 ft as normally used in the US.

Hence,

(2) p1 = alpha / dc

might become - a mere assumption at the moment -

(3) p1 = alpha * r

As the angle will be rather small we can use alpha ≈ sin alpha for alpha in radians (you will see the reason for that in a moment)

(4) p1 = r * sin alpha



In my first posting I said balanced superelevation is

(5) u = 11.8 * vd2 / r

vd: designed track speed [km/h]
r: radius of the circular arc [m]
u: superelevation [mm]

and I disregarded cant deficiency. Now, in real life, you shouldn't do that and I had to remember that regular superelevation is defined as 60% of balanced superelevation.

That brings us to

(6) u = 7.1 * vd2 / r


Banking angle and superelevation in mm have this relationship (see first posting):

(7) u = w * sin alpha

with

w: gauge [mm], but measured between centre of rail heads (where the wheels touch), 1500 mm for standard gauge.
alpha: banking angle
u: superelevation [mm]


We combine (6) and (7) and get:

(8) sin alpha * w = 7.1 * vd2 / r

and

(9) sin alpha * r = 7.1 * vd2 / w

and finally we are back at (4) and you now see why sin alpha ≈ alpha becomes handy:

(10) p1 = 7.1 * vd2 / w

For 1435 mm standard gauge w is 1500 mm.

I did my tests and let TransDEM lay track at different radii of 180, 300, 500, 750, 1000 and 1250 m, for each radius three tracks side by side with different track speeds of 80, 120 and 160 km/h. While for most combinations superelevation/cant would be ridiculously high, this doesn't matter at all if you want to prove a formula. I let TransDEM apply (10). In Surveyor I measured railhead surface height above flat ground and compared to the opposite rail.

And the result is: it worked! I received the values as anticipated from (6) with quite good accuracy.

To sum it up it basically says that p1 is proportional to track speed squared. That shouldn't be surprising at all, more importantly my assumption about degree of curvature and the chord length of being 1 appears to be rather close to the point, otherwise I wouldn't have got the anticipated values from (6).



Practical use

Track vertex parameter p1 Superelevation Degree for given track speed, standard gauge, formula (10):

km/h p1
60 17,04
80 30,29
100 47,33
120 68,16
140 92,77
160 121,17
200 189,33
250 295,83
300 426,00

And a few helpful values for track vertex parameter p2 Superelevation Limit [rad] for a given maximum superelevation in millimetres, standard gauge, from formula (7):

mm p2
150 0,1002
160 0,1069
170 0,1136
180 0,1203

martinvk
June 30th, 2015, 03:09 PM
super, (pun intended) that is one table that will be pasted beside my track design sheet. Thanks for taking the time to test and validate your assumptions.

geophil
July 2nd, 2015, 11:44 AM
It appears that the maximum allowed value for the Superelevation Degree parameter is 100 if entered via the dialog box.

The formulas I've figured out may all be wrong, but they deliver the banking angle they are supposed to for given track speed. And in that case the maximum supported track speed in T:ANE for superelevation would be 145 kph, with 40% cant deficiency. Can this this value range limit be lifted?

(I didn't notice this before because I let TransDEM set the parameters and T:ANE produces correct results with a Superelevation Degree value of 121 for 160 kph.)

RPearson
July 2nd, 2015, 02:10 PM
Thanks for the work on this geophil. In US max SE is 7 in and the under allowance used in the allowable speed formula is 3 in. Larger values of under allowance can be used if railcar equipment passes specified tests. I'm pretty sure this is the cant deficiency you're talking about but stated in terms of reduction in SE from that required for full compensation for centrifugal force at allowed speed. I've been looking at this myself but haven't come up with anything as elegant as your proposal.

Actually cant angle is not defined or specified in the US Federal Regs as far as I'm aware. Nor is the required SE explicitly specified. The regs only provide a formula for allowed speed in the curve as a function of actual SE (plus 3 inches) and degree of curvature (measured in degrees based on 100ft chord). If you know the radius of the curve this will result in an arcsin function to get degree of curvature however for most rr curves of fairly large radius we can either use the sine of a small angle approximation or take the engineering approach that defines DOC as measured along a 100 ft arc length of the curve. Both of which result in same approximation not too surprisingly.

If I get a chance tonight I might revisit the work I did a few days ago and see if I can eliminate the radius of the curve in some manner to simplify the results as a function of speed only.

Bob Pearson

RPearson
July 2nd, 2015, 06:20 PM
I won't post too much at the moment but I can at least confirm a similar set of numbers based on 2 assumptions:
1) the actual SE is set at 5.0 inches
2) the degree of curvature used to calculate geophil's P1 parameter for Trainz is not the "degree of curvature" but actual curvature measured as 1/R where R is the radius of the curve in meters

Using the formula in the US Federal Regulations:

(1) V = sqrt((Ea+3)/0.0007D)

V - mph
Ea - actual SE - inches
D - degree of curvature based on 100 ft chord - degrees

solving for D we get:

(2) D = (Ea+3)/0.0007V^2

Degree of curvature (measured in degrees for a 100 ft chord as specified in the regulations) is defined as:

(3) D = 2 arcsin(50/R)

D - degree of curvature - deg
R - radius of curve - ft

Note: D in general is not restricted to small angles, so the approximation of sin(B) ~ B (where B is an angle measured in radians)
is not appropriate for all cases here. We can use D =~ 2(50/R)(180/pi) for those curves with rather large radius typical of most railroad track work. This gives and approximation of D=~ 2 x 50 x 180 / (pi x R) = 5729.57795.../R =~ 5730/R

FYI - There is another definition of degree of curvature (in the US) used more by engineers (IIRC) rather than surveyors. This one is based on the 100 feet measured along length of curve (the arc length) rather than 100 ft length of chord and surprisingly (or not) we end up with the same relationship as the above approximation. So I'll use:

(4) D = 5730/R

(5) R = 5730/D

So in (2) set Ea = 5
and for each V in the following list solve for D and then using (5) solve for R. Convert R from feet to Rm meters. Set Cant angle (A) in radians based on Ea = 5in and track gauge g = 56.5 in using A=~ Ea/g. Finally based on assumption 2) calculate P1 = A/(1/Rm):


Ea 5 in
A 0.0885 rad

V D R P1
Km/h Mph deg ft rad m

60 37.28 8.224 696.7 17.18
80 49.71 4.626 1238.6 30.55
100 62.14 2.961 1935.3 47.73
120 74.56 2.056 2786.9 68.73
140 86.99 1.511 3793.3 93.55
160 99.42 1.157 4954.5 122.18
200 124.27 0.740 7741.3 190.91
250 155.34 0.474 12095.9 298.30
300 186.41 0.329 17418.0 429.55




This doesn't mean the P1 values are appropriate ones to use or that they will develop a cant angle of 0.0885 rad in the game on track having the curve radii indicated in the above table.

Assuming a single value for SE and solving for the set of minimum curve radii corresponding to the allowable speeds in the list is one way to simplify the problem but not the only way.

I have not tried to measure any cant angles based on the above. I did try a few weeks ago with not a whole lot of success when I first fooled around with the new SE parameters. Clearly we can provide more guidance like this if we can get a qualification on the exact definition of the DOC the game uses with respect to the P1 parameter we input.

The fact that N3V sets an upper limit for P1 input to be 100 tells me we have some misunderstanding here - but time and some dialog might clear things up. But 100 is somewhere between 1/3 to 1/5 the value I'd expect to see to generate the required cant angle for very high speed traffic on curves with up to 7 in of SE.

For track in the US where the maximum SE is limited to 7 in, the cant angle limit, geophil's P2 parameter, can't be greater than 0.1239 (based on my definition of cant angle given above). For the speeds and curve radii in the above table based on Ea = 5 in, P2 can't be less than 0.0885.


Bob Pearson

RPearson
July 3rd, 2015, 05:36 PM
A quick follow up on my post from last night. My calcs above and herein are based on the formula to calculate allowed speed on a curve from the US Federal Regulations governing railroads. Clearly the underlying physics is the same for the formula from the US FED Regs and Roland's work above.

Basically in my approach I eliminated the curve radius from consideration by calculating the minimum radius for which the specified SE (Ea) and allowed speed (V) combination would be valid. It can all be rolled up into a single formula using the steps outlined in the previous post. For those who want to take it a step further you can vary the actual SE (Ea) used up to the limiting value of 7 inches and calculate Roland's P1 parameter based on the required speed value and your Ea of choice.

I'll give my thoughts on using this for gauges other than standard gauge later.

The parameters P1 and P2 are calculated using the following formulae:

P1 = 1.2226EaV2/g(Ea+3) with units of rad-m

P2 = Ea/g <=0.1239 with units of rad

Ea = actual SE - in
V = speed - mph
g = gauge width - in

If you always take P2 as equal to the the cant angle formed by the Ea and gauge width then the following is possible:

P2 = Ea/g

P1 = 1.2226P2V2/(Ea+3)

Taking Ea = 5 and g = 56.5 as in my previous post gives:

P1 = 0.01352V2

P2 = 0.0885


For anyone that wants to do it on a case by case basis and you know the curve radius you can go back to my previous post and the formulas you need are there to plug in all the "known" data.

I assumed the cant angle was based on the gauge width equal to the track gauge measured between the railheads. Roland used a width measured from center to center of the railheads. The difference is the width of the railhead. For typical rails this would be between 2 to 2.5 inches. You could use g = 58.5 inches if you prefer in the above formulas - the difference is a reduction in cant angle of ~3.5%.

If I can verify the cant angles in game based on the above then I think that would validate Roland's approach to apply SE to track in TANE in rational manner. You'd be free to use any of the above formulas or tabular data to provide realistic SE values to the track based on track speed alone or if you felt the need based on curve radius too - sufficient info has been provided above for either approach.

[EDIT 2] I made several tests in TANE's Surveyor last night (7/3) and can confirm that that cant angles generated in the game based on the P1 values Roland proposed are visually correct while those generated based on the description in the track vertex dialog box are not. In fact when I used P1 values based on "1.0 is one degree of bank per degree of curvature" I got values that were exactly 1/30.48 times the size of ones using my approach above. The test were made using an SE of 12 in (large enough to be seen on a scale of meters) and a curve radius of 984.2 ft (300 m). P1 input for this combination was 63.716 and the cant angle should be 0.2124 rad. Measured on a vertical ruler the resulting SE is clearly on the order of 12 inches. The value for P1 based on "degrees per degree of curvature" was only 2.09 and the resulting 0.4in of SE was almost imperceptible.

[EDIT 3] I can confirm that Roland's P2 parameter is the limiting value of the cant angle at the vertex specified in radians (Chris stated so in an above post but I checked anyhow since the in game description for P1 is incorrect and only units mentioned there are degree units). I would also suggest that P2 limits be applied reasonably, so the cant angles generate with the P1 parameter aren't reduced by the P2 parameter. I my tests I saw anomalies when I forced this to happen where the clamping was applied only within a short distance from the vertex on one side and on the other was a smooth curve to the next vertex.

I think this verifies Roland work on SE and what values we should use to generate it in the game.

[EDIT 4]I can confirm that Surveyor also limits the input value to 100 which is insufficient to generate cant angles on curves matching real rr curves for very high speed passenger traffic where the radius may be several miles in length.

Bob Pearson

[EDIT 1]
PS While reviewing the calcs this afternoon (7/3) I noticed that the variation in P1 with respect to Ea is essentially logarithmic and independent of speed. So a single table as originally provided along with an auxiliary table providing a multiplier as a function of Ea should cover all cases for which the minimum curve radius assumption is ok. I use imperial units out of habit so the following is provided for any one interested:



Ea 5 in
A 0.0885 rad

V P1 Ea P2 Ke
Mph rad-m in rad

30 12.17 1 0.0177 0.4000
40 21.64 2 0.0354 0.6400
50 33.81 3 0.0531 0.8000
60 48.69 4 0.0708 0.9143
70 66.27 5 0.0885 1.0000
80 86.56 6 0.1062 1.0667
100 135.24 7 0.1239 1.1200
120 194.75
140 265.08 For Ea different from 5 use:
160 346.22
180 438.19 P1e = KeP1

RPearson
July 11th, 2015, 05:20 PM
With this post I'm sharing some pics of the tests I ran in TANE using input data calculated with the formulae presented above.

The tests were made on a track radius of 984.2 ft (300 m). In order to develop a SE large enough to easily see on a meter measuring ruler I set the actual SE (Ea) to 12 inches. Therefore for a specified radius and Ea value I used P2 = Ea/g and P1 = P2Rm based on the work shown in the previous posts. Note: I'm not concerned about allowed speed here just the cant angles (and SE) calculated and rendered in the game using the P1 and P2 parameters proposed by Roland.

Based on Rm = 300 m and Ea = 12 inches (304.8 mm) I calculated P2 = 0.2124 radians and P1 = 63.7163 radian-meters. The track on my test loop is basically the same stuff I've been using since TRS04. But dimensionally it is very accurate. The standard gauge is exactly 56.5 inches between the inside edges of the top flanges representing the rail heads (and exactly 36 inches for the ng3 track and width of the rail head for all 3 rails is 2 inches and rail height is 5 inches)

The resulting cant angle in the game is visually right on the expected value. Note the P2 input in Surveyor for this test is set to a large value so it won't effect the results by clamping the angle to the correct value.

http://i109.photobucket.com/albums/n74/EBTng3/TANE/TANE%202015-07-04%2014-43-22-686.jpg




For this test the P1 is set to 2.0904 degrees of cant angle per degree of curvature (for R = 984.2 ft D = 5.82 degrees of curvature per 100ft chord - this should give a SE = 12 in). This agrees with the guidance given in the input dialog but clearly it is not correct. (The cant angle results from a calculated SE of less than 1/2 inch assuming the input should be radian-meters.)

http://i109.photobucket.com/albums/n74/EBTng3/TANE/TANE%202015-07-04%2006-04-06-070.jpg




For this test the recommended value of the P2 parameter (for SE = 12 inches and g = 56.5 in) is set to 0.2124 radians and P1 is reset to 63.7163 radian-meters. Results are visually identical to the 1st test.

http://i109.photobucket.com/albums/n74/EBTng3/TANE/TANE%202015-07-04%2006-00-56-003.jpg




In this test P1 is the same as the previous and should generate a SE of 12 inches but input P2 is set to 0.0885 radians (SE for this angle should be 5 inches) which should limit the cant angle displayed as shown in the following pic.

http://i109.photobucket.com/albums/n74/EBTng3/TANE/TANE%202015-07-04%2014-49-42-899.jpg




However on the fore side of the vertex we see that the limit is enforced only with in a short distance from the vertex and a very short transition is used going from the calculate value based on P1 to the limiting value base on P2. This results in a rather bad section of track as seen in the following pic. Note the transition on the far side of the vertex is quite long and smooth.

http://i109.photobucket.com/albums/n74/EBTng3/TANE/TANE%202015-07-04%2016-23-51-333.jpg




Question: Why do we see the kink on the near side in this pic going from a calculated cant angle of 0.2124 radians to the limiting value of 0.0885 radians but a rather smooth transition on the far side of the vertex going from the limiting value of 0.0885 radians back to the calculated cant angle of 0.2124 radians?

Bob Pearson

WindWalkr
July 11th, 2015, 07:15 PM
Question: Why do we see the kink on the near side in this pic going from a calculated cant angle of 0.2124 radians to the limiting value of 0.0885 radians but a rather smooth transition on the far side of the vertex going from the limiting value of 0.0885 radians back to the calculated cant angle of 0.2124 radians?

Difficult to say. I agree that it looks wrong but I can't see enough of the construction to get any idea for why that might be the case. Are you able to send in these test assets (including route)? trainzdev@auran.com

chris

RPearson
July 12th, 2015, 06:49 PM
2 cdps sent to the above address. If you need anything else let me know. Thanks,

Bob Pearson

WindWalkr
July 12th, 2015, 08:10 PM
Cheers Bob,

I've received these. I'll take a look at them and get back to you.

chris

WindWalkr
August 5th, 2015, 07:49 PM
Question: Why do we see the kink on the near side in this pic going from a calculated cant angle of 0.2124 radians to the limiting value of 0.0885 radians but a rather smooth transition on the far side of the vertex going from the limiting value of 0.0885 radians back to the calculated cant angle of 0.2124 radians?

Thanks Bob,

This is a bug relating to the proximity of the spline vertex, which is incorrectly being flagged as a junction in this scenario. It will be corrected in the next test build, so please retry this test.


One other gotcha; review the following sequence of vertices:

A: (ratio: 64.0, limit: 0.0)
B: (ratio: 64.0, limit: 0.0)
C: (ratio: 64.0, limit: 15.0)

If these tracks are short, there will appear to be a discontinuity just after B. This is in fact correct mathematically, but looks wrong, so you should avoid it.

The issue is that 15.0 is far higher than you actually need as a limit. The actual angle used is probably somewhere around 1.0. To reach the 15.0 limit at C, you will transition between the 0.0 angle at point B and the full 1.0 angle by 7% of the distance between B and C.

This could be resolved by:

* Using a more reasonable limit, so that the rapid transition does not occur.
* Using longer track between the vertices.
* Ensuring that the limits are not engaged later than the actual superelevation ratio. (ie. using ratios of 0.0 for A and B.)

hth,

chris

martinvk
August 5th, 2015, 08:07 PM
Looks like the use of SE will have to include some detailed help and / or guidelines or the forums will be flooded with people with issues. Ideally the popup note should contain suggest values. Will the P1 parameter upper limit be increased. For those with high-speed lines, a value of 100 is too low.

WindWalkr
August 5th, 2015, 09:13 PM
Looks like the use of SE will have to include some detailed help and / or guidelines or the forums will be flooded with people with issues. Ideally the popup note should contain suggest values. Will the P1 parameter upper limit be increased. For those with high-speed lines, a value of 100 is too low.

The degree can range between 0.0 and 1000.0 in the current test builds.

chris

martinvk
August 6th, 2015, 06:32 AM
The degree can range between 0.0 and 1000.0 in the current test builds.

chrisStating the obvious but are there plans to increase this in production builds?

WindWalkr
August 6th, 2015, 09:09 AM
Stating the obvious but are there plans to increase this in production builds?

Anything done in the test builds is with the intention of eventually releasing it; we wouldn't spend time on it otherwise. When exactly that will happen, and whether other changes will occur first, is not stated.

chris

RPearson
August 6th, 2015, 10:35 AM
Thanks Bob,

This is a bug relating to the proximity of the spline vertex, which is incorrectly being flagged as a junction in this scenario. It will be corrected in the next test build, so please retry this test.


One other gotcha; review the following sequence of vertices:

A: (ratio: 64.0, limit: 0.0)
B: (ratio: 64.0, limit: 0.0)
C: (ratio: 64.0, limit: 15.0)

If these tracks are short, there will appear to be a discontinuity just after B. This is in fact correct mathematically, but looks wrong, so you should avoid it.

The issue is that 15.0 is far higher than you actually need as a limit. The actual angle used is probably somewhere around 1.0. To reach the 15.0 limit at C, you will transition between the 0.0 angle at point B and the full 1.0 angle by 7% of the distance between B and C.

This could be resolved by:

* Using a more reasonable limit, so that the rapid transition does not occur.
* Using longer track between the vertices.
* Ensuring that the limits are not engaged later than the actual superelevation ratio. (ie. using ratios of 0.0 for A and B.)

hth,

chrisThanks for looking at this Chris. I agree the 15.0 far exceeds a realistic value for this limit. IIRC when I made the 1st set of tests I wanted to make sure the limit value wasn't influencing the results for the values the game was calculating and set it to a high value. For practical use I'm proposing to use values like those shown in the tables that appear earlier in this thread. In real world terms that would be cant or bank angles resulting from 7 inches or less of SE depending on the allowable train speed.

Regards,
Bob Pearson

martinvk
August 6th, 2015, 09:33 PM
Anything done in the test builds is with the intention of eventually releasing it; we wouldn't spend time on it otherwise. When exactly that will happen, and whether other changes will occur first, is not stated.

chrisMy apologies, I didn't notice the 1000.0 as the upper limit, thought it was still 100.0.