[C44-9W]

When resuming a saved activity, the diesel engine starts with 0 HP and 0% load, even when the activity was saved in run 8 with full load. Then it loads up slowly.
This can lead to break-in-two on steep grades with a heavy train and DPU.
The following screenshots are taken when resuming a Scenic sub activity, driving from Merritt towards Berne.

The first screenshot is before the activity resumes. This is the state when the activity was saved. It shows that all engines are in run 8, and are producing close to 100,000 lbs tractive effort. Note that HP is zero and load is 0%.
https://i.imgur.com/WnoTmRl.png


The next screenshot is after resuming (Continue playing). Note that the tractive effort has dropped to about 5000 lbs. The train is rapidly decelerating.
https://i.imgur.com/Y6LhB4R.png


The engine continues revving up, and after another ~ 10 seconds the tractive effort is up to 38,000 lbs.
https://i.imgur.com/emrEtBb.png

Another 10 seconds later the train breaks apart, just behind the lead consist.

Attached is the txt file from the saved activity.

 BNSF_Scenic 2023-03-26 16.33.13.txt (18.18K)
Number of downloads: 60

[engmod]

This is normal behavior.

[PerryPlatypus]

I strongly feel that this behavior *should* be changed. This was originally implemented as a way of preventing wheelslip and/or broken coupler issues right after a save re-load, but the OP's exact situation is one I and others have encountered many times - the loss of tractive effort at resumption from a save causes speed to drop quickly if on a steep uphill grade, which can cause the speed to drop enough that by the time the engine revs up, the lower speed results in higher tractive effort,and thus causes a broken coupler (unless the player quickly notches the throttle down, which should not be necessary).

I have tried to advocate in the past that a better solution could be, upon resuming from a Save, the sim temporarily prevents wheelslip and coupler breakage for about 10 seconds, by which point the wheelslip model should be stabilized. Then we can hopefully get rid of this behavior where the engine is forced to rev up again from Idle after resuming a Save game?

[cesarbl]

At least from the adhesion point of view, the code is capable to gracefully resume the simulation without causing instabilities. Anyway I added further data to the saves just in case.

Diesel engines should start with the same RPM as when the simulation was saved.

Quote

This was originally implemented as a way of preventing wheelslip and/or broken coupler issues right after a save re-load

This could be fixed by adding coupler status (elongation, etc.) to the saved data.

[Csantucci]

After having a look at the code and having performed a debug, IMHO there is an (unwanted?) bug in the restore process. in Train.cs there are these two code lines in RestoreCars.cs (executed during the Resume procedure)

TrainCar car = RollingStock.Load(simulator, this, inf.ReadString(), false);
                    car.Restore(inf);
                    car.Initialize();

car.Restore recalls, after some nestings, Restore(BinaryReader inf) within DieselEngine.cs. Restore(BinaryReader inf) has following code line

RealRPM = inf.ReadSingle();

and this is OK: RealRPM is set to the saved value.
However car.Initialize recalls, after some nestings, Initalize() within DieselEngine.cs. This Initialize has following code lines

           if (!Simulator.Settings.NoDieselEngineStart && !Locomotive.gearSaved)
            {
                RealRPM = IdleRPM;
                State = DieselEngineState.Running;
            }

The condition is evaluated to true on a resume and therefore RealRPM is overwritten to the idle RPM.
Maybe adding a further condition to the if would avoid this overwrite.

[Csantucci]

I've applied a fix to ORNYMG 143.1 basing on the above assumptions, and now the RPMs reume with the value they had at save time. At least in my test, I don't have wheelslip when resuming.
I attach here the fix, to be unzipped in ORNYMG 143.1. Please note that saves with the unpatched ORNYMG 143.1 won't resume with the patched one.
If the feedback is satisfactory, it will enter into ORNYMG and into the Unstable release, in addition to César's patch.
If additional wheelslips will appear, I have the intention to insert -at least temporarily- a wheelslip neutralization in the first 10 seconds after resume in ORNYMG, as proposed by PerryPlatypus.

Attached File(s)

•  Orts.Simulation.zip (1MB)
  Number of downloads: 63

[cesarbl]

Carlo, thanks for your useful debugging. It is weird that Initialize() is called after Restore(). I would expect that it is the other way around: once you have the car fully initialized, you restore the simulation at the point you left it.

In fact, this weird behaviour is a source for bugs, and it has caused some ugly hacks. I would prefer that we first Initialize() and then Restore(). Unfortunately, there are some side effects (at least, it will affect Pantographs.Restore()), but I think that this is the correct procedure anyway. Initializing after restoring is a headache.

I attach a couple of ugly hacks which had to be done due to restore() being called before initialize:

ScriptName = inf.ReadString();
if (ScriptName != "")
{
    Initialize();
    Script.Restore(inf);
}

The script name has to be saved without need (it is a constant thing, not something that changes during the simulation), and then Initialize() has to be manually called first. If car was initialized before restore, the function would be simply "Script.Restore(inf)"

Locomotive.dieselEngineRestoreState = inf.ReadInt32();
Locomotive.gearSaved = inf.ReadBoolean();  // read boolean which indicates gear data was saved

This is a buggy hack caused by the same issue. Also, the Menu Option overriding resume data is wrong, it should be the other way around.

So I would suggest that we take the time to fix the root issue (we must initialize before restore) instead of adding hacks everywhere. I can do it myself.

[Csantucci]

César,
I decided not to touch the Restore-Initialize sequence fearing the side effects you mention. As you volunteer to do the big job, I will refrain to move my patch to Unstable. Once someone confirms that my patch works when applied to ORNYMG, I'll insert it in the ORNYMG download pack, in order to have a solution now, and will leave it there until the result of your job will be stabilized. At that point I'll switch to your solution (maybe it's a question of few days).

[cesarbl]

Quote

I decided not to touch the Restore-Initialize sequence fearing the side effects you mention.

In fact this was a regression introduced between 1.4 and 1.5. Previously, cars were initialized before restore.

The only problematic part that I noticed was related to the Pantographs class, so I hope I won't break lots of things. I'll upload the changes to unstable and keep them there for a while. I'll need some users helping with testing and reporting problems after resume.

I expect problems with Diesel Mechanical locomotives, couplers and TCS scripts, but I cannot test all possible situations, so help will be welcome.

[Niknak]

Carlo, I've tried a couple of saves and the patch seems to do the job perfectly. The activity resumes without the loco initially losing speed as it used to before. Many thanks.