[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?