How to resolve NavMesh conflicts in TES5Edit?

[Sacralletius]

While building a new load order, I stumbled upon some conflicting NavMeshes in TES5Edit.

 

I was wondering whether there is a way to resolve them in TES5Edit?

 

This is what I'm talking about:

 

https://i.imgur.com/3SA2UGe.png

 

I doubt a normal Conflict Resolution Patch is capable of resolving these conflicts?

 

Or is there a way I don't know of?

 

Thank in advance

 

Kind regards

 

Sac

[TechAngel85]

Navmesh conflicts, as far as I know, have to be resolved in the CK. You could create a patch with the Navmeshes forwarded from CRF and test it in-game by spawning some NPCs in the areas where bridges are added. You'll quickly know if these Navmesh edits conflict because of how the NPCs navigate the area. If they get stuck or go way off path, you've most likely have issues that will need to be fixed in the CK.

[Kelmych]

There is some useful information about Navmesh conflicts and the Creation Kit in this post and this post by keithinhanoi.

[Teabag86]

Hmmm. CJ used to have a merged file with BCE, Nernies Solitude, Skyrim Sewers and Windhelm Lighthouse in the REGS pack all with perfect navmesh. It was removed for some reason and recommended to install the individual files which I have done. I'm wondering now if I should rebuild the navmesh on these and my other location mods in the CK? However if I delete the navmesh existing records as a first step won't that break the navmesh in mods that add new areas, ie Skyrim Sewers??

[Harpalus]

One thing I've always been unclear on is resolving navmesh conflicts between mods when neither mod edits the same vertices. (Unlike the 15EBB example given in the screenshot). That is, two mods have altered the same navmesh, but neither one has modified a single vertex that the other has (and the navmesh record shows as green text on a red background).

 

Theoretically, the only changes they have made to the navmesh don't conflict with each other, and I fail to see how forwarding the unchanged vertices in this particular situation is a bad thing. Am I missing something? I always see the "never resolve navmesh conflicts in TES5Edit" advice, but I could easily resolve most of my current navmesh conflicts in my load-order as-is without touching the changed vertices in a navmesh. Is this also incorrect? If so, why?

 

Given that most navmeshes that I see change a relatively minimal subset of the vertices in the navmesh, its clear that the unchanged vertices are still referring to what they do in vanilla: the values are the same and this occurs too often to be coincidental. If resolving conflicts as I specified above is bad advice, then I would expect to see completely new navmeshes whenever a mod needs to change them, rather than this patchwork of changed vertices interspersed with unmodified, vanilla vertices.

Edited July 4, 2015 by Harpalus

[Kesta]

@Harpalus :

 

I think you're missing a point, when navmesh is regenerated, AFAIK, there is nothing proven that vertex1 in mod A still match vertex1 in mod B in its "functionnality".

 

 

Here is a quick illustration of what I mean:

(bear in mind that this one is higly innacurate on how navmeshs works and are distributed in the grid, as I have no details on how it's actually done. But from the knowledge I have of both spatial-geometry representation and beteshda's records, that's the best I can come up with at the current time. Oh, and I made rectangles instead of triangles, but the idea is the same)

 

Link for full image : https://www.hostingpics.net/viewer.php?id=725023navmesh.png

 

 

As you can see, if you try to carry informations for vertex 3 from mod A to mod B, you won't get what was expected, since what was vertex 3 is now represented by vertex 11. That's assuming that when the navmesh is regenerated, points are stored in a sorted order, x coordinate 1st, y coordinate second (and z coordinate third, even if z coordinate doesn't appear in my schema). Whatever the sorting order is in the list, the same issue will arise at one time or another.

 

As I said, it's highly innacurate (or rather incomplete), since by the look of the data stored for each vertex, there is probably more than their simple coordinates (most likely, the number of triangle they belong to).

 

 

 

 

As for "fixing" navmeshes, I think the best thing to do is to load both mods in the CK, create a new one as a patch, go into the cell/ws with the conflicted navmesh, and recreate it from scratch.

Edited July 5, 2015 by TechAngel85

[Harpalus]

@Harpalus :

 

I think you're missing a point, when navmesh is regenerated, AFAIK, there is nothing proven that vertex1 in mod A still match vertex1 in mod B in its "functionnality".

 

 

Here is a quick illustration of what I mean:

(bear in mind that this one is higly innacurate on how navmeshs works and are distributed in the grid, as I have no details on how it's actually done. But from the knowledge I have of both spatial-geometry representation and beteshda's records, that's the best I can come up with at the current time. Oh, and I made rectangles instead of triangles, but the idea is the same)

 

Link for full image : https://www.hostingpics.net/viewer.php?id=725023navmesh.png

 

 

As you can see, if you try to carry informations for vertex 3 from mod A to mod B, you won't get what was expected, since what was vertex 3 is now represented by vertex 11. That's assuming that when the navmesh is regenerated, points are stored in a sorted order, x coordinate 1st, y coordinate second (and z coordinate third, even if z coordinate doesn't appear in my schema). Whatever the sorting order is in the list, the same issue will arise at one time or another.

 

As I said, it's highly innacurate (or rather incomplete), since by the look of the data stored for each vertex, there is probably more than their simple coordinates (most likely, the number of triangle they belong to).

 

 

 

 

As for "fixing" navmeshes, I think the best thing to do is to load both mods in the CK, create a new one as a patch, go into the cell/ws with the conflicted navmesh, and recreate it from scratch. 

Thank you kindly for the technical explanation. I'm still hesitant, looking at the number of unmodified/vanilla vertices, but I can see how that situation might arise and how vertices might not refer to the same coordinates.

[zilav]

You can switch off "Simple Records" option in TES5Edit and reload to see more information in navmeshes. There is much more in navmeshes than simple vertex positions to update as noted above, like "navmesh grid" coordinates, center and bounds which all are affected by vertices too.

In short - you can't reliably resolve conflicts in navmeshes using TES5Edit like other records just by drag&dropping several fields.

[hishutup]

You can "kind of" decode the vertex and tri data but it is very limited. I know you can figure out what the tri is marked as, what vertexes its using and some other minor things. As for vertexs, I havent found any pattern other than location data which is not comprehensible.

 

Most nav mesh conflicts are okay but followers and npcs may get suck here or there. If they really need to get to another navmesh then they'll teleport after a few seconds.