[NickonWheels]

Thanks, folks...

Regardless of where I set the breakpoint according to the tutorial the ORTS loading screen appears, loads and then crashes without telling me something useful except there is some problem with the UpdaterProcess.cs file (the last public void of it).

I tried anything to tell VS that if the three bearing types are not in use (and this should also mean to not use friction bearings to which ORTS defaults when ORTSBearingType is NOT present), but it leads to nothing or to the wagons not having friction at all again. It is not possible though to set the line

case "wagon(ortsbearingtype":
                    stf.MustMatch("(");
                        string typeString2 = stf.ReadString();
                        IsRollerBearing = String.Compare(typeString2, "Roller") == 0;
                        IsLowTorqueRollerBearing = String.Compare(typeString2, "Low") == 0;
                        IsFrictionBearing = String.Compare(typeString2, "Friction") == 0;
                        break;

into a clause, like

if (IsDavisFriction = true)
{
case "wagon(ortsbearingtype":
                    stf.MustMatch("(");
                        string typeString2 = stf.ReadString();
                        IsRollerBearing = String.Compare(typeString2, "Roller") == 0;
                        IsLowTorqueRollerBearing = String.Compare(typeString2, "Low") == 0;
                        IsFrictionBearing = String.Compare(typeString2, "Friction") == 0;
                        break;
}

There is no indicator showing that this part is only used for IsDavisFriction because it must not be used in IsORTSFriction.

[Csantucci]

To perform debug I suggest you to use a simple route (good choice is one of the 6 original MSTS routes), and to disable the watchdog. To do the latter go to Runactivity.Viewer3D.Processes.WatchdogProcess.cs and replace this

               if (hungTokens.Count > 0)
                {
                    // Report every hung thread as a fatal error.
                    foreach (var token in hungTokens)
                        Trace.WriteLine(new FatalException(new ThreadHangException(token.Thread, token.Stacks)));

                    // Report every waiting thread as a warning (it might be relevant).
                    foreach (var token in waitTokens)
                        Trace.WriteLine(new ThreadWaitException(token.Thread, token.Stacks));

                    // Abandon ship!
                    if (Debugger.IsAttached)
                        Debugger.Break();
                    else
                        Environment.Exit(1);
                }

with this

 /*              if (hungTokens.Count > 0)
                {
                    // Report every hung thread as a fatal error.
                    foreach (var token in hungTokens)
                        Trace.WriteLine(new FatalException(new ThreadHangException(token.Thread, token.Stacks)));

                    // Report every waiting thread as a warning (it might be relevant).
                    foreach (var token in waitTokens)
                        Trace.WriteLine(new ThreadWaitException(token.Thread, token.Stacks));

                    // Abandon ship!
                    if (Debugger.IsAttached)
                        Debugger.Break();
                    else
                        Environment.Exit(1);
                }*/

which means that you avoid that the watchdog intervenes aborting your debug session.
The fact that OR crashes without telling anything useful to you doesn't mean it doesn't tell something useful to us. So I suggest you to attach here the OpenRailsLog.txt file in such case.

[NickonWheels]

Thanks, folks

I heavily reworked the new code section, totally mislead myself. My original intention was for two calculations (aside from MSTS friction stuff) to work side by side, hoping they are not interfering with each other. Now they work in conjunction, meaning if the two new lines are missing or one has a value of 0 the program reverts to the older Davis version, though due to the absence of ORTSBearingType it should default to friction bearings. This by now is not tested as there are still some problems in the addition. I will explain it better when the addition is working as intended. Maybe soon...

[NickonWheels]

Well, folks... ORTSStandstillFriction finally works as intended, even when using pounds.

Though here is still the problem that ORTS thinks the (default) value for ORTSMergeSpeed is miles per hour. Judging from the older calculation ORTS uses meters per second internally. Do you know how I can fix this?

MergeSpeedFrictionN = DavisAN * WheelBearingTemperatureResistanceFactor + MpS.ToMpH(MergeSpeedMpS) * (DavisBNSpM + MpS.ToMpH(MergeSpeedMpS) * DavisCNSSpMM); // Calculate friction @ merge speed
Friction0N = StandstillFrictionN * StaticFrictionFactorN; // Static friction x external resistance as this matches reference value
FrictionBelowMergeSpeedN = ((1.0f - (AbsSpeedMpS / MpS.ToMpH(MergeSpeedMpS))) * (Friction0N - MergeSpeedFrictionN)) + MergeSpeedFrictionN; // Calculate friction below merge speed - decreases linearly with speed
FrictionForceN = FrictionBelowMergeSpeedN; // At low speed use this value

