Talk:INI Settings (Papyrus)

Which INI File?

WHICH INI FILE? Skyrim.ini? SkyrimPrefs.ini? Those in user's folder or in steam's game path? ...?

If I remember correctly, the ini files in the installation directory are used to regenerate the ini files in your user directory, and shouldn't be touched. Also, I think Skyrim.ini is overridden whenever the game is updated, whereas SkyrimPrefs.ini is not and it overrides Skyrim.ini, which means they can contain the same settings but you should basically just be editing SkyrimPrefs.ini

P.S. Please sign your posts on talk pages with ~~~~. This appends a timestamp and your username so we know who said what and when.

-- Cipscis (talk) 19:30, 9 October 2012 (EDT)

iMaxAllocatedBytes

The description of iMaxAllocatedBytes has some mistakes. It's mostly correct as far as I can tell, but setting the value too high will never cause a stack buffer overflow (that is invariably caused by allocating too little memory to the stack), nor is a stack buffer overflow the same thing as stack thrashing, as the description seems to imply. On top of that, I'm not 100% convinced the problem really is stack thrashing, either. Stack buffer overflows are commonly used in stack smashing exploits, and it's a pretty common mistake to think smashing and thrashing are the same thing, but they're really not. Smashing is when you deliberately fill a stack with data and use the overflow to inject code. Thrashing is when you're spending excessive time on stack maintenance procedures (i.e. push() and pop() are your most used functions).

I have two guesses of what might be happening: If the VM can't allocate memory to a new stack, either it puts everything in the same stack and then has to use an excessive amount of push and pop to maintain that stack and find the right entries (which is true stack thrashing), or (more likely) it suspends the stack until it can find memory to allocate to it, which, if this value is set too high, will never happen. Because Skyrim is a 32-bit process and can only use 4GB of memory, if you set the stack size to 2GB, the VM can only allocate memory to one stack at a time, and every other stack is suspended, which is why the suspended stack count frequently exceeds the warning threshold. At least, that seems plausible.

I would edit it myself, but I'm not confident enough that I'm right about this. At best, though, it's unclear. Maybe some explanation of the tradeoff between stack size and active (as opposed to suspended) stack count would also be worthwhile, here, but I'm not quite sure how papyrus handles stack count - only that the VM will start dumping stacks if the suspended count gets over the warning threshold. --Thegooseking (talk) 2014-08-22T09:18:00 (EDT)