Original forum topic is here, it may be temporary disabled. ENBoost and ENBSeries web site is here
For those users who are new to ENBSeries and ENBoost, i recommend to read it description in readme_en.txt and on the nexus page of ENBoost. In short, ENBSeries and ENBoost are the same, but ENBoost functionality can be toggled on/off independently from graphic modifications of ENBSeries, so performance will not degrade while using ENBoost only. Simply set UsePatchSpeedhackWithoutGraphics=true in enblocal.ini and all graphics modification will be disabled. Those users who want graphics but have very low performance with ENBSeries - you are not properly configured game and/or mod, so pay a little attention to understand what is wrong.
This patch will require your first born and a pint of your blood.
What bad can happen when Skyrim uses more memory without tripping over itself?
Fried Hardware maybe? If anything bad does happen then it is your problem since I already got your firstborn and I do not care. This information is provided as is. I am sharing it because I am hoping a large part of the community will benefit from it. Take it or leave it.
Be sensible about memory use and modding done right in general - refer to S.T.E.P.
The information below helps my(!) Skyrim with higher ugrids and many mods. For the love of the holy cow make sure to only use well documented and tested ini settings or spend some time testing them thoroughly yourself. If you can not properly verify cause and effect all you do is wasting time. No need to mess with unknown, untested, unproven settings or mindlessly copy and paste made up things that have no effect.
For additional memory add this to the .ini
2014, January 20
* Added How much memory to pre-allocate section
* Added Recommended section and note about precache killer
2014, January 19
* Added a link to more detailed post from ZerOxShadows how to compile
2014, January 18
* Added a note about the need of Stable uGridsToLoad in requirements
* Added hint to run updates after installing a 4 year old program from MS
It has been a while since the first memory patch that fixed 4GB LAA that made it into the official game. Thanks to Boris we have the second memory patch ENBoost taking care of textures not wasting main memory anymore. In this naming tradition this third memory patch will allow Skyrim to use that available space right from the start to fix ILS (infinite loading screen) without side effects and other memory related CTD (crashes to desktop) or freezes. After many hours of peeking and poking it turns out there is a simple fix and one has to wonder why this is not something that is implemented as an option or parameter for the PC version of the game.
When tesv.exe is started it allocates two 256MB blocks of memory. When the first block gets full, the engine will allocate more blocks. This can cause the known troubles. Thankfully, by telling the engine to request a bigger block from the start it magically makes use of it without any further ado. This isn't the case with the second block. Thankfully again, the second block does not fill up as quickly and once it is full the engine does not trip over itself when allocating more blocks.
To make the engine allocate a larger block of memory it needs to be patched. This needs to happen very early in the process. This can not be done by a SKSE plugin because they are executed much later. However, SKSE loader already patches tesv.exe before the game starts and since SKSE sources are provided adding the patch is straight forward.
Because of the nature of this patch I will only provide instructions how to do this.
I contacted Boris about this and he is doing his own tests and investigations. If this can be part of ENB I do not know. Best not to waste his time with silly questions.
You have a 64bit OS and lots of main memory. You have decent hardware. You already use ENBoost and do not run out of VRAM. You went through all your mods, used tes5edit to clean them and use BOSS and what not. You searched and read lots of discussions and guides and spend hours over hours fixing and optimizing everything.
If you use safety load this fix will most likely help you to replace it and not have any side effects.
You can get VMMap and check if the first memory block is fully used. It is a yellow private data block that at first has 2 childs. Once all its memory is commited it only has one child and both the size and committed column showing the same number 262,144K.
This is not problematic in itself, but this condition raises the chance for ILS, CTD and freezing and this fix will most likely help avoiding any of that.
If you have "random" CTD you need to try to make them reproducible.
For example, typically the committed number grows when crossing cell borders but maybe also shrink when busy cells are unloaded. If it reaches 262,144K troubles may start. Use tb for toggleborder in skyrim console to show cell borders and if you freeze or CTD right on a yellow line this fix will most likely help.
SKSE can write minidumps that can be analyzed in what part of the program the game crashed and why. Even if this doesn't mean anything to you, you can check if the crash is the same every time. If this crash data would be supplied whenever people talk about CTD it could help tremendously in finding related discussions to a particularly crash condition and over time eliminate a lot of guess work.
If you happen to come across
Here is a well documented patch that you can put into SKSE steam_loader main.cpp at the end of
* For the love of the holy cow, please do not ask me for help with this. Check out this light version of post from ZerOxShadows or original post from ZerOxShadows for a bit more detail on the process.
* Get SKSE sources, doh
* Get a 30 day free Visual C++ 2010 Express, run windows updates to make sure this has all the updates
* Open SKSE src/skse/skse.sln
* add patch to steam_loader/main.cpp
* in top menu change dropdown from Debug to Release
* in left pane right click steam_loader, build
* you will find new skse_steam_loader.dll in src/ske/Release
* if Skyrim does not start just put original skse_steam_loader.dll back
* 64bit OS - 32bit may work but untested, probably should use /userva switch, but if you are that desperate good luck
* a decent amount of RAM - more than 4GB
* a suitable graphics card with decent amount of VRAM - depending on texture sizes
* ENBoost - need to free up main memory
* Stable uGridsToLoad - if you want to test with higher uGrids. You may not really need it, but it fixes a recursion bug that could potentially cause CTD with default uGrids as well.
* You may still need a precache killer to load all the assets. Remember this fix is not making the game use more memory it just tells it how much memory for a certain block to anticipate.
Remember to add this to skse.ini
If you look at the code you can see how this becomes a real setting ;)
Check skse_steam_loader.log for the message about your offspring.
Before: two 256MB allocations.
After: one 512MB and one 256MB allocation.
Disable Safety Load and test if ILS are fixed. Test with any old saves you have, travel back and forth Solstheim.
You can still use Safety Load, but if you need it, it basically means the 1st memory block is not large enough for your setup.
Do speed runs, you should already know about tgm and player.setav speedmult
Use Skyrim Performance Monitor to keep an eye on VRAM
There is no need to pre-allocate a much larger block than the game will actually need. In fact doing so can have a negative impact, because other parts of the game need memory as well and the more is pre-allocated to this specific block the less is available to the other processes.
Remember, we are not telling the game to use more memeory, we are telling it to pre-allocate the first block in one big continues chunk instead of the default small chunk and later using additional smaller chunks somewhere else.
If you look at this screenshot of VMMap you can see that from the 524,288K of the first block 94,464K are not used. It is not much in this example, but it also means there is no use pre-allocating any more than this.
When testing for the highest needed value of your setup, you need to find the busy spots with lots of cell data. Windhelm Harbour comes to mind, the Rift or Solitude Harbor. It is typically the exterior spots where you had ILS. You can lower your value with a buffer in mind.
Any Megabyte size should work, but only experience will show if there needs to be a multiple of something.
Only raise the second block if the game doesn't start. It is a workaround at the moment and should only really be needed when testing limits with high uGrids or many mods.
It is only recommended to raise the first block to 512MB and leave the second block alone. Like with all new mods this needs to be tested. Extensively.
This fix should be suitable for a lot of setups, provided there is enough main memory, a decent graphics card with plenty of VRAM and some common modding sense.
This will simply raise the limit of when the engine will trip over itself again when overloaded. If VMMap shows the same number in both size and committed column the engine is in trouble.
Raising uGrids can have effects on quests and game play, depending on installed mods.
It is your responsibility to find out what is safe for your setup.
If this fixes something I didn't describe yet.
If this fix works for you on exotic hardware or 32bit OS.
Please be detailed and thorough in any report.
For the love of the holy cow, please get rid of all the nonsense settings. For starters you can check the tesv.exe for its content with notepad.
All settings are there to read. saveini does not dump everything it seems or there are strings that are not used.
Whatever wierd things you copied and pasted in your futile attempts to make higher uGrids stable, get rid of them now.
A little known setting, make this half uGrids if you want to raise fGrassStartFadeDistance in prefs.ini
Use this info for whatever you like. This will stop working if for some strange reason a new version of tesv.exe comes out. Fat chance.
Please link back to this original post on ENB forum instead of copy and pasting.
If you use this in your loader, patch, mod or whatever I would be honoured if you keep the setting name. As an alternative make a dancing holy cow animation for one of MMOxReview videos. Please give credit if you use this.
Yeah, so I can set 768MB for both and raise uGrids to 17/19 with 100s mods and textures packs etc. The only practical use is pretty? screenshots. Papyrus is pretty much dead at this point. Test what is possible if you like. You understand the consequences. It will fry your hardware, mess up your save game and you will never be able to have kids again.
It is your responsibility to find out what is safe for your setup.
Can we filter out the crap from the Internet please?
Can you please stop mindlessly repeating stuff that you read somewhere else as fact and thus adding to the crap on the Internet?
So SKSE can write minidumps and nobody uses that information to share and discuss?
Thanks to Boris for his continuous work on ENB, ENBoost and having a Forum
Thanks to the SKSE team for SKSE and its sources
Thanks to who explains and document things for other to learn from it
Thanks to who can help themselves with the information provided.
Nord Cattle - HD cows
Holy Cow I fixed Skyrim - Sheson