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

[steamer_ctn]

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

Ok, I can reproduce this error, and will have a look at it over the next few days.

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

I can reproduce the error for this one as well, and will have a look at it as well when I get some time.

[rman]

Ok, I can reproduce this error, and will have a look at it over the next few days.

A simple fix: Initialize the train's acceleration tracker to 0 m/s/s^2 when loading from a save.

Still struggling with the wheelslip...

[steamer_ctn]

A simple fix: Initialize the train's acceleration tracker to 0 m/s/s^2 when loading from a save.

I agree that this appears to be a cosmetic problem only.

The patch suggested seems to set the projected speed to the current train speed at restart.

An alternative approach might be as suggested in the attached file. This will attempt to preserve the projected speed at the time of saving.

Are you happy to take ownership for the resolution of these two issues?

Thanks

[rman]

An alternative approach might be as suggested in the attached file. This will attempt to preserve the projected speed at the time of saving.

I considered such an approach, but I don't think we should introduce any more state into the save file than we need to. With the current acceleration at resume set to "0" instead of "-Infinity," the track monitor rapidly arrives at the correct projected speed.

Are you happy to take ownership for the resolution of these two issues?

I would be happy to, but if you're familiar with the advanced adhesion code (I'm not), it would be a big help if you could keep investigating.

[steamer_ctn]

I considered such an approach, but I don't think we should introduce any more state into the save file than we need to.

Whilst I can understand your thoughts, I tend to lean to getting the pre-resume figure displayed, otherwise in my mind, there is little difference to having the NaN value, which also rapidly arrives at the correct projected speed.

I would be happy to, but if you're familiar with the advanced adhesion code (I'm not), it would be a big help if you could keep investigating.

Whilst I have done some work in this area I wouldn't call myself an expert. I can have a look at it when I have sorted out a few other things. In the meantime, if you sort it out let me know.

Thanks

[rman]

Whilst I can understand your thoughts, I tend to lean to getting the pre-resume figure displayed, otherwise in my mind, there is little difference to having the NaN value, which also rapidly arrives at the correct projected speed.

Well, the current transition takes several seconds, and passes from NaN to 0 to (finally) the correct speed. To me, assuming no acceleration and then picking up the correct speed within one or two seconds is a noticeable improvement. The player should never see NaN, which would indicate something is seriously wrong with the physics simulation (if he or she understands what "NaN" stands for in the first place).

Perhaps someone could offer a third opinion on the matter.

[steamer_ctn]

Perhaps someone could offer a third opinion on the matter.

Perhaps there are actually two questions that it would be nice to get an opinion for:

i) Projected Speed Feature question - As you suggest whether it is reasonable (acceptable) to allow the project speed to reset itself over time?


ii) Architectural question - How much state should/shouldn't be introduced into the Save file? Which items are essential, which ones are desirable /optional, and which ones are not needed to be added at all? Ideally this sort of information could be compiled into a set of architectural guidelines for the guidance of all.

[steamer_ctn]

I have had a look at the resume problem for the locomotive wheel slip, and I think that I have identified what is happening (though I still need to develop a patch for it).

In short, when OR resumes, it is not "correctly" remembering the value for the axle speed in the Axle.cs module. I suspect that this error is a result of the incorrect restoration of the Slip Derivation parameter which the axle speed in turn uses for its calculations.

Thus this all results in an increased slip speed for the axle, which exceeds the slip threshold, and hence the locomotive goes into a wheel slip mode. The rail friction then drops, increasing wheel slip even more, and thus the locomotive will not recover from this condition without reducing the power. A vicious "circle"!!!

I will be away for a few days, so this is a progress report so that everybody knows that it is still being looked at.

[meeshu]

Thank you!

[rman]

Nice catch, Peter! It was the "previousSlipPercent" and "previousSlipSpeedMpS" fields that needed to be saved. After a few successful tests with my Marias Pass scenario, I believe this bug is squashed.

I have opened a pull request for this fix, which I expect to be merged shortly and made available in next week's testing release.

[meeshu]

Good work!!

Looking forward to the revised release which incorporates this fix!!!!

[meeshu]

Run some tests under Open Rails unstable version 8th July, and under NewYear MG version 68.

It appears the issue of wheelslip on resuming saved activities is largely fixed, but not entirely.

The variable NaN no longer appears (for Projected speed), and the previously saved Projected speed value seems to reappear on resuming activities.

However, when actually resuming the activity, there is a brief drop in Projected speed value, and wheelsip warning indicator appears briefly. But the Projected speed value is quickly recalculated and rises in value again. The result being trains no longer actually wheelslip (for the current conditions).

So the fix for the wheelslip on resuming activities is basically usable, as it stands at present.

Thank you!

[rman]

To be honest, that's good enough for me... glad to hear the fix works.