Resuming Activity From Save, Locomotive Wheelslip and Power Reduction Occurs!

[Vince]

Gd Morning,

Yeah, when you run a test I'd agree you shut everything down except the Sim for an accurate test.

regards,

[meeshu]

Successfully completed the activity under Open Rails "MG" version this time!

Made sure there were no other (major) processes running in the background, including no downloads.

Noticed that the frame rates dropped down to nearly 100 fps in several places, and the passing train looked a bit" stuttery" at times.

So it seems for my computer setup, I have to be careful not to have any other software running that might also use the same physical HDD as is used for Open Rails (various versions) and MSTS. Otherwise it seems likely there might be MSTS and ORTS crashes occurring, particularly for areas that have a large number of objects and/or have a lot of textures that have to be processed.

[meeshu]

Back to the original issue of wheelslip and tractive power reduction on resumption of saved activities.

I am still getting these problems when resuming activities under Open Rails (unstable version 22nd June and MG version 63)!!

The problem is usually worse when saving activities while the trains are crawling uphill at maximum power. On selecting the activity to resume, it is noticed that the Projected speed within the Track Monitor shows NaN instead of a value close to the actual current speed! And on actually resuming the activity, the projected speed shows "0" now!?

The wheelslip warning comes up and power is reduced with the train eventually stalling/coming to a stop, or the train rolls backwards down the hill!!

Why aren't the programs showing correct Projected speeds on resumption of activities, and what can be done to enable resumption of saved activities to trains speeds (current and projected) to those values saved to begin with!?

It is frustrating not being able to resume such activities!

Here are three screenshots in chronological order which shows what is happening (via the Track Monitor).

Just before saving activity (FM).jpgJust after selecting resumption of activity (FM).jpgJust after actually resuming activity (FM).jpg

[csantucci]

If you get such slipping at game restart you can try switching for some seconds to Autopilot mode until train has reached the desired speed, and then switch back to player driven train.

[meeshu]

Thanks for the tip.

Engaging the Autopilot (Alt + A keys) immediately after resuming the saved activity does prevent the train from stalling.

HOWEVER! The train now accelerates to tremendous speeds as though it was supercharged!! This happens under both the 22nd June unstable release and also for MG version 63 of Open Rails!

Here is a screenshot of the train accelerating uphill!

Resumed activity with Autopliot engaged (FM).jpg

Note the present and projected speeds. They are WAY beyond the original (before activity saved) current and projected speeds!?

So it seems there is a "bug" in Open Rails(?)

Another issue is that when the train stalls and starts to roll backwards (no Autopilot engaged) and train brakes are applied (via the train brake lever or when the emergency brakes are activated), it seems only the rear brakes are applied with the front brakes not applying at all!?

So the train continues to accelerate backwards downhill with only some brakes applying!?

Another "bug" in Open Rails?

[derekmorton]

>So it seems there is a "bug" in Open Rails(?)

Here we go again!!
When you are in autopilot, you are running under the AI controller, the AI controller does not honour physics.

>Another "bug" in Open Rails?

How are you determining that only some brakes are applied?
It is more likely that you are expecting the train to stop immediately, remember the word "physics".

[meeshu]

Never used the Autopilot feature of Open Rails before. It was assumed that the Autopilot would take over the control of trains as though an engineer was still in control of the train. I wasn't expecting the train to almost literally take off under tremendous acceleration!

The front brakes not apparently being applied were that as indicated by the HUD (F5 key). The front brake cylinder pressure (BC) continued to show "0" for some time after brakes were applied via the train brake lever and the rear brakes indicated on the HUD that the rear brakes had finished being applied.

What might complicate the issue, is that for this particular activity, I'm driving a rear of the train helper set. The train is controlled from the lead locomotive of this rear end helper set. But on further testing and after switching to the lead locomotive of the train, again the brakes seem to apply only to the rear of the train and not to the front.

Here is a screenshot of brakes within the lead locomotive (after switching to the lead train locomotive from the lead helper locomotive using the key combination Ctrl + E). Note that the front of train BC pressure still shows "0" PSI about 5 minutes after applying train brake.

Brakes (FM).jpg

[rman]

Regarding the wheelslip-on-resume issue, this seems to be an old bug reported in 2014.

The advanced physics simulation breaks down if the time between physics updates is out of the ordinary - and resuming a save is one of these cases. The bug report is marked "triaged," so I wonder if James knows the exact code section to investigate.

[steamer_ctn]

