Skyrim Memory patch 3.0

[z929669]

@keithinhanoi

I am no expert with VMMap, but I have played with it quite a bit. You can save the PID and reopen as long as the process continues to run. You can even look at the timeline of Committed (which is not very useful for our purposes, since it combines all allocations). I see no way to log anything.

 

Unfortunately, Alt+Tabbing kills the process when I try to return. Probably something to do with ENBoost, but not sure.

 

As I said though, I have been many places in game and have never had more than 450/200 allocated to the blocks in question. I am attempting higher uGrids (greater than 11) now, so will report back if I see any big increases in block allocation.

[z929669]

WOW.

 

uGrids 17 seems very stable. walking around outside of Windhelm and fast traveling back and forth to Solstheim, no issues at all. My frame rate is really not suffering either. This is quite playable!

 

Private bytes to both MemBlocks still does not exceed 470/210 for me ... did I mention uGrids=17??

 

I really don't think that there is any need to bump up the default settings applied by sheson.

 

This patch combined with ENBoost (which is really brilliant) and Stable uGrids mod are all together a viable solution to all the past two or more years of Skyrim bugs and glitches.

 

Problems solved, IMO.

 

@sheson

You should post this patch on the Nexus or work with SKSE, ENBseries folks to package everything into a single solution (yeah, right ... that would make too much sense).

 

@all else

Need persons with lower-end rigs to test this for any buggy games. STEP needs to know if/how well this applies to 32-bit architecture or RAM/VRAM-limited 64-bit systems.

 

This will all go into the STEP 2.2.8 guide, which will be released in the next couple of weeks.

[Neovalen]

I was able to run uGrids 9 tonight for about an hour with no hiccups of any kind using the default setting. My VRAM got up to 4000MB at one point though, however I suspect ENBoost would save me should I get to the cap. Game looks and plays amazing at 9 grids, script latency was not an issue either.

[keithinhanoi]

@SSL - The first patched .dll I downloaded was from this Reddit thread.

 

I have since started using a compiled .dll with the adjustable block allocation .ini settings by Daetarek (in the original ENB Forums thread.) The first link to a pre-compiled Daetarek version forced me to get a LL account, but it's now available from many sources (such as Neo's variation with the .ini setting name changes, and also Phinix has posted one on his ENB page on Nexus.) There's even another variation on the original ENB thread from a "Tase" who has patched the SKSE_loaded executable to load a custom .dll with Sheson's code, all of which allows you to circumvent the need to run Steam. Not something I need since I've got enough system RAM to leave it running in the background (and besides, I use Process Lasso to give SKSE.exe and enbhost.exe multimedia app priority status).

 

