Welcome back, everyone! After a little break during the busy part of the week, it's time to get back to work on Ambient Slaves 0.2b. If you haven't read Part 1 and Part 2 yet, I recommend you do so first, as by now we're pretty deep into the project.

 

To recap, here's what's on the agenda still:

 

• We need to go through the navmesh conflicts and create determine which ones need compatibility patches. We'll review the two ways to accomplish this.
• After working with the author, we now have a good feel for what's causing the pathing issues in Windhelm. Basically, one of the meshes in use has collision bounds that are causing problems. Fixing that is outside the scope of this effort, so we'll leave that alone for now - fixing vanilla nif issues could be the subject of its whole own blog! We do however need to go back to Windhelm and make a compatibility patch for a few objects that are sunk into the pier. 
• We need to look at the finish touches for this mod, such as whether or not we can get it to load in the FE space reserved for light plugins.

 

Today we are going to start talking in detail about Navmesh Conflict Resolution. We'll look at simple conflicts that can mostly be addressed in xEdit, and more in-depth conflicts that require analysis or even corrective action in the Construction Kit. 

 

Navmesh Conflict Resolution - Diagnosis

I kind of hate this function, because it's one of the most tedious activities for modding. However, it's worth the effort. Navmesh conflicts can cause all kinds of problems - up to and including crashes - and it's a problem that tends to snowball the more and more conflicting mods you have. Keeping on top of it will at least minimize the frustration. 

 

First, we need to go into xEdit and turn on "Simple Records" in the options section. This is important because the full detail records are just going to e information overload. With simple records, we can at least get a general feel for the relationship between the various records. Once you do this, you'll need to restart xEdit.

 

 

After we do that, let's apply a conflict filter to just AS and review what we've got. We'll only be looking at worldspace and cell records, since its navmeshes we're trying to find. As you can see below, we've got a lot to look at.

 

 

When I go through these, I like to start at the bottom of the list - it's just personal preference, but I find I get "lost" in the records less often that way. So the first one we're going to look at is CAD79. As it turns out, this navmesh has some significant conflicts. There are two ways we can handle this.

 

1. If the individual Navmesh components aren't in conflict other than the overrides against the vanilla files, then we can take the easier but less precise approach of patching the navmesh in xEdit.
2. However, if more than one mod is making complex additions or edits to the navmesh that are overlapping or that are large enough in scope that they make it difficult to reconcile in the editor, we need to involve the Creation Kit and it's GUI much more in the process.

 

In this case, let's look at what we have here. On one hand, AS has a lot of conflicts, but on the other hand, in each case only one column is flagged as conflicted while the others are grayed out. This means that all these conflicts are vanilla overrides, and so we can fix this in xEdit. 

 

 

 

Patching Navmeshes in xEdit

We're going to approach this with two objectives:

• Forward USSEP navmesh adjustments into the main AS file (these are generally legitimate bugfixes and as long as they don't introduce a hard dependency on the USSEP there's no harm in forwarding them)
• Create a compatibility patch for Diabloesque Decorations (ZDD.esp)

 

Patching the vanilla stuff is pretty easy. For each vanilla/Update/USSEP record that's red white AS' entry is gray, just drag the red entry into AS. As an aside, don't mind all the red background on the AS records that you see in the early screen shots. I forgot to disable my own navmesh deconfliction patch, which was causing every record in AS to show up as conflicted. 

 

 

Repeating this each time it shows up, we only find ourselves left with the one vertex definition from ZDD, which we'll make into a separate patch. To do this, we'll right click on the Ambient Slaves column for this Navmesh and choose "copy as override into..." just like we did with the compatibility patches in the previous blogs. 

 

 

Doing this will create a mirror of AS's patched navmesh that we can use as a starting point. From there, we just drag the conflicted ZDD vertex into the compatibility patch, and we're done (for now). We'll be revisiting both files at the end to do some final processing in the CK.

 

 

 

Investigating Navmeshes in the Creation Kit

The next Navmesh conflict is E0BB6. At first glance it looks like we may have lucked out and found another one we can fix in the CK. However, it quickly becomes apparent that some of the same vertices/triangles are updated by different mods. You can see below that at vertex 68, Rigmor of Bruma tries to edit a line-item that AS also changes. Unless we're 100% sure that we can discard one change in favor of another, this is something we need to look at in the CK to be sure. For now, we'll just keep a tally of which vertices/triangles we need to look at.

 

 

