Jump to content

Skyrim Memory patch 3.0


Aiyen

Recommended Posts

Sorry if this seems stupid but i cant seem to get this to load no matter what i try.  I've been at it since yesterday. So far here's my situation: I place the modified dll in my skyrim dir make sure i have the latest skse and the latest enb with enboost from boris, i modify the line in SKSE.ini in skse folder in data folder, i start the game using the skse launcher as always since i use skyui and mcm that need it.  However skse_steam_loader.log never generates in my documents/mygames/skyrim/skse folder.  Just a 3 text files with the names SKSE, SKSE_loader, and skse_steam_loader.  I thought maybe the 3rd one is the file that people are mentioning is created. i look for the message about sacrificing my firstborn to shensen in that text file but it reads

skse loader 01060100 (steam) 01CF16270EEB712E 6.1 (7601)

base addr = 66020000

GetSystemTimeAsFileTime IAT = 0106B1D8

original GetSystemTimeAsFileTime = 759A34A9

patched GetSystemTimeAsFileTime = 660217F0

GetStartupInfoA IAT = 0106B1D0

original GetStartupInfoA = 759A0E00

patched GetStartupInfoA = 66021810

InstallHook: thread = 4112 retaddr = 00F69112 hookSrc = 0

appPath = C:\Users\Public\SteamGames\skyrim\TESV.exe

dwSignature = FEEF04BD

dwStrucVersion = 00010000

dwFileVersionMS = 00010009

dwFileVersionLS = 00200000

dwProductVersionMS = 00010009

dwProductVersionLS = 00200000

dwFileFlagsMask = 00000017

dwFileFlags = 00000000

dwFileOS = 00000004

dwFileType = 00000001

dwFileSubtype = 00000000

dwFileDateMS = 00000000

dwFileDateLS = 00000000

version = 0001000900200000

steam exe

dll = C:\Users\Public\SteamGames\skyrim\skse_1_9_32.dll

old winmain = 0069D1D0

runtime root = C:\Users\Public\SteamGames\skyrim\

config path = C:\Users\Public\SteamGames\skyrim\Data\SKSE\skse.ini

OnHook: thread = 4112

calling winmain

 

I used to have a .log file in documents/mygames/skyrim/skse when i used skse to clearinvalidregistrations in an old save file of mine but that was deleted when i formated my hard drive awhile ago. This is a fresh install of skyrim i reinstalled it with the hope that this patch would allow me to play the game.  If there is anything obvious i'm missing please let me know.  

Its the steam version of skyrim and i have not modified the .exe in anyway.  Also I have changed the SKSE.ini in the skyrim data folder in case you think that would be my oversight.  Also i have tried the DLL from reddit and the one that was posted earlier on this forum from Neovalen

Link to comment
Share on other sites

@SSL. I once saw a "tip" from Arthmoor that Skyrim runs for some with steam disabled and firewalled. works for me (and I do have legal version I just hate steam).

 

@tallgeese3w. Do read my previous post, it'll help you generate that log file. I had the same issue because I force steam not to run. 

Link to comment
Share on other sites

Thanks to this patch I have my working screenshot profile (setup entirely through Mod Organizer) loading up at uGrids 15. I am using these settings:

 

Block1=768

Block2=512

 

My next play through might just be with uGrids 7.

 

Are you using Neo's version or sheson's or your own?

 

Also, the graphic following shows how to check how much memory should be allocated. I am running at uGrids=11, and the default of 512/256 is still more than necessary. My numbers reveal that 420/200 is all that is needed even at this demanding level.

 

Posted Image

Link to comment
Share on other sites

Are you using Neo's version or sheson's or your own?

 

Also, the graphic following shows how to check how much memory should be allocated. I am running at uGrids=11, and the default of 512/256 is still more than necessary. My numbers reveal that 420/200 is all that is needed even at this demanding level.

 

Posted Image

I am using the version found here.
Link to comment
Share on other sites

For kicks I just tried uGrids 19. Walked from Honningbrew Meadery in Whiterun all the way to Rorickstead without a crash. Framerate had stutters and only had a max of 20fps at my native resolution 2560x1080. Same settings in previous post.

 

This patch is amazing. Note that I am using hundreds and hundreds of graphical enhancing mods for my screenshot profile. The highest quality textures (4K rocks, 4K tree textures, 2K grass textures, 2K landscape). My game has never been stable until the last several months with ENBoost coming out, stable ugrids to load, and safety load. Now this comes out, replacing safety load. Safety load wouldn't let me use ugrids higher than 7 without crashing.

 

p.s. I am sure this is also dependent on your enblocal.ini memory settings. For reference, I have attached that file.

enblocal.ini

Link to comment
Share on other sites

I have tested the limits of the INI settings extensively.

 

Environment is Windows 7 with MO used to start Skyrim via SKSE (uGrids = 11 with STEP:Core 2.2.8 and full Requiem build ... see my prev posts on this). All of this was running under Stable uGrids mod and ENBoost. The latter confirmed to consume about 1.65 GB of memory from the TESV process (I assume). In the background, I am running Process Hacker and VMMap to view/kill TESV.exe as necessary. This is only testing to determine the limits of execution of the hacked skse_steam_loader.dll.

 

