1. How To Install Tes5edit

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 by Harpalus, 04 July 2015 - 05:22 PM. @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: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 by TechAngel85, 04 July 2015 - 07:55 PM. @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.

How To Install Tes5edit

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: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.