tony971 Posted January 29, 2014 Posted January 29, 2014 Wait, are the default values of this set to an actual allocation of 512 or a VMMap 512? Also, what values would be changed for a VMMap 768/512 split? I'm assuming that you would just add these lines to the SKSE.ini: [Memory]defaultHeapInitialAllocMB=768scrapHeapSizeMB=512 I just don't want to spread misinformation.i guess you have to put this lines: [memory]DefaultHeapInitialAllocMB=768 in skse.ini in order to have 512/256 in VMMAP, but i need to do some tests to be sure. In the code, skse authors have written:SafeWrite32(0x00687E87 + 2, defaultHeapInitialAllocMB);instead of:SafeWrite32(0x00687E87 + 2, kVanilla_defaultHeapInitialAllocMB + defaultHeapInitialAllocMB);, and the defaultHeapInitialAllocMB var is firstly initialized to kVanilla_defaultHeapInitialAllocMB var. So before doing some more testing, i can not be sure of the best defaultHeapInitialAllocMB settings.I think it's been empirically shown that sheson's default values work well for the average user and 768/512 (VMMap) works well for those with ugrids 9+. I'm just trying to figure out how to set these equivalents  with the SKSE implementation.
thalixte Posted January 29, 2014 Posted January 29, 2014 Wait, are the default values of this set to an actual allocation of 512 or a VMMap 512? Also, what values would be changed for a VMMap 768/512 split? I'm assuming that you would just add these lines to the SKSE.ini: [Memory]defaultHeapInitialAllocMB=768scrapHeapSizeMB=512 I just don't want to spread misinformation.i guess you have to put this lines: [Memory]DefaultHeapInitialAllocMB=768 in skse.ini in order to have 512/256 in VMMAP, but i need to do some tests to be sure. In the code, skse authors have written:SafeWrite32(0x00687E87 + 2, defaultHeapInitialAllocMB); instead of:SafeWrite32(0x00687E87 + 2, kVanilla_defaultHeapInitialAllocMB + defaultHeapInitialAllocMB); , and the defaultHeapInitialAllocMB var is firstly initialized to kVanilla_defaultHeapInitialAllocMB var. So before doing some more testing, i can not be sure of the best defaultHeapInitialAllocMB settings.I think it's been empirically shown that sheson's default values work well for the average user and 768/512 (VMMap) works well for those with ugrids 9+. I'm just trying to figure out how to set these equivalents  with the SKSE implementation.Ok, i see what you mean, so let's try this:[Memory]DefaultHeapInitialAllocMB=1024scrapHeapSizeMB=512 What seems strange to me is this comment:// in megabytes, -256 depending on bInitiallyLoadAllClips:Animation
keithinhanoi Posted January 29, 2014 Posted January 29, 2014 I've tried out the new SKSE 1.7.0 alpha build. Without any changes to skse.ini, both memory block 1 & 2 show as 256MB in VMMap and also using sheson's Memory Blocks Log plugin. Then I added these lines to the skse.ini: [Memory]DefaultHeapInitialAllocMB=256ScrapHeapSizeMB=256 Skyrim does NOT start, at all - a bit of a problem! Looking at the source code, I can see right away that there is no trap to prevent users from setting both memory blocks too low. By setting DefaultHeapInitialAllocMB to 256, that means I have set memory block 1 to zero as we would see it in VMMap. As thalixte has pointed out, there are some clues in the source code as to why the default value set for block 1 in TESV.exe is 512MB, while we only see 256MB being used in VMMap: // in megabytes, -256 depending on bInitiallyLoadAllClips:Animation <snip> _MESSAGE("default heap = %dMB (effective %dMB if not preloading animations)", defaultHeapInitialAllocMB, defaultHeapInitialAllocMB - 0x100);This must mean all 512MB is allocated if animations are preloaded, but that must not normally happen. I've never seen this bInitiallyLoadAllClips setting - is that something that would be in skyrim.ini or skyrimprefs.ini? Anyhow, continuing with my tests - Since clearly the skse.ini setting needs to be 256MB higher than what you want to see in VMMap, the next .ini settings I tried were: [Memory]DefaultHeapInitialAllocMB=768ScrapHeapSizeMB=256 In VMMap and in the Memory Blocks Log, I confirmed that the allocations appear as 512MB & 256MB. To answer tony971's question, in my last test, I changed the .ini settings to: [Memory]defaultHeapInitialAllocMB=1024scrapHeapSizeMB=512 In VMMap and the Memory Blocks Log, the block 1 & 2 allocations were 768MB & 512MB. I hope that clears things up. Some final thoughts - 1. I need to let the SKSE authors know as soon as possible about needing to prevent users from setting the two allocations under the vanilla defaults. 2. I don't see the third part of sheson's patch in the source code file I looked at, named Hooks_Memory.cpp. Maybe it's elsewhere - but I'm curious to know if they implemented that as well. Sheson has explained it as an important part of his original idea for the memory allocation fix, and it should probably still be left as part of the patch. 3. I really want to know what this bInitiallyLoadAllClips setting is, and the animation preloading that supposedly would take up the other 256MB of block 1 that we never see represented in VMMap. Is that something we want to be doing? 4. Before dropping in the new SKSE alpha build I had been doing tests with SSME in trying to figure out a problem with reproducible CTDs when loading some earlier savegames. When I removed SSME's .dll, and used the new SKSE build's memory patch - I was not able to reproduce any CTDs when loading any savegames whatsoever. This is an interesting development because absolutely nothing else was changed between the last CTD I got 20 minutes prior to my tests with the new SKSE build.
thalixte Posted January 29, 2014 Posted January 29, 2014 I've tried out the new SKSE 1.7.0 alpha build. Without any changes to skse.ini, both memory block 1 & 2 show as 256MB in VMMap and also using sheson's Memory Blocks Log plugin... ... prior to my tests with the new SKSE build.Many thks for this exhaustive report keithinhanoi (off-topic: very beautiful city, i've been there two years ago for a month).I made some researches, and it seems that the bInitiallyLoadAllClips setting is part of the animation section in skyrim.ini, but don't know what it really means.
Nearox Posted January 29, 2014 Posted January 29, 2014 It's really fantastic that the SKSE team incorporates this fix. But I am a bit concerned that having to set DefaultHeapInitialAllocMB to 768 in order to get 512 in vmmap is going to confuse a lot of end-users.Â
z929669 Posted January 29, 2014 Posted January 29, 2014 It would seem that the SKSE team has some more coding to do (and more explanatory comments within the code might be helpful :\ ), given the alpha release state, and I will test a beta when available (thanks to tony971, thalixte, and keithinhanoi for providing feedback on the alpha).I think it's been empirically shown that sheson's default values work well for the average user and 768/512 (VMMap) works well for those with ugrids 9+. I'm just trying to figure out how to set these equivalents  with the SKSE implementation.I think that it is pretty clear from my own exhaustive testing at uGrids 11 under [ STEP:Core + Requiem + kitchen sink ] that 768/512 (VMMap) is unnecessarily large an allocation. Nobody here (and to my knowledge, anywhere) has empirically shown that 768/512 is needed in any scenario. This is pure speculation and evidence would suggest otherwise. I have been running now for 30+ hours using Neo's version of sheson's patch at 512/256 ... It may *feel good* to allocate more, but why unless empirical evidence lends to doing that? Perhaps the SKSE teams version uses a different base value for DefaultHeapInitialAllocMB (MemBlock1) and has made other alterations/omissions (why without explanation and in a silo is completely beyond me ... an aloofness I have found in many developers), and 768/256 might be the new norm in terms of this version, but this is still 512/256 as mapped to sheson's version. As I said previously, 420/200 is just enough for uGrids 11 on my box (450/200 would be maybe a little 'safer'). Even at uGrids 17, 470/210 was enough for a long trial run. These values might correspond to SKSE block sizes of around 730/210 max.
Nearox Posted January 30, 2014 Posted January 30, 2014 For those who do not use a steam version' date=' i found in the source code that you need to launch skse with the forcesteamloader parameter in order for the fix to work.[/quote']What exactly is the parameter? Can't find it on google.
hellanios Posted January 30, 2014 Posted January 30, 2014 For those who do not use a steam version' date=' i found in the source code that you need to launch skse with the forcesteamloader parameter in order for the fix to work.[/quote']What exactly is the parameter? Can't find it on google.+1 for nearox's request. I don't want to use steam, it takes many recources.
elenhil Posted January 30, 2014 Posted January 30, 2014 Those having trouble with ENBoost should be certain to use the correct INI version for your GPU and VRAM capacity. As a test, abandon your standard ENB, and use only the barebones ENBoost with UsePatchSpeedhackWithoutGraphics=true. Also, playing without Steam could be introducing unknown behavior, so try with Steam configured properly as another trial run. Lastly, CTDs and ILSs will still be a problem if there are any mod issues or incompatibilities, so this is a likely possibility. Try using MO and set up a different modding profile with, say, STEP:Core as a base just to rule out this possibility (or even a vanilla setup would rule out mod problems). Your issue lies elsewhere, no doubt. Again, set up a vanilla profile under MO and be certain to use a clean Skyrim install (see the STEP Guides on the wiki). Then follow SRB's link above. A fellow user named Solmyr have pointed out OneTweak was the culprit. One needs to edit OneTweak.ini changing BWMode = 1 to BWMode = 2.
Nearox Posted January 30, 2014 Posted January 30, 2014 Found it. https://enbseries.enbdev.com/forum/viewtopic.php?p=46663#p46663 Edit: This is apparently a new feature of the SKSE 1.7x. Simplified instructions to make it work without steam: Add -forcesteamloader to the shortcut to skse_loader.exe. If using MO, you have to put -forcesteamloader in the "arguments". Thanks to talixte :)
hellanios Posted January 30, 2014 Posted January 30, 2014 Found it. https://enbseries.enbdev.com/forum/viewtopic.php?p=46663#p46663 Edit: This is apparently a new feature of the SKSE 1.7x. Simplified instructions to make it work without steam: Add -forcesteamloader to the shortcut to skse_loader.exe. If using MO, you have to put -forcesteamloader in the "arguments". Thanks to talixte :)I'm confused. How are we supposed to make it run without steam?
Nearox Posted January 31, 2014 Posted January 31, 2014 @Hellanios:Â Add -forcesteamloader to the shortcut to skse_loader.exe. If using MO, you have to put -forcesteamloader in the "arguments".
hellanios Posted January 31, 2014 Posted January 31, 2014 @Hellanios:Â Add -forcesteamloader to the shortcut to skse_loader.exe. If using MO' date=' you have to put -forcesteamloader in the "arguments".[/quote']Yeah but how? Could you provide instructions?
Nearox Posted January 31, 2014 Posted January 31, 2014 Haha sorry, I thought it was pretty clear like that :P In MO, open the menu to modify executables. Go to SKSE. In the empty field next to arguments, put -forcesteamloader. Click modify. Ola kala :)
Astakos Posted January 31, 2014 Posted January 31, 2014 ............ Ola kala :)Nice! I see your biz trip to Greece was quite "teaching"!! :)
Recommended Posts