Welcome back, everyone. Now that the navmeshes are all patched, it's time to wrap up some final matters and get everything neatly packaged.

 

Windhelm Dock Barrel and Fishing Poles

Before we get into the top, level stuff, you might recall that there were a couple of static conflicts left at the Windhelm docks. In researching these, they turned out to be from an out of print mid - Argonian Hatchlings - so I'm not going to make a separate compatibility patch for this one. I'll just roll it into my private conflict resolution plugin. The process to accomplish this is very much like making a patch for redistribution - identify at least some of the relevant statics (it's enough to get most of them), copy them as overrides to a temporary plugin file*, add AS as a master to that plugin (and temporarily flag it as an ESM file), and then switch over to the CK.

 

*We're still doing this work in a temporary file because large deconfliction patches with many master files can sometimes choke out the CK and make it crash.

 

 

Once we're in the CK, we want to look at the area that contains the conflicted statics and one thing we can see right away is that there's an idle marker that we hadn't been tracking before. We'll need to move this along with the rest of the items. In the second picture, you can see how just adjusting the Z plane on the cluster of references moves everything to the desired position except for the fishing poles. This is because they originally rested on one of the crenelated parts of the dock. We'll go ahead and adjust it so it's level with the new pier. The third picture shows the end result in the CK.

 

 

Next we'll go back to xEdit and remove the ESM flag from Ambient Slaves. We'll also check the contents of the temp file to make sure the CK hasn't injected any unwanted records. In this case, everything looks OK. Now we'll enable the temporary patch and visit the Windhelm Docks in-game with a throwaway character, just to confirm that everything is where we expect it to be. As we can see, they now appear to be level with the pier, as we want. So we'll wrap up by copying all these records as overrides (with overwriting) into my worldspace deconfliction file. With this done, we can delete the temporary working file we made.

 

 

Before we move on you might be asking: why am I not publishing this patch just because the underlying mod is out of print? Well, it boils down to compatibility. I don't remember whether or not I compacted the form IDs on this mod for ESL flagging, and I don't have the original to check against, so I'm not going to share a patch with @gargamel9 that ostemsibly works but that might actually cause CTD if, as I suspect, the original master is an uncompacted ESP file. Hopefully if anyone else is using that particular mod, they won't find it too difficult to replicate the steps in this blog.

 

Top-Level Cell Records - Hidden ITMs?

Now that we're done messing around with the contents of the mod, we need to address a type of hidden ITM that we haven't looked at before, and these are full or partial ITMs in the top level cell data. Every mod that contains any object references (REFR) to character placement (ACHR) records also needs top-level cell data to define the location where that record points to. This is just a fact of life when it comes to how the Gamebryo/Creation Engine database structure works and there's no real workaround. Moreover, since they have to stay in the file, the automatic ITM cleaning function will not remove these even if they are, in fact, ITMs.

 

That's unfortunate because this top level cell record is where mods like music overhauls, water flow fixes, ENB particle patches, and several other high value mods keep their data --- and it all gets reverted back to vanilla when the CK injects top level cell data during mod creation. So we need to go through all the top level cell records of the AS plugin and its patches to check for two things:

 

1. Orphaned top level cell data that doesn't have any records underneath it anymore. Some of these may have come into existence during the navmesh cleanup we talked about in the previous blog entry.
2. Top level cell data that reverts changes from Update.ESM, the canonical DLC files, as well as non-unique records from the USSEP. Separately, I'll also be looking for cell edits that revert music, particle fix, and other records from my other mods - though those will only go into my private conflict resolution file.
   • Why aren't I patching these, you ask? Because the number of possible combinations of end-user mod loads is almost infinite. It's just not possible to predict these things, and if users want to bring those sorts of mods to their load order, they'll need to learn basic conflict resolution and patch the records themselves - either manually or with a tool like Wrye Bash. The purpose of what we're doing here is to ensure compatibility with SSE by avoiding edits that revert the game into its original release state.

 

For the first case, we'll just delete any orphaned cells we find (from the plugins, that is!). In the second... well, I'm sure we'll find some, so we'll get to that. If you look below, you can see what a "clean" top level cell record looks like. Despite many mods touching this record, none of them change its data, so the vanilla data that was automatically put here is fine as-is. We don't need to make any changes to this record.

 

 

The #1 potential issue we are looking for here are ITMs affecting the water data. SSE made significant changes to the game's built-in water system, and it deployed these changes by putting an override into Update.ESM, rather than editing the original Skyrim.ESM. This was good on one hand because it maintained uniformity of the Skyrim.ESM file across all users, but no so great because it created a vulnerability to ITMs. You can see below that the water data is flagged as a benign conflict because at least some other mods in my load order are trying to revert this data. In this case, I created this top level cell data in xEdit, and it already carried over the baseline information from my own configuration, which included Update.ESM and the USSEP, so the water flow data was pre-populated correctly. No edits needed here either.

 

 

But now, below, we've got a problem. As you can see, the AS-XPO compatibility patch doesn't forward the water flow information. We'll just drag the water flow data into the appropriate column. AS itself is also missing that data for this cell. We'll fix both plugins before moving on.

 

 

Next, let's look at how we identify an orphaned TLCD record. If you look below, you can see how B497 doesn't have a "+" icon next to it. This is an orphaned cell, and we'll just remove it from the plugin. The only situation we would want to keep an orphaned record like this was if the mod added or changed the cell's music or lighting data without editing any of the contents of the cell. We still look into each record to rule out that possibility, but it's unlikely we'll encounter that use case in AS since the mod has a different focus.

 

 

While the water flow data and orphaned records are our main focuses, we'll also find other discrepancies. One of them is the Dawnguard navmesh region data. These are some regional data that Dawnguard added to certain cells. Only some of AS' records in the affected areas forward these, while others don't. When it's missing, we'll want to restore it. As with the water flow data, we'll do a simple drag and drop of the data.

 

 

Beyond what you've read above, there wasn't anything else exciting to be found in these files - a few water references, a few orphaned cell records, and that one dawnguard AV mesh. 

 

On parting note - if you find that there is nothing left not just in a cell (orphaned cell) but in the group data above the cell (the "sub-block X, Y" line), you can delete that too. That's an orphaned GRUP record and it also isn't needed. Just make sure it's really orphaned - if you delete the GRUP, you delete everything nested underneath it.

 

 

Load Order Management

A lot of our patches were actually editing vanilla assets like navmeshes. This means that if I forgot to manually add AS and/or the conflicting mod as masters, we can't count on the patches to always load after them. This is especially true when the end user is using a Vortex, which by default doesn't give them manual control over load order (incidentally, this is one of the big reasons I always recommend MO2, but I digress...).

 

We want to right-click on each of the patches and choose "add masters" from the menu. Then, from the menu that appears, choose Ambient Slaves along with the conflicted mod. I nthe first example, we'll choose AS and Cutting Room Floor. We'll repeat this process for each patch. 

 

 

When this is done, go ahead and save the patches. 

 

 

Does This Mod Really Need a Load Order Space?

SSE introduced the concept of ESL flagging. Essentially, the ESL flag is an entry on the file header that tells SSE to load the file in a special reserved area of the load order, allowing many more mods to be added to a game. Legendary Edition effectively allowed about 250 mods at most (there were 256 slots, but five got eaten by the base game files, and the last was reserved for the saved game file). This limit as actually lower in SSE and especially in the anniversary edition, but that only applies to files that don't have the ESL flag. ESL-flagged files go into a reserved load space with room for up to 4096 plugins. Initially SSE would break long before users reached this limit, but SSE Engine Fixes has subsequently overcome this in all but the most extreme cases.

 

There are two limiting factors for ESL flagging:

 

• Each "slot" in the reserved space only has room for 4096 records, and by default 2048 of them are "reserved" and off limits to modders. There are ways to work around this, but they will cause all sorts of problems in the creation kit (not the live game!) so this sort of conversion should only be done if the user is certain they will never need to make changes in the CK, including to things like navmeshes.
• Because of a problem with the game engine, top-level cell data located in the reserved space cannot be overridden by patches. This means that mods that add their own cells and that are likely to be patched by other mods need special handling. 

 

Let's look at how these factors relate to AS:

 

• AS does add new cells, but barring someone making a lighting patch or something in the future it's unlikely they will be edited by other mods.
• AS contains 5451 records, of which more than 4096 are unique records that would need to load in the ESL reserved space. 

 

The second bullet is a problem, though there is a workaround. Essentially, we would need to split the AS plugin into three files, each with fewer than 2048 records, and then ESL flag each of those. This is a bit of a double edged sword, however. For SSE users, it'll mean that this mod takes up 3 of their 4096 ESL reserved space records... a much lower impact than using up a single slot out of the main load order. On the other hand, LE and Skyrim VR users, whose games do not recognize ESL flagging, will use 3 of their much smaller supply of ESP slots, rather than just 1 ESP. 

 

Before we proceed, we'll need to understand if the author intends to support LE and VR. So for now, we'll hold off on splitting and flagging the file. I'll probably revisit this at some point, even if its just documenting my private modding practices, but for now, since this mod is still under development, I'll hold off.

 

What does this mean? It means the mod is now in a deliverable state. I'll be sending my updated plugins over to Gargamel for him to review and, if he's happy with them, distribute!

 

If you haven't already weighed in on my poll regarding my next narrative blog, please take a moment to swing by and register your opinion. Since the poll is currently swinging to me adding a grab bag of new content rather than targeting a specific aspect of the game, please also feel free to let me know if you have any particular mods you would be interested in seeing "in action." No promises, but I'll seriously consider all requrests.