Skyrim Memory patch 3.0

[b3ast1e]

I've been coming here for a while now but never registered, just lurked and soaked up all the great stuff here to make my game better. But this patch was enough to draw me out of the shadows just to shout from the rooftops how chuffed I am.

 

I've not been using it enough to give any real contribution to feedback other than anecdotal, no numbers or anything useful to back myself up. And I've been using Safety Load for a while now so ILS has been much less of an issue for me than it once was. What I wasn't expecting was for this patch to give me a big general boost in performance.My game has gone from okay but a little stodgy because of all the stuff I throw at it (thanks to STEP lol), to significantly smoother and more stable than I think it's ever been, by some margin too. I've even been brave enough to up my u-grids to 7, and my creaky old rig didn't even seem to notice!

 

Sheson is a master of the dark arts, this has to be black magic - he's fixed Skyrim.

 

And thanks to Neovalen for going to the trouble of making it much easier for us folk who don't much like computers to get up and running without chasing our tails.

 

My hobo setup: AMD Bulldozer 6100 (don't hate me) slightly clocked / 2x 2GB 1.3ghz DDR3 /GTX 650ti 2gb. I'm running the general core STEP guide with a bunch of other stuff I've added, about 190 plugins, all dirty edits cleaned and textures optimized at 1024 or lower. I'm using a performance ENB (Saraan Suum) but with deferred rendering enabled so I can turn on stuff like reflections. I play at 1920x1080 and generally get avg 30fps exteriors, 40-45 interiors.

 

As I say, no problems with loads, no freezing, no stuttering, load times were often longish (25 - 30 secs max) for big transitions, but most interior to exterior loads within cities seem much faster now (this ENB has always been slower than others I've used). As a quick test I did the North Tower dragon, always been a lag spot for me. Throughout that fight I was getting 35fps - normally it can plummet to 24fps there. In wooded areas around Falkreath I normally get as low as 22 or 24 fps, with the patch it's 28 or 30 - but the significant difference is that I'm not getting any little freezes, no pauses while cells load - unheard of for me in that area.

 

I've not thrown anything like Immersive Patrols at it yet, but that's going to be a significant test as I've never been able to run it well with this setup. I'll update with how it went if that's useful.

[keithinhanoi]

Just a quick report on my findings so far -

 

I tried using windowed mode, without any of the SKSE-based plugins that are supposed to help when doing that, so I could watch things in VMMap & Process Hacker.

 

This did not work well, because #1 VMMap does not refresh the numbers on a consistent & regular basis, so I still had to tab out to hit F5 to refresh.

 

#2 problem was that (on my system) in windowed mode loading of my game or interior / exterior cell change requiring a loading screen took 1-2 minutes. Changing back to full screen fixed this, but I worried that having to tab out of Skyrim would affect the numbers shown in VMMap (because the game effectively pauses when tabbed out.)

 

I notice that you can view memory address allocations in Process Hacker, but it only shows commit values (not too bad, because usually the same as private bytes), but more importantly it did not group all the children of the 2nd block, so I needed to keep VMMap open to cross check on the addresses of the 2nd blocks, er, um, children.

 

Going to some memory intensive places suggested by sheson and others, I saw peak usage at roughly 340MB/135MB, but I just don't trust those numbers without having some kind of log. After hearing back from sheson, I am now going to try to find some way to log the private byte / commit usage for the two memory blocks that this patch affects.

 

I also did experience a CTD after 1 minute at speedmult 1500, but then I couldn't check the final memory block usage before crashing because of the problem with infrequent refresh in VNMap, and hitting refresh after TESV.exe has died give you "PID no longer available" type error (as to be expected.)

 

Nonetheless, as I mentioned before, in all the places where I've previous seen consistent crashes, I was still able to sail right through, or open up inventory, etc. menus without incident.

 

Anyhow, when this CTD happened, I had the SKSE minidump feature turned on, so I uploaded it to the OSR Online site recommended by sheson, but the fault listed did not match the one in sheson's explanation in his ENB forum post. As much as I could tell from the analysis, I seems that some memory address was trying to be written to that wasn't available or protected. This may have been TESV.exe trying to start a new allocation block because my first 512MB got full, but with the values I was seeing in VMMap, I doubt it.

 

To be honest, the CTD I saw could be related to using not the best settings in enblocal.ini, because I prior to this memory patch, I had been trying to work through my CTD problems without the ENB memory boost features, as I never saw my TESV.exe memory usage go much over 2GB.

 

I can certainly post all my .ini's, modlist, etc. and the crashdump on pastebin if it interests anyone - but this is by no means a plea for tech support! My system specs are in my sig for reference.

[z929669]

Thanks for the feedback keithinhanoi.

 

I suspect that all of the heretofore 'dangerous' skyrim.ini settings may be on the table as well now that we can assume taht most creashing has been due to MM issues. Perhaps you can push things by increasing UseThreaded* ini settings and shadows, etc.

 

I am doing just that with uGrids 11 and playing as normal for a couple of hours (hopefully) tonight. A logging solution would be great if you can find one.

 

More on using VMMap for anyone willing to learn and report back.

 

More tools to evaluate

[Neovalen]

I suspect that all of the heretofore 'dangerous' skyrim.ini settings may be on the table as well now that we can assume taht most creashing has been due to MM issues. Perhaps you can push things by increasing UseThreaded* ini settings and shadows, etc.

 

Z-Fighting Tweaks :D

[vfxninjaeditor]

I suspect that all of the heretofore 'dangerous' skyrim.ini settings may be on the table as well now that we can assume taht most creashing has been due to MM issues. Perhaps you can push things by increasing UseThreaded* ini settings and shadows' date=' etc.[/quote']

Z-Fighting Tweaks :D

Speaking of which, could you point me in the direction of good Z-Fighting tweaks? My mountains z-fight very badly at the moment. Could use the fix now that my PC can handle it.

[Neovalen]

I suspect that all of the heretofore 'dangerous' skyrim.ini settings may be on the table as well now that we can assume taht most creashing has been due to MM issues. Perhaps you can push things by increasing UseThreaded* ini settings and shadows' date=' etc.[/quote']

Z-Fighting Tweaks :D

Speaking of which' date=' could you point me in the direction of good Z-Fighting tweaks? My mountains z-fight very badly at the moment. Could use the fix now that my PC can handle it.[/quote']

https://wiki.step-project.com/Guide:Z-Fighting#tab=What_is_your_fix_3F

[TehKaoZ]

Indeed, I haven't touched Ugrids, but I have been working with those Z-fighting tweaks again alongside the memory patch.

[Redferne]

Hi all,

Can someone explains what this line is supposed to do: UsePatchSpeedhackWithoutGraphics=true

Meanwhile I tested a little too, using Novalen DLL (even so I made mine but without the nice ini options).

My rig: Intel i5 2500k@4GHz 8Gb RAM GTX 670 2Gb VRAM uGrids 9 Windows 7 64bits.

I walked around in the tundra between Whiterun and Rorikshead fighting everything I could find with an heavy moded game (STEP + SR:LE + some other mods + Phinix ENB 19.5a).

No crashes, descent framerate (20-40) but some lags.

At uGrids 7 I never reached 480Mb in the first block according to VMMap. The games lags a lot less and framerate is way better (30-55).

[torminater]

That line disables all effects from end except the ENBoost feature.

 

 

Gesendet von meinem iPad mit Tapatalk

[Redferne]

All right, so do not use if you actually use an ENB :)

[rootsrat]

If you use ENB, then:

 

UsePatchSpeedhackWithoutGraphics=false

[thalixte]

I just came to this board to share a new version of the sheson fix, that works for steam and non steam users.

 

This version uses a modification in skse_loader.exe in the part of code i pointed out in the enbdev board, to load a mempatch.dll containing sheson's fix, as suggested by Tase.

The version i propose uses Neovalen's skse.ini settings. Just copy/override the files skse_loader.exe and mempatch.dll in your Skyrim main folder. This version creates a mempatch.log in /Documents/My games/Skyrim/Skse/ folder. If the fix is enabled, you shoud see this message:

 

Tase's Evil & Thalixte Non-Steam Memory Patcher... HUEHUEHUE... All credits to Sheson for this patch... and Daetarek and Neovalen for their skse.ini modifications...

 

So feel free to try it. Here is the download link =>

 

Of course, all credits go to sheson for his tremendous fix...

 

Last update: I've decided to delete the link provided in order to respect skse copyright. Waiting for the next skse release that will include the sheson's fix.

[hellanios]

So basically I should be able to run ugrids 7 or 9 with absolutely no problem with this patch right? And I mean along with a step 2.2.7 install.

As long as you follow the guide and properly create the Bashed Patch and have no mod issues, yes.

 

Requirements:

• CellStabilizer (Stable uGrids)
• ENBoost (ONLY the following needed):

• d3d9.dll
• enbhost.exe
• enblocal.ini (ignore all other settings, they have no effect)

• UsePatchSpeedhackWithoutGraphics=true
• FPSLimit=42.0 (optional)

[*]sheson's patch (recommend Neo's version in the OP for now)

Please report back how much RAM and VRAM you have (and CPU/GPU brand/architecture) as well as if there is any difference you notice during play. Load times (game startup, indoor/outdoor transitions) will be increased due to enbhost process memory manager and increased asset load time, but it is well worth it.

Y should we limit the fps at 42?

[Aminados]

Maybe you guys have noticed this but I'll report it anyway.

 

The original skse_steam_loader.dll is 114KB in size, so if you're adding code to it then compile it, it should be larger size, no?

 

If you compile the dll using VS2010 with no updates or service pack, the dll size is 107KB , witch is odd because you added code so it should be larger then 114KB .

 

If you compile the dll using VS2010 with service pack and all updates, the dll size is 108KB , witch is still odd because you added code so it should be larger then 114KB.

 

Also, when you compile using VS2010, if you look at the output log it shows:

 

========== Build: 2 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

 

 

Now, "PurpleLaunchBox" said "SKSE only supports building on VS2008 due to a language change from C++11." in the following post:

https://forums.bethsoft.com/topic/1478879-wipz-skyrim-script-extender-skse/?p=23273343

 

So I went ahead and downloaded VS2008 90Trial from here:

https://download.microsoft.com/download/8/1/d/81d3f35e-fa03-485b-953b-ff952e402520/VS2008ProEdition90dayTrialENUX1435622.iso

 

Now when I compile the dll using VS2008 with service pack and all updates, the dll size is 122KB. It is now larger then the original dll since i've added code to it, witch makes sense.

 

Also, when you compile using VS2008, if you look at the output log it shows:

 

========== Build: 3 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

 

So.. I say it's better to compile the dll using VS2008.

[torminater]

The Skse guys said that only the 2008 version is supported, so I guess that's the reason.

 

 

Gesendet von meinem iPad mit Tapatalk