HOW TO USE TES5EDIT TO FIND MOD CONFLICTS MODS
Edited Jby :Īs 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. Whatever the sorting order is in the list, the same issue will arise at one time or another.Īs 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).Īs 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. 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). Oh, and I made rectangles instead of triangles, but the idea is the same)Īs 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. 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. (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. Here is a quick illustration of what I mean: 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". 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. 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.
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. 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. 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). (Unlike the 15EBB example given in the screenshot). One thing I've always been unclear on is resolving navmesh conflicts between mods when neither mod edits the same vertices.
0 kommentar(er)
