Our first objective today is to install an undisclosed mod related to loose ends from Kirstia's first adventure. This mod has two 'line items' in MO2; the mod itself and a LOTD plugin that adds a display for its unique items. Conflicts are minimal, and placing this mod in my quest mods section already moves the conflicts into a situation where I'm happy with the results. Honestly, I could probably hide all the winning conflicts and have no problems, since they appear to be redistributions of existing assets, but that's not a big deal. 

The LOTD patch is already ESL flagged, but the main mod is not; it contains only 285 records, so it's a strong candidate for compacting. Normally I don't compact LOTD interfaces since that mod and its downstream patches frequently receive updates, but in this case the mod itself has been in a stable state for a long time and its LOTD patch is separate from the main 'official' patch stack, so I'm comfortable compacting it immediately. 

This mod does contain facegen and an SEQ file, and we'll need to reindex the first and regenerate the second as part of the compacting process. Both plugins are clean and have no conflicts with other mods. Reindexing went off smoothly with no errors, allowing this one to very seamlessly work into the load order. 

If you've been following this blog for a while, you know that Project Proteus has been an essential tool for my playthroughs, especially when it comes to having the same character star in more than one story blog. That mod was in an extended beta, which recently ended. The result of that effort is Proteus (no 'project'), the official release version of the tool. We're going to upgrade to this version today. 

The mod itself is very clean from an assets point of view, with no problematic conflicts. It redistributes some assets from UILib, but this appears to be a benign conflict, and even if it had a functional impact, I'd want a brand new mod like this to be winning. 

The plugins consist of an uncompacted ESP file and a number of ESL-flagged patches. We'll be putting these after our conflict resolution stack but before our occlusion file. The main file has 1,247 references, which makes it a candidate for ESL flagging. I posted a question to the mod author to confirm if this is fully safe, but I'm going to press ahead and compact it for now. I can always restore it to the original later if he gets back to me and warns me of issues (my concern is potentially hard coded references in the DLL, as it otherwise looks safe).

All the plugins were free from errors and contained no deletions. The main file had about 50 ITMs (mostly orphaned top level cell records and cell partition records) which I removed. Unsurprisingly, the patches had no conflicts (they just contained form lists for the main mod's functions to hook into). The main file had some conflicts within the top level cell data, which I just had to overwrite with the data from my worldspace conflict resolution patch. 

An initial test of Proteus with the compacted file appears to be working. The only issue seems to be that it can't see Kirstia's saved character from the 'project' version, but that's not too much of a problem - I'll just need to manually rebuild her baseline inventory (I have her appearance saved separately already) using the console. All in all, that was not only a smooth upgrade.

After a long period of being moribund, Blood and Silver has received a major update. Since Kirstia has already played through this content, it wouldn't normally be a big priority for me to update this. However, my Prison Outfit Overhaul mod has a Blood and Silver patch which I need to update, so we'll go ahead and do this one now. 

Conflicts between the new version and the official content are minimal, just a couple of script overrides that are only conflicting the vanilla game. The plugin file is an uncompacted ESP with 3,975 records. This means the mod is a candidate for ESL flagging. However, I am going to hold off on doing this for now until I'm confident that no further updates are going to be forthcoming for the mod. The plugin has no errors, ITMs, or corrupted edge links, but it does have a navmesh deletion. Since the deletion appears to be a simple case of an edited mesh getting assigned a new form ID by the CK, we'll just remove the deleted record and then change the form ID of the new record to replace the deleted one. 

This mod has a lot of conflicts, but most of them are fairly straightforward record merges; for example, a number of vanilla placed actors have an enable parent added to them that just needs to get forwarded to my conflict resolution patch. Two major quests get updated, but the only conflicts are with the USSEP; we'll just let this mod prevail in that conflict. As I've touched on a few times before, at some point I also need to go back to Cidhna Mine and do some substantial navmesh work. This need is really underscored by the update here, so we'll be attending to that today.

Before we attack that navmesh, let's update our patch for POO. 

There are two things we need to do here. First, we want to compare the current patched NPC records with the ones in the updated plugin file. Any changes to them need to get forwarded into the patch. 

With that done, we're going to look at the two new actors. However, they appear to both be followers who get added to non-Cidhna locations so we'll leave them alone. 

Now let's visit the mine and make sure all the visuals look right. 

Everything seemed to be working right except for one actor who had dark face bug. The problem was related to a head part not being updated to the new record, which I fixed in both my personal conflict resolution patch and also the BAS patch for POO. With those changes made, we'll go ahead and upload the new version of POO, then move on to the navmesh.

There's only one badly conflicted navmesh in Cidhna: 2DF8D. 

In theory, this mesh is only touched by XPO and Blood and Steel, but my conflict resolution patch also shows an interface with Cutting Room Floor via door links. Further review, however, seems to discount this and I've removed that linkage (the 'vanilla' CRF door doesn't have the navmesh link). Unsurprisingly, BAS has major navmesh edits, but so does XPO. Let's first compare those two in the CK to see what's involved.

