Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 43

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

  1. #21
    Join Date
    Nov 1999
    Location
    Doreen, Victoria, Australia.
    Posts
    6,713

    Default

    >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".
    Cheers
    Derek

  2. #22

    Default

    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

  3. #23
    Join Date
    Nov 2011
    Location
    California, USA
    Posts
    105

    Default

    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.
    Ryan
    US-based railfan and programmer. Author of various timetables and safety scripts for Open Rails.

  4. #24

    Default

    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.

  5. #25

    Default

    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.

  6. #26

    Default

    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.

  7. #27
    Join Date
    Nov 2011
    Location
    California, USA
    Posts
    105

    Default

    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.
    Ryan
    US-based railfan and programmer. Author of various timetables and safety scripts for Open Rails.

  8. #28
    Join Date
    Nov 2011
    Location
    California, USA
    Posts
    105

    Default

    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.
    Ryan
    US-based railfan and programmer. Author of various timetables and safety scripts for Open Rails.

  9. #29

    Default

    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.

  10. #30
    Join Date
    Nov 2011
    Location
    California, USA
    Posts
    105

    Default

    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.
    Ryan
    US-based railfan and programmer. Author of various timetables and safety scripts for Open Rails.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •