bcsp

Probably not whats happening to most of you but if you use an enb and happen to hit the 'Home' key it enables a fps limiter or something. Press it again to disable it.

Thanks EoS. Updated link in OP.

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.

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.

If you've clicked on anything while in console TCL won't work. Just click on something twice to deselect.

Have you ruled out the string table issue? http://forums.nexusmods.com/index.php?/topic/3924850-corrupt-saves-strcount-0xffff-ctd-on-load/

Have you ruled out the string table issue? http://forums.nexusmods.com/index.php?/topic/3924850-corrupt-saves-strcount-0xffff-ctd-on-load/

@Zelazko I don't think there's any such mod/tool yet. Another possible way of saving some string space if you know how: I just cut 160 property strings from a follower mod with one of those body changer scripts. They're convenient alright but you'd only ever really use it once per game. So I cut it out and set it up with the default body I use. Saves strings and no configuring on a new game...

Hmm. I'm not seeing that. Activating the save breaker without the activating the esp does not result in the properties being added to the string table in the save file at least, whatever about what the engine is doing.

True. And Champollion is capable of decompiling most pex files. But wouldn't you be depriving yourself of a huge chunk of string space? I mean, what are the chances of all scripts being instanced at the same time? I think you'd have a better chance of getting hit by a meteorite while collecting your lottery winnings. Looking at a save with 160,000 script instances and 7,000 scripts, many of the instances are duplicates.

And how would you determine it was those mods that added the strings and not another mod after 10 levels. I can tell you that it is definitely not zero though. When vampires attack has around 200 properties. But lets be clear. Properties are the correct way to do things. We've always been told that. I don't want to see anyone harassing mod authors to reduce their string count (not directing this at you personally, but in general). If they try to make their mod more efficient string wise then that's great! If not you'll just have to accept it. It's not the mod authors fault. This is a skyrim limitation. You'll just have to make a call on what mods to use yourself.

There are certainly efficiencies to be gained but you tell that to the author of Interesting NPCs for eg. with 6000 script fragments to rewrite. Not a nice proposition, particularly when there's nothing actually wrong with the mod. Updated the OP with some more info.

Measuring strings by uninstalling mods may not be very accurate. See the "Impact of mod uninstallation" section in the OP. A certain amount of strings may remain 'baked in'. And yes. As far as we know, strings are only added by scripts.

Meh, 99% of the posts there are people asking questions. No answers. Including the original strcount bug post.

I asked this question over on LL but I'd like to ask it here. For anyone that knows papyrus. Why does the string table grow? What causes it to grow? Why would it grow much bigger for some people and hardly grow at all for others? If the table is comprised of script variables and script properties then: Properties: Is the number of properties not constant as long as you are not changing the load order? From my experimentation with the save breaking mods it does not seem to matter if they are filled or not. ie unfilled properties are still added to the string table. It also does not seem to matter if the quest is active or not. Are there any conditions under which properties are not part of the string table in the beginning but added at a later stage? Variables: From (hours of) experience looking at my saves in the save game cleaner I know that the number of active scripts does not change much. You might have 1 active script in one save and 30 in another. They come, they are processed and they are gone. They would certainly add a certain amount of fluctuation to total string count but once the script has completed local variables are removed from the string table. One thing I have noticed over this time is that the number of script instances grows as the game is played. Is this related? Are script instances causing variable strings to be held in the string table? Does it then slowly inflate the string table as the number of different scripts (remember there are no duplicate entries in the string table) that are instantiated increases? Help me get my head around this please. :confused: Edit: Variables also don't need to be initialized to a value to make their way onto the string table. It's a pity TESVESSE doesn't have an export function we could compare saves with to see where the extra strings are coming from.

Crash loading a save or crash loading the main menu? If its the main menu it could be missing masters or you might need to reinstall DirectX from the skyrim dir. If it's crashing loading saves: check the "how close are my saves to imploding" section of the corrupt saves thread in this same forum to see if it's the same issue.

More test results. Modified the mod this time using 99,0000 string variables. Loaded the save I've been using. Opened some MCMs, set some sliders, toggled some toggles. Exited menu and opened again. Everything is the way I left it. Fired up frostfall and realistic needs and diseases. Nothing wrong that I can see except that I can't load the save I made afterwards. Papyrus log size: 184KB. # of lines: 1413. Scripts are reading correct variable contents: I will upload this version to the nexus download page for people to try themselves. In theory, if the game engine was not capable of strCount > 0xFFFF there should have been all sorts of problems....

LAL cell - 48,457 5.5 hours later - 50,090 Difference - 1,633 296 strings per hour :D Only 95 esps. No merged mods. There's probably something wrong there. Laptop again. I'll have better stats when I can get back to my main rig. I started keeping a rolling save count of 500 saves since this started.

Dialogs problem is mainly properties. Removing them would undoubtably break things. Unfortunately the system implemented by Beth is piss poor. We're examining the possibility of using duplicate property names across scripts to reduce string count.

Scripts are the only thing that add strings as far as I know. Specifically, script properties and script variables. If you are using mod organizer it has little symbols that tell you the contents of the mod. One for meshes, one for textures and one for scripts etc. For scripts they look like little spanners I think. I can't remember if MO can look inside bsa files though. I have MO set to extract all my bsas anyway. But if a mod has no scripts it should be as safe as it gets (string wise). Good to know about that vanilla save. There might be some method mods use that have a disproportionate effect on the string table. By that I mean that maybe only certain types of mods cause the string table to grow.

Finally managed to get the mod loaded onto an existing save. Had to reduce the number of variables per script down to 9000. Not sure why I can load 20,000 at the start of a new game and only 9,000 on a save. No matter, I added 7 more scripts to the quest so total scripts = 11. 9000 variables per script = 99,000 strings. I'm installing it on to a save with 45,608 existing strings. 65,535 - 45,608 = 19,927 strings needed to fill the string table to 0xFFFF, which leaves 99,000 - 19,927 = 79,073 strings for the pointer wrap around. It should, in theory, obliterate the existing string table. Nope. MCMs look fine. Opened some sliders. Set some values. Exited. Returned to MCM and everything is the way I left it. Debug traces to the papyrus log from the 11 active scripts are correctly reporting back a value of 1 for the first and last variable in each script. Papyrus log size: 135KB. Lines: 959 I will try with string variables next.

Ha, if you are just under the 65k mark I'd give you five minutes. You are going to need a certain amount of 'cushion'. How much we just don't know yet. Depends on the mods. But at least now if/when your saves stop loading you'll know what the problem is. I spent ages banging my head off my keyboard :D In one way you're better off being way over the limit. Nothing worse than being over the limit after 50 hours. In fact, I've not actually played any skyrim since this has been discovered :(

Local variables held persistent with a wait loop. Variable contents are outputted to the papyrus log every 5 seconds and that section of the log is from some time after the game had loaded so they definitely exist concurrently. I'd be a little concerned that due to the time division processing nature of the papyrus VM there is a chance that with a new game that race conditions exist with regard to string creation. I need to get those scripts off the suspended stack when loading the mod on an already saved game. Anyone got any thoughts on why that is happening? Will try with strings later.

Bah, results are somewhat inconclusive. Added a debug trace to output the first and last variable of each script during the wait loop. Loading the mod on to an already saved game results in the scripts ending up on the suspended stack again. => Strings not created => save not corrupt. Starting a new game, the mod loads ok. MCMs look ok. Saves are messed up. Papyrus log output of script variables:

Hmm, ok. So if the string table were to overflow MCMs should definitely be adversely affected. I modified the variables version of the save breaker. Added another script with 20,000 variables for a total of 80,000 strings. In theory should guarantee the string table is completely overwritten if the game engine can only handle a strCounf of 0xFFFF. Also initialized the variables to 1 just in case. Loaded that old save. MCMs check out. No oddness that I can notice. Papyrus log size and number of lines are less than earlier tests. Is there a particular data type I should be using instead of integers maybe? Seems unlikely but what if the pointer does not wrap around like we'd think and only strings above 65,535 are affected? Not sure how to test for that.