So we need to cut that new area off the XPO mesh and weld it onto the BAS mesh. If you've been following this blog for a while you know the drill here:

• Copy the XPO mesh to a working file
• Change its form ID
• Copy the BAS mesh to the working file
• Add masters to the working file for XPO and BAS (also Update.esm for good measure)

• Open the CK
• Delete all the non-unique triangles from the XPO mesh

• Connect the vertices to the BAS mesh

• Finalize the new, combined mesh
• Clean it up in xEdit
• Move the new navmesh to the navmesh conflict resolution patch (also copy any navmesh linkage updates)

• Rebuild the navmesh conflict resolution patch's NAVI record by opening it in the CK and save without making any changes

The welding in the CK went smoothly, but when rebuilding the NAVI I found two errors that I need to look into further:

MASTERFILE: Failed to find door portal array index for tri 221 in NavMesh (0002DF8D).
MASTERFILE: Failed to find door portal array index for tri 137 in NavMesh (0003D2CE).

Can you spot what I did wrong from the screenshots? I sent the door data to my worldspace patch rather than my navmesh one, which caused confusion when it tried to update the NAVI. After fixing this, the NAVI regenerated correctly.

The first part of fixing the issues in Raven Rock is going to be to resize the Boethia statue. This should be a pretty straightforward fix - we'll just resize the statue in the CK and adjust its position to fit with the rest of the display. Here's the before and after view in the CK:

And here's how it looks in game:

OK, that takes care of the issue with the Boethiah statue. We'll be back since we still need to fix the slavers' office, but at least we can have one less eyesore to worry about.

Not that kind of watersports - an oddly under-represented fetish on the Lab, now that I think of it. No, I'm talking about Water for ENB. This has been on my acquisition list for a while, and today we'll try to get it integrated. I expect there won't be any major technical problems - it'll just be labor intensive updating top level cell data. We're going to grab the 1.58 Beta version since it includes a significant structural change that'll be present in future versions. Downloading 1.54 is just signing myself up for re-work  As a nice added bonus, 1.58 incorporates the creeks add-on out of the box.

Structurally, the asset conflicts are very similar to (though not totally overlapping) the water nif fix that I downloaded yesterday. We'll put this mod right after that one to provide the same general asset management strategy. This mod contains two plugins - a master file and a normal ESP. Neither file is ESL flagged. Both mods are clearly eligible for compacting and we'll be compacting both of them before we proceed. As you'd expect for a visual mod, neither plugin has any sensitive assets associated with it, so this'll be a simple conversion job. Note that the ESM and ESL flags can coexist on the master without any problems. There's no need to change it to an ESL 'light master' file.

Neither plugin contains any errors or corrupted edge links. Cleaning revealed no deletions but 5 ITMs - orphaned cell data - which I removed. Conflict resolution, unsurprisingly, was mostly a matter of injecting the new water records into the relevant top level cell data, as well as updating the baseform for certain water-related statics. 

As expected, there are a lot of top level cells to edit, but this is expected and will mostly be a matter of drag-and-drop. We'll filter to show conflicts only to reduce the amount of scrolling

