Corrupt Saves - StrCount > 0xFFFF - CTD on load

[Gawad]

Not to worry, dark_wizzie, I understood perfectly well what you meant, and it was perfectly clear that what you care about the most is whether your own load order works for you, no problem. The point I was apparently not so clearly trying to make was that this doesn't do anyone else any good, at least unless you share some of your results. Not asking for a load order here, but just a general sense of how heavy it is and how its strcount evolves over however long you consider a playthrough is useful information. So hopefully we can learn something from everyone on this thread.

Edited April 7, 2016 by Gawad

[BoredErica]

Not to worry, dark_wizzie, I understood perfectly well what you meant, and it was perfectly clear that what you care about the most is whether your own load order works for you, no problem. The point I was apparently not so clearly trying to make was that this doesn't do anyone else any good, at least unless you share some of your results. Not asking for a load order here, but just a general sense of how heavy it is and how its strcount evolves over however long you consider a playthrough is useful information. So hopefully we can learn something from everyone on this thread.

If I had data for a complete playthrough I would share it and plot a graph. I'm just too lazy to do that right now, though. :sick:

 

Maybe I'll do some more quests and give a more complete update later if I find it useful to others.

Edited April 7, 2016 by dark_wizzie

[cdcooley]

Poking around a bit it seems the TIF (Topic Info Fragment) scripts attached to dialogue really are dynamically loaded and purged from memory and the properties and string values they use are too. But the QF (Quest Fragments) scripts and other scripts attached to quests and their aliases get loaded into memory from the start and remain.

 

State names themselves don't appear to be stored in the string table, but the active state for each script is. So if you have 1000 uniquely named states in your script it will still only result in one string table entry at any one time.

 

Since someone posted an InigoMCM count and it was small I decided to take a look at it and I'm feeling much better about MCM scripts now. My tests show the InigoMCM uses 23-24 unique strings (because it reuses some from Inigo, SkyUI, and the core game files). It only uses 23 when the game loads and then 24 after you've used it the first time.

 

The string literals used in MCM scripts aren't stored in the string table either, so MCM scripts are not really much heavier than other scripts except that people tend to use lots of properties and variables. The state names get stored in a string array while the menu is open, but the array is cleared and the strings released when the MCM closes. The help text string shown at the bottom of the MCM and any other string variable values that aren't reset to null get stored in the cache table (which is why the InigoMCM goes from 23 to 24 strings after the first use) but there doesn't appear to be anything about how MCM options work behind the scenes that make them particularly expensive in terms of string count other than the need for multiple properties. And from my tests it does seem the new state-based MCMs are less string heavy than the older style because state names don't count and you can declare fewer properties and variables.

[Gawad]

^^^ That's good news. And here's a little good news/bad news tidbit I've discovered with some of my testing this evening. I'd been assuming that mods without scripts and just ESPs wouldn't affect string count (and I believe this was brought up by someone else as well, though I can remember on which thread at this point), but it turns out that's not quite the case. In one my tests TESV ESS clearly shows the ESP from Naked Comment Hypocrisy Fix disabled a script from the prior save (4755 scripts to 4754) and the StrCount dropped by 2. So, unfortunately, it turns out that bare ESPs can affect StrCount: one ESP can disable one or more scripts, and a conflicting ESP of higher priority could re-enable them affecting overall StrCount. And therefore load order definitely has an effect beyond the simple load out. And here I was hoping that I could just skip testing mods without scripts. Sigh. The good news is that, on a hunch, I wouldn't expect the effect to be that large.

 

Also I should mention that right now, with the PC just standing there outside Helgen in the middle of the night, my string count doesn't seem to be fluctuating randomly at all from multiple save to save except when I add mods.

Edited April 7, 2016 by Gawad

[cdcooley]

Even better. The currently released InigoMCM has 5 unused variables in one of the scripts. I removed those, reloaded a game, then saved immediately. I had exactly 5 fewer strings in my new save compared to the old one. So through careful script rewrites it is possible to reduce string counts from existing games without breaking everything. I doubt many modders will do it because it's not an easy task but it means MCM scripts could be rewritten in the new style and the string count lowered without requiring people to restart or lose configuration information.

[bcsp]

Interesting. I wonder what the 800 strings being left behind when uninstalling interesting npcs are and why they're different.

 

It would be pretty useful if tessv ess had an export function.

Edited April 7, 2016 by bcsp

[Gawad]

"Btw if you're lucky you can bypass string limit by using threading/multithreading feature of ENBoost."

 

I just wanted to reply to this to avoid misinformation getting spread around (so please anyone correct me if I'm mistaken) but I don't think there's any way assigning different numbers of cores or threads to Skyrim can help avoid this, whether through the Skyrim.ini or ENBoost. Skyrim is just writing the StrCount values it has in memory out to the save file. It will do that regardless of how many cores/threads you use.

 

I remember running into a similar comment on another thread, but its just misinformation. I can see how someone skirting the 65535 limit and starting to get corrupt saves (but not knowing why) might start messing about their Skyrim.ini and trying to work around the problem by increasing performance by using more cores/threads...and then just "got lucky" and got a useable save, but it's almost certainly just the regular fluctuation of numbers in the StrCount table that saved them, not the additional cores/threads.

 

Trust me, I've had anywhere from 2 to 8 cores assigned to Skyrim (on an i7 5960X) and I can still corrupt my saves along with the best of them :wink:

Edited April 7, 2016 by Gawad

[bcsp]

Horseshit.

Attempting to increase the string count limit by manipulating threading settings will be as effective as using a bubble gun on a dremora lord.

Threading settings have nothing to do with the format the save file uses. It is hard coded into the game binaries which is why people are talking about patching the exe.

In fact, according to Boris Voronstov (the guy that know this stuff) increasing threads above 1 will only introduce a ton of bugs and not improve performance in the slightest.

[BoredErica]

My understanding of it (and it may also be wrong) is that str count and thread count are unrelated, even if strings and threads sound similar when it comes to knitting. :laugh:

[EpitomyofShyness]

I've updated the Spreadsheet I made. Its no longer at its original location, but instead at the first like I provided which includes links to all the forum threads discussing this issue as well as other speadsheets. I have set it up so that by using the Outline feature in google docs people can easily located various categories and compare and contrast the string counts of mods of similar types. The previous spreadsheet has been locked and anyone who wants to add in new data should do so on the Google Doc.

 

https://docs.google.com/document/d/1HY4b4L3tJuYPxJazEc8XeF-q3WXI11u76hlKKleQel8/edit?usp=sharing