The final tally comes to three conflicted vertices and 18 conflicted triangles. Now lets take a look at each version in the CK. Now, for context, you might recall that when we were looking at this same zone during the cleaning portion of this project, we noticed that AS had calved off a large portion of the navmesh into its own island. What we're seeing now is that when this happened the CK made a number of new triangles available for reuse. All of the conflicts seem to be linked to this: new triangles added by the AS mod author. 

 

In the case of a serious conflict (such as both mods trying to use the same triangles to add new land), this would be a big headache to unwind. Fortunately for us, it appears that all of Rigmor's edits are small tweaks and, additionally, many of them overlap into the new areas created by AS. In this case, there's no need to patch these records. We can just recommend to users that they load AS after ROB and let this conflict sort out in AS' favor. Since we are going to let AS win on all the triangle conflicts, we can also let it win on vertices.

 

 

There's a similar, smaller conflict at the city gates one grid over.

 

 

In this case, we can go right ahead and forward the USSEP triangle definitions to AS. Rigmor only changes one vertex relative to the USSEP, and it looks like this is a case of Rigmor attempting to replicate the same fix that the USSEP implemented. However, let's go ahead and patch this using the same technique we used for ZDD, just to be safe. We'll forward the USSEP version to the main AS file and the ROB version to the ROB patch

 

 

At this point, you might be wondering why I'm skipping over edge links again. Up until this point, we haven't had any edge link conflicts to address, but... the next conflict is with Sweet as Honeyside and its a really clean conflict; the triangles in AS are all vanilla, so we'll just overwrite them with the honeyside compatibility stuff. However, there are some meaningful differences in the edge links (see second image). Since we don't have any hard conflicts, we just want to patch them so that the new edge links win (for now). We'll go back and regenerate these later in the CK, then clean them with the edge links cleanup script, but for now this will get us into a minimally deconflicted state.

 

 

 

Patching Navmeshes in the CK

Then... we get to FC127. This mesh is a mess of conflicts. AS forwards, and edits, the navmesh changes introduced by the Dragonborn DLC. The USSEP also edits the cell extensively, in ways that conflict heavily with AS. Finally, XPO massively expands the navmesh, presumably to ensure smooth execution of its punishment scenes.

 

 

We can't get around this with simple xEdit record management or by arbitrarily choosing to ignore one of the sets of changes. We're going to need to actually merge these conflicting navmesh records.

 

Just like before, let's first look at each version in the CK to understand the differences. Note that we're only going to look at FC127 and FC11C as they are the two with conflicts here. 

 

 

So here's our four versions of this Navmesh. 

 

• Vanilla is generally complete, but the Solstheim ship has only a rudimentary navmesh that doesn't cover the front or back of the ship. This is probably generally harmless, but it could result in NPCs getting stuck if something pushes them into these areas.
• USSEP corrects this by fleshing out the full navmesh. It also makes some expansions to FC11C, which covers the southeast shore and most of the water areas, by adding some additional coverage on the east side of the map. 
• AS is based off the vanilla meshes, but it expands the dockside area to match the mod. I appears to also, inadvertently, create an island navmesh with some of the water along the docks.
• XPO is... interesting. Do you think you're seeing double looking at its navmesh map? You kind of are. The XPO developer appears to have merged all FC127 with FC11C and then did an incomplete trim and drop undeletion on one of them, resulting in a full copy of the entire combined navmesh underneath the zone. Visual review doesn't reveal any obvious differences between the XPO and vanilla.

 

So it looks like what we want to do here is to weld the new northern pier area to the fixed navmesh from the USSEP. We also want to remove the orphaned cell since it won't be needed using the USSEP mesh data from this area. We are going to ignore XPO as this navmesh appears to be the result of CK issues and an incomplete navmesh repair. 

 

 

That's where we'll have to leave it for tonight. Please note that the xEdit based fixes described above are not final and shouldn't be used in a vacuum as a template for resolving navmesh conflicts. We'll cover the "finishing touches" for those repairs in a future blog entry.

 

In the next issue of this blog, we'll continue with the Windhelm Docks repair and also review the finishing touches to get a few stray statics to line up with the new pier; we'll also talk briefly about working with the Anniversary Edition's new content.