I did a quick search to see if I could dig up any solution but I didn't find anything. When I load up up a mod it gives me a warning about navmesh bounds missing and saying I need to re-finalize the cell - so I do, only next load up I get the same warning. What's the reason for this? What does it even mean to begin with?

When a cell has multiple navmeshes a bound gets calculated and saved out. This is so that even if the cell/navmesh isn't loaded you can determine which navmesh an NPC would be on given their position so that you know what spaces they can traverse.

If you don't mean for there to be multiple navmeshes in the cell, you should be able to find the offender in the object window (probably with an "Island" tag indicating it has no connectivity to other meshes that would allow traversal.) If it's just a speck of navmesh the calculation could be failing to build a valid bound.

If you do mean for there to be multiple navmeshes in the cell, make sure there are no odd geometric features to the mesh - like a vertex that shoots out into the void.

That said the worst case for that warning is that the NPC either gets stuck because they think they can't get anywhere from where they are or they manage to get to somewhere they shouldn't. Both occur because the wrong navmesh is selected when they begin pathfinding.

Hope that helps.

That's excactly what I needed to know, thank you.

Wow, was that a dev?
if so, good news! i have been seeing the same problem.
i guess it isn't a problem : )

I have been getting this message as well. On one cell (RiverWoodPath). I have a mod that puts a shack in that cell and I only started seeing the error since the creation kit and/or game update (not sure which).

I have examined the navmesh thoroughly but haven't been able to track down what is causing the error. So, since I couldn't fine the source of the error I took a follower there and roamed around the cell for a while. The follower didn't have any problem following me everywhere in the cell. I also kept telling her to "wait there" and she was able to get to every place I pointed her to.

So, based on what the dev said earlier in this thread I am going to assume (for now) that this isn't a major issue.

EmptyK, thanks for the comments!

I have edited a LOT of road navmeshes and now getting four of these Warning: Pathfing messages when loading my mod. I have looked at the cells and while they do have mulitple navmeshes, none have the Island tag. I've looked at many of the surrounding cells and I see navmeshes with islands and tried cleaning those up too. These are all vanilla navmeshes, but they are in areas people have reported problems with their horse pathfinding, so I figure it's related. I found the "Navmesh Only" view works great for checking for any strange vertexes, but I have yet to find any problems and I cannot fix the warning.

Given the reported problems, I'd really like to fix these issues. Any more insight you can offer? And thanks for taking the time to help us modders!

I've seen this out of bounds error come up when some navmeshes I was cleaning up and merging together caused the original forms to become deleted. The CK apparently doesn't like that much, and it's well known deleted records cause game stability issues. Refinalizing the cell has no effect because the deleted navmeshes aren't covered by that.

I've yet to run into this on any live navmesh that hasn't been deleted.

One should avoid trying to clean up islands by making them merge with other nearby navmeshes because it will lead to generating deleted records. The safe approach is to find the island and move all of its triangles to somewhere outside the viewing area, then fill in the missing parts on whatever navmeshes remain.

In an external cell, how would you move the island? Wouldn't out of view mean another cell?

Does this error apply if you leave some of the original tris in a cell you are cleaning up? I feel like this error has come up for me but I thought I left some of the original navmesh intact, and likewise this error has only been flagged by CK from the update...

Out of view in an external cell would mean pulling them all far enough below the landscape to be out of the way. There's not much else you could do there. Interiors you can at least drag them outside the boundaries of any of the meshes.

I don't know if leaving a few of the isolated tris will help. In my case I dragged them all out of the way but otherwise left them alone.

Without the deleted forms, the CK stopped complaining about it.

Ok thanks for that, though from what the dev said does it mean the problem only occurs when you have multiple navmeshes in one cell, as that is when the bounds are calculated?

That's what it sounds like, but even with that being the case I only ran into it after trying to merge them into one navmesh.

Unfortunately, I'm getting this with cells I haven't

I've never tried to merge different navmesh groups, and the cells that are being reported do have two (or more) navmesh groups.

I did a lot of testing yesterday evening and I can confirm that Arthmoor is correct that merging navmeshes is one cause of this error. More specifically, it appears that any edit that results in a NAVM record having a "D" (deleted) in the details window will cause this error. I tested this every way I could think of and it was easily reproducible and very consistent.

When you connect two vanilla navmeshes together the CK will flag one of them with the "D" and add duplicates of its triangles to the remaining navmesh. This makes sense considering that after being joined there is only one contiguous navmesh instead of two separate meshes.

Based on these findings I revisited my mod that was getting the bounds error on a particular cell. In that case I had a situation where I needed NPCs to be able to get from one navmesh to another navmesh in the same cell. To accomplish that I had originally just joined the two meshes together. That resulted in the "D" in the details window and the "navmesh bounds missing" error in the CK. I reverted the cell back to the vanilla navmesh and then followed Arthmoor's advice and selected the smaller of the two navmeshes and moved it down on the z-axis below ground level. Then I extended the remaining navmesh to cover the area that was previously occupied by the navmesh I had moved. This way, the end result was that I had a contiguous navmesh covering the two areas and no navmeshes flagged with a "D". After that, I no longer got the "bounds missing" error on that cell.

Also (and this may just be my perception) it really seems to me that NPC movement in that cell is noticeably smoother now that I don't have any navmeshes with the "D" flag.

Did you also cover check and finalize the cell?
no edits to the adjacent cells after finalizing your molded cell?

Shalani,

I did cover check and finalize the cell. Finalizing will always flag all adjacent cells as edited. This is necessary due to the links (indicated by thick green lines) being created between the navmeshes of the adjacent cells. So, basically, any time you finalize an exterior cell it will mark the four bordering cells' navmeshes as being edited (you will see asterisks next to the forms in the CK).

Note that those links between navmeshes in separate cells are not physically joining the meshes of the two cells so they do not result in any mesh being flagged with the "D".

But, when you join two separate navmeshes within a single cell you are actually creating a single navmesh out of the two. So one of the original meshes will remain and it will now contain triangles for the entire region that was previously covered by the two individual meshes. The other original navmesh will be flagged with the "D". And the presence of a navmesh with the "D" always (at least in my experience) results in the "navmesh bounds missing" error occurring on that cell.

If that explanation doesn't address what you were really asking about let me know and I will try again.

It is worth noting that it looks like CK 1.6.89 isn't refreshing the asterisk status until you actually have the adjacent cells in focus. A minor thing, but that's probably why some people aren't thinking it's been edited.