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.

You Memory Blocks Log from just outside Helgen shows Block 1 usage at 640 right before the crash. DefaultHeapInitialAllocMB was set to 896 so, again, like I said, there no surprise about the crash. That's what the memory patch fix helps with. You just need to bump up the DefaultHeapInitialAllocMB value until Memory Blocks Log shows that actual Block 1 usage is under the DefaultHeapInitialAllocMB/Block 1 allocation, which is why I suggested 976, so the effective allocation is 720 - a little higher than the highest value you saw in your log. Before talking about other culprits, let's make sure TESV.exe isn't choking due to lack of available memory resources. Now when you increase the DefaultHeapInitialAllocMB/Block 1 allocation, that is memory that is "locked" for use, but it's part of the roughly 3.1GB memory space that TESV.exe has to work with. So going from the default 256MB to the 720MB I'm suggesting, TESV.exe is in effect "losing" 464MB that it would normally have to play with. Another part of the TESV.exe's memory space is the mirror of the buffered texture / geometry (3D model) data of your video card's VRAM. Boris has never said it directly, but as I understand it, whatever value you use for ReservedMemorySizeMb in the enblocal.ini file will affect video buffer memory allocated in TESV.exe. So, with that in mind, my suggestion is to try lowering your ReservedMemorySizeMb value. Start with 256 as Phinix suggests, and then if that doesn't work, try 128, or even 64. 64 is what I use in my setup, though admittedly I don't mind micro stuttering as much as others do. The other enblocal.ini setting you could try toggling is EnableCompression to false. Just keep in mind that it results in ENBoost's cached textures taking up more space in VRAM, so it would ideally go hand in hand with a lower ReservedMemorySizeMb value. I have EnableCompression set to false myself, which helps reduce stutter, but then I have a 4GB video card. It shouldn't make any difference in terms of crashes, but I remember reading people reporting that turning off the ENBoost compression helped reduce the number of crashes they saw. If those suggestions don't help any, then by all means set it back the way you had, and then I'll share a "secret weapon" with you that saved my bacon a few times.

DefaultHeapInitialAllocMB can be set to any value. For example, I've had to bump my value up a number of times over my current playthrough (>500 hours) and it's been set to 992 (effective 736MB for the primary heap) for some months now. In your case, the crashes that occur with DefaultHeapInitialAllocMB set to either 768 or 896 are totally predictable, since when you set DefaultHeapInitialAllocMB to 1024, Memory Block Log shows the "block 1" heap goes up to 712MB. So, you could try going with DefaultHeapInitialAllocMB=976 (720 + 256) and see if that gets the save game to load. You mentioned seting expandsystemmemoryX64 to false. What are the rest of your enblocal.ini settings? It's probably important to point out that crashing when opening menus or a loading a save game may not be solely caused by the DefaultHeapInitialAllocMB setting.

Yeah, Mator PM'ed me to see if I could help with testing. I really wish I could, but with my big move back to the US in five weeks, I simply don't have the time. The only thing I've alloted time to is one last update to AOS, including any new relevant UP v2.1.3 fixes (now released out of beta,) but when I saw the USLEEP announcement, it caught my attention as I'm sure AOS users will be asking about it soon enough. I'm half glad I won't be around to see the bazillion "Is your mod compatible with USLEEP!?!!!" on every Nexus mod comment thread. -------------- Another thing that worries me - and I've voiced my concerns - is the recommendation of switching from the separate UP patch plugins to the new unified one even on an in-progress game. Obviously the UP team's goal will be for that to work in the sandbox of a load order which only consists of Skyrim LE + the UP plugins. Where things can get hairy is load orders with "sensitive" quest-adding mods that don't seem to respond well to their plugins' load order slots being shifted. I've seen things get messed up in my game after adding a new plugin into my load order of an in-progress game, and the problems were due to a plugin lower / later in the load order being shifted one slot down in the LO. The mod's scripts no longer saw their corresponding data stored in my save file, because the load order index of the reference ID no longer matched. This was despite that mod never being disabled / removed from my load order. Because of that experience, I now go through great pains to make sure all the plugins in my load order never change their index position. I know it's well outside the UP team's concerns, but when loading an old save based on the separate UP plugins, certainly the effects of changes further down one's load order caused by the deletion of up to three of the UP plugins is something to consider with caution.

It's an interesting request, trying to kill two birds with one stone here. However, most authors who have been using Game.GetFormFromFile or Game.GetModByName to recognize and act on the presence of other mods did not expect it to become a problem. It became common practice before the merge plugin script started to exist. So it does not seem fair at all to even imply that mod authors have been doing the wrong thing by using those function calls. Nevertheless, those calls do depend on other mod authors not changing the names of their mods' plugins, but we've all seen instances of this happening over and over again. So - how to deal with that, yes? It has to be some kind of call that can identify a uniquely identified element in another plugin without referring to the plugin's name. I'm a Papyrus noob, but I see things like Quest.GetQuest() might work, if you don't mind making SKSE as prerequisite. I know USKP adds some new uniquely named quests, so maybe check into that? Another crazy idea: Keep Game.GetFormFromFile or Game.GetModByName (whichever you're using), but have the script make use of an external text file which lists the names of other mod plugins that are checked for. Bring those names in as variable strings and then use them for the function calls. The mod user could then edit the text file's line with USLEEP.esp to change it to Unofficial Skyrim Patch.esp -- of course this would depend on the ability of scripts to read from external text files, and I don't know if that's possible. Last thought on this is to just add USLEEP.esp to the script in addition to checking for Unofficial Skyrim Patch.esp so both cases are covered. This solution, of course, won't help those who are trying to use the merge plugins script. I consider myself fully proficient in TES5Edit, have done beta testing of matortheeternal's merge plugin script, and have made such changes and other changes to specific papyrus scripts. Based on this experience, I would say that changes the name of a referenced plugin in a papyrus script is no trivial matter. Many mods refer to other plugins in more than one script, and you need to be aware of the dependencies of the scripts you want to recompile in order to do it correctly. It's pretty easy to screw things up in a way that won't be noticed until issues have been baked into your save file, especially if you're coming in without any background knowledge of papyrus whatsoever. These 18 or so posts originally came from this topic. The posts were move due to being off topic, sorry everyone. -hish

Green Man Gaming is on the last day of it's big summer sale - the "Encore", combining all of the last week of daily themed deals. I already got Witcher 3 for $29.99 (on the "VIP" page - only for past GMG purchasers,) and Skyrim LE can be had for $9.99. Also, Elder Scrolls Online (unlimited): 75% off, at $14.99 - enticing, but I just don't have the time...

Well, as long as the unified plugin doesn't have any scripts that refers to itself by name, the easy fix is for the user to simply rename it themselves. But that doesn't help if you then have a mix of old mods and new mods that use USLEEP.esp (or whatever the new plugin will be named) as a master. In that case, you need to do a bit of "fancy footwork" in TES5Edit with both USKP & USLEEP loaded, and manually edit the entry in the masters list of the old mod's plugin in question. Voila - problem solved. Even better would be to open the plugin in a hex editor and just change the in the header for USKP.esp to USLEEP.esp, and then open it in TES5Edit to correctly sort masters (assuming that USLEEP.esp will be placed after all of the DLC .esm plugins.) But then, I know how to use TES5Edit, which is why it seems like a small annoyance to me.

I appreciate the offer, but looking at the XML code that you (& Ren?) did for shurah, I'll have no problem reworking the AOS installer code. Knowing that all the File Installs have to be flagDependency based and moved down to the conditionalFileInstalls is probably key to getting it to work. When you say an "external plugin" is used by MO, you're referring to MO's "built-in" FOMOD installer, right? That's the default, and the "smart" installer aspect of your FOMOD code worked perfectly for me. It's just that I swear I tried some very simple tests and couldn't get the auto-select feature to work - but that was with MO 1.2.18 and earlier. My main concern is that if I rebuild the AOS installer, it may not work for some MO users - obviously I would have to include a warning that the internal FOMOD installer needs to be used, but it's a can of worms if it won't work in the built-in FOMOD Installer for users of MO 1.2.x. Either way - thanks a bunch for the reply! (and apologies to everyone else for steering things off-topic a little, though I will bring it back on topic by saying the all-in-one "smart" installer just makes ICAIO even more awesome)

It's really important to point out the .esp plugin edits of the majority of variants of this mod can be merged into your Bashed Patch in Wrye Bash, which means this fix can be added to an already in-progress game, as it effectively wouldn't disrupt your load order (assuming you use a Bashed Patch, of course!) EDIT: I use skysan4298's Transparent and refracting Glass Equipment mod, but not the aMidianBorn glass armor variations myself, and it seems skysan4298's mesh/texture combo won't work Glass Helmet Fix.

It's a shame that not enough mod authors make use of the NavCut collision markers. I learned about their use last September when SilentResident released Skyrim Better Roads v1.3. Anyone interested to read the related comment posts about NavCut collision markers should start with this announcement post by SilentResident. She says that Arthmoor is quite knowledgeable in how to set them up, and helped her out. I also know Manny GT is a fan of NavCut collision markers, as mentioned in this 2012 post by him. As for JK's city / town overhaul mods - I did mention NavCut collision markers to JKrojmal last year and he said he thought they were a "godsend" so as far as I know he's been using them in his mods as much as possible. I also mentioned using them to Blue Piano Two. As for ETaC, I would have to assume that MissJennaBee is aware of how to use NavCut collision markers, but since she moves things around and changes the landscape of towns so much, there has to changes to the NavMesh in the affected areas. Since I'm on the topic of NavMesh edits - please everyone remember that if you use TES5Edit to remove NavMesh records from a plugin which has a NAVI record (Navigation Mesh Info Map - always form ID 00012FB4), then you also need to delete the NAVI record and load that plugin in CK and then save it to create an updated NAVI record. The NAVI record is a special kind of record with NavMesh and Teleport Door data, and all the copies of that record that exist in your load order get merged by Skyrim when it starts up. If the NAVI record is not updated in CK after making NavMesh / Teleport Door edits using TES5Edit, then NPC pathing and going through doors may be glitched or not work at all. This is also true if you use Matortheeternal's xEdit Merge Plugin script to merge any set of plugin which has more than one plugin with a NAVI record. ----------- Also - I have a question about the new FOMOD installer for ICAIO (v2.0.5b): Does the FOMOD XML code that detects plugins in the user's load order work with versions of Mod Organizer prior to v1.3.x? I tried some experiments using the <fileDependency> tags a while ago, and could never get it to work correctly, so I decided not to use it in the Audio Overhaul for Skyrim installer. I'm really busy preparing for my move back to the US, but I'd like to release an update to AOS in the next 3-4 weeks, and it would be great if I could make use the of <fileDependency> tags to check the presence of plugins to make the installer even more automated. Maybe you know, shurah, or GrantSP or JawZ could confirm whether that works with older versions of MO?

To add to what Double-You said, there is a script included with TES5Edit that will list all records in a plugin which reference another specific (master) plugin. The name of the script is List records referencing specific plugin. In the left-hand pane of TES5Edit, right-click on the name of the plugin that you want to remove a master from, and select Apply Script in the pop-up contextual menu. Next, click the pop-up list button next to "Script:" to see the list of available scripts, and select List records referencing specific plugin. Then, click the [OK] button. You will get a small dialogue box asking you to enter the Hexidecimal load order of references to search for. What you need to sype here is the load order prefix for the master plugin that you want to remove. For example, if you want to remove Dawnguard as a master to the plugin, look for the value in square brackets next to the name over in the left-hand pane of TES5Edit. In the case of using the unofficial patches, you should see [03] Dawnguard.esm, which means you want to type 03 in the scripts dialogue box. Then click [OK] and TES5Edit's messages tab will output a list of any references to the plugin corresponding to the hexidecimal load order value that are are found in the plugin you ran the script on. Each reference will list the EditorID (if there is one) and then the FormID for the record in which the master reference was found. You just need to copy that FormID and paste it into the FormID search text box, located in the upper-left corner of TES5Edit's main window, and hit return to go directly to view that record. It may start off showing you an instance of the record in an earlier-loading plugin, so over in the right-hand pane, find the column for the plugin you are working on removing masters from, and then right-click on the name of that plugin at the top of the column, and choose Jump to so that you select the override for that FormID in the plugin that you are working on. Alternatively, you can manually search through the plugin you're working on to find each of the listed records in the messages tab. Sorry if it sounds a bit complicated, but it is far far easier to find references to a master that you want to remove by using this script.