keithinhanoi

I've updated the AOS main & update download with an improved installer which has an "Install for STEP and SR:LE users" option.

I have released an update to the AOS 2.5.1 Installer, which now features a quick and easy "Install for STEP or SR:LE" option in the first menu: That will give you the Skyrim+DG+DB variant of the main AOS.esp, and all the sounds (or just the updated sounds in the "update" installer"), and none of the patches, as previously discussed. So Neo & Tech, you can update your respective guide instructions for the AOS installation step! ;) For anyone else who is curious, I have completely revamped the weather mod / Sounds of Skyrim patch section of both the "Smart" Installer and the manual options installer, with more logical option names, better organization, much better descriptions, and a lot more warning and information menus that will be shown in certain situations to make sure the user is aware of potential / definite incompatibilities. Interestingly, it's only about 188,000 characters now! Friday is my last day of work here in Hanoi, and after that I am going into full on "preparation mode" for my move. I don't think I'll be dropping again by until the middle of next month, so see you all again then!

WoW uses the original interior rain sound that was "hidden" in Skyrim (Bethesda never implemented it), and LoRd Korn made an improved interior rain sound. It just sounds different - better or worse, depends on each person. However, when putting together the interior rain feature, I looked at how it was set up in WoW, and then expanded on the number of places where you would logically be able to hear rain in an interior space. So with AOS, you'll hear it in more places, not to mention hearing muffled thunder sounds when exterior weather is storm rain, which is really freaking cool. The AOS installer will not handle WoW automatically for you. There's a "Disable AOS interior rain sound" patch, but my personal recommendation is not to use that, and instead go into the WoW settings menu and turn the rain effects volume slider to zero. That will actually turn off the script that is used for the rain effects - which reminds me of the last thing about the AOS method, is that it just uses conditions which are built into the game instead of an extra script (AOS is and never will be a scripted mod.) The WoW script is very very "light" though. Tech is correct here - in any places where both WoW and AOS think interior rain should be heard, you are actually hearing two interior rain sounds being played simultaneously. I should double check the AOS compatibility forum sticky to see that this is mentioned. Come to think of it, it might be a cool feature in the "smart" installer to add a check for WoW, and give the user a warning message so they can decide what to do - thanks for bringing it up. As for the grindstone sound, AOS does absolutely nothing other than change its volume / reverb values. Nothing about the mechanics of when it should start or stop playing is affected. So I highly highly doubt it's caused by AOS. Have you tried testing it without AOS installed? To everyone: I have added a STEP / SR:LE option to the installer code, and am now re-working it so the menus, presentation, and descriptions are clearer, easier to follow and more logical, I think. Somehow all the descriptions for the second page of patch options in the manual installer were still the same as the smart installer, so that is really confusing right there. I feel really bad, not sure what happened, maybe I slipped and used an older revision of the XML code. Either way, it will all be fixed in an updated file soon, with the same version number because everything else remains unchanged.

Well, I'm all in favor of avoiding confusion and making things more convenient / easier to follow for people. So - just to be absolutely sure, with STEP Core / Extended, the user would only need to install the main AOS.esp for Skyrim+DG+DB with the sounds, and none of the included patches, is that correct? If yes, then I can add that option when I upload a hotfix (same version number) with the fixed installer sometime tomorrow.

That problem with options that can't be changed is due to the way Mod Organizer's internal FOMOD installer works, which is quite different from the behavior with a FOMOD in NMM. When the AOS installer sees that a particular option is not correct (in most cases because the plugin isn't detected), then I've set the selection type to "NotUsable". In NMM, if change your selection to one that has been marked as "NotUsable", you'll get a somewhat scary warning message, but it will still let you do it. In MO's internal FOMOD installer, the options marked as "NotUsable" are just greyed out completely and can be selected. I couldn't just change the selection type of the preferred option to "Recommended" and the others to "Optional", because with the logic of the selections, in many cases it would default the selection to the wrong option. By marking all the other options as "NotUsable", it forces the correct option to be selected. However, because of STEP and SR:LE and people in the middle of installing their own mods, and people merging mods before installing AOS, I really had to include the old manual installer as well. When you choose the "Manual Installation", you are basically getting the same menus that were in the AOS 2.5 installer, which means the user manually selects all their choices. But of course for STEP / SR:LE users who probably don't need any of those patches, then the manual installer requires 4 more clicks than it would need to if I were to put a third option in that initial menu of "Install for STEP / SR:LE Users" that just installs the AOS.esp for Skyrim+DG+DB and the sounds without any patches. Somebody discovered an issue with the selection logic in the smart installers SoS / SoS + weather mod patch selection menu, so I have to fix the installer anyhow, so... Do you guys want me to add a STEP / SR:LE menu choice which reduces the install to just the one menu????

Hey Neo - I got your Nexus PM, and just wanted to mention that STEP / SR:LE users should definitely NOT use the new AOS "smart" installer. Because you handle compatibility patching elsewhere, choose the Manual Installation option in the first menu, then AOS + DG + DB in the second menu, and skip through the compatibility patch menus without selecting anything. If you like, I could add a third option in the first menu of the AOS installer for STEP Core / SR:LE users which just installs the AOS + DG +DB plugin and the sounds and nothing else. Please let me know!!

Unfortunately for STEP users, they won't get to experience the "smartness" of my new installer. It should go without saying, but just in case - for STEP and SR:LE users, because compatibility patching is handled elsewhere, the new AOS "smart" installer should NOT be used. Please use the Manual Installation option, choose AOS for DG + DB, and click through the other compatibility patch menus. Same recommendation for people using STEP / SR:LE with added mods, except you need to select any compatibility patches that correspond to mods you've added beyond STEP / SR:LE.

Nah, keithWASinhanoi, please.

I have just released AOS v2.5.1. This is mainly a maintenance / bug fix release, with a number of new / updated patches, but still a highly recommended update for all current users of v2.5 (or v2.2). What is really the most exciting thing about this update for me is a completely re-worked FOMOD "Smart" Installer, which I was inspired to do after seeing what JawZ did with the installer for Immersive Citizens - AI Overhaul by Shurah. I've tried to take it one step further though, by including conditional warning menu steps when the combination of plugins detected in the user's load order may or will lead to a conflict or incompatibility resulting in AOS and/or other mods not working as expected. The update installer will also check for the presence of the AOS.esp plugin and warn the user if it's not found to avoid an incomplete install that doesn't have any of AOS' sound files (a common mistake that's come up in the comments thread numerous times.) What's best is - again using FOMOD XML conditions - I was able to keep the full manual installation method in the installer as a option that you pick in its very first menu. A win-win situation!! This does mean that the updater FOMOD XML file is a monster at about 3700 lines and roughly 200,000 characters, however. No fun when it needs updating. ;p I have tested the "smart" installer code for nearly every possible configuration both in NMM and Mod Organizer, but if you find any bug or seemingly illogical warning messages, please let me know. Just keep in mind that there are actually a lot of situations in which people may not realize there would be an incompatibility. (EDIT) PLEASE NOTE: for STEP and SR:LE users, because compatibility patching is handled elsewhere, the new AOS "smart" installer should NOT be used. Please use the Manual Installation option in the first menu, choose AOS for DG + DB in the second menu, and then click through the other compatibility patch menus without selecting anything. Same recommendation for people using STEP / SR:LE with added mods, except you need to select any compatibility patches that correspond to mods you've added beyond STEP / SR:LE. I should also again mention that my big move from here in Hanoi back to the USA is in 3 weeks, so I'm going to be very busy with that and the "aftermath" for several months - I apologize in advance for not responding so quickly. Here's the v2.5.1 changelist:

I'm sorry to say I am not. I did help him with some issues and to merge two of his mods a while back, but I've just been to busy lately to play any Skyrim at all. I do know he could use help with creating landscape / tree LOD for the areas of his mods that lie outside the game's border.

Well, the only reason why anyone would need to set DefaultHeapInitialAllocMB higher than 768 is when the actual "Block 1" heap usage in-game reaches 512MB, and you get a CTD. That's why Sheson's Memory Block Log tool is so very useful. The recommended value to start with for DefaultHeapInitialAllocMB is 768, but what you actually need to set it too depends heavily on the kinds of mods you have in your load order, and whether you've set uGrids above the default of 5. In truth, a lot of people probably don't need to set DefaultHeapInitialAllocMB at 768, because if they used the Memory Block Log tool they would find the actual "Block 1" heap usage never even gets close to 512MB. However, for people that have a lot of mods adding spawned creatures, NPCs, and other exterior worldspace elements - like myself - setting DefaultHeapInitialAllocMB to 768 is not enough. In my current play-though (on hold while I get ready to move back to the USA), I have had to bump up my DefaultHeapInitialAllocMB value no less than 8 times. What happened was I entered an area of the exterior worldspace where I had not gone before which pushed the "Block 1" heap usage to the same as I had allocated, and *boom*, I got a CTD. So, at this point, my DefaultHeapInitialAllocMB is set to 992, and if I turned on ExpandSystemMemoryX64, Skyrim would insta-crash on startup, unless I set ScrapHeapSizeMB to 256, of course. Anyhow, in your case, it's pretty clear that you probably don't need to set DefaultHeapInitialAllocMB any higher than 768, but if you ever experience a crash that keeps happening in a certain area of the exterior worldspace, I'd recommend using the Memory Block Log tool to check if your "Block 1" heap usage is hitting the allocated limit. You have the "luxury" of being able to choose if you want to set ExpandSystemMemoryX64 to true or false. If things are stable and working fine, then why change anything?

I'm sorry that it's such a long post, but it really has to be read to the end: So, with your settings, I would expect no CTDs. Keeping ScrapHeapSizeMB=256 and ExpandSystemMemoryX64=true, if you increase your DefaultHeapInitialAllocMB to 1024 ("effective" 768MB in-game), there's a good chance you will see Skyrim crash as I and other have. If no crash, try going higher, all the way up to the maximum - DefaultHeapInitialAllocMB=1280 ("effective" 1024MB in-game), and it's almost guaranteed that Skyrim will crash. When you've found a value for DefaultHeapInitialAllocMB that causes Skyrim to crash, then set ScrapHeapSizeMB=512, and Skyrim should start and work fine (I was running like this for quite some time, actually). After that, set ScrapHeapSizeMB back to 256, and set ExpandSystemMemoryX64=false. Skyrim should also work fine, but it's just gained 256MB in its memory space to make use of. Here's something of a chart to make it clearer: ExpandSystemMemoryX64=true DefaultHeapInitialAllocMB=768 ScrapHeapSizeMB=256 Result --> No CTD / Stable ExpandSystemMemoryX64=true DefaultHeapInitialAllocMB=1024 (or even > 768) ScrapHeapSizeMB=256 Result --> CTD on startup for some users ExpandSystemMemoryX64=true DefaultHeapInitialAllocMB=1280 (or even > 1024) ScrapHeapSizeMB=256 Result --> CTD for most everyone ExpandSystemMemoryX64=true DefaultHeapInitialAllocMB=769 or higher ScrapHeapSizeMB=512 Result --> No CTD on startup / Mostly stable but 256MB of memory wasted ExpandSystemMemoryX64=false DefaultHeapInitialAllocMB=769 or higher ScrapHeapSizeMB=256 Result --> No CTD / Stable and you didn't waste 256MB of memory I hope that helps explain it better. I really really wish SKSE hadn't decided to make it so the DefaultHeapInitialAllocMB value has to be 256 higher than what you want in-game. It leads to so much confusion... If you try these tests and have different results, by all means - please let us know. It's really important to know if there are some exceptions to this.

Just to clarify here - The "Sheson Memory Patch 3.0" does not change the way TESV.exe (Skyrim's app) allocates memory in its 4GB memory space. Those two "blocks" of heap memory were already programmed by Bethesda to be created when TESV.exe is started. By default, TESV.exe allocates 256MB of memory to both of those blocks. The problem is that when the "Block 1" / Default Heap usage hits 256MB, the routine the programmers used to automatically increase the size of the "Block 1" / Default Heap is flawed, and causes a memory exception error, leading to the instant CTD. This almost always happens as the player is crossing the invisible border of an exterior worldspace cell. Sheson pinpointed the exact two bytes in the TESV.exe binary code which tell the program the default amount memory to allocate to those two blocks of heap memory, and the SKSE team incorporated Sheson's method of writing new values to those two bytes of the program code during SKSE initialization process, before TESV.exe actually starts running. So, this allows the user to manually increase the default "Block 1" / Default Heap allocation, and as a result avoids the problem of the memory exception error, because if you set the default allocation higher than the actual highest memory usage of the "Block 1" heap, then the flawed routine to increase the heap's size never has to be run, and you don't get CTDs for that reason. Sheson also included access to adjust another block of heap memory, called "Block 2", because some people found that when the "Block 1" heap allocation was set to 768MB or higher, then Skyrim would crash upon startup. The workaround for this was to set the initial "Block 2" heap (called the "Scrap Heap" in the SKSE.ini) to 512MB instead of its default 256MB. However, with the great help of Hishtup, I figured out that the "Block 2" scrap heap only needs to be raised to 512MB when ExpandSystemMemoryX64 is set to true. If ExpandSystemMemoryX64 is set to false, then the "Block 1" / Default heap can be set higher than 768MB without the need to set the "Block 2" scrap heap to 512MB. Also very important - in my extensive testing using a program that allows you to track the exact usage of these two blocks of heap memory, I discovered that the "Block 2" scrap heap" never uses more than 256MB, even when you set it to 512MB. However, when its set to 512MB, that extra 256MB of allocated memory is "locked" out, and TESV.exe can't use it for any purpose. The last thing in my testing that I found is that setting ExpandSystemMemoryX64 to true did not significantly increase available free memory in TESV.exe as compared to it being set to false. And it especially doesn't outweigh the loss of 256MB of memory if you have to set the "Block 2" scrap heap to 512MB because you need to set the "Block 1" default heap over 768MB. Again - the benefits of setting ExpandSystemMemoryX64 to true do not outweigh the downside of having to set the "Block 2" scrap heap up to 512MB to avoid Skyrim crashing because "Block 1" is set to 768MB or higher. Because of all of that, the STEP Guide recommends setting ExpandSystemMemoryX64 to false. However, I think the wording of the recommendation is a little unclear because of the way the DefaultHeapInitialAllocMB setting works in SKSE.ini -- Every time I said "over 768MB" for the "Block 1" / Default Heap allocation above, I am talking about the "effective" allocation, which is what TESV.exe actually allocates, as would be seen in either the .log file the SKSE produces or by using Sheson's Memory Block Log SKSE plugin. So, this translates to DefaultHeapInitialAllocMB=1024 in the SKSE.ini file. Remember that the value in the SKSE.ini file must be 256 above the number of MB you want the program to actually use, again which can be verified using Sheson's Memory Block Log SKSE plugin. Therefore, if someone says they are running with DefaultHeapInitialAllocMB=768, and ExpandSystemMemoryX64=true, and have no problems with CTDs or instability, I am NOT surprised at all. The problems can start as soon as you find that you need to set DefaultHeapInitialAllocMB to something over 768 in your SKSE.ini file. For example, with ExpandSystemMemoryX64 set to true, and I set DefaultHeapInitialAllocMB to 800 (which equates to an "effective" allocation of 544MB), Skyrim will crash upon startup, unless I set ScrapHeapSizeMB=512 ("Block 2"), and you now know by doing this, it means I am wasting 256MB of memory. So I would want to set ExpandSystemMemoryX64=false in enblocal.ini, and set ScrapHeapSizeMB=256 in SKSE.ini, and I'm not wasting 256MB of memory and Skyrim doesn't crash. Boris is right to say that the code he uses to change memory allocation when ExpandSystemMemoryX64 is set to true does not cause bug on its own, but rather what is happen is some kind of interaction between TESV.exe allocation of the two heap memory blocks and his routine under certain circumstances. The STEP recommendations here are not something pulled out of the dark randomly. Quite a lot of time has been spent and investigation into the reasons for the CTDs, and my explanation above has been confirmed by enough people by now that it's consistent and repeatable. If in doubt, I recommend you try some tests yourself - in the name of science!

Hey, no worries. I'm just glad I was able to pinpoint the reason in just a few posts. I think you can go back to using DynDOLOD now to make up for the loss of uGrids at 7. DynDOLOD is much more memory efficient anyhow! Happy Skyrim-ing!

Although I suppose it was worth testing out of curiosity, setting DisableDriverMemoryManager to true is not a good idea. It's even more of a hack than other elements of ENB, and was only added to help out AMD users a while back. The NVidia drivers have been perfectly fine for many versions now. Really at step 2, the next thing to try was to increase DefaultHeapInitialAllocMB even higher, because the actual usage hit that limit, and that's what causes a CTD. The whole point of setting DefaultHeapInitialAllocMB is to make sure the usage never reaches the initial allocation, because Skyrim's routine for allocating more memory for the Block 1 heap is flawed and causes an exception error (aka, CTD). So, you simply need to raise DefaultHeapInitialAllocMB again. Try setting it to 1024, but keep ReservedMemorySizeMb set to 256, and try test both with EnableCompression set to true and then false. After a quick look through your mod list, there's only one thing I can think of which would lead to such high Block 1 heap usage right from the start of the game: uGridsToLoad in Skyrim.ini set higher than 5. The reason why the uGridsToLoad setting is directly related to the Block 1 heap is because that heap is used to cache data related to all cells around the player, at the radius set by the uGridsToLoad setting. Raise uGridsToLoad above the default value of 5, and a lot more data needs to be cached in the Block 1 heap. In fact, if you use the tb console command to toggle cell borders you will see yellow lines showing the edge of each cell. With uGridsToLoad at the default of 5, the game caches data for the cell you are in, and 2 more cells in every direction, which makes a grid that is 25 cells (5 x 5). Now raise uGrids to 7 and you've almost doubled the number of cells (49), and the data to be cached could even be more than doubled in any particular spot because some cells have more data to cache than others. Set uGrids to 9 and it means 81 cells have to be cached. When you cross one of those borders, data for an entire row of cells needs to "flushed" (marked as available to use) and then data for a new row of cells is cached into the Block 1 heap. Because of this, you will almost always see the Block 1 heap related CTD happen when you are crossing a cell border. One notorious spot is on the road out of Riverwood heading west, on the way to the standing stones. There's a spot right in the middle of the road where you can cross diagonally past the corner of a cell, which forces the flush of data for 9 cells (2 sides of the 5 x 5 grid) and loading of "new" data for another 9 cells. Before the Sheson memory patch fix, people with a significant number of mods that add spawns and other element would pretty much always crash at that spot. So yeah, a higher uGridsToLoad setting is the first thing that comes to mind when I see a high Block 1 heap usage so soon after starting a new game / loading a save.