[NickonWheels]

Nothing overlooked. Right now there is no true way of calculating ORTSStandstillFriction/ORTSMergeSpeed so you may have to run some tests. Personally I use a self-made program to calculate all 5 relevant lines of this part and indeed I like to upload if I can get there. After the last modifications the values for the C44-9W (low friction bearing just assumed for such modern engines but this too is just a guessing game) it puts out are


ORTSDavis_A ( 2771.100615 )
ORTSDavis_B ( 25.525386 )
ORTSDavis_C ( 1.607582 )
ORTSStandstillFriction ( 3213.85 )
ORTSMergeSpeed ( 0.306274 )

It seems the Davis A value is now higher, but this was my fault on the older version of said program. Also the difference between the Davis A and standstill friction values are quite close now, which using given bearings is more faithful. When using standard roller bearings instead standstill friction is proportionally greater and there are also slight differences in Davis A/B and merge speed as, you said it, newer bearing are more efficient and it only makes sense rolling friction is something different too.

[Lamplighter]

I thought about the new parameters and their functions. However, I'm not sure if such car behavior is realistic.
For most current rolling stock wagons, a very small inclination of the track to start spontaneously is sufficient.
For example, in the case of national regulations (Czech Railways), the need to secure vehicles at a slope of more than 2.5 ‰ is stated.
If I enter the train resistances calculated, for example according to FCalc2.0, in the .eng settings of the railway vehicle - it works.

But if I use the new ORTSStandstillFriction and ORTSMergeSpeed ​​parameters, the initial train resistances will be greater and the vehicle's behavior will no longer correspond to the real situation.

[NickonWheels]

Then you have to modify those values such way it fits to your expectations. By using the new lines this is indeed possible, just take lower values for ORTSDavis_A and ORTSStandstillFriction to make it realistic in your way, something not possible by using ORTSBearingType and not practical by using MSTS friction setting with FCalC. Every line in the ORTS systems work with values higher than 0 but please don´t take a smaller value for ORTSStandstillFriction than for ORTSDavis_A, this is definately unrealistic and so I never tried it out.

The starting friction when using ORTSStandstillFriction is greater than the value in wag/eng file because this newer system also uses bearing temperature settings, the given value is only reached above 25 degrees Celsius just as the older one. When keeping this in mind it´s a good idea to compare values of the MSTS friction settings and FCalC with what is now possible, something I did when developing a new calculation tool.

[Lamplighter]

OK. So if I now have the friction balanced by the FCalc2.0 calculation so that the vehicles can start spontaneously on a 3 ‰ slope, I don't need to use the new parameters.

However, I noticed notes on the effect of the ORTSStandstillFriction parameter at temperatures of 25 °C and higher.
Bearing temperature 25 °C will be sometime in the summer months. In other cases, the temperature only rises with greater axle rotation (aka higher speed).
In this case, the ORTSStandstillFriction parameter limited by the ORTSMergeSpeed ​​parameter does not find use.

[NickonWheels]

For similar performance as with FCalC the value of ORTSMergeSpeed should be VERY low (0.000001) then you have the same starting off characteristics, but not everyone would be happy with this and that´s the reason of these lines. MSTS frition setting are a rigid system, changing just one number anywhere could lead to a horrible mess including disappearing axles! That should never happen with these new lines, it´s meant more like a replacement for ORTSBearingType than anything else. Not using ORTSMergeSpeed at all (or having a value of 0, same for ORTSStandstillFriction) would lead to reverting to this older system and when ORTSBearingType is missing too (as you would not need it in such cases) ORTS reverts to friction bearing settings. ORTSMergeSpeed has nothing to do with bearing temperature, it´s just where low speed friction and Davis calculations meet.

[YoRyan]

To make the new friction system more clear, here is an excerpt from the code:

private void UpdateTrainBaseResistance()
{
    IsDavisFriction = DavisAN != 0 && DavisBNSpM != 0 && DavisCNSSpMM != 0; // test to see if OR thinks that Davis Values have been entered in WG file.
    IsBelowMergeSpeed = AbsSpeedMpS < MergeSpeedMpS;
    IsStandStill = AbsSpeedMpS < 0.1f;
    bool isStartingFriction = StandstillFrictionN != 0;

    if (IsDavisFriction) // If set to use next Davis friction then do so
    {
        if (isStartingFriction && IsBelowMergeSpeed) // Davis formulas only apply above merge speed, so different treatment required for low speed
            UpdateTrainBaseResistance_StartingFriction();
        else if (IsBelowMergeSpeed)
            UpdateTrainBaseResistance_DavisLowSpeed();
        else
            UpdateTrainBaseResistance_DavisHighSpeed();
    }
    else if (isStartingFriction && IsBelowMergeSpeed)
    {
        UpdateTrainBaseResistance_StartingFriction();
    }
    else
    {
        UpdateTrainBaseResistance_ORTS();
    }
}

StartingFriction() uses Nick's static friction model, DavisLowSpeed() and DavisHighSpeed() use the Davis curves, and ORTS() uess the conventional MSTS-compatible simulation. I hope this makes clear which model applies under which conditions.

[NickonWheels]

I just noted in X1.3.1.185 as well as NewYear MG Rev66/67 that FCalC-based MSTS friction settings do not work the way it did some version ago. Now ORTS uses those values like the three Davis lines are used though they´re not written in wag/eng files. And because ORTSBearingType is abcent too it behaves like all vehicles have friction bearings. Though this is not a problem in regards to the extended friction model told here but it´s bad for those folks still using the old system.

[YoRyan]

I very possibly could have made a mistake when splitting up the UpdateTrainBaseResistance() function. If you believe you've found an inconsistency, please consider submitting a bug report and test case.

[NickonWheels]

Pretty much every vehicle can act as an example in this regard, as starting friction is noteably higher than before. Now ORTS does´nt care whether you use roller/low bearing in FCalC; it behaves always like you use Davis settings.

I compared NewYear MG Rev 67 with U2020.05.08-1451 and tested wellcars off TS Mullan Pass, one uses

Friction ( 666.1N/m/s -0.05 1.4mph 2.827N/m/s 1.866 1N/rad/s 1 -1rad/s 0 1 )

in older versions this gives a starting friction value of 184lbf compared to newer versions which have 1641lbf, one very big difference. I reworked all vehicles for Mullan Pass with MSTS frcition settings and now got a huge mess. Reworking them again using the extended ORTS friction system is obviously exhaustive, but that´s just me.

[YoRyan]

Confirmed and bug report filed. Not to worry, Nick - this was the result of a change I made, not yours ;)

[NickonWheels]

YoRyan, on 06 July 2020 - 11:37 AM, said:

Confirmed and bug report filed. Not to worry, Nick - this was the result of a change I made, not yours ;)

Thanks Ryan, not the bug got fixed. Just one other question; how often does the source download section of http://openrails.org/download/source/ get updated? If I can get a newer version, with all changes of recent versions regarding all the friction stuff I could then try to make such improvements to variable weight friction settings as described before.

[YoRyan]

You are advised to learn the Git version control system and check out the master branch from GitHub. (You don't need an account to do this.) This will keep you in sync with the latest changes from other developers and allow you to produce diffs instead of complete files that cannot be merged.

[NickonWheels]

My self-made calculation tool using those new lines was previously uploaded here, now you have to check out the file library...