Welcome back, folks. When we left off in part 3, we had just concluded that AS had a major conflict with navmesh FC127, where substantial navmesh fixes from the unofficial patch were getting reverted by AS. However, we also determined that the changes did not overlap (other than existing in the same mesh). Today, we are start by cutting the FC127 navmesh at the lines marked in green below. We'll keep the north pier area from AS and weld it onto the rest of the USLEEP version of the navmesh. At the same time, we will go ahead and remove the orphaned navmesh that AS created in favor of using USLEEP's version of navmesh FC11C. 

 

 

Patching FC127

 

Because this is a slightly risky operation, the first thing we are going to do is sequester our work into a separate plugin. We'll start by copying the AS version of the navmesh as an override into the new file, then we'll change its form ID. I'm just going to change the index bytes. When the conflict resolution menu comes up, do not change any of the other records - we still want them to point to the original Form ID. Finally, we'll go back and copy the USLEEP version of the navmesh in as an override. Since we changed the form ID for the AS version, both meshes will coexist within the same file.

 

 

With this done, now we can open up our temp file in the CK. We'll see both navmeshes overlapping, so as we proceed here we need to carefully watch the bottom of the screen to confirm we're clicking on the right triangles.

 

 

Referring back to our reference image at the top, we need to find the cut points so we can separate the meshes. We're going to delete the "cut point" triangle on both meshes, then use flood fill to highlight the side of each mesh we're not going to keep - we'll delete those too. The end result will be something like this -- where there is only some very small overlap at the edge of the two "new" meshes:

 

 

 

Let's start with the bottom cut point. On immediate examination, we can see that we have some almost-but-not quite duplicate vertices in the corner on the left. Also we can see that the navmesh partially passes through a bucket. So let's tweak this interface a little bit. First, we'll delete the triangle that contains the green vertex you see below. Then we'll shift the remaining vertices just a bit so the line between them won't pass through the bucket.

 

 

After this. we need to make a square (two triangles) to bridge the gap. So we'll start by control-clicking three of the four vertices and pressing "A" to put in the first triangle. We'll then repeat that process to make the other half of the square. Ignore any messages about deletions failing. This is just saving us time later that we'd otherwise waste on navmesh repair.

 

 

If you're following along in the CK, you probably notice how the navmesh on the steps near the new pier might be able to be tweaked a little to try and steer actors away from the collision area that NPCs have trouble getting over. We'll leave that alone for now however and revisit it later.

 

Next up, we need to repeat the same process at the upper cut point. It starts out looking like this, so we can see immediately that we need to adjust the vertices a little bit, since currently they slightly overlap. After a small adjustment, we end up with the quadrilateral illustrated in the second screenshot

 

 

Now, just like the lower cut point, let's fill this with two triangles. With the navmesh rejoined, you can see how the duplicate mesh we created is showing zero triangles (this is the one the game wanted to but failed to delete - it's actually because, in retrospect, I realize I gave it an illegal form ID   If you do this yourself, remember to not ESL flag your working file so you can avoid this problem. Fortunately it didn't cause any problems today.)

 

 

With our work done here for now, we'll click the "finalized navmesh" button, save, and then quite out of the CK. Turn off simple records in xEdit and then load up your working file. The first thing you want to do is run the navmesh edge link cleanup script and then clean the file for ITMs. This will remove any (or at least most) junk edits the CK did without asking you. As you can see below, this fairly simple edit created a ton of wild edits.

 

 

Now look at what's left. You'll notice that there are actually quite a few new navmeshes - this is because the expanded AS mesh interfaces with a number of other cells that vanilla FC127 doesn't touch. It's fine to leave these here for now - we'll screen them out in the next step. However, go ahead and delete the temporary navmesh you created since you're done with that.

 

 

Now let's roll these edits back into AS's main file. Before we do this though, turn simplified records back on so we can have better visual awareness of what's going where. Most of the navmesh records should be identical to what is already in AS, but if you see something has changed, go ahead and overwrite the original with our modified version. For example, you can see here in 0C9DF9E, the edge links have changed slightly. We'll retrofit that back into AS.

 

 

When you find novel entries like this new edit to 54405, we want to copy the working file's record as an override into AS.

 

 

Once those are all done and saved, we're finally done with FC127! Before we move on too much however, let's revisit FC11C. Now with this one, we know we're going to ignore the XPO edits, so we're only concerned with the USSEP navmesh edits, as well as cleaning up that island navmesh we spotted a while back. Visual examination doesn't show any areas where switching to the USSEP navmesh would cause issues with FC11C, so we'll just straight up overwrite with that data (as always, we'll need to clean this up in the CK later to get all the connections harmonized). Once that's done, we just need to remove the calved island navmesh and we're finally done with the Windhelm Docks navemeshes!

 

Hlaalu Farm - Compatibility Patching "vanilla-like" navmeshes

The next navmesh we need to look at is D3669, the Hlaalu Farm area across the river from Windhelm. It has conflicts with Interesting NPCs and with XPO. However, further review of the XPO records reveals that these are just edge links related to the navmesh merges that XPO did in the Windhelm Docks region - so ne need to patch that. AS probably will need a note advising users to load it after XPO, however. 

 

We probably need to look at 3DNPC however and see how it conflicts with AS. However, first we need to scrutinize the AS navmesh itself, first, as it appears to be substantially the same as the vanilla one. This may be a case of a "hidden ITM", so we'll load just AS and its masters and run and ITM check to see what happens. The plugin passes the ITM check, but on closer scrutiny we can see some very minor differences. So this is a legitimate navmesh for AS even though it's not really adding anything. In the process of seeing this, however, we can see that the only difference compare to vanilla are a few edge links. At this stage the compatibility patch is simple, literally just copy-as-override the 3DNPC mesh. During cleanup at the end of this stage, we'll update all the edge links.

 

 

 

Whiterun Exterior 15 - is it, or is it not a simple conflict?

We have a similar situation in Whiterun Exterior 15, though you might not think it based on xEdit. This cell only contains one navmesh (A3449), but it has conflicts between the USSEP and AS. in xEdit, there appear to be substantial differences between all three, especially when it comes to triangle data. Let's compare the layouts of these meshes.

 

 

Comparing these, we can see that, in fact, all three versions are substantially identical. However, when we look at the AS version we see that it adds entirely new triangles as well as a door reference. So we should investigate this in more detail. The door is at triangle 167, and tris 168-179 are newly added by AS. Homing in on 167 and turning the terrain back on, now we can see the conflict - it's the Frostbite Clan outpost at Whiterun! We certainly don't want to kill that, but we also don't want to get rid of the improvements from USSEP, so this'll be a patch job like Whiterun Docks. For ease of navigation, we'll set fairly permissive cut lines, as illustrated below. Basically we'll snip out that corner part at the far side of the road and weld that onto the USSEP navmesh.

 

 

...and here's the result below. One thing you probably notice is that we've lost the yellow highlighting on part of the road. To fix this, we will just select these triangles and click "P" to return the "preferred path" flag to them.

 

 

And with that, we can finalize, save, clean, and reintegrate just like we did with the Windhelm docks. Now AS has all the benefits of USSEP's navmesh improvements without losing the door links and fine tuning in the corner for the outpost. 

 

 

 

That takes us about half way through the remaining navmesh conflicts, which we'll continue knocking out in the next edition of the blog.