It's great that the source code has been shared, and very very well explained, but since it's out "in the wild" there are now dozens of sources for patched .dll, not all guaranteed to work (see #1 of my four questions.) I really hope the SKSE team or Boris takes this up to include in their next release, so this situation stabilizes. For now, however, I expect there still to be a bit of a "voodoo" aspect to the reports of how well the patched .dll works from quite a few people (present company excluded!)

 

@z929669: I will have to see if running in windowed mod will change the private usage levels of the two blocks, because that how I usually run when I want to watch memory usage beyond simple on-screen stats (say, using Process Hacker.) If the memory usage is the same, then you don't have to worry about tabbing-out. Still, peaks in usage could happen suddenly and briefly and you may miss them. It's these sudden jumps that lead to Skyrim choking in the first place, from what I can tell. If I was using audio recording equipment I'd have a dB metre which displays the highest peak, and then set levels such that I've got some additional headroom above that.

[yuser]

Nearox, thank you very much, it's working!

 

For the first time i'm able to run from Riften to Solitude with all my mods (about 170), ugridstoload=7 and speedmult=300.

 

And how about a Skyrim script (Papyrus) problems, especially "cloak scripts" (such mods as Wet and Cold, Frostfall, Enhanced Blood Textures, Footprints)? Does this patch solves stability problems with such mods or at least reduce this problems?

 

I'm using Wet and Cold and Frostfall now and didn't play for sufficiently long time, just run around about an hour with slightly increased ugridstoload and speedmult.

[z929669]

I was able to run uGrids 9 tonight for about an hour with no hiccups of any kind using the default setting. My VRAM got up to 4000MB at one point though' date=' however I suspect ENBoost would save me should I get to the cap. Game looks and plays amazing at 9 grids, script latency was not an issue either.[/quote']

I have 3 GB VRAM, and beyond uGrids=9, I always cap. Basically, enboost does kick in at that time and takes on the better part of 2 GB, and the VRAM dips down to a few hundred KB and rises again to between 1 and 3 GB again after playing for a time. I also get no scripting errors or other buginess from loading so many cells. It just takes longer to load a save or transition in/outdoors. uGrids=11 or even 13 will be my new personal standard. I assume VRAM is not as much a limiting factor now either with ENBoost. My system RAM never takes on more than 1024 KB (assume ENBoost controls via INI).

 

Need to log several contiguous hours and high uGrids before I now for sure about stability though. Not sure how ENBoost handles more than one handoff.

 

Limit will be RAM (for enboost process bleed) and CPU/GPU I would guess now. Maybe VRAM, but I want to hear from those with 8 GB system RAM and 1 GB VRAM.

 

I will also venture to guess that almost all of our past stability problems have been MM related rather than script/mod related.

[xeres]

Nearox' date=' do you mean' date=' that your build of skse_loader works without steam? And please, can you upload it to another filesharing site? From your link above there is 7z.exe and my antivirus treat that as virus/malware.[/quote'']

Yes it does. you need my skse_loader.exe and one of the compiled skse_steam_loader.dll files posted here. I placed the file in the attachment. 

thx u very much for the skse_loader.exe .. really appreaciate it :)

WOW.

 

uGrids 17 seems very stable. walking around outside of Windhelm and fast traveling back and forth to Solstheim' date=' no issues at all. My frame rate is really not suffering either. This is quite playable!

 

Private bytes to both MemBlocks still does not exceed 470/210 for me ... did I mention uGrids=17??

 

I really don't think that there is any need to bump up the default settings applied by sheson.

 

This patch combined with ENBoost (which is really brilliant) and Stable uGrids mod are all together a viable solution to all the past two or more years of Skyrim bugs and glitches.

 

Problems solved, IMO.

 

@sheson

You should post this patch on the Nexus or work with SKSE, ENBseries folks to package everything into a single solution (yeah, right ... that would make too much sense).

 

@all else

Need persons with lower-end rigs to test this for any buggy games. STEP needs to know if/how well this applies to 32-bit architecture or RAM/VRAM-limited 64-bit systems.

 

This will all go into the STEP 2.2.8 guide, which will be released in the next couple of weeks.[/quote']

hmmm i've got a decent rig with 32bit os,

i5 2500k non-oc, 8gb ddr3 1600, msi gtx 660 2gb non-oc, and w7 32bit ( i patch the kernel so it can utilize my 8gb ram, but the application is still limited to 4gb max ) ..

i use around 150mods, HD texture mix 1k and 2k, ugrid7, realvision enb lite.. with default setting of 512 block1 size and 256 block2 ..

it ran smooth without safety load .. and i think my loading time between maps is faster now.. i'll report here if i found something new.. ;)

[sheson]

1. With all the reports of different file sizes and results from the same patch code added and compiled on different people's machines and with different versions of Visual C++ Express (particularly the suggested 2010 version vs 2013' date=') I wonder [i']why this is true - and which version of VC++E is the "correct" or best one to use for compiling the patched .dll?[/i]

 

SKSE team says to use 2008 actually.

 

3. If the answer to #2 is "yes"' date=' then I expect the best way to discover the optimal block sizes is to start with the patches default 512/256MB allocations, and save a log of private memory usage for block 1 & 2 over some period of gameplay in memory "intensive" areas, and then search for the peak usage values and add to those (as Sheson & z929669 have explained) for your final block size settings. [i']Can anyone confirm that this would be a good method for this? Also, what could we do in game that would guarantee to produce situations with peak memory block usage values?[/i]

 

A log would be indeed the best way to find the value for the first block. At the moment the value of the second block just needs to be high enough so the game starts or a save can be loaded.

 

#4. I've read posts by Sheson (& elsewhere) that if the block allocation sizes are set too large and/or you have limited system ram (4-6GB) then it is possible that this will "squeeze" the memory available to allocate to other non-renderer processes in the game' date=' including NPC's not completing actions, and probably more importantly, the papyrus VM bugging out and not working properly, so scripts will fail, etc. [i']Can anyone confirm this to be true, and even better, explain why/how this happens?[/i]

 

Simplified: It has 4GB to address. Pre-allocaing memory means we are reserving from this address space. Other parts/processes can not make use of reserved address space. It doesn't matter if the reserved address space is used or not (committed).

 

NINJA EDIT: Any papyrus/script troubles I see happen because of high ugrids, or lots of actors/data not because it is out of memory. The engine can only work on so many items each cycle...

On #2 / #3' date=' it would be of course lovely if the patch code could be extended to read the private bytes usage of the two blocks and present them on screen in game, as a direct way to help in determining the optimal values. I don't expect anything that advanced any time soon, so I'm hoping my ideas /questions above may help to make a good methods to determine those settings.[/quote']

 

I wanted to ask the author of Skyrim Performance Monitor if he could track the blocks instead of one total number. If anyone wants to ask him, go right ahead.

 

If SKSE is ever updated to officially support a type of plugin that needs the early access to the game I probably would release a version that could track and aid in setting the values. Do not get your hopes up :)

 

On the other hand if you are roughly in the ballpark all seems fine. This fine tuning may only be required if memory is really tight, may be because of 32bit OS or someone wants to reach crazy limits just for the heck of it.

 

 

@sheson

You should post this patch on the Nexus or work with SKSE' date=' ENBseries folks to package everything into a single solution (yeah, right ... that would make too much sense).

[/quote']

 

I would most likely release something if SKSE officially supports the needs of such a plugin.

I am still looking at that 2nd block and am talking to Boris from ENB. Do not get your hopes up. I am just saying this is still being worked on.

 

Sheson

[mindw0rk]

Guys, can somebody please share skyrim.ini, skyrimprefs.ini and enblocal.ini to use along with this patch on i5 2500k/GTX680 2Gb/16Gb? I get hiccups and shuttering for some reason, and they especially noticable at Ugrid=9. Its like you run and every 5 seconds fps drops to half, then going back. And every time I turn camera, it shutters.

 

My Skyrim has 4/2k textures with 1k normals, but even without Texture folder its not smooth. Using default ini settings, default MemBlock1=512, MemBlock2=256 and tried verious settings for ReservedMemorySizeMb

[torminater]

You max out VRAM mindwork. No current way of helping with that besides downscaling your textures.

 

 

Gesendet von meinem iPad mit Tapatalk

[mindw0rk]

You max out VRAM mindwork. No current way of helping with that besides downscaling your textures.

 

 

Gesendet von meinem iPad mit Tapatalk

Well, as I said, if I rename Texture folder (making it Vanilla textuers) its not very smooth either. I have alot of mods, but Im pretty sure gtx680 2gb should be enough to handle them smoothly.

[z929669]

snip/...

 

@all else

Need persons with lower-end rigs to test this for any buggy games. STEP needs to know if/how well this applies to 32-bit architecture or RAM/VRAM-limited 64-bit systems.

 

This will all go into the STEP 2.2.8 guide, which will be released in the next couple of weeks.

hmmm i've got a decent rig with 32bit os,

i5 2500k non-oc, 8gb ddr3 1600, msi gtx 660 2gb non-oc, and w7 32bit ( i patch the kernel so it can utilize my 8gb ram, but the application is still limited to 4gb max ) ..

i use around 150mods, HD texture mix 1k and 2k, ugrid7, realvision enb lite.. with default setting of 512 block1 size and 256 block2 ..

it ran smooth without safety load .. and i think my loading time between maps is faster now.. i'll report here if i found something new.. ;)

 

32-bit should be limited to more like 3 GB RAM per process; however, ENBoost obviates this restriction even on 32-bit I would think, since it offloads from TESV.exe as a separate process. As long as you have the system RAM, I thnk that 32-bit arch should benefit

 

Someone that knows more about MM should confirm/deny though.

 

Basically, if you can confirm any difference in your fully-modded gameplay (uGrids=5 [default]) between (create a save looking over the bay at Solitude, pan 360):

• No MM mods active
• Only ENBoost active
• both ENBoost and sheson's MM 3.0 active
• as above but at uGrids=7 and Stable uGrids (CellStabilizer) active

Just report any CTDs or ILSs

 

Based on shesons last response above, it would seem that whatever is allocated in the INI to the MemBlocks is still available, since this is not technically "Committed" under VMMap, but you should leave this at default (use the version in the OP attachment) or possibly reduce if you run out of memory (which you won't since you have enough.

---

Guys, can somebody please share skyrim.ini, skyrimprefs.ini and enblocal.ini to use along with this patch on i5 2500k/GTX680 2Gb/16Gb? I get hiccups and shuttering for some reason, and they especially noticable at Ugrid=9. Its like you run and every 5 seconds fps drops to half, then going back. And every time I turn camera, it shutters.

 

My Skyrim has 4/2k textures with 1k normals, but even without Texture folder its not smooth. Using default ini settings, default MemBlock1=512, MemBlock2=256 and tried verious settings for ReservedMemorySizeMb

Are you using ENBoost?? That should prevent this. Sheson's method will prevent ILS and maybe some CTD, but not stutter.

[Aiyen]

A badly setup enblocal.ini file (The MEMORY subsection) will cause massive stuttering.... only way to get it away is by trial and error until you figure out what works for your system! Sorry but each system is unique in this regard. Also driver version affects ENBoost as well.

 

If the stuttering persist no matter what, then you simply need to reduce texture load, since then you have a bottleneck somewhere in your system that cannot handle the data transfer load you are asking of it. Can happen if you have a cheap motherboard for example.

[mindw0rk]

@keithinhanoi

I am no expert with VMMap, but I have played with it quite a bit. You can save the PID and reopen as long as the process continues to run. You can even look at the timeline of Committed (which is not very useful for our purposes, since it combines all allocations). I see no way to log anything.

 

Unfortunately, Alt+Tabbing kills the process when I try to return. Probably something to do with ENBoost, but not sure.

 

As I said though, I have been many places in game and have never had more than 450/200 allocated to the blocks in question. I am attempting higher uGrids (greater than 11) now, so will report back if I see any big increases in block allocation.

Try window mode with boardless window mod from Nexus. With ENBoost Skyrim lets me ALT-Tab instantly back and forth without any issues.

 

Btw, Ive heard there is fear.exe file to use instead of SKSEloader. Does it indeed raises performance? And where I can get it?

[hellanios]

How do I know it's working? I'm not getting a skse_steam_loader.log. I'm using Neo's .dll and Nearox's .exe.