Jump to content

Mod Cleanup Case Study - Ambient Slaves 0.2b - Part 2


gregaaz

763 views

Welcome back everyone! If you're new here and haven't read Part 1 yet, I recommend you start there. It has some background and setup information that I won't repeat here, and it also covers navmesh deletion repair, which we've finished for this mod and won't be rehashing.

 

 

SolitudeWorld - Prison Overhaul Conflict

When we left off, I had just identified a conflict between Ambient Slaves and Prison Overhaul Patched in the plugin file. What had looked like a benign conflict involving positioning a tree ended up revealing a potentially game breaking conflict where XPO furniture was blocked off behind market stalls. This could have lead to the game getting into a loop during punishment scenes if the actor couldn't reach the furniture. We created a patch file and used the CK to move the furniture (and its associated markers and collision boxes) to a nearby location that wasn't blocked off. 

 

Because the furniture items were persistent records that were already loaded into my save, I had to start a new game to test this. Fortunately, it's easy enough to spawn a new character at the Winking Skeever, so I was quickly back at Solitude to assess the new location.

 

ScreenShot539.png.d19fa250009b038d44b01099a180bd8a.pngScreenShot538.png.76f3fc3c647fb9f4064c5c0d341add7b.png

ScreenShot540.png.59a7fcb1b3f44ddc789c701627bd3e3a.png

 

As you can see from these screen shots, the new location is indeed unobstructed and its close enough to the original position (behind the cages you see in the oblique screen shot) that it shouldn't substantially change the overall flow of XPO punishment sequences. There is a minor gap under the X-Cross's wooden platform on the right side rear. This could have been addressed with a small landscape edit, but frankly I try to avoid landscape edits like the plague whenever I can, so I left it be. The final picture also demonstrates that the brazier's idle marker is working properly. 

 

 

Tamriel - Lanterns of Skyrim conflict near Solitude Docks

Since we're already spawned in at Solitude, we'll take a quick walk around town to see if there are any other irregularities related to AS. SolitudeWorld itself looked fine - no other observable issues. Outside the city, we can see the slaver outpost near the docs and it is mostly meshing right into the world. However, there's a Lanterns of Skyrim light pole that would normally be on top of an SMIM static. This static, AEE4E, gets disabled by Ambient Slaves, leaving the LOS pole floating in midair. So we also want to move that to the nearby pole shown in the second screenshot. We're going to accomplish this like we did with the XPO furniture - create an override patch and then use the CK to move the statics to the new position.

 

ScreenShot545.png.813947102ea08eb3d92e1aa991bfb565.png

ScreenShot543.png.ba674f28647cacfc65b869a575e93d3b.png

 

So first let's fix the SMIM conflict. This should be a pretty straightforward one. There are three records that go together - the pole, the lantern, and the light source, so we just select them all at once and drag them to the new position, as shown here (don't mind the missing mesh warning in the screenshot - its a false alarm)

 

image.png.44b018d5b5065b41802138f79b339cd5.png

 

With that done, we want to go back to xEdit and make sure CK didn't add any wild edits. And indeed... there were. Its a weird one, too - a wild edit in Whiterun of all places!

 

image.png.53cb1becf9dd6accad64dcf2de79a768.png

 

So we'll remove the whole 1A26F branch from the patch and save it up. Now let's see how it looks in game:

 

ScreenShot546.png.9ba9e7fd5bae79b53e65f0cdc4538bff.png

 

Looks good!

 

The Grand Tour - Visually Inspecting the Major Modded Areas

Now let's tour the other major zones this mod edits to look for visual issues. Once that's done, we can go back and finish the technical review in xEdit. According to the mod's documentation, we want to visit...

 

  • Riften
  • Windhelm
  • Whiterun
  • Markarth

 

Riften doesn't have any critical issues, but there is some landscape and grass intrusion which we'll need to keep in mind during our technical review. The grass intrusion may just require rebuilding the grass cache and go away on its own, but the landscape intrusion suggests a conflict within the landscape record. It doesn't actually block the door however, so really the only issue is the visual impact of the grass getting in front of the door. 

 

ScreenShot548.png.99ea49b5b68d2370b47f25df751f0c45.pngScreenShot547.png.05244ffcfef77b7cab7d2842b9670449.png

 

Windhelm's statics seem fine at first, but as you can see here there's some kind of navmesh issue. This NPC is just perpetually walking in place, like she's hitting an invisible wall. On further investigation (looking at it from a different angle) we can see that there's this huge chunk of landscape blocking the way. Just like with Riften, we'll need to scrutinize the landscape records here to make sure they aren't breaking things. Note that just like with Riften, it's possible the problematic landscape data is from a different mod.

 

