Jump to content
  • 0
Sign in to follow this  
Sacralletius

How to resolve NavMesh conflicts in TES5Edit?

Question

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

Share this post


Link to post
Share on other sites

8 answers to this question

Recommended Posts

  • 0

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.

Share this post


Link to post
Share on other sites
  • 0

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??

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

@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)

 

725023navmesh.png

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 by TechAngel85
  • Upvote 1

Share this post


Link to post
Share on other sites
  • 0

@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)

 

mini_725023navmesh.png

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.

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Similar Content

    • By packwatch
      Screenshot of the problem:

      I dragged SSEEdit from my 1080P Monitor to my 4K Monitor. Most things scaled properly, except for the font and title bar. I did it again. The font got smaller.
      My monkey brain thought this was funny, so I continued until I couldn't read it anymore. Well, there was NOTHING funny about it AT ALL.
      When I restarted, the font stayed the same.
      Overriding Windows DPI scaling to System for the Mod Organizer and xEdit applications didn't work. Running xEdit manually outside of MO didn't work. Changing theme didn't work. Deleting and reinstalling xEdit didn't work. Setting my windows scaling to 350% makes the font a little bigger, but still barely readable. Changing my Main Display in Windows/Nvidia and relaunching didn't work.
      I've been crying from troubleshooting an infinite loading screen error for the past 2 days and I need xEdit to help troubleshoot it. I miss Lydia. Please help.
    • By keithinhanoi
      Over time, and by reading comments of mod authors, I have learned that for certain record types displayed in TES5Edit, when using the conflict filter feature, some records are incorrectly identified as conflicting (ie., "conflicting" = overridden by a plugin which comes later in the load order.)
       
      For example, ripple, the author of Inconsequential NPCs has explained that location persistent references (LCPR sub-records in LCTN / Location records) supplied by different plugins are not actually overwritten by the last mod in the load order LCTN for certain locations (source). The implication here is that all those references are combined and used from all mods with that record type when Skyrim is started. So in other words, when making a compatibility patch in TES5Edit, you do not need to copy overrides for those particular records.
       
      I have asked in a number of places which records types do not need to be carried forward into compatibility patches, but have never received a reply, and still to this day have not found a definitive list in one place. Well, I'd like to change that, and I need your help, if this is something you are knowledgeable about.
       
      Below is a list of record types, grouped by category, that I have read comments saying they are incorrectly identified as conflicting, because they are actually combined at runtime:
       
      A List of Non-Conflicting Record Types seen in TES5Edit [WIP]
      Default Object Manager (DOBJ)Record sub-record types:
      DNAM - Objects  (Confirmed here) Dialogue Topic (DIAL) Record sub-record types:
      TFIC - Info Count  (Confirmed - sources: here & here) Dialogue Information (INFO) Record sub-record types:
      PNAM - Previous Info  (Confirmed here) Idle Animation (IDLE) Record sub-record types:
      ANAM - Related Idle Animations  (Confirmed here) Location (LCTN) Record sub-record types:  (Confirmed here)
      ACPR - Actor Cell Persistent Reference LCPR - Location Cell Persistent Reference RCUN - Reference Cell UNique ACSR - Actor Cell Static References LCSR - Location Cell Static Reference RCSR - Reference Cell Static Reference ACEC - Actor Cell Encounter Cell LCEC - Location Cell Encounter Cell RCEC - Reference Cell Encounter Cell ACID - Actor Cell Marker Reference LCID - Location Cell Marker Reference ACEP - Actor Cell Enable Point LCEP - Location Cell Enable Point NOTE: Other LCTN sub-record types require conflict management.
      (Confirmed - sources: here, here, here & here)

      Story Manager Quest Node (SMQN) Record sub-record types: (Confirmed - source: here & here)
      SNAM - Child sub-records QNAM - Quest Count / Quests Story Manager B??? Node (SMBN) Record sub-record types:
      SNAM - Child sub-records  (Confirmed here) For more details about how the above listed sub-record types merge at runtime, please see this excellent opening thread post by Arthmoor from 12 March 2014. Many thanks to him for confirming / explaining all of these, and a tip of the hat to MonoAccipitor for noticing Arthmoor's post.
       
      I will update this list with additional confirmed non-conflicting record types based on your replies.
      Thanks in advance for your help, and let's hope others can benefit from this list!
    • By KillingMachine1914
      Greetings, 
       
      As it was stated in the title, it seems DynDOLOD is not applying modded statue of Azura (Sexy Statues Skyrim v2 NSFW Warning) when generating LODs. When I launch the game, vanilla Azura appears instead of the modded variant. The modded statue of Azura will only appear once I get close enough to it. Also, I installed a mod which resize the statue 2x its normal to make it visible all across Skyrim (Elizabeths Tower - Azura Shrine SSE).
       
      I have checked SSEEdit to see what defines the conflict and it turns out DynDOLOD.esp set the statue as persistent only and removed "is full lod" definition which was there in Elizabeth's Tower. I have very little idea of what those terms mean but my gut tells me that it has something to do with the trouble I am facing currently. Hence, is there a method to overcome this matter? 
       
      Thank you very much in advance.
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.