My savegame loads just outside the path to Solitude (I am looking towards the main Gate from the carriage-for-hire).

  • For starters, MemBlocks 1 & 2 correspond to the highest two Privet Bytes allocated to TESV.exe process (as seen using VMMap by Sysinternals) ... HINT: sort by decreasing "Committed"
  • On my box (link to my specs in sig below), MemBlock1 cannot exceed 2046 KB or the TESV process dies after a few seconds (while MemBlock2=256).
  • On my box, MemBlock1 > 512 and
  • On my box, MemBlock2 cannot exceed 256, or I CTD before getting to the main menu.
  • Reverting MemBlocks 1 & 2 to 512 & 256, respectively restores functionality (on my box)
  • Using the DEFAULT skse_steam_loader.dll, I get a ILS (infinite loading screen) after selecting "Continue" via the main menu (default MemBlock sizes confirmed to be 256 KB for BOTH)
  • Using the hacked skse_steam_loader.dll at MemBlock sizes of 256 KB (mimicking the default), results in identical ILS
  • For this particular savegame under these particular conditions and on my particular box, I need to allocate MemBlock1=360 and MemBlock2=180 in order to load a functional session. I have done no extensive testing under these minimal conditions.
I have tested 512/256 for approx. 90 minutes without any issue. I see no reason not to continue using these upper limits (as they relate TO MY BOX).

 

It would be great if others that do not have my system specs (e.g., more/less RAM/VRAM) could confirm or deny my findings as generally applicable. The following image is a map to the numbers that are in play.

 

Posted Image

UPDATE: In continuing to test out a number of independently-patched versions of skse_steam_loader.dll, I am finding that they do not all work the same way (and some not as advertized).

 

Also, in further testing the version that Neo uploaded, I have found that I actually can run Neo's version posted earlier on this thread with MemBlock settings higher than 512/256 using a different save game and mod setup (STEP:Core 2.2.8), so the patch may have save-game dependencies as well as mod dependencies ... or even Windows session dependencies in my case.

 

Anyway, do not assume that the patch you are using is working as you think or intend:

  • Launch VMMap
  • Launch Task Manager
  • Launch Skyrim (skse_loader.exe) via MO or any other method
  • Quickly select the TESV.exe process in VMMap (Ctrl+p) before the game launches
  • Load up an intensive savegame
  • Alt+Tab back to VMMap and hit F5 to refresh
  • Click on the "Committed" column header to sort descending (see above graphic)
  • The first two Address nodes should correspond to MemBlocks 1 & 2, respectively
  • Note the bit values under the "Private WS" column header (convert to KB by dividing by 1024^2)
  • The skse MemBlock INI settings should be about 10-25 KB higher than indicated under "Private WS" (assuming that this is the max allocation)
I will update the OP with this info for anyone that cares to test and report back ...
Link to comment
Share on other sites

Nearox' date=' do you mean, 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. 

skse_loader.7z

Link to comment
Share on other sites

I'm sorry to say that I'm unable to report with details of numbers, but on my system (Win 7 x64, 32GB RAM, 1GB Radeon 5750 Mobile,) using an patched .dll (already compiled from XXX's original code, shared on a Reddit thread) set with the default 512/256MB blocks, I am able to waltz through every trouble area I have seen even in a fresh new game with my current mod line-up (200+ mods, 140 plugins). These trouble areas were previously 95% consistent  in producing CTDs / freezes, and they're all gone now. Note that I am using the ENB wrapper with graphics post-processing off, and after one CTD on exiting an interior cell, found that turning on the Stable UGrids Loading SKSE plugin from Altimor made things work properly for me (not sure why that's true, though.) However, I have never touched my UGrids setting, so it's still at the default of 5.

 

I reverted back to the original .dll and followed Sheson's instructions to investigate causes of CTDs, etc. in your game (I love the console toggleborders - type "tb" hint, btw). I confirmed my crashes were due to attempts to a new block allocation when block 1 is filled.. It seems so simple now in retrospect, but I am left shaking my head at just how much time I've wasted trying to chase down CTD's / freezes thinking they were due to specific mods. It turns out the combination of mods seems to have been simply shifting the same problem around to other places in the game where the 1st allocated block becomes filled.

 

Although I've not had much time to do in-game testing, I've been able to do quite a bit of reading, which leads me to some questions for everyone reading here:

 

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,) I wonder why this is true - and which version of VC++E is the "correct" or best one to use for compiling the patched .dll?

 

2. Having used VMMap to look at my TESV.exe's VM allocations, I don't see a direct menu option for presenting the usage for any particular allocated block (or child) in graph form (over time.) I expect since the program is fully scriptable, it should be possible to save a log of the trace for an particular block(s)/child(s), but I've got a knowledge/experience gap here - can anyone confirm that this is possible?

 

3. If the answer to #2 is "yes", 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. 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?

 

#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, including NPC's not completing actions, and probably more importantly, the papyrus VM bugging out and not working properly, so scripts will fail, etc. Can anyone confirm this to be true, and even better, explain why/how this happens?

 

On #2 / #3, 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.

 

Thanks so very much to Sheson, as well as z929669, Neo and everyone else that has done testing and reporting on it. I do hope I can find some time myself and report back as well (especially as I've got a uniquely large amount of system RAM!)

 

Exciting year this is going to be.

Link to comment
Share on other sites

when you do tests with urgids just to see how far you can go... try this in console

tll - to turn of distant lod, so you get a feel how huge a ugrid 15/17/19 area really is

tb - to turn on the yellow borders

combine those 2 while looking on at map

 

Solstheim almost fits into 19x19

 

for real kicks, use tfc fly out to the edge and look across all loaded cell and not just

Link to comment
Share on other sites

I'm sorry to say that I'm unable to report with details of numbers, but on my system (Win 7 x64, 32GB RAM, 1GB Radeon 5750 Mobile,) using an patched .dll (already compiled from XXX's original code, shared on a Reddit thread) set with the default 512/256MB blocks, I am able to waltz through every trouble area I have seen even in a fresh new game with my current mod line-up (200+ mods, 140 plugins). 

 

 

Out of curiosity, from which reddit thread did you get your files?
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.