ScreenShot549.png.592264d34c47f973ffb686f25acbc93d.png

ScreenShot550.png.5233769e5b4e46a476e256d4ae729227.png

 

Markarth's modden area is mostly indoors, so there's not much risk of overt conflicts in the worldspace. There do seem to be some NPC package issues with the slaves not properly populating their gibbets, but after entering the outpost and then leaving again, they properly aligned, so this probably doesn't require further action during cleaning.

 

ScreenShot551.png.167bd7a229ac2f5c80549ecc1b590637.png

ScreenShot552.png.4fba9f74a1a881f4f729b7c3818e10bd.png

 

Finally there's Whiterun, which I saved for last because I expect it to be the most likely one to have layout conflicts. Frankly, even if I found nothing I'm sure I'll be revisiting it later as I have big plans for the Whiterun Valley area. However, other than occupying a high risk location that's used by many other mods, this one seems to be OK (there's a little grass intrusion at the door step, but this may be fixed by rebuilding the grass cache and since I'm going to have to move this building eventually anyway, I'll leave it untouched for now).

 

ScreenShot553.png.af563aafec07f5b28cfd9503de95ddbc.png

 

 

Back to xEdit -- Conflict Resolution Review

Now that we've done the visual tour, we want to do a technical review to pick out matters that might be less obvious. We'll primarily be doing this in xEdit, and while this mod clearly has both navmesh and landscape conflicts, we're initially going to put these aside and focus other types of conflicts (mostly REFR and ACHR, I expect). 

 

Why? Because I really hate doing navmesh and landscape deconfliction, so I'm going to procrastinate on these!

 

image.png.f54ebf3045f9aa230a4b9b564e19dc64.png

 

Lets also talk for a moment about top level cell records.

 

image.png.40a207636038ac9e97f467669862be83.png

 

Almost every mod contains these records, because they're structurally neccessary for lower-level cell records to work. They're also almost always ITM records and there's no good way to get rid of them. This means that they wipe out important cell edits like lighting, music, encounter zone (see example above) and so forth unless the end-user patches them.

 

Why do I say unless the end user patches them and not unless the modder patches them? Because it's not feasible to make dozens of compatibility patches just for the different combination of potential top-level cell edits. For better or for worse, these are up to the end user to fix, either with an automated tool like Wrye Bash or manually in xEdit. In this case, I'm going to forward that encounter zone record to my private worldspace deconfliction plugin and not both putting it in a separate file. 

 

Now, as we continue going through the records, we are seeing a lot of conflicts where some other mod moves a static, but AS disables the static. In these cases, we're going to let AS prevail and not bother patching. In theory, we could move the vanilla assets again to a neutral location, but since these are just vanilla scenery assets, we're not losing anything by allowing them to be disabled. Most of the time. One thing to remember with trees is that sometimes other stuff gets attached to trees, like birds nests and beehives. Part of why we do a visual tour is to look for "floaters" that might indicate a need to pay closer attention to the trees. We didn't see any of these during visual inspection, so we can let AS' disabling edit stand without further intervention.

 

image.png.6d1a3dadd7e9e4cdc6b5dc1f7e73d686.png

 

Now, here's one we need to patch - see below. This is a situation where AS moves the object in a different way than the USSEP did. That part is actually fine, we can let AS prevail as it seems to be just a different way to achieve the same goal as USSEP (lowering the object into the ground). However, USSEP also adds a missing location tag to the reference. This is a vanilla tag that won't add a dependency on USSEP, so we can just add it directly to Ambient Slaves.

 

image.png.17d85affc21566d7a663eb150b76dea0.png

image.png.c9bfae0d373f2adc31be33f8928605d2.png

image.png.2507972b4ee5d374d290030986350a62.png

 

Here's a pretty easy one that does require a new patch file -- SMIM changes the static used in this piece and AS reverts the change back to the lower poly model that comes with vanilla Skyrim. We'll just forward the SMIM info to a new patch while keeping the positional data change from AS.

 

image.png.bed6924fea75c8141670756bdadf2159.png

image.png.95a1901b78d394304c41f573c667630d.png

 

On the other hand, the other record is disabled. So we can just let AS prevail without any patching.

 

image.png.1e8395e1f33a5a4ac02f5359b37f131c.png

 

 

And that's the summary of the non-landscape, non-navmesh conflicts. All in all, this is a pretty clean mod when you consider what it does. Next, let's look at just the landscape conflicts. Note that we aren't going to look at the landscape issues we observed near Riften during the visual tour just yet. That'll be about the last thing we do in this process. Most of them are going to look something like this:

 

image.png.4374bbe7cd31221f767c59334e0a39fa.png

 

In general, these sorts of conflicts are fine. We can reasonably expect any mod that adds buildings or otherwise modifies the world to override vanilla landscape data and we don't need to scrutinize that unless we identify problems during visual inspection, or it appears that the mod is introducing a pseudo-ITM that reverts data from update.esm back to vanilla.

 

So for these type of landscape conflicts we're only going to do a cursory review of the data. We're looking for a pattern of edits where the main, or only, change is to replace update.esm or other canonical master data with vanilla Skyrim.esm data. A good indicator, for example, would be if added details like the LReachGrass01 record we see below were consistently removed from the landscape record and we don't see a logical reason why the data would be absent, such as new buildings or other structures getting added to the world.

 

image.png.a0132dae250da638138e1291b767c6bc.png

 

Until we get half way down, the landscape edits all appear benign and don't require patching. Then we get to A61C and we find something odd. We have two issues here, that you can see below.

 

  1. There's a null reference located in the record that appears to be a wild edit added by the CK. We'll go ahead and trim that right out of the main file. 
  2. There's also a major conflict with Cutting Room Floor. In that case, its hard to fully assess which landscape configuration works better, or if this location needs a genuine landscape patch for compatibility. For now, we'll just forward all the CRF data to a compatibility patch and then we'll test it in game after we've looked at the rest of the landscape conflicts.

 

image.png.96e0b40fab7f801f1ed85ffa34235a3a.png

image.png.69bfeb3be092f042e59bb1d8b92436a9.png

 

Since we didn't find any more landscape related red flags, now let's go over to Tamriel 3, -3 and look at that landscape. A walk through the zone revealed that the CRF version of the landscape did not interfere with AS's additions to the area, so we can just forward CRF's landscape edits and leave it as-is.

 

Now let's see if we can track down the source of that odd landscape intrusion we saw at the Windhelm docks. When we load up just AS and its masters in the CK, we can see that the unexpected geometry is still there, so this isn't coming from some other mod as far as we can tell.

 

image.png.77b091b55ac96d4de70b7be0c908d491.png

 

As it turns out, even though we weren't able to interact with these through the in-game console, these are not landscape items. They are two specific object references added by AS.

 

image.png.92afc2fbcfa83988e2cd498fc18a2262.pngimage.png.fb8268802a478242af7125bf199a9259.png

 

Let's disable these (in a patch for now) and see how the docks look afterwards.

 

image.png.dbb3260e0b3dde7f7f2c2f5e7ba14f2d.png

 

Disabling those two statics did resolve the pathing issues; as you can see there's no traffic jam at the turn of the corner anymore. However, now we have some floating terrain. Further analysis shows that there are a large number of other Windhelm steps and other related statics added to the area by AS. Finally, loading back in with the unmodified cell shows that the floating terrain is still there even with the large blocks in place. It's starting to look like this is actually an unfinished area, so rather than mess with it further we'll just report it to the author for further attention. 

 

 

Well, that gets us to the end of part 2. To recap, here's what we've done so far.

 

  • We've cleaned all the deleted and identical-to-master records
  • We've repaired five deleted navmeshes
  • We've created patches to resolve several conflicts with other mods
  • We've reported one problematic area to the author for further review

 

What we have left to do is:

 

  • Try to resolve any navmesh conflicts with other mods
  • Do final cleanup and optimization, including trying to get the mod out of the main load order

 

In part 3, we'll focus on navmesh conflict resolution and, if time permits, also cover the final wrap-up steps.

Edited by gregaaz

1 Comment


Recommended Comments

Thank you again for your absolutely amazing guide.
But regarding Windhelm, I'm confused. The area is not, or so I thought, unfinished. The prison wall cap statics were supposed to represent a pier, one protruding over the water, the other submerged and flipped over, to extend the pier to reach all the way down to the river bed. I think I did the same for the other vanilla piers when I noticed they are just floating there, all made of stone, unsuspended, My OCD would not let me just leave that. On the new pier, I made a new navmesh leading over the improvised steps onto the pied. I just ran the game to take a few screenshots, and my follower, though she did get stuck for a bit, eventually did manage to get over it. I remember noticing this glitch before, and I did play around with the navmesh a bit, but this was as good as it got. I don't really understand why the NPCs get stuck there.
Regarding the five locations in the current version of the mods, I had no plans on further developing them, these are finished. Any further changes I plan to do using additional mods which will add the slavery mechanic, and those won't touch any terrain or navmeshes etc.
Here's a few pics I made of the place in-game
 

20211201195447_1.jpg

20211201195529_1.jpg

20211201195549_1.jpg

20211201195621_1.jpg

Link to comment

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use