Search the Community

It's been 4 years and I cannot remember where (or even which forum) we had the old thread, so here's a new place to discuss. AFAICT, this hasn't been improved in the SE CK. The first principle of navmesh modding is: never delete or merge navmeshes! That way lies CtD (crash to desktop). The second is like unto it: to reduce the number of conflicts, border triangles should not be renumbered! 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. If possible, have the same number of triangles as the original. When you delete any triangle, the CK renumbers. This often changes border triangles. Therefore, great care must be taken. It is usually better to first create a new triangle over the old, then delete the old triangle so that the new triangle is renumbered with the old triangle number, then join/merge the final vertice in place. (This technique is also used to repair border triangles.) When you "Find Cover" for a cell, sometimes the CK renumbers triangles. Up to 2 sides of cover are saved (the 3rd side is assumed to be flat to the adjacent triangle), so triangle vertices sometimes need to be rotated to allow the cover data to be in side "0-1" and/or side "1-2" (as shown in xEdit). Apparently, the CK deletes the triangle (causing renumbering), then adds a new one in the proper orientation. Yet the CK already has a user tool for rotating a triangle without renumbering; it fails to use it internally. 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. (Following posts have more detailed information.) See also: https://www.afkmods.com/index.php?/topic/3337-skyrim-fixing-navmesh-deletion-using-tes5edit/ https://www.afkmods.com/index.php?/topic/4072-navmesh-audits/

Has anyone investigated the UFO Crash site with a follower / companion of the two legged human variety, and experienced odd behaviour of the companion ? In the following screenshot I have llamaRCA's new companion Heather in company. She avoids the "bowl" of the crater which is just before where the ship is (behind me in the screenshot) And occasionally when she sandboxes away to the other side of the crater bowl, she will launch into the air and then drop back to earth I am guessing that after the crash maybe the game is supposed to set a new navmesh for the changed landscape, and its a bit buggy.

This is another fairly strange discovery, made again while working on my mod. Cell 19,-9 was the perfect location to place some objects, so I arranged everything, then adjusted the navmesh, finalized it without problems, saved, and got the well-known annoying editor warning on reload. Nothing too unusual, actually, but read on. Inspection of my mod in TES5Edit revealed, that I did not accidentally delete a navmesh, but only modified it, as expected. There was however another navmesh in the cell, and this was marked as deleted. Back in the CK with only Skyrim loaded, the cell view window listed in fact two navmeshes for this cell, FA18B and FA18E, with 122 and 432 triangles, respectively. Actually, there's only one navmesh, however: the cell has one comprehensive mesh and there's no trace to be seen of a second mesh anywhere. I did check every single triangle and they were all displayed as belonging to FA18B. When I right click on the navmesh entry for FA18E in the cell view window and select "view" (while in "navmesh only" view mode in the navmesh editor), I only get a blank screen, while doing the same for FA18B displays the cell's navmesh as expected. After modifying the navmesh to some extent, only FA18B is marked as modified in the cell view window, while FA18E is still marked as untouched. Though, when I save my mod, the CK repeatably marks FA18E as deleted. A close inspection of FA18E in TES5Edit showed that this mesh, although apparently not existing, has connections to both the visible (i.e. editor-visible) navmesh and another "ghost mesh" (checked this in the CK) in cell 20,-9. So far, it also appears that these are the only two cells with ghost navmeshes in the whole southwestern Eastmarch area. What a lucky guy I am to hit just one of these two cells ... On my way to solve the problem, I opened the mod in TES5Edit, removed the deletion override of FA18E and saved. Back in the CK, I suddenly had FA18E as a VISIBLE duplicate of the unmodified FA18B (sic!) overlapping with my modified navmesh in the whole of the cell. I will now reduced the duplicate to a few triangles, move it out of the way and see whether this works. Now, there also is a reason why I'm posting this in the UOP forum: (1) The navmesh in one corner of cell 19,-9 is poorly constructed and two points are below a tree with refID 000B57E7. (2) There also remains the question whether those ghost meshes might break things and need to be taken care of.