[copperpen]

One question. Are you testing your results comparing your friction curve with a published known real world curve?.

[NickonWheels]

I like to remind you that there might only be this rather small bug (stated above) left in this edition of the modified code. If it could get fixed, for which I need just a little more help, I would then share it with you and maybe somebody who likes to include it in a future ORTS version (maybe Carlo, James...)

Obviously there are the questions about how to calculate standstill friction and merge speed. To be honest this subject in the end might be quite subjective and that´s the reason why I made this in the first place. For now and only for myself I´m working on a replacement for FCalc, which was not developed with ORTS in mind all that time ago. If the modification could be brought to life and published on a wider scale I would be reluctant to upload it here, though I have no idea on how this works at the time. The good thing is that you don´t have to bother with the extended version if you don´t understand. Everything old would work as before...

[NickonWheels]

Judging from my observations I experienced such jumps in the friction. Looks like ORTS does indeed know my intentions for merge speed to use meters per second as the unit of measurement, but sticks to use MPH. This messed-up combination may cause this. I had tried anything what came to my mind on this but with no results. How can I define merge speed to use the right unit of measurement?

[NickonWheels]

MergeSpeedMpS = SpeedMpS;
MergeSpeedFrictionN = DavisAN * WheelBearingTemperatureResistanceFactor + (MergeSpeedMpS) * (DavisBNSpM + (MergeSpeedMpS) * DavisCNSSpMM); // Calculate friction @ merge speed
Friction0N = StandstillFrictionN * StaticFrictionFactorN; // Static friction x external resistance as this matches reference value
FrictionBelowMergeSpeedN = ((1.0f - (AbsSpeedMpS / (MergeSpeedMpS))) * (Friction0N - MergeSpeedFrictionN)) + MergeSpeedFrictionN; // Calculate friction below merge speed - decreases linearly with speed
FrictionForceN = FrictionBelowMergeSpeedN; // At low speed use this value

I tried this in order to define MergeSpeedMps as unit meters per second as is described in MSTSDieselLocomotive.cs

public override void InitializeMoving()
        {
            base.InitializeMoving();
            WheelSpeedMpS = SpeedMpS;
            DynamicBrakePercent = -1;
            if (DieselEngines[0].GearBox != null && GearBoxController != null)
            {
                DieselEngines[0].GearBox.InitializeMoving();
                DieselEngines[0].InitializeMoving();
                if (IsLeadLocomotive())
                {
                    Train.MUGearboxGearIndex = DieselEngines[0].GearBox.CurrentGearIndex + 1;
                    Train.AITrainGearboxGearIndex = DieselEngines[0].GearBox.CurrentGearIndex + 1;
                }
                GearBoxController.CurrentNotch = Train.MUGearboxGearIndex;
                GearboxGearIndex = DieselEngines[0].GearBox.CurrentGearIndex + 1;
                GearBoxController.SetValue((float)GearBoxController.CurrentNotch);
            }
            ThrottleController.SetValue(Train.MUThrottlePercent / 100);
        }

But this time it does not work. Do I have to make an additional public override void in MSTSWagon.cs to make this work because it does´nt sound like a conversion factor could change this as the problem pictured earlier would still be there. Please can anyone reply something helpful as this is really the last roadblock for this code extension. If it works you can have it...

[NickonWheels]

I just achieved some kind of SUCCESS! Now merge speed works because I basically had to flip the way of... ah, just look

if (AbsSpeedMpS > MpS.FromMpH(MergeSpeedMpS / 1.609344f * 3.6f))

For me it looks like two times the same calculation but they are contradictory to each other, so in the end I finally got the code to use meters per second as the default unit. There are still some issues left though...

[NickonWheels]

To better explain you what I meant about how to calculate the values of ORTSStandstillFriction & ORTSMergeSpeed I made an image of the program done for this reason. Obviously it´s like FCalC which I wanted to replace in case to use these new lines. I experimented a lot with FCalC in order to set the mathmatical ingredients as reasonable as they could be.

--With this program Davis C is the easiest to figure out, just the user value for frontal area m^2 and a factor basically copied fram FCalC
--Davis A depends on vehicle mass and bearing type
--Davis B depends on axle number as well as mass
--standstill friction is calculated by mass and a factor given by different bearing types
--merge speed is figured out by two different friction values (though not the actual standstill friction value as described above)

What do you think about this?

[NickonWheels]

Some pictures for comparison of the older code section and the addition working side by side (no further code changes yet)

At zero speed the friction values of the first two ES44s are by way of the older code using ORTSBearingType ( Low ), which looks reasonable for such a modern engine. the third engine uses the two new lines as described before.
--212.5 us tons in weight / 6 axles / 13.24 square meters of frontal area / modern roller bearings

The three Davis lines are the same with all three engines. All six lines at once

ORTSDavis_A ( 2606.907023 )
ORTSDavis_B ( 31.875 )
ORTSDavis_C ( 1.607582 )
ORTSBearingType ( Low )
ORTSStandstillFriction ( 3506.25 )
ORTSMergeSpeed ( 0.870116 )

Here the train just met the merge speed of the third engine, lower than the ubiquitos 5 mph of old; ORTSMergeSpeed ( 0.870116 ) means about 1.9464 mph. The values of the other engines are still on their way down...



Above 5 mph all three engines behave the same as they have the same Davis values (though the first has frontal resistance).

[NickonWheels]

Back here after reviewing the code...

I just added the function of the friction rising back up when slowing down below the inserted merge speed of a given vehicle, just like in the unstable U20xx versions but sadly not in the X... versions.

For comparison the current friction code starts like

                if (AbsSpeedMpS > MpS.FromMpH(5.05f))     // if speed above 5 mph then turn off low speed calculations
                    IsLowSpeed = false;
                else if (AbsSpeedMpS < MpS.FromMpH(4.95f))
                    IsLowSpeed = true;
                if (AbsSpeedMpS <= 0.0)
                    IsLowSpeed = true;

And the extension...

                    if (AbsSpeedMpS > MpS.FromMpH(MergeSpeedMpS / 1.609344f * 3.6f))     // if speed above merge speed then turn off low speed calculations
                        IsBelowMergeSpeed = false;
                    else if (AbsSpeedMpS < MpS.FromMpH(MergeSpeedMpS / 1.60934f * 3.6f))
                        IsBelowMergeSpeed = true;
                    if (AbsSpeedMpS <= 0.0)
                        IsBelowMergeSpeed = true;

The effect is essential the same in the end. I know dividing a variable by unit of speed conversion factors looks a bit awkward but is was obviously neccesary to make it work, but I guess I´m repeating myself here...

[NickonWheels]

The next step is to include ORTS freight animation weight differences, for example FullORTSStandstillFriction...

I think I have most of it done but there are some anomalies; ORTS takes the empty weight standstill friction and merge speed when the tender is full and also messes up the Davis A value as it uses some value in between.

If there´s anyone interested in this here



Sadly this subject seemingly had run out of attention and admiration, left me thinking whether ORTS is as open as intended...

[copperpen]

Open Rails is open source, but that does not mean any code is accepted into the main trunk without validation. How does your code output compare with published real world resistance curves?.

[NickonWheels]

copperpen, on 03 February 2020 - 03:45 AM, said:

How does your code output compare with published real world resistance curves?

The code I´m working on and which values are used in the end are two different things. The code addition should only give users the chance of inserting values that seem to be appropriate. Though it´s hard to know or calculate such values but the current ORTS friction model serves as a good indicator, at least when talking about starting friction. Of course calculating merge speed is more than subjective.

As said before the modification I´m working on is just an extension, everything working at the moment would still work uninterrupted and as before, only with a nice addition you would just have to use if preferable. Admiring traction force curves and what is possible with them really out forward the experience when driving so it is just natural to have similar chances about resistance. I´m not saying the current model on this could not be modified; indeed I have some ideas on how to fix this but in the end I don´t made my personal version just for fun. I´m rather serious about this because it´s a serious problem and I´m not the only one who thinks the current model on starting friction is a problem. Though it´s not the only issue with ORTS so some effort is reasonable in order to move on to the next issue, whatever it is.

At last I need all the help I can get so it would be nice to have the chance of helping you to make ORTS more realistic.