Every adjacent cell navmesh has a link table with pointers into these border triangles. If a navmesh is deleted, or merged, or a border triangle is renumbered to be anyplace else, creatures/NPCs will "jump" into that triangle number as they cross the cell border. Sometimes they become stuck in place. Sometimes this also may make it impossible for the PC to move.
fallout 4 navmesh fix
Download File: https://miimms.com/2vFRcr
When you Finalize a navmesh, the CK doesn't just touch the one you are changing. It also saves adjacent cell navmesh. In the outdoors, this results in 4 cells around the square. Presumably, this is to update border links caused by deletion or renumbering -- even when there have been no changes.
The CK works reasonably well only having Update.esm, but is a disaster waiting to happen with multiple modders updating adjacent cells. Each changes 5 cell navmesh, so the conflicting border link tables cause massive confusion.
To avoid deleting or merging navmeshes, use an edge link instead. The same link table that crosses cell borders is also used to create triangle connections within cells, usually where developers want NPCs to "jump" from ledges. Link edges between existing navmeshes without creating a new triangle. (Such links usually appear in pink.)
There exist both indoor and outdoor cells with auto-generated navmesh that is not internally connected. Finalizing such cells or adjacent cells will cause the original navmesh to shrink (renumbering its border triangles), and new island navmeshes to be created. Needless-to-say, this is a potential disaster.
After deleting extraneous navmesh, re-load in CK, carefully select 1 good navmesh vertice (this will usually set the changed flag even though it has not been moved), then save to update the NAVI table.
After Remove "Identical to Master" records, re-load in CK, carefully select 1 good navmesh vertice (this will usually set the changed flag even though it has not been moved), then save to update the NAVI table.
I'd just like to point out that it's probably unavoidable to change the number of triangles in the navmesh when you're building anything of significant size outdoors. It would create an even bigger mess for people to ignore the proper layout of the cell than it would be to leave it alone. Using navcut boxes is only effective as a solution when there's no need for doors to access attached interiors.
For example, in the raw SE Update.esm, there's a cell where they did a Finalize (or something) that drastically changed the number of border triangles, but the changes were not saved properly. Obviously, they aren't using the same CK, or it was an older version, or they saved conflicting navmesh from different edits. There's also a deleted navmesh in this cell.
The above shows the latter triangle references the former, but not vice versa (no match). (In this case, it was apparently an unusual CK error generating the navmesh.) Frequently this is an inverted triangle (wrong way around), done by the CK or by hand. Fixing this will also fix all the missing Found flags.
Sorry, I started to reply to this, and do some navmeshing updates, but then the next version USSEP beta came out that weekend. So waited for stability. The newer CK has some ease of use issues, too. But now that we've given up on USLEEP, at least now I don't have to worry about doing everything twice.
So we select our new .esp and Apply Script "Skyrim - Clean edge links in navmeshes". Now we have only the necessary changes (compare right panels); one changed Triangle, and its new Edge Link #45 appended at the end of the table:
Quit and reload, filter and clean ITMs, and all the unnecessarily included navmesh are removed as well (compare left panels above and below). Only the 2 actual changed navmeshes are present, preventing neighboring conflicts with other plugins:
A can do this & a do not do this tabulation in a pictorial guide might help as well. It's terrific for this good info to be out there, notwithstanding navmeshing having been a longtime bugbear for most at the best of times.
Added parenthetical and italicized directions for your reading pleasure. The 5 navmeshes are a cell in the center, with the 4 bordering cells (nominally up, left, right, down, although SSEEdit by FormID can seem somewhat random; it's just the order they were initially created). The road edge is below the farm. The change is in the left panel.
I've now posted bug trackers for a fair number of the road navmesh issues that I'd found building Touring Carriages. But trying to fix a road segment near Fort Sunguard turned out to be one of the most challenging. Finalizing there found that nearly every navmesh in the area (more than 20) is badly broken. So many warnings that you have to copy and paste them into a document for analysis. Each interdependent with the others.
Instead, use SSEEdit to correct the half linked triangles without affecting the border links. Copy navmesh 000e85c6 into a new .esp. Change Triangle #421 edge 1-2 from 2 to 461, and change Triangle #242 edge 0-1 from -1 to 193. Easy enough.
When examining FortSungardExterior01 with the 3rd navmesh view mode ('w') - navmesh only - it becomes apparent that there are two navmesh, but one of them has two disconnected parts. This should never happen! (But appears in a dozen or so cells.)
When you save, the smaller part (hopefully) will be split into a new third navmesh (here named 0x020099ae, although that changes every repair attempt). There is nothing that can stop this problem. We are fortunate in that the smaller part also has the highest numbered border triangle, so the rest of the cell is unchanged.
UPDATE: Further complicated in the 4 years since I'd originally figured out how to fix this, US*P has updated FortSungardCourtyard (the navmesh has already been split), probably during Finalize of adjacent FortSungardExterior04 (edge cover and removed triangles on mountainside and updated door). Nothing other than the door in the logs. Missing the border connections. So we get to do it all over again, with US*P as a base. Conflicting navmesh is hard.
In this case, the vanilla navmesh 000EDB5E roadway is missing preferred flags. Touring Carriages fixes those. In addition, US*P did "Find Cover". Unfortunately, US*P didn't Finalize, so it's missing half of its border links. (I'll not illustrate, as this is easy to reproduce and surely US*P will be fixed soon.)
Combining the two changes from scratch, cleaning navmesh, repairing the renumbered border triangles, Finalizing, cleaning navmesh again, you'll see the following somewhat interesting xEdit messages from the cleaning script:
When an area has been built and cluttered, we need to determine where actors can navigate. This is where navmesh comes in. Simply put, a navmesh is a collection of polygons that tells an actor where it can walk.
It's easy to take for granted the amount of information we use when playing. Our brains process every visual detail, constantly drawing conclusions and making predictions. Unfortunately, AI systems are nowhere near advanced as the human brain, and must rely on information we provide. Navmesh is critical to the knowledge an AI actor has about any given space. Quality navmesh is an important factor in helping the AI behave as well as possible.
The navmesh editor is a robust tool - which can be frustrating to use at first. We'll learn step-by-step how to get started with it. Once you've learned the fundamentals and had some practice you'll be a navmesh expert in no time.
All navmesh work is done in a separate editor mode. To enter this mode, click the Navmesh Button (Fig. 4.1) on the Main Tool Bar, or press "CTRL+E". The Navmesh toolbar (Fig. 4.2) will appear.
We don't actually need to use anything on the Navmesh Tool Bar in order to auto generate our navmesh; it exists as a convenience. We do need to be in Navmesh Mode in order to use auto generation, however, and the presence of the toolbar lets us know that this is the case.
There are four types of auto-generation: Object Based, Havok Based, Recast Based, and Advanced. For the majority of interiors, you'll want to use the Recast Based generation and clean up your navmesh by hand afterwards. This tutorial will not go into depth on Object Based or Havok Based generation. Advanced users may opt to create all of their navmeshes by hand. Some find this faster than auto generating and then cleaning up by hand - it's all a matter of preference once you become comfortable with the system.
Now that we have a navmesh created, we need to spend some time cleaning it up. The easiest and fastest way to do this is by hand. Before we begin the clean up process, take a minute to look at your navmesh and see where Recast Based generation didn't do so well.
If you're having trouble seeing your navmesh you can try one of the three Navmesh modes: Normal, Transparent, Navmesh Only. Press "W" to cycle through the three different modes, or use the toolbar buttons, pictured here:
When cleaning up automatically-generated navmesh, it's often best to begin by eliminating unnecessary segments of navmesh that have been placed on non-reachable areas. This will make it easier for us to see what's going on with the remaining navmesh afterward.
The Cave area and the stairs of the Nordic Ruins seem to be the biggest offenders. You will also see a lot of navmesh islands. Don't worry about these for now. Once we have cleaned up the main navmesh, removing the islands is fast and easy.
To clean up the cave section, Left Click and Drag Select the vertices in the cave section. Remember to toggle visibility ("W") to get your bearings. Don't worry about trying to preserve any of the navmesh in the cave area: we'll rebuild it later. Be sure that you have Select Vertex (Fig 4.7) and/or Select Triangle (Fig4.6) toggled on. You can clean up the cave section by selecting the vertices or triangles or both. Fig 4.9a shows the navmesh with all vertices and triangles (or "verts and tris", for short) in the cave area selected and ready for deletion. 2ff7e9595c
Comentários