Once Again, Another Crash to Desktop!

**derekmorton** · 05-04-2020, 19:22

Does it crash with a small train?

Do you have the FPS showing in the HUD?

**meeshu** · 05-04-2020, 21:47

First, a slight correction. The train consist is actually 214 cars with 20 locomotives.

Also, the activity was resumed from a previously saved run. But it should be noted that after the saved activity, it was found there were quite a few missing wav files and some errors in the locomotive sms files. So I corrected these (by deleting references to the wav files, as the wav files were not found on my system, in the corresponding sms files), and saved changes to the locomotive sms files.

But the activity crashed as described in my first post after resuming the activity, despite editing the sms files (the sms files were correctly edited by the way, no errors there, as far as I know)! I'm wondering if when saving activities under Open Rails, it also saves locomotive and car settings, including sms settings? So when resuming the saved activity any "errors" (missing wav files) are also resumed? In other words Open Rails doesn't read the updated locomotive and car settings after resuming saved activities?

I've also run shorter (and fairly long) trains over this section of the route. Most of the time there were no issues. But on odd occasion there was a crash back to desktop. In those cases I think the issue might have been due to no wav file being found(?)

I don't usually monitor the frame rates for activities under Open Rails. I didn't check frame rates for this crashing activity either.

However, I have just re-run this activity from the start (after making corrections to locomotive sms files for missing wav files). Most of the views were from trackside. Frame rates were monitored this time. Frame rates varied from nearly 400 fps down to 120 fps. Not bad, considering this is a long train!

The activity completed successfully this time!

Comments?

**slipperman** · 05-05-2020, 02:49

Also, the activity was resumed from a previously saved run. But it should be noted that after the saved activity, it was found there were quite a few missing wav files and some errors in the locomotive sms files. So I corrected these (by deleting references to the wav files, as the wav files were not found on my system, in the corresponding sms files), and saved changes to the locomotive sms files.

It's very poor practice to edit any files used in an activity between saving and resuming it! It's asking for trouble!!

Cheers,
Ged

**baldwin** · 05-05-2020, 06:26

Originally posted by meeshu

However, I have just re-run this activity from the start (after making corrections to locomotive sms files for missing wav files). Most of the views were from trackside. Frame rates were monitored this time. Frame rates varied from nearly 400 fps down to 120 fps. Not bad, considering this is a long train!

The activity completed successfully this time!

Comments?

For a train sim, those FPS are a waste of computer resources. Lock them to your monitor refresh rate and the memory that was being used to generate those FPS can be used for things like physics calculations.

**meeshu** · 05-05-2020, 20:39

Yes, I agree that it is "risky" changing values/settings for locomotives and/or cars between saves and resumption of activities. As the program was (maybe) "expecting" the settings to be the same, and then finds them to be different from the saved values(?) This could indeed lead to program crashes as there could be a conflict of data.

However, for removing references to missing files (particularly wav files), I would have thought that would not cause issues as the program no longer has to "search" for these missing files. In fact it would, in theory, speed up the program as the program doesn't have to waste resources in finding these missing files. And these (wav) files are not really critical to the running of the program anyway, they are not "physics" related(?)

But if the program saves information that "missing (wav) files are still to be found" when saving activities, then it might then become a problem. When resuming saved activities, the program might go into an infinite loop still trying to find the missing files that have since had their references removed before resuming the saved activities(?)

Frame rate calculation, I thought, would be easy to do with little load on program resources(?) So there should be little to no (practical effect) on overall program performance(?) Regardless, I don't usually display frame rates (continuously) anyway.