As an aside, ones like the screenshot above that only conflict the occlusion file I'm not going to touch. I'll just regenerate the occlusion file afterwards since it imports the winning record for each cell that gets occlusion added. We need to regenerate LOD anyway to use the new water assets, so why do the extra work? With that work done, we'll do that LOD regen and then see how things look in the game.

Looking good. As promised, there are no seams to be seen anywhere, and the water textures and transparency level all look really good!

While we're doing water related stuff, let's grab the latest Depths of Skyrim and GKB Waves. Both of these have been on the back burner for a while, so it'll be good to cross them off my list.

GKB Waves is an uncompacted ESP file with 2,481 records, of which 2,368 are unique. We'll need to split this file for ESL flagging. Copying one of its Tamriel sub-regions to an overflow file offsets enough records to achieve this. We'll save the overflow file, put it in correct load order, then change the form IDs and delete the original references. Other than needing clean a couple of ITMs, this was a very smooth installation - the mod basically just adds the wave objects to the seacoast without messing with anything else.

Depth of Skyrim is a bit more involved. This one is another uncompacted ESP file with no asset conflicts. Clocking in at 16000 records, we won't break up this file today. However, since it mostly contains object references it certainly is feasible to break it up in the future if we need to reclaim a load order slot - though there are other mods in my load order that make for better candidates right now. The plugin is clean - free from errors, deletions, ITMs, or bad navmesh edge links. There are a lot of conflicts, though most of them are false alarm reports where a landscape record is overwriting the vanilla record in one of the DLC files. The remaining issues were top level cell records conflicting with Water for ENB (merged to preserve all the relevant changes from each mod involved) or changes to the underwater grass definitions (allowed this mod to prevail vs. the generalized grass mods). For a large mod like this, it was a very smooth installation.

Let's see how these mods look in game.

Well, after all those watersports, I guess now it's time to delve into scat, right? Specifically, Mihail's Animal Dung and its texture patch. As you might imagine, this is a pretty self-contained mod, so there aren't any conflicts except for the texture patch overwriting the original texture files. The plugin is already compacted, so we just need to check it for dirty edits or conflicts. We'll also grab Morgenstern's Mushroom Circles, which seemed thematically appropriate. Both mods were free of errors, deletions, or broken navmesh edge links. Mihail's mod had a bunch of ITMs, which I removed. 

The conflicts in these mods were pretty limited. The mushroom mod had some landscape edits that conflicted with other location mods (mostly Amber Guard), while the animal dung mod had a couple of USSEP edits that needed to get forwarded. Otherwise, they were fine. 

Looks good! Very immersive!

ENB has been nagging me for a while to update it to the latest version. I also see that there's a new release of Rudy ENB SE. Let's grab both and update them. The latest Rudy seems designed for use with either EFLX or Lux, and frankly I've been considering getting Lux for a while anyway, so I guess we can take the plunge now. This is going to push me up to at least index F0, so tomorrow we'll need to compact some files, but this should give us a nice boost to our lighting effects so it'll be fine. 

This new version dead ends the ENB Night Eye fix, so we'll uninstall that and move it to the "not used" section. Speaking in mod interactions, the list of patches for Lux is really outrageous. I'll have to periodically reinstall this mod as my load order grows so I can keep up on the patches. Somewhat frustratingly, too, I'm pretty sure I'll need to uninstall at least some of these because of issues with fairly extensive ESL conversions (multi-file splits) breaking the patches. Oh well. We'll just hold off on installing most of the patches till later.

Strictly speaking, I don't expect any problems installing Lux. The main issue is going to be updating top level cell data, and that'll be a fairly intensive job. 

Initial cleaning of the files found a bunch of deletions and ITMs, which I removed. Lots of conflicts, of course, but it's interesting to see that unlike Luminousity I'm not having to do tons of fiddly work involving lighting data. Instead, this mod seems very focused on working with the image space characteristics and that's making patching a much quicker process than with LLO.

While this is going to be easier than integrating LLO or Shadows, it'll still take a while. I got up to Bleak Falls Barrow, but now I'm going to take a break. We'll continue with the integration of Lux tonight. For now, here's how Bleak Falls Barrow looks with the new lighting: