keithinhanoi

I'm curious - did you do the "clean" save routine as the author suggests on the description page (ie., uninstall old version, load save file, save game, use save game script scalpel utilities to remove orphaned scripts, install new version, load save) or just replace and continue?

The enblocal.ini looks fine to me, and although reducing VideoMemorySizeMb would be a good idea, that value of 18432 won't cause Skyrim to crash. If running through the vanilla Skyrim launcher, without SKSE, then that rules out any influence of the Sheson Memory patch fix (because it's provided as part of SKSE if using the skse.ini settings), and you don't need Memory Blocks Log because it's only necessary to check on how the memory patch is working out in game. Just to double-check though - are you using SSME (the other implementation of the Sheson Memory patch fix) by chance? If not, then I only have one other suggestion at the moment - I do remember reading on the ENB forums an issue for one user with Skyrim crashing at startup and they resolved it by re-installing DirectX 9. ENB does hook into DX9, even if only using ENBoost, so that's something to try.

Before doing anything drastic, can I suggest sharing the contents of your enblocal.ini file, and also if you're using the SKSE implementation of the Sheson memory patch, what your skse.ini settings are and whether you have confirmed the skse.ini settings are being applied (by either using Sheson's Memory Block Log mod or checking the skse_steam_loader.log file in YOUR_BOOTDRIVE:\Users\**YOUR_USERNAME**\Documents\my games\skyrim\SKSE )

Hi & welcome here at the STEP forums, Mator! As you can probably guess, I've been super busy in RL lately - not much time for testing, but I promise I'll try my best when I can squeeze it in. I've also updated the Nexus Forums Mator Smash thread OP, including your rapid pace of updates since 0.8 earlier today!

I think it's a new... but good thing:

Somehow I missed this - so many apologies for the late response! If you have no need to raise your block 1 heap allocation over 512MB, then the only potential downside to ExpandSystemMemoryX64=true is increased instability in the form of random CTDs. But that is just based on user reports I've read. Personally, knowing everything I do about how ExpandSystemMemoryX64 actually works, I can't find any compelling reason to turn it on unless you have evidence that it reduces the change of CTDs while playing. While for me, the setting does not seem to have any effect on stuttering, FPS, or perceived smoothness of rendering, others have reported that turning it off helps reduce stuttering - so that would be a benefit of changing it to ExpandSystemMemoryX64=false. Also, keep in mind that while at v0.251, Boris removed ExpandSystemMemoryX64=false after some number of users reported problems with it being turned on, and then later brought the option back due to users asking for it, but changed the default in the included enblocal.ini with the ENB download to false. He has stated, however, that it is "good for certain things", and helps him personally with stability on his own system. So - I say try doing some tests with it on and off to compare stability, stuttering, FPS, and smoothness of rendering. Despite this, I still strongly believe the default setting should be false when a user first installs ENB, and then they can experiment with turning it on to check if there are any improvements. If not, then just leave it off.

As a disclaimer, I am not a programmer by trade, but I've looked at the Safety Load source code, and discussed it with several people who are knowledgeable in C, and what safety load tries to do is address the ILS (infinite loading screen) problem of Skyrim, which is just one aspect of what the Sheson memory patch fix takes care of. Safety Load is quite different from the Sheson memory patch fix in that it hijacks Skyrim's routine to automatically increase the heap cache memory allocation if it happens during a loading screen. When I say "hijack", I mean that it uses a sort of "brute force" method to insert itself into Skyrim's code to take over that memory allocation routine. My personal experience is that although it does work most of the time, in some cases it caused severe visual corruption to the flash-based graphic of the SkyUI mod. Even scarier is that the corruption was "baked" into subsequent game saves. The author did try to address this issue, but there was no guarantee that it was completely resolved. The Sheson patch method is far less invasive, because for its central feature, it literally just changes one byte (if you only change the block 1 allocation) before Skyrim even starts executing code, and that byte is just used to set the initial size of the "Block 1" heap cache allocation. Long story short, Sheson's memory patch supersedes Safety Load, because it addresses the problem both when it happens during a loading screen, and also when it happens while moving across exterior cell borders. Purely based on my direct experience with the SkUI, I sadly cannot recommend using Safety Load. And, really, it's not adding any more stability. I myself hardly ever experience ILS, and I use Sheson's fix and ENBoost, without Safety Load. Keep in mind that there are other reasons that ILS can occur, related to troubles loading texture / 3D geometry data. Also, from everything I've read people reporting, certain combinations of settings in ENBoost and mod load out can lead to loading screens taking much longer than expected, and I think a lot of people get impatient and assume it was an ILS instead of a TMLS (two minute loading screen ).

I still have all 4 FAtT in my load order, and actually have already finished part IV first (oops.) I've not had a chance to check it in CK, but I do have NavMesh issues at the southern end of the Dragon Bridge, and my follower(s) often get stuck at that end if I'm headed for Dragon Bridge (town). I can only assume it's FAtV IV, because I don't have anything else which modifies that area that I'm aware. Probably more important to mention is that I've run into both of the major issues that people have mentioned in the comments thread for FAtV IV, and figured out fixes for both of them. The first problem is that when you enter the mine that is part of the mod's quest, you may get a black screen after the loading screen finishes, and although you can hear your player's movements, there's no way to get our of the black screen. With the ENB preset I was using, I actually could see myself, but with a fog effect all over the screen, and things like trying to use my inventory or weapons wouldn't work properly. The fog effect was the clue I needed to figure out that the loading screen wasn't finishing upon entering the mine's first interior cell. I had two followers at the time (one vanilla and one from Interesting NPCs), and found out that if I told the followers to wait outside, most of the time I could enter without getting "stuck" in loading screen limbo. However, with the two followers still following, I could use the console coc command to enter the mine without getting stuck. From this I figured out the problem was related to the exact position of what's called the Teleport Destination coordinates that tell the game where to place you when you go from outside to inside (or vice versa). So for that one, here's the fix, to be applied to DragonmournInn.esp in TES5Edit: In FormID xx02f821, change the XTEL - Teleport Destination coordinates to X 1967.909058, Y 2335.874023, and Z 6810.511719. This changes the spot where your character appears inside the mine when you enter it from Skyrim. In Form xx02F820, change the XTEL - Teleport Destination coordinates to X -115286.546875, Y 66846.140625, and Z -10837.288086. This changes the spot where your character appears in Skyrim outside when you exit the mine. The other problem is that all in-game music stops playing for some people after going through one of the areas in the mine (which is quite large.) This has to do with some Add Music Triggers set up to play certain kinds of musical cues (for example, Reveal, Combat boss, or Reward) in certain places. For some reason, the musical cue never finishes, so your normal in-game music doesn't come back. To be honest, I have not found out why this happens, and only sometimes for some people. Anyhow, there are two fixes for this, and the first one just involves using TES5Edit to remove those Add Music Trigger records: FormIDs xx0569C6 - MUSReveal xx0569C7 - MUSCombatBoss xx0569C9 - MUSReward Or, you can leave them in, and if your in-game music stops working, open the console, and type the following: RemoveMusic MUSReveal RemoveMusic MUSCombatBoss RemoveMusic MUSReward This should make sure that any of those three music cues are cleared out. You may have to exit whatever cell you are in via fast travel and/or re-load your game save after this, but it worked for me. One last thing is that you should make sure to "clean" DragonmournInn.esp in TES5Edit, because there are a bunch of unneeded identical to Skyrim records that could cause overwrite "conflicts" with other mods. They are: 23 cell records which are identical to Skyrim.esm but had a Location Reference (XLCR) subrecord added by CK even though nothing was actually changed by DragonmournInn.esp. The CK adds the Location Reference to any cells that are edited, but even if the changes are reverted, the Location Reference stays in the mod plugin. You can read about this type of ITM here. 8 unnecessary NavMesh which are completely identical to Skyrim.esmAs for parts I to III of FAtT, I am in fact using the old REGS replacer .esp plugins, and haven't experienced any issues with those - even FatT III. I've been through 80% of Aldmeri Domain house (north of Solitude), and not experienced any CTDs as some others have reported. Perhaps I'm lucky?

