file corruption

[Watercrown]

Nah, it's enabled. Might not have explained that well. After I saw that the hitch free gameplay was mostly due to that section I enabled it and just started messing with all the options idefaultmode = 1 seems to be working so far. idefaultmode = 2 was an instant crash upon boot. I never tried 5 since 1 seems to work for now.

[dubiousintent]

That itself is interesting to learn: that "idefaultmode = 1" works, while "idefaultmode = 2" doesn't. Do let us know if you experiment with any other "CriticalSections" setting that cause problems. It may be that only certain ones are problematic, which may help others who need that section.

 

-Dubious-

[dookie32]

That itself is interesting to learn: that "idefaultmode = 1" works, while "idefaultmode = 2" doesn't. Do let us know if you experiment with any other "CriticalSections" setting that cause problems. It may be that only certain ones are problematic, which may help others who need that section.

 

-Dubious-

 

Confirmed.

 

"iDefaultMode = 1" under both "CriticalSections" and "LightCriticalSections" is good for me. Otherwise, sometimes it hangs on loading screen. The version of NVSR I got came with "idefaultmode=3" which is said to be a "hybrid of 1 and 2" according to the commented notes in the .INI file. I don't have an idea of what this means, but I just know that changing idefaultmode to 1 seems better than turning off CriticalSections altogether in the "Master" section.

 

Oh yeah, also increasing "iHeapSize = 384" under the "Heap" section helps too, but that's not necessarily for infinite loading screen fix. It just seems to decrease likelihood of random crashes and stutters.

 

However, I'm getting a frame skip / stutter issue whenever CASM auto-saves. Sometimes it lasts up to almost 2 full seconds. It doesn't happen on new game saves, and manual saves with F4 seems to be only a split-second freeze as opposed to a longer stutter. This is most likely completely unrelated to NVSR settings.

Edited July 25, 2018 by dookie32

[dubiousintent]

Thanks for confirming the "iDefaultMode = 1" setting. A single instance might just be happenstance on a given machine. Independent confirmation makes it much more likely to help others. I'll be updating that issue.

 

There are actually a couple of "heaps" that various settings in various files affect. Unfortunately they aren't labelled. They are basically "temporary holding buffers" for code instructions. More is generally better, but it does take away from available memory for other purposes. Multiples of 16 are most efficient.

 

Writing to disk (saves of any kind) are the slowest things the game does. The further you are into the game, the more things it has to write out to keep track of (e.g. everything you moved or picked up). The only ways to speed things up would be to only save "incrementals" (which save things that are "different", but may miss something crucial in the event you needed to revert to that point), or for the system to "queue up" the write in the background in order to get back to the user more quickly, which runs the risk of something happening to the queue preventing everything from getting written to disk. F4 is the default "quick save" key and as best I can tell is only an "incremental" save which might be queued as well. Regardless, "quick saves" have proven to be unreliable as restoration points in the event of needing to revert to a previous save point in the game. I've waited a lot longer than 2 seconds for a save after setting CASM to only make "full saves" on just a few points. Even then I only really trust manually triggered saves. Better safe than quick.

 

-Dubious-

[dookie32]

 

Writing to disk (saves of any kind) are the slowest things the game does. The further you are into the game, the more things it has to write out to keep track of (e.g. everything you moved or picked up). The only ways to speed things up would be to only save "incrementals" (which save things that are "different", but may miss something crucial in the event you needed to revert to that point), or for the system to "queue up" the write in the background in order to get back to the user more quickly, which runs the risk of something happening to the queue preventing everything from getting written to disk. F4 is the default "quick save" key and as best I can tell is only an "incremental" save which might be queued as well. Regardless, "quick saves" have proven to be unreliable as restoration points in the event of needing to revert to a previous save point in the game. I've waited a lot longer than 2 seconds for a save after setting CASM to only make "full saves" on just a few points. Even then I only really trust manually triggered saves. Better safe than quick.

 

-Dubious-

 

Thanks for the detailed explanations of the various save states. The CASM with MCM config menu lists F4 as "Manual Save Hotkey" so I assumed it was the same thing as a save from the main menu, but I apparently I was mistaken. I occasionally saw some weird phenomena when loading these auto-saves and incremental saves, but to be honest, I got so spoiled being able to run while CASM was frequently saving that I actually don't mind as long as it doesn't completely corrupt the save. I don't plan on playing several characters at once, so I'm willing to risk it if this means I can somehow get that experience back.

Yes, I read somewhere that the save files gradually get larger to account for more items, objects, and quests the further along you get. The thing is, I had progressed quite a bit before noticing this save freezing issue--the auto-saves used to be extremely smooth. (And, they still don't cause any noticeable frame skip or stutter on new test starts.) Perhaps, it's because it is saving to my SSD. At first, I thought this issue was due to a mod I had installed recently (Solid Project), but after uninstalling it, the auto-saves in my current playthrough still stuttered the game frequently. In CASM config, I decreased the Save Frequency, increased the Save Delay, and disabled most of the Save Events so it's not saving as often. Oh well, it's not a big deal... at least it ain't crashing or hanging on the load screen.

Thanks again for the info.