Let's start by squaring away the two cosmetic issues - the geometry conflict with Groot's Solitude and The Ruins. There are two statics causing potential problems for us: a tower that partially blocks the door to the Solitude club and some rubble that protrudes out of the wall of the Windhelm club. We'll also do a quick tour of the Riften and Windhelm club interiors with a light source equipped to check for any out of place objects or opportunities to integrate other content.

 

 

Windhelm Men's Club had a Talos statue in the basement, but that's actually thematically appropriate for that region, so we'll leave it alone. I toyed with making it one of the more lewd versions, but I think those are already adequately distributed in the world. 

 

OK, so our to-do list here isn't that bad. We need to...

 

1. Move the rubble outside WMCExterior 1

2. Remove the corner building in Solitude World

3. Reposition the lavendar plant by the SMC entrance so it doesn't intrude into building bits

4. Move the floating Yuriana poster

5. Fix the navmesh door links

 

We'll start by putting the items we need to edit into a working file. 

 

 

 

With those changes made and rolled into the conflict resolution patch, all that's left are those pesky door links. If you recall from last time, the issue is that the base file of SMC had two door links with problems - this was related to changes to the navmesh in the residential district, which added a number of new triangles. The door links point at those triangles and don't line up with my patched navmesh for LOTD and so forth. 

 

In theory, the location patch should have fixed this, but while it changes the coordinates of the door it didn't change the triangle assignment. Consequently, the door link is still looking for the modified navmesh. 

 

[00:00] [REFR:00090E58] (places SHouseDoor03 "Door" [DOOR:0005D7EA] in GRUP Cell Persistent Children of [CELL:00037EE6] (in SolitudeWorld "Solitude" [WRLD:00037EDF]) at -14,24)
[00:00]     REFR \ XNDP - Navigation Door Link \ Teleport Marker Triangle -> <Warning: Navmesh triangle not found in "[NAVM:000ECFFC] (in GRUP Cell Temporary Children of MuseumExterior [CELL:00037EE3] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -14,24))">
[00:00] SMCDoorExt [REFR:EE00AA48] (places SHouseDoor01 "Door" [DOOR:000368CE] in GRUP Cell Persistent Children of [CELL:00037EE6] (in SolitudeWorld "Solitude" [WRLD:00037EDF]) at -14,24)
[00:00]     REFR \ XNDP - Navigation Door Link \ Teleport Marker Triangle -> <Warning: Navmesh triangle not found in "[NAVM:000ECFFC] (in GRUP Cell Temporary Children of MuseumExterior [CELL:00037EE3] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -14,24))">
[00:01] Done: Checking for Errors, Processed Records: 4645, Errors found: 3, Elapsed Time: 00:01

 

The first door, 90E58, we can ignore - the conflict resolution patch already fixes this one as its a vanilla door that was just updated to point to the new navmesh. EE00AA48 is the one that could cause trouble. This one point to triangle 7 on ECFFC. The vanilla mesh is small - just one triangle - and so it can't map to the Triangle #7. What we need to do is go into Solitude and find the new navmesh triangle for this door. 

 

 

Below you can see the navmesh at the new door location, pulled from my navmesh conflict resolution patch. We seem to be looking at B328A, triangle 69 (or 56 if we want to be more conservative). We'll make the actual changes in xEdit. 

 

 

 

 

With that done, we'll delete the NAVI record from our navmesh conflict resolution patch, clean the edge links, then regenerate the NAVI and (obnoxiously) clean the edge links again. If you recall from previous diaries, the way to regenerate the NAVI is to open the patch in the CK and save it (no edits required). The save process will recompile the NAVI record.

 

At some point I'm going to need to dive into that navmesh patch a little, because we do have some issues starting to trend in the edge link report; basically, there's a slow accumulation of flawed navmesh data from various mods that is causing a lot of red herrings in the cleaning report. These issues aren't normally game breaking - likely at worst to cause some odd or inefficient pathing - but cleaning them up will prevent them from concealing more serious issues. 

 

 

oh FFS. I love how the CK runs out of memory (that's what the C-5 exception indicates) long before the actual game does. Looks like its time to fork the navmesh patch, which is something I kind of hate to do. What I'm going to do here is copy all the Solitude World navmeshes to a new file and then clean masters on the original. After that, we'll need to regenerate the NAVI for both files.

 

This kind of issue, by the way, is an argument against using "all in one" patching tools like Wrye Bash for a complex load order. When you reach a certain level of complexity, you'll lose the ability to edit your patch in the CK, and while xEdit can do a lot, it can't do everything. NAVI regenerating in particular can be complicated, since it often won't play nice with the workaround of using a temporary working file for the CK actions.

 

 

Well, that didn't fix the problem on its own, so we may have a case here where there's a deeper issue at work. Minidump analysis didn't add much. You can see where it runs out of memory but there's no good way to tell if it was a genuine "out of memory" failure from loading too much or if the problem is that there's some kind of unloadable record causing a loop that fills the memory with garbage. 

 

 

Isolation testing narrowed the issue to the specific navmesh with the door link error, so it seems that we've still got an unresolved problem hiding in there. We'll remove the door link for now and see if that fixes it, then chart a course of action moving forward. 

 

Clearing out that record did allow me to load the navmesh in the CK, so now we need to go into it and fix that problematic record. We'll first try to do this entirely with the CK, by editing the opposite door and hopefully goading the CK to fix the missing data. If that fails, then we'll probably need to go and do some manual editing. Let's see how it looks in xEdit afterwards.

 

There we go! Embarrassingly, it seems the issue was that I needed to use my 'second guess' tri, #56. We'll patch this into our navmesh file and try to regenerate the NAVI again.

 

 

Success! With the Navmesh Info Map regenerated, we just need to clean the edge links and we're done with this exercise  

 

 

Well, that gets the Men's Club mod properly fixed up. All that's left now is to go through conflict resolution, but hopefully what remains will be minimal. And indeed, on review that was exactly the case. I did need to do a little management of top level cell data and forward a few edits by other mods to vanilla Solitude scenery - totally expecting considering that I have some pretty extensive Solitude mods loaded - but otherwise the hard conflicts were quite light. As expected, there were several landscape edits, notably in the Riften area, that I may have to revisit in the future if I really start expanding the suburban part of that city, but for now we can leave them as-is. 

 

The final step to put this one to bed is to take a look at the NPC records. At a minimum, they need the Exhibitionist trait so they don't play modesty animations in the bath. For the new NPCs this was a simple case of directly editing the records, but its a bit trickier for the vanilla ones. For those, I had to copy their packages to a working file and then, in turn, move their NPC records.

 

 

From there I was able to follow there 'referenced by' data to the NPC records and inject the exhibitionist attribute. With that final bit of integration completed, we can put this one down and move on to Man Those Borders!