• As mentioned above, we have about 1200 mods installed already
• The current load order index runs up to EF, so we will need to find and compact more mods to ESL during this round of work. There are a number of candidate mods in the current loadout that require varying degrees of modification to accept an ESL flag without degraded function.
• All of our conflict resolution edits are stored in ten holding files at the end of the load order. This build does not use Wrye Bash or similar automated conflict resolution tools.
• Except for cases with BSA asset conflicts, this build generally doesn't use any kind of load order management; it relies on override records and asset load management to control conflicts.
• The build contains several cosmetic mods that are currently partially installed - their assets are loaded but their plugins are inactive. This is because the mods were discovered just after I locked the configuration for my last playthrough and they'll be some of the first things we load.
• I have a waiting list of several hundred mods for integration, of which we will not be covering all or even most of during this round of 'hobby time.' 
• This build follows a "zero trust" philosophy where all ITMs and deletions are assumed to be errors unless the mod contains a clear and valid explanation for their presence. 

 

I have a few focus areas to work on here, but broadly speaking they fall into five categories:

 

1. Adjust, augment, or replace existing mods that caused problems in the last playthrough (or that are on the waiting list for attention) - for example, switch to the new modular version of Skyrim at War; change the faction values for BD Hoodies to fix the oversized SOS parts, patch Skyrim's Shrouded Secret for better world integration and to move the activator switch to the Alternate Perspective starting cell.
2. Improve and expand the locations in the game
3. Improve and expand the diversity of characters, both in terms of appearance and outfits
4. Incorporate more quest content
5. Update existing mods to latest versions and track (don't necessarily install right away) new related mods

The biggest technical issue my current playthrough has is that it can't display all its Mod Configuration Menus at the same time. SkyUI started its life as a Legendary Edition mod and probably never anticipated needing more than 128 MCMs. However, my current build has over 160, which means that key opportunities to set up aspects of the game get lost when starting, and they get lost somewhat randomly. In the last game, Bondage Furniture World got missed and this caused some unexpected problems early in the game. 

 

The solution for this is a patch that's available here on the Lab: SkyUI Resort. This mod patches SkyUI to allow significantly more MCMs. In theory, the new maximum is 1143, though in practice the amount will be lower because of how the patch displays the entries.

 

This one is easy to install. It's a straight patch the overrides SkyUI, so all we have to do is activate the mod in MO2. In theory I could leave it right where it is, but to keep things tidy I'll prioritize it to load just after SkyUI itself.

 

 

Loading up a new game, we can see that the new sub-menus have loaded up as intended.

 

This one is a little bit of an oddball. When BDS rolled to its current (V3) version, the name of the plugin changed. So right now I have the legacy plugin running with the new assets. This seemed to be working fine, but I'm sure I'm losing some functionality doing it this way. 

 

First things first, we need to see if any of my override mods depend on the old plugin. As you can see below, none of my private patches are impacted, but several other patches are.

 

 

These patches are from Campfire, Ambient Slavery, and in the the case of the two middle ones, Better Dynamic Snow itself. First things first we'll check these mods to see if they have native patches. I know AS doesn't because I made the patch as part of my Mod Cleanup Case Study, but the other one might have something. A quick review of the Campfire BDS patch reveal that neither have been updated in some time, so we'll just privately patch these.

 

What we're going to do is activate the new plugin and put it right after the old one. Then we'll go in and remap the conflicted form IDs in them to the ones in the new file. I suspect we can just straight up disable the Snowy Farmhouse patch, so let's check that first.

 

 

So in this case, we do have some new data - the updated snowy farmhouse model. It also has new LODs further down. Under other circumstances, I'd create override records and merge the changes of the two at that level, but here our goal is to strip out the original master reference, so we need to make the changes in the patch itself. What we're going to do is take each conflicted record and drag the new dynamic material data into the patch. This will ensure they have not just the new models but also the new snow textures.

 

 

Once all the records are patched, we'll use the "clean masters" function in xEdit to remove the dependency on the old version of BDS.

 

 

Now, the campfire BDS patch is an interesting one. Reviewing this reveals bad form IDs on the directional material data, so this patch was actually broken before.

 

 

Looking up the correct reference, it turns out that the new version of BDS directly patches the vanilla material record, so we can just remove the Campfire patch entirely.

 

That leaves Kaidan and AS. Kaidan edits a lot of records, but it appears that all of its changes involve subbing in custom records that are folded directly into the vanilla versions in BDS V3. Moreover, the patch conflicts Majestic Mountains in a number of places, replacing that mod's custom meshes with the vanilla versions. Just like the Campfire patch, we're going to remove this one entirely. 

 

For now I'll store both of these files in my "not used" MO2 separator in case I need to refer back to them later.

 

 

AS is the final dependency we need to address. A look at its four records reveals they are all deprecated, so I'm going to deactivate this patch and also notify the author that it is not needed for the current version.

 

In the case of AS, the patches are not in a separate MO2 line-item, so we are going to use a different method to remove this file. After opening the information menu, we'll go to the "optional ESPs" tab and move AS-BDS Patch to the optional column. This will remove the file from the data folder and put it in an "optional" folder instead, reclaiming a file handle slot and unloading the plugin.

 

 

Finally, we can disable the old BDS plugin. We'll use the same method (optional ESP screen) and keep the file in case we need it to debug other old BDS-dependent mods. As a footnote here, it's worth noting that hiding the old BDS plugin revealed another missing master situation with Majestic Mountains. The resolution path was the same as for the Snowy Farmhouse patch, though it underscores the need to keep the original plugin in the optional folder. If MM gets updated without removing the BDS V2 dependency, I may need the original file to facilitate patching.

 

Now that all the old references have been updated to match the new plugin, there's just one bit of business to be done here. While I was going through the new BDS plugin, I observed that its structure might be a candidate for ESL flagging. BDS only has 596 records in it, and many of them are now vanilla overrides. Further review reveals that BDS only contains 27 native records, most of which are self-referential materials and a few static replacers. 

 

 

This makes BDS a low-risk ESL flagging candidate on its own, where the only potential issue could be future BDS patches that make use of the new statics. The potential issue here is that a future patch may introduce a null baseform error that would cause CTD; however, these should be caught during routing error checking and can be easily corrected. Based on this, we'll go ahead and compact this file then add an ESL flag.

 

Going into the game, we can see that something isn't right here. Better Dynamic Snow 3.x uses a different technical approach compared to version 2, so when the leftover edits from version 2 got cleaned out in this update, it unmasked an incompatibility with BDS 3.x. To address this problem, I would have to either roll back to version 2.11 (which I upgraded from to get other stuff working) or remove the Parallax Fix and, therefore, all mods that depend on it. BDS' main competitor, Simplicity of Snow, does support parallax and, as you can see from the second image, works with my setup. So after all that work on BDS, I dumped it and installed Simplicity instead ?

 

So that's annoying, but it's also the kind of thing that sometimes happens. 

 

 

Since this one was partially installed, it's already had all its asset load order stuff taken care of. What we do need to do however is go through the plugin to make sure it is clean and unconflicted, then do a quick walkaround in game to make sure there aren't any visual issues.

 

Right away we can see that this mod is using a load order slot, so we need to assess whether or not we can put an ESL flag on it. Looking at the file header, we can see that it only contains 38 records, so clearly we'll need to compact this for ESL.

 

 

Running through the usual cleaning and conflict resolution checks we find the following:

 

• No deletions, 1 ITM, no errors.
• Three landscape edits in the Whiterun worldspace, none of which directly conflict other mods
• A wild edit to one Wind District top-level cell record

 

After removing the ITM and the wild edit, I compacted the mod and added an ESL flag. From an integration point of view, this looks like a five minute job. We'll take a little stroll through Whiterun, but I'm not expecting any issues. 

 

 

The city is looking pretty good! I didn't observe any overlapping items or messed up landscaping, so we can mark this one off as successfully installed.

 

Whoops! Maybe  spoke too soon. This tree is actually vanilla, but it's getting in the way of this ZDD static. There's two pieces of terrain intrusion here, along with a little big of landscape conflict. 

 

010012BA is the scrubby bush that's directly blocking the ZDD static. We'll just disable that in xEdit.

010012C0 just needs to be moved a bit to the left. We'll do that in the CK.

 

The author of ZDD was nice enough to extend the vertical supports below the level of the punishment platform, so it looks fine when see from the street. Based on that, I'm going to leave the little landscape intrusion alone.

 

 

If you've read my previous blogs about mod cleanup, you know the drill from here - we start out by making a working file that only contains the shrub we want to me. We'll also add ZDD as a master to it. Then we bring it up in the CK and move that sword fern just a little bit out of the way.

 

 

With that done, we just need to go back into xEdit and forward the edited plant to my worldspace deconfliction file. The end result looks like this:

 

 

The rest of the tour revealed a few more plants from Update.esm that were intruding into mod-added statics, which I disabled in xEdit.

This is another full-size plugin with only a small number of records. I wonder sometimes if the widely misunderstood limitation about top-level cell records is causing folks to omit the ESL flag even though this mod could clearly take it. Either way, I'll add it myself before I'm done.

 

Initial checking reveals no errors and only minimal dirty edits (2 ITMs). As the theme of the mod suggests, all the worldspace edits are in the Windhelm World itself and in the surrounding exterior cells. There are no navmesh or landscape edits that require manual examination.

 

The mod overwrites two snow shaders, which negates the effect of Simplicity of Snow. I've forwarded the SoS version of the record unchanged to a deconflict file. There was also one static that was a pseudo-ITM, reverting a non-plugin-dependent fix from the USSEP. This was repaired by patching the record.

 

 

The bulk of the conflicts, unsurprisingly, were in the worldspace records. Review of the top-level data revealed unforwarded occlusion information, which I passed forward. This mod disables a number of vanilla records, which is fine. Those changes prevailed. The Gray Quarter (WindhelmWorld 34, 9) contains a number of conflicts with Gray Quarter Overhaul that aren't easy to assess from within xEdit. We'll check these out when we take a tour through the zone. The remaining conflicts were either small positional edits or, in one case, relocation of some barrels to make room for a Prison Overhaul static. I adjusted these as bast as I could in xEdit, but we need to check all of these in the game to see how they look.

 

 

Overall, the inside of the city looked good. I found a few statics that were conflicting - I'll handle it by disabling some of them in xEdit - but no other issues. I did not see any observable problems in the Gray Quarter, so that's good. The exterior looked fine also. What I did find (you can see an example above) was a lot of projected texture striping. This ranged from "you only notice it if you look for it" to "awful eyesore" but it's not directly a problem with this mod. For now, this is a watchlist item - need to look out for a good solution that will serve up these snow textures without distorting them as noticeably.

 

There's a few follow-up items for later, such as getting snow shaders applied to some of the surfaces in the upper-class area, but generally this one seems to have integrated correctly.

This is a little one, just a mesh replacer for the Malacath statue. Curiously, it comes with its own plugin, so we'll have to see what's involved with that.

 

The mod has only 22 records and it's already ESL flagged. The technical approach here is interesting; rather than shipping with a replacement mesh, this mod instead remaps the underlying static to a different path. Now, this is fine as it is, but it gives me some ideas for the near future. In the meanwhile, this mod has some dirty edits (deletions) in it, which I cleaned. No errors, conflicts, or landscape/navmesh to worry about, so that's all good.

 

 

Now... looping back to that statue. There's another high quality replacer for the statue out there that is a simple replacer. Including mod-added ones, there are currently 6 Malacath statues in my game world - enough for some diversity. What we're going to do here is inject the custom statue path back into this plugin as a separate record, and then remove the vanilla version. We'll use the Boys to Men version for the two vanilla statues, and let the Midden Expanded ones (along with future mod-added ones) use the Legendary Statues version.

 

Here is the one from the Fallowstone Cave quest:

 

 

More and more interesting, the ones in the Arcane Grotto are tiny little chess pieces. This in turn is kind of prompting me to make some more changes. I don't really like the snow shader on the chess pieces, so I'm going to change my approach to the statue. I'm going to take the nude one and fork it, removing the snow shader. That will be for the chess pieces. I'll put the Legendary version in Trinimac's shrine and it will continue to be the default for future statues that appear in the game.

 

 

Non-snowy chess pieces... Need to add to my watchlist an entry to do the same with the statue of Magnus.

 

 

Temple of Trinimac

 

 

So that was a fun little diversion, probably more work put in than the results justified, but it did add a nice bit of uniqueness to my game world.