A likely cause of NaN values on resume is if a value has not been saved correctly when the activity was saved. On restoration this "unsaved" value can then cause calculation issues potentially resulting in NaN value(s).

The best way to try and sort this out is to set up a simple and very short activity using default stock that consistently reproduces the problem. A developer can then look at it and identify what value(s) might be not being saved/restored correctly.

If you use some stock from my CTN site, and can provide a test activity that reproduces the problem, I will have a look at it and see if I can identify the problem. If you do so, make sure that you set the activity up against the latest unstable build.

[meeshu]

Comments noted, thanks.

The test route I use is "Europe2" (Innsbruck to St. Anton). Particularly along the steepest section starting from about MP 18 to the end (St. Anton).

I've tried several consists using default locomotives and default cars, but they all seem to resume OK, but with the following note. The Projected Speed within the Track Monitor initially shows "NaN" on selecting the activity to resume. Then the Projected Speed shows "0" after actually resuming the activity. There is a slight pause (duration of pause increases with longer consists), then the Projected Speed increases in value to around the value when the activity was saved.

But the issue seems, so far, to be with non-default locomotives and cars!?

Here is one consist/train that consistently wheelslips and stalls upon resuming saved activities on Europe2 route (steep section).

3_dda_7_ac60_120_coal.zip

Can use any DDA40X locomotive from the File Library for the three leading locomotives of this consist.

The seven rear AC6000CW locomotives are from UP Engine pack from Streamlines. Not sure if this pack is still available.

The 120 hoppers and caboose are from here.

If trying this consist, run the consist in Europe2 route (Innsbruck to St. Anton), starting from ~ MP20 and head uphill to St. Anton (MP0). Save the activity when the train reaches MP 15 or so. Try to resume the activity and see what happens.

Tried this test under Open Rails unstable version 26th June, and also under Open Rails NewYear MG 66.1. Both exhibit the same issue of stalling/wheelslipping trains!


As an aside, trackside view frame rates were around 390~400 fps for OR 26th June version, and around 240 fps for the MG 66.1 version. Train passing under OR version 26th June was smooth. Train passing under OR version MG 66.1 was very slightly jerky on odd occasion.

According to the HUD (F5 key), front of train brakes didn't appear to release (stuck on 50 PSI, but train moved off OK) under OR version 26th June. Under OR version MG 66.1, brake values appear to be correct and released.

[meeshu]

Here is another consist that also wheelslips and stalls upon resuming saved activities.

3_3_sd90MAC_103_coal.zip

The locomotives are from here. Again Streamlines UP Engine pack is required for the shape file (sorry!).

The hopper cars are from here, and from here. You could just use ONE of those hopper cars to substitute for all of the existing consist cars, as the hoppers are all about identical apart from the car number.

Again, run the train from about MP20 in Europe2 route and save the activity when the train reaches about MP15. Resume the activity and see what happens next.

[rman]

No wheelslip, but I've managed to reproduce the NaN/0 projected speeds on resume with default content.

EUROPE2 route, Dash 9 + 40 mixed consist, Landeck to St. Anton path. Keep the train's speed around 10 mph when you save.

[rman]

Have succeeded in reproducing the wheelslip bug on MSTS Marias Pass. Spawn a Dash 9 + 40 mixed consist on the grade just north of Blacktail.

[meeshu]

Thanks for your efforts!

I always try to maintain maximum train speed where and when possible.

Here is another consist that wheelslips after resuming the saved activity.

Using default equipment only (Dash9 locomotive and US2 cement cars). There was no wheelslip prior to the save.

This is the consist used on Europe2 route from MP20 to MP15 -

6_7_dash9_200_cement.zip


I now suspect that wheelslips that occur only after resuming saved activities are more likely to occur when the train is close to wheelslipping but not actually slipping when the activity is saved. The slight delay in actually resuming the activity and re-processing data may cause the program to think that the train has lost traction and wheelslipping now occurs.

[rman]

Thank you for the test case!

The NaN issue with the track monitor was cosmetic only - it had no relation to the underlying physics - and has been fixed. Unfortunately, the wheelslip bug is proving a much harder problem. The culprit is definitely the advanced adhesion code, which wasn't designed to be resumed from a save. This means it "starts fresh" with newly initialized variables on each load, causing the train to momentarily lose power as the simulator collects its bearings.

The fix would be to record the necessary variables in the save file so that Open Rails can properly resume the advanced adhesion simulation. I'm still trying to figure out which ones would need to be saved.