Hey Tech - alt3rn1ty was actually referring to a recent post by me on the thread about Sheson's Memory Blocks Log and despite what I've said before regarding ExpandSystemMemoryX64, I now believe that the STEP ENB Guide's recommendation should be to set it to false. The reason for this is that STEP also recommends increasing the "Block 1" heap allocation in the SKSE.ini, and with help from hishtup, I have confirmed there is direct relationship between the ExpandSystemMemoryX64 setting and using Sheson's Memory Patch fix (with either implementation - SSME or SKSE) to increase the "Block 1" allocation. If ExpandSystemMemoryX64 is set to true, after the "Block 1" allocation is set above a certain number, Skyrim will crash just before the main menu. For me, this happens when "Block 1" is over 512MB, though I've read user reports of it happening closer to or just past 768MB. Before hishtup told me about his findings, the only way that I knew of to allow Skyrim to run after the "Block 1" allocation causes it to crash is to increase the "Block 2" allocation to 512MB. However, using Sheson's Memory Blocks Log and other tools, I and other people have observed Skyrim still never actually uses over 256MB for "Block 2". So that additional 256MB allocated to Block 2 is essentially wasted. Then, after I posted an explanation of how the Memory Blocks Log tool works with a bit of history regarding Sheson's Memory Patch Fix, hishtup told me that if ExpandSystemMemoryX64 is set to false then Skyrim won't crash based on the "Block 1" allocation. From this, I realized that increasing the "Block 2" allocation should not be necessary. So, I did some tests and can confirm that this is correct. With ExpandSystemMemoryX64, set to false, I can set my Block 1 allocation even over 1GB, and Skyrim doesn't crash when started, and I do not need to increase the "Block 2" allocation. In retrospect, this make complete sense, because based on the source code of the ExpandSystemMemoryX64 feature that Boris posted on the ENB forums, it uses a system memory allocation function call (MEM_TOP_DOWN) to change the allocation of memory from the "bottom" of the memory space of a program to the "top" of its memory space. The MEM_TOP_DOWN call is intended to be used for testing when converting a 32-bit application to 64-bit. I did quite a bit of research about MEM_TOP_DOWN, and although my findings were inconclusive, I never found any evidence to fully support the idea that it would allow memory to be used more efficiently. For an enlightening and interesting article on MEM_TOP_DOWN, you can check out this blog post by Bruce Dawnson, a programmer at Google (who used to work for Valve). Scroll down to the bottom of the page, and you will see my questions to him that I asked back in March last year. So I highly recommend changing the ENB Guide to suggest setting ExpandSystemMemoryX64=false in enblocal.ini as the default, and adding an explanation about its effects on the Sheson Memory Patch fix. For the explanation, my suggested edits: (9 Jan 2014, 3:52PM GMT -7: I edited my explanation of what hishtup told me, for clarity, and added some interesting, relevant and factual links.)

Although a bit off topic for this thread, I think it's really important to share something I've just learned which will hopefully help a lot of people such as yourself, afonik. hishutup has identified the reason why Skyrim crashes at startup for some people when the Block 1 allocation goes over a certain threshold (eg., over 512MB or 768MB). This crash is directly related to the use of ENBoost, when ExpandSystemMemoryX64=true in enblocal.ini. If ExpandSystemMemoryX64 is set to false, then the Block 1 allocation can be set above 512MB, even above 1024MB without Skyrim crashing at startup, and without the need to set the Block 2 allocation to 512MB. Based on hishutup's discovery, there should be no reason to set the Block 2 allocation higher than the default 256MB, as long as you have set ExpandSystemMemoryX64=false in enblocal.ini. In fact, I think for anyone using the Sheson Memory Patch fix, the advice should be to set ExpandSystemMemoryX64=false if they are also using ENBoost. I have put this information as edits into my above post, just so anyone coming across it will see that as well. I also want to note that setting ExpandSystemMemoryX64=false in enblocal.ini and setting ScrapHeapSizeMB back to the default value of 256 in skse.ini got rid of a Microsoft Visual C++ Runtime Library error I would get every time I tried to quit Skyrim. Kudos and many thanks to hishtup for solving that particular mystery!

I'd like to clarify / qualify the statements quoted by Sheson. As explained in Sheson's OP for his Skyrim Memory Patch on the ENB forums, it involves two blocks of memory (heap cache to be precise) that Skyrim reserves for use of certain kinds of cached data (mainly interior / exterior cell data.) In an unmodified TESV.exe, both blocks, which Sheson refers to Block 1 and Block 2, are initially set to be 256MB. This 512MB of memory is reserved out of the total RAM that TESV.exe has access to, and being a 32-bit Large Address Aware (LAA) executable, that is either 2GB on a 32-bit Windows system, or about 3.1GB if running on 64-bit Windows. The game's code includes a routine to automatically increase the allocated size of these two blocks of memory when they are full, and in an unmodded Skyrim, this works just fine - most of the time. But when using a good number of mods that add things to the game, the amount of the Block 1 allocation can increase rapidly, and in certain fairly reproducible and consistent situations, the routine to automatically increase the memory reserved for Block 1 fails, causing a memory exception error (ie., CTD.) So, Sheson's fix was to patch the code that sets the size of the two blocks. In his own personal testing, he found that with his load-out of mods, his actual Block 1 usage remained under 512MB, and Block 2 never hit 256MB, so his initial recommendation was as GrantSP quoted - but there was a bit else Sheson said that was missing: Well, after Sheson announced his fix, people went crazy with testing, myself included, having to depend on a utility called VMmap to monitor how much of Block 1 and 2 were being used while playing in-game. I went as far as to make a batch file that would help create VMMap snapshots at regular intervals so I could look at memory usage whenever a CTD occurred to check if it was related to Block 1 usage being maxed out. From the testing, a few things were discovered. Firstly, it was discovered that Block 2 usage could reach 256MB, without any CTDs. The next discovery was that for some mod load-outs or a higher uGrids setting, Block 1 usage did reach 512MB, and then the CTDs returned, because the same code to increase the allocated size went into effect. So, people set their Block 1 allocation even higher, to 768MB, and then even 1GB. However, when people set the Block 1 allocation higher than 512, for many of them (myself included) Skyrim would CTD while starting up. Others reported it happening with a Block 1 allocation of 768MB. Testing showed the solution to get around the CTD at startup was to allocate 512MB to Block 2. Setting Block 2 to anything between 256MB and 512MB would not work, though. Sheson does also mention the need to increase the Block 2 allocation in that same OP on the ENB Forums: EDIT: hishutup has identified the reason why Skyrim crashes for some people when the Block 1 allocation goes over a certain threshold (eg., over 512MB or 768MB). This crash is directly related to the use of ENBoost, when ExpandSystemMemoryX64=true in enblocal.ini. If ExpandSystemMemoryX64 is set to false, then the Block 1 allocation can be set above 512MB, even above 1024MB without Skyrim crashing at startup, and without the need to set the Block 2 allocation to 512MB. Interestingly, it was also found that regardless of what you allocate to it, Block 2 usage never seems go over 256MB. An important final observation is that besides the need to increase the Block 2 allocation when Block 1 is set over a certain size, there is no other directly relationship between the two allocated memory blocks. This means that when the game tries to automatically increase the allocation of Block 1, it does not use Block 2 as "overflow". By all observations and accounts, they are separate and independent. Now again keep in mind as you increase the allocations of these two blocks of memory, you are telling Skyrim to reserve it for these heap caches, and it cannot be used for any other purposes, such as cached textures and 3D geometry data. This is why Sheson recommends using his memory patch fix on a 64-bit Windows system and also using ENBoost. A 64-bit system gives Skyrim more memory to work with, and ENBoost allows some memory usage to be offloaded to your videocard's VRAM or even RAM outside of what TESV.exe can use. But, even if you are running on 32-bit Windows, and can't use ENBoost, you could still potentially benefit from Sheson's memory patch fix with relatively small increase in the Block 1 allocation. So, with all of this in mind, here is what you need to know when using Memory Blocks Log: It is the best and most trustworthy method to check that your Block 1 / Block 2 allocations have been changed as you expected.It is the best method to monitor your actual Block 1 / Block 2 usage while playing the game, so you can decide ifyou need to decrease the Block 1 allocation because you never see actual usage go near the amount of memory allocatedyou need to increase the Block 1 allocation because you saw its usage max out (and followed by a CTD)It will show you that when the Block 2 allocation is higher than 256MB, the actual usage never goes over 256MB, and no CTDs happen when it reaches 256MBMemory Blocks Log will not tell you when you need to increase the Block 2 allocation, but from my explanation above, it's pretty easy to know when you need to do it: If you have just increased your Block 1 allocation, and now Skyrim crashes while starting, then you need to increase the Block 2 allocation to 512MB. Skyrim should start up fine after that, but keep in mind you've just set aside 256MB of memory that the game can't use elsewhere. EDIT: Based on hishutup's discovery mentioned above, there should be no reason to set the Block 2 allocation higher than the default 256MB, as long as ExpandSystemMemoryX64 is set to false in enblocal.ini. Apologies for the very long post, but I hope that clears things up for people.

I used to use Earthquake. Although it seemed like fun, the Earthquake mod causes all havok objects to be moved from their placed positions, and all of that has to be recorded in your game save file. It also can make a complete mess of your player home. Oh, and every now and then, it would get stuck in earthquake mode, solved by loading my last save. But despite all that, it was pretty fun.

Is battlemap01.dds also used for the Skyrim map loading screen? Although I have HQ Skyrim map V2 installed, my map loading screen looks like crap.

I've never found any post by Boris confirming that UseSpeedHackWithoutGraphics=True (just to use the ENBoost features) will completely shut down all of the deferred rendering effects. The only thing we have is the enblocal.ini files from the ENBoost download on Nexus, and those all have the line UseDefferedRendering=false in them. From this, it has been inferred by many people that Deferred Rendering should be turned off in the .ini if you just want to use the ENBoost features. I swear I've read a post somewhere on the ENB forums that said it's best to turn off Deffered Rendering when only using the ENBoost features, because even though you see no visual difference, the Deffered Rendering code is still taking up processor cycles and therefore has some performance impact. So until you get direct confirmation from Boris that UseSpeedHackWithoutGraphics=True also turns off Deffered Rendering, I'd leave in the recommendation for the line UseDefferedRendering=false for those just wanting the ENBoost features only. However for ENBoost-only users, there's no reason to mention which effects are turned off with UseDefferedRendering=false.

@kyd462 - That's a great report there, and thanks for taking the time to share your findings. I'm wondering about what you said with comments in the .ini: "it's still not good to put comments on their own lines". I've not read that anywhere, and since my .ini files are full of lines that are comment only (starting with a semi-colon of course), I'm wondering where you got that information.

I too am running short of other suggestions. Could it be a problem with the DirectX install, and that's why VLC plays the sounds and Skyrim doesn't? This of course doesn't cover the fact that loose sound files extracted from one of the Bethesda .esm archives does work, while sound files from other mods don't.

That is excellent news, so glad to hear it. I can't tell you how many hours I spent trying to troubleshoot that Riverwood CTD area, and I would have gave up on Skyrim completely if it were not for Sheson's discovery coming about a month after I ran out of ideas. Ah yes, I should have remembered that third very common reason for the SKSE.ini heap allocation settings not working! I have added it to my post, just in case anybody else reads it upon searching for "freezing near Riverwood".

From all the reading I've done on those .ini settings, these are all you need to edit: [General] iNumHWThreads= iHWThread6= iHWThread5= iHWThread4= iHWThread3= iHWThread2= iHWThread1= iAIThread2HWThread= iAIThread1HWThread= iRenderingThread2HWThread= iRenderingThread1HWThread= All the settings with the word threaded or background are either not actually read by the game, the game does nothing with the setting, or have strange / unpredictable consequences - as kyd462 seems to have discovered with the bouncy horse cart ride at the start of the game. @kyd462 No worries and no reason to apologize! It's important that people know those two settings don't actually work any miracles. Honestly though, when I first read about them, I thought I had made a discovery that would get rid of my CTDs. The problem is that the myth has been propagated so long and widely that nearly all links in a Google, etc. search will seem to confirm they should do something helpful. But when you start reading them, it's a lot of "I heard that X setting in Skyrim.ini does blah blah!" As for the FOV being set in the .ini, I also used to have it in my .ini, but then found out that it's not guaranteed to stay at that FOV in your game if you only set it in the .ini. The best way to make sure the FOV setting stays set the way you want, do it using the console, and on your next save, it's "baked" into that playthrough. Alternatively, it can be set by any mods that let you change it through an MCM menu, such as Customizable Camera. I think we're all for exploration around here, though - so please keep letting us know about anything interesting you find!

@TigerWolfe - If those two lines I mentioned in my previous are not in skse_steam_loader.log, then the heap block memory fix setting in your skse.ini wasn't read, plain and simple. Even your test with Memory Blocks Log confirms this. So, I will go out on a limb and say that you have discovered your problem right there. A majority of the times I've seen people claiming the SKSE implementation of Sheson's memory fix doesn't work either: did not actually have skse.ini in the correct location,had not updated to SKSE 1.7.1, orhad set Windows to hide file extensions, and accidentally saved skse.ini as skse.ini.txt (as Nozzer66 points out)SKSE will look for the skse.ini file in ... Skyrim/Data/SKSE/ Alternatively, if SKSE's script files have been installed as a mod in Mod Organizer, the .ini can be kept in there, in a subfolder named SKSE, like this: I would suggest this method for storing the skse.ini because then you can edit it directly in MO - just click on the INI-files tab as seen in the above pic of the mod info window, and then choose skse.ini to edit right in that window. Until you see those two lines in skse_steam_loader.log, and verified that block 1 can go over 256, there is honestly no use in looking at other reasons for the CTDs. If your skse.ini is in the correct location but the heap size lines are still not appearing in skse_steam_loader.log let us know, and we can help troubleshoot why it's not working. Good luck! @Vulgar1 - Regarding your iMaxAllocatedMemoryBytes setting - with absolutely no personal offence meant towards you, that is a ridiculously high number, and although not necessarily CTD-inducing, will almost guaranteed lead to Papyrus stack dumping, which means at best you get massive script lag, and at worst lots of scripts won't run or finish - in other words, things won't work as intended or expected. I have just posted about this and the myth about another supposed "magical" game-fixing .ini setting in the Correct Enblocal Settings thread, here. I highly recommend reading it. (Post edited to add one more reason why the SKSE implementation of the memory patch may not work - thanks to Nozzer66 for the reminder!!)

Thanks - the Modwat.ch uploader is not working for me ATM (getting an error, as mentioned on the comments thread for the mod), and that double entry for fFlickeringLightDistance was a snapshot between .ini edits - I am doing an experiment to double check which heading it goes under. I hope to figure out what is causing the Modwat.ch uploader error soon...

It never ceases to amaze me that the myth of iPreloadSizeLimit and iMaxAllocatedMemoryBytes continues to this day. These are the modern equivalent of snake oil for Skyrim. iPreloadSizeLimit only sets how much memory is used to pre-cache the Bethesda splash video shown when you start Skyrim. It has no effect whatsoever on how much RAM is allocated to anything else in the game. TESV.exe is a 32-bit LAA (large address aware) executable, which means it is capped at 4GB of memory addressing. System and other dynamically loaded libraries (.dll) either take up 2GB on 32-bit Windows (by design, and true for all programs), or roughly 900MB on 64-bit Windows. That's where the 3.1GB memory limit that you hear about so much comes from. The iPreloadSizeLimit can't magically grab more RAM for TESV.exe to use, nor does it change how much memory of the available 3.1GB can be used for anything other than the opening video - and that is also capped at a very low amount of memory, like 32 or 64MB (can't find source ATM.) Don't believe me? First, try reading this post by Purple Lunchbox, who has been part of the SKSE team. If that's not enough, then try looking "under the hood," inside Skyrim's memory allocation itself. To do this, download and use the amazing free VMMap utility from SysInternals. This utility allows you to view exactly how a program is making use of it's entire memory address space. Fire up SKSE to launch Skyrim, and during the delay until Skyrim starts, open VMMap and select TESV.exe as the program to trace. You can save a snapshot of TESV.exe's current memory address mapping, and then quit, change iPreloadSizeLimit to something much bigger and then run Skyrim again and take another snapshot with VMMap. You should so no or hardly any change. No, there are only two thing that can change how TESV.exe uses memory and those are ENBoost, which relocates some of the cached texture / 3D mesh data that would normally get written in TESV.exe 3.1GB memory space over into available VRAM (and RAM if set up as such), and Sheson's heap memory block fix, which does actually tell TESV.exe how much memory to set aside for certain kinds of cached data (mostly to do with loading / unloading of cells as you move around).And iMaxAllocatedMemoryBytes? Directly from Bethesda's Creation Kit wiki page on the Papyrus settings in Skyrim.ini: I'm not even a programmer, and it takes 5 minutes of Googling to figure out that increasing the memory just used for the stack used by Papyrus to 2GB is absolutely preposterous. The amount of memory needed for the stack of such a simple virtual machine is minuscule. At worst, you are telling TESV.exe to reserve memory that is needed for things that actually do take up a lot of memory, like cached texture data, and that will not help at all with any stuttering. If you're really looking for mod pages that are good guides, my advice is to look here.

That area along the road between the Standing Stones and Riverwood where the wolves are waiting to attack has always been notorious for causing CTDs. The main reason is that there is an intersection of 4 worldspace cells right in the middle of the road - in a couple of places, so your system could potentially be loading and unloading data for 3 cells in rapid succession, and it fills up the allocated heap memory, which then causes a CTD when TESV.exe tries to increase the heap allocation. If you don't believe me, before walking down that road, open the console, and enter tb to toggle cell border display, and you will see a bright straight yellow dotted line wherever the edges of two cells meet. Then walk down the road and look for the meeting point of four cell corners. It should be actually in the road you are walking. Walk through there, and see if the CTD comes immediately or soon after. Anyhow, until Sheson's "discovery" of this problem and his memory patch fix for it was released, I would CTD nearly every time going through that area, not always in the exact same spot , but it was pretty much guaranteed to happen. After putting his fix in place, I've never crashed in that area again. In an earlier post, you confirmed you have the correct skse.ini setting to activate the SKSE team's implementation of the Sheson's fix: ...but, have you verified beyond any doubt that The DefaultHeapInitialAllocMB=768 setting in skse.ini has actually increases the heap memory allocation to 512MB, and 512MB allocated to heap allocation is actually enough?The best way to find out on those two checks is look at the skse_steam_loader.log file, which is located in C:\Users\<YOUR_USER_NAME>\Documents\my games\skyrim\SKSE and check for two lines near the bottom of the log output: default heap = 512MB (effective 768MB if not preloading animations) scrap heap = 256MB if you see the lines in skse_steam_loader.log then download, install and use Sheson's Memory Blocks Log mod, which is a SKSE .dll based plugin to create a log of all changes to the heap memory size while Skyrim is running. Then, with the logging activated, load up your game and run through to Riverwood to cause the CTD. Then check your MO overwrite folder - Memory Blocks Log normally writes the log output to \Skyrim\Data\skse\plugins\MemoryBlocksLog.log, so MO catches that and sticks in the overwrite folder. Scroll down to the very bottom of the MemoryBlocksLog.log file to see what the final "Block1" heap memory sizes was just before the crash. That's the last number in the left column. If it was really close or equal to 512MB, then it means you need to bump up the allocation set in SKSE.ini, to something like 896 (which sets the effective size of the heap to 640MB). Leave the Memory Blocks Log on in case you run into more crashes, so you can check if you've hit maxed out on the heap allocation and need to raise it even further. Using Memory Blocks Log, I found out that I had to set my DefaultHeapInitialAllocMB= to 896 to stop CTDs, and then I later had to increase it to 1024 after installing some higher resolution texture replacer mods. When I raised DefaultHeapInitialAllocMB= to 1024, I had to then increase ScrapHeapSizeMB= to 512, or otherwise Skyrim would crash after starting it, at the main menu.Personally I shy away from looking at my papyrus log for inspiration on why I've just had a CTD, because a majority of the time, it only sends me on a wild goose-chase. In other words, the Papryus log is not a Skyrim crash log. It's only logging script events that actually output messages to the log when it's turned on, and loads of scripts remain completely "silent". That said, when you pile on loads of mods which use scripts that add an always running "cloak" effect to the player character or other NPCs, then yes, it can really slow things down in terms of responsiveness for anything script-related, and the vanilla game already has loads of things that depend on scripts. This causes script lag, but it is highly debatable as to whether it's directly related to CTDs in every case. There are normally other factors at play, and the "script-heavy" mods are just the thing(s) that breaks the proverbial camel's back (ie., pushes past the limits of what your system can handle.)

Not out-of-left-field at all, it's the kind of outside-the-box thinking that may actually solve this! From this Microsoft Developer Network information page: it goes on to explain there are other API versions that allow for longer path lengths, but if Mod Organizer's virtual directory uses the API as described above, then it would also have the 260 character limit. I tried a quick search to verify whether MO is or isn't limited by this path length when accessing files, and couldn't find anything. Totally worth a try checking into, though.

I think you're using the files in the third test. Those are re-saved AOS bow shoot sounds, and should sound exactly the same to you if AOS has been working. The second test was the one with the goat sound(s), but note I've since removed the linked file. The point of the goat sound test was to check whether loose .wav audio files that are known to work would play in game for NomenNescio. So, I extracted the goat sounds from Skyrim - Sounds.bsa, renamed them to the file names of the three bow shoot sounds, and packed them into a "mod" archive with the sounds located in the correct folder structure to be loose file replacements for the vanilla sounds if installed in MO. In reality, I only renamed one of them correctly, and the other two had an extra character in the name. Nevertheless, NomenNescio reported that he heard a goat sound about 1/3 of the times, which is exactly what would be expected because only one of the files was named correctly. In sum, the fact that the loose .wav goat sound file played for NomenNescio shows that the problem with no sounds is specific to AOS' sounds, and loose .wav sound files taken from Skyrim - Sounds.bsa will play normally, as expected. Confirmation of the goat sound test being heard in game also rules out loose files being "overwritten" by BSA assets in MO's virtual file system, and rules out the problem being associated with all loose files. Then, the last test of putting the three AOS bow shoot sounds that I re-saved without the timecode data into the "real" Skyrim / data directory and running Skyrim directly without MO confirms that there's some interaction specific to MO and AOS' sounds that causes them not to be played. Here's a quick "matrix" of the tests so far: Vanilla BSA sounds -> Skyrim launched normally -> Sounds play AOS loose sounds -> Skyrim launched normally -> Sounds play Resaved AOS loose sounds -> Skyrim launched normally -> Sounds play Vanilla BSA sounds -> Skyrim launched in MO -> Sounds play Vanilla loose sounds -> Skyrim launched in MO -> Sounds play AOS loose sounds -> Skyrim launched in MO -> Sounds do NOT play Resaved AOS loose sounds -> Skyrim launched in MO -> Sounds do NOT play

Oh, you're welcome - that's just a few minutes of poking around, nothing compared to what you've come up with for the MCM menu. I hadn't though of adding a second sub-menu page - that would be good, because it would reduce the amount of scrolling needed. Ahhhh, I see. I didn't play with it enough to figure that out, and as you could guess from my comments, it wasn't obvious to me how that works. The thing is if two more options can be added to all the group options with the "Reveal Markers" tick-box, then it will become painful to cycle through the four because of needing to move the cursor away and back each time. Maybe take a look at how other mod's MCM menus are set up to get that toggle-cycle feature working more responsively. When I ahve a chance, I'll check in my long list of MCM menus to find out which ones work well in that respect. Oh - I also noticed a typo: "hiddened" should be "hidden".