[Lyd]

Wow... that's interesting. I knew there a bunch of seemingly senseless NVMIs written; but being so many of them, and so tedious to track down (actually have to search for the FormID embedded in the beginning of it) that I never looked into just how senseless they got. I assumed that cells bordering cells being finalized have their NVMIs written to the mod... which is a bit excessive but I see the value in it; as the finalized cell may have changed the border-merges. But if they don't, I believe those subrecords shouldn't be written, that's where it gets excessive.

Now.. have you discerned which NVMIs are auto-gen'd so irregardfully? (I like to make up words, and that's one of my fav's) I see our problematic Whiterun is one of them... perhaps if these were exhaustively listed we may have a listing of what I called the 'Anathema Cells'. Perhaps it really is the CK doing something it shouldn't... or at least writing something in that data that shouldn't be there; if this is in fact the case.

[Christina Trayler]

Arthmoor: Using your own logic, I demand to know which subrecords are damaged by Snip and how to exactly reproduce it. I'd be curious to know the list of things you seem to presume I forego... and specifically what my mods damage. BTW... your Open Cities won't work even without using Snip... I thought I proved that with my Riften/Whiterun Experiments, but I realize that every one of those posts made you cringe; rendering you unable to read them. [not for nothin, but if CK fixes the aforementioned problems, as you seem to agree to, how is STILL not an exceptable work-around?]

So would you like me to compose a 4 page long wall of text that says a lot but contains no actual useful information? No? Didn't think so. So I'll give you the information as I received it, minus who told me since neither of us have said anything about this before:

Some records have an extra flag that's set which means that there is additional compressed data beyond the quoted size. Snip only processes the quoted size amount and drops the rest. figured out what was going on with that and we're processing all the compressed data.

As a quick test, load Skyrim.esm into Snip and resave it (under a new name of course). It will be larger, which is fine. I don't think you have to recompress the data, although you should. If you flip things around and load the resaved master, you'll find lots of stuff missing in the game.

So no. Based on that, TESVSnip is not safe to use. I got further clarification on some of it:

Oi. Ok. I'll track down which records are affected. I know we found the sub-records, as I'll call them, in NPC records. I'm pretty sure they're in cell records too, so yeah, that might be why things are missing.

Try it with the skyrim.esm and you'll see what I mean. It won't crash your game - at least it didn't mine. But it looks super weird.

After that, I did what was suggested. It's super easy to verify, and extremely enlightening. Strongly implying LAND and NAVM records are likely affected since they both contain compressed data. CELL records are definitely affected considering everything outside of the immediate cell I was standing in vanished completely. Except the trees. No idea why the trees survived. No placed references besides those were present. It looked exactly like descriptions I've seen of dungeons going missing, interiors of house mods going missing, etc. My follower fell over the side of the edge of the cell, so there's nothing there at all. It's not just hidden from view.

Since NPCs are affected by this for sure, there's no telling what information is being lost. If the information is lost, the CK can't resurrect it. Damage done. I used TESVSnip on Open Cities, it has LAND records in addition to NAVM records. Since it's been conclusively proven that Snip isn't necessary to induce the navmesh bug I don't think it damaging those records would matter.

The author of TESVSnip was notified, but it appears the project has been abandoned.

[Ells]

Now.. have you discerned which NVMIs are auto-gen'd so irregardfully? (I like to make up words, and that's one of my fav's) I see our problematic Whiterun is one of them... perhaps if these were exhaustively listed we may have a listing of what I called the 'Anathema Cells'. Perhaps it really is the CK doing something it shouldn't... or at least writing something in that data that shouldn't be there; if this is in fact the case.

i didnt write down the list of form ID's, but you can create a new empty cell make a single navmesh triangle, then finalize and save. go to the NAVI in tessnip and check out the NVMI's. obvoiusly the one with the 01 form ID is your triangle, but the other 9 or so are auto-gen'd by the CK and its always the same ones.

After that, I did what was suggested. It's super easy to verify, and extremely enlightening. Strongly implying LAND and NAVM records are likely affected since they both contain compressed data. CELL records are definitely affected considering everything outside of the immediate cell I was standing in vanished completely. Except the trees. No idea why the trees survived. No placed references besides those were present. It looked exactly like descriptions I've seen of dungeons going missing, interiors of house mods going missing, etc. My follower fell over the side of the edge of the cell, so there's nothing there at all. It's not just hidden from view.

Since NPCs are affected by this for sure, there's no telling what information is being lost. If the information is lost, the CK can't resurrect it. Damage done. I used TESVSnip on Open Cities, it has LAND records in addition to NAVM records. Since it's been conclusively proven that Snip isn't necessary to induce the navmesh bug I don't think it damaging those records would matter.

The author of TESVSnip was notified, but it appears the project has been abandoned.

whoa that's pretty scary. i've already used snip on my current WIP mod. i'd hate to have to start over.

[Alyesha Neufeld]

Yeah, I'm certainly not keen on the idea either. So far it doesn't look like anything I did got damaged, but I'm certainly not about to use Snip on my stuff again. Especially since future work I have planned involves NPCs, landscaping, navmeshing, and cell work. All of which are affected in some way by this.

Data loss = BAD.

[roxanna matoorah]

so that makes me wonder if both issues combined (the snip data loss, and the CK writing NVMI's for whiterun/helgen etc) is what is causing those particular areas to break most often for navmeshed mods that dont have anything to do with those trouble spots.

if i want to clean out the potential damage done by snip in my current WIP, do you think duplicating the cells in their entirety in the CK will allow for the CK to create new legit records in the duplicated cell, or do you think the damage is done forever? i really dont want to start over and i feel a bit paranoid releasing this mod having already snipped it many times

[anna ley]

Those NVMI records belong there. That's how the NAVI system works. I'm sure JustinOther could explain it better since he has more exposure to it, but there's nothing wrong wit those showing up the way they do. They're in every mod ever released with a navmesh edit.

We don't know specifically yet what portions of CELL records are lost, only so far that compressed subrecord info in NPCs gets lost and you'd have to go back and set whatever those belong to back up again. If you have landscape edits, those should automatically fix themselves, but you can be double sure by making a small tweak somewhere in each cell you edited it in. That would force the information to be regenerated. Cells I guess you could fiddle with lighting data or fog or something. Enough to force it to regenerate the records for those. Duplicating them probably wouldn't do the job and would likely make things worse.

[Amy Gibson]

manually going in and "touching" cell and NPC stuff to register a new edit in the CK would certainly be easier for me than starting over, or tracking down and re-chaining properties and links etc for duplicates. if thats all it takes to re-correct the data loss, thats a relief

[Neliel Kudoh]

I appreciate the explanation on compression and Snip... I understand it better now and see why you're so concerned. One question though... do we know this definitely affects ALL plugins? That quote and your examples cite editing skyrim.esm to test - but doing that for any reason is a mistake... and really unnecessary in my opinion. Skyrim.esm could have been compressed using something other than our public-version CK.. so I don't think that's the best way to prove or test this. A simple little ESP should suffice... I may have to start keeping a reminder text file of things I'm supposed to be testing further heheheh.

My spodum mannequin mod was Snipped a bit, but it seems to function uneventfully. There ARE isolated complaints about strange behavior, but that's true for ANY mod and is usually chalked up to anything BUT the suspected mod... heheheh. I'm currently working on an update for that mod, so I'll DEFINITELY be looking into this I go along. It may be a little while to see results, as I'm rewriting the entire mod basically - to be alias-driven instead of each mannequin having a million properties on them (seen in the console with showvars).

The NVMIs, from what I see, are basically placeholders which point to the NAVMs, which in turn contain the actual geometry. [I'm sure there's more to it than that - but like I said, I'm more of a 'big-picture' kinda guy.] By deleting one, the game-engine no longer can send an AI-driven actor TO that navMesh... but if forced into the area (by console, script, or whatever), the actor will behave normally because the NAVM is still intact. Since the NVMI for Vanilla is presumably still intact, the actors can LEAVE the area... but not return. This is why at one point I suspected the NVMIs to be causing the NavMesh Bug... but even if they were, I don't know how to edit that raw data to do anything meaningful with it.

[Shannon Lockwood]

Testing it on Skyrim.esm was just the most dramatic way to see the results. I haven't been able to reproduce the effect on a straight ESP, so I'm thinking that the problem manifests more with people converting to ESM files.

[Dagan Wilkin]

hmmm... I'll note that for when I get around to testing it.

But I thought of a way to better describe my theory/suspicion regarding NavMesh Bug... this is based on my Riften and Whiterun Experiments. Just because one person isn't willing to actually read through a wall of text doesn't mean it has no valuable data. In this case, quite the contrary in my opinion. I just posted my actual notes in case anyone wanted to see how I arrived at my conclusions, or if there was anything I missed. [I've since removed the files from my Dropbox, but if anyone wants to dl them and see my 'proof' just let me know and I'll put em back up.]

What I think it comes down to is this: ALL the data is valid... NVMIs and NAVMs. It seems to be the game-engine overlooks/nullifies/misinterprets the NVMIs of certain cells after fast-trav-return (during certain specific 'events' such as onCellLoad). The NAVMs are intact even AFTER the bug is triggered (possibly one of the most important findings of my Experiments)... proven by actors forced back into the area, either by script or console or whatever... telling a follower to "wait here" seems to work as well - since they are tethered to ONE spot (and apparently some mechanism forces them back to it).

I concede that it's possible there is still corrupt data to blame, and simply not noticed until fast-trav-return. But since we all know the area will work perfectly upon first-arrival, that indicates the data is NOT corrupt. There COULD be some kind of flag or minor block of data which trips something up... though the 'important' remains intact. I looked at the raw data but didn't see anything out of the ordinary.. so if this IS the case, it's most likely a small block of corrupt data. I never looked more into this using a simple navMesh test; altering one tri of Vanilla in a known trouble-cell... test for the bug, then compare the raw data between it and the Vanilla.

I tried this briefly during the Experiments, but one NVMI was identical yet still Bugged... though it's possible I chose the wrong NVMIs to compare so I want to revisit this eventually (searching for tiny anomalies). I'm also suspicious this really is the case, because ESM/ESP combos seem to work in some cases; yet the only difference between ESM and ESP is the single flag... is ALL the other data in those files not identical? That's why I'm led back to the game-engine nix'ing the NVMI under certain conditions, such as during the time the engine triggers onCellLoad events.

[EDIT: type-o]

[James Rhead]

it will function, it's just not the correct way to do it (although we have no choice otherwise). the navmeshed esm has navmesh info in the NAVI group with no ONAM. it may work fine for you during testing and initial playthrough, but as soon as you start adding in other mods with NVMI edits, the whole thing starts to cave in (missing architecture and statics in several RANDOM places, but most frequently in DB sanctuary, Helgen, and whiterun) long story short, it works, but its dirty as hell. it is NOT a solution to the navmesh bug, it just offers an alternative bug in place of another bug (you decide which is worse). it is physically impossible to create a clean esm/esp pair with the given tools we have. some are more successful than others, but none are legit

I know you guys are just trying to anolyze this and so forth, but quite frankly, my eyes start to glaze over (and my head hurts, lol) when I try to understand all this ONAM / NAVI / NAVM stuff.

Bottom line, is it just safer to assume at this point that doing some combo of esm and esp is not going to be a viable solution? If so, should we just plan on doing everything in an esp like normal, but adding a HUGE disclaimer that the navmesh bug will probably happen, and just be prepared to save and reload your game when it does? I hate to say it, but I’ve said all along that while I hope Beth fixes it, I don’t believe it CAN be fixed. And they’re completely silent other than “we know it exists and are looking into it”.

[Jesus Lopez]

its safe to assume there is no viable solution whatsoever (until beth fixes it).

there are only shoddy workarounds, and you have to decide if the workaround is worth it, because any workaround to the navmesh bug comes with risks, and can and will introduce new bugs also (although there are a handful of lucky success stories under very specific conditions). but its a BAD idea to use an esm without understanding the gamble you are taking, and the possible damage you may be causing to users of the mod. i'm not saying dont ever use esm, im just saying understand all the currently known risks if you do use esm, and that there may possibly be other unknown side effects


as arthmoor pointed out above, it may not necesarilly be conflicting NVMI's causing the esm bugs, but quite possibly because of the use of tessnip causing the strange things to happen, especially in esm's

there may still be some hope for esm/esp combos, but at the end of the day, it wont ever really be an optimal workaround without the ability to write esms the legit way through the CK (with ONAM lists)

[Lori Joe]

Thanks AD, that's what I figured. I think I'll just stick with the esp, at least I know what that may possibly introduce, and with the other methods Gods only know what may happen it seems. Ggrrrr......

[Dalley hussain]

I'm not being an expert on any of this, so please forgive me if this has been covered and discounted elsewhere.

Using TESVSnip (yes, I know it introduces its own bugs), if I alter NAVM values "unknown2" and "unknown3", my esp NavMesh starts working properly (no longer requires esm-pair).

I can tell this, because I have an interior cell with lots (20) of Mannequins and the NavMesh seems always (?) to manifest with "wandering" Mannequins.

If I change the "unknown" values, the Mannequins stay in place on Terra Firma and in my limited testing (more to do), NPC followers don't get stuck.

Anyway, I thought it worth posting, even though my results may possibly due to random coincidence or just a brain fart on my part.

Thanks

[Michelle davies]

Using TESVSnip (yes, I know it introduces its own bugs), if I alter NAVM values "unknown2" and "unknown3", my esp NavMesh starts working properly (no longer requires esm-pair).

Altered the values to what exactly? That could be useful information to provide to Bethesda if it's something that can work consistently.

Though, yes, I'd strongly advise against doing this for a serious mod since TESVSnip WILL corrupt data in the file.

[Esther Fernandez]

I haven't seen any values like that under an NAVM.. what version of Snip are you using? I only see a single NVNM subrecord with a single block of data in it. Also, the wandering mannequins are caused by a little glitch in the AI system (my interpretation)... the NavMesh Bug only makes it worse.

But about those NVMIs that get written every time: If navMesh is contained in the plugin anywhere (even when NOT finalized yet), the CK writes the following NVMIs EVERY time the ESP is saved. Presumably, if these areas happen to be changed in the mod, those changes should be reflected - but I haven't gotten that far yet.

000A3F44 RoriksteadEdge (-22,2)
0010377B DawnstarWesternMineExterior (6,24)
00098776 HelgenExterior (4,-19)
00100F4B WinterholdExterior01 (26,25)
00105E9A SolitudeExterior03 (-18,24)
000B87DF WindhelmAttackStart05 (33,5)
001030CB SalviusFarmExterior01 (-40,1)
00079BBF WhiterunExterior17 (5,-4)
00103120 (42,-22)
000E88CC (-9,14)

So far, I only found the Vanilla NVMI for Helgen... the mod's is identical to Vanilla (before AND after finalizing). You'll notice that Riften isn't included, and the Whiterun cell listed is too far away to cause that area's problems... so this find backs up the findings I made back then - that NVMIs are not damaged (at least not ALL of them are). I still think that something triggers them to be nullified or overlooked; it's about the only logical explanation left.

On a different note: Another thing I was testing was a huge list of console commands I found somewhere on the net. Someone had dumped the EXE or some such thing. But I've found anything related to memory stats or navMesh seems to have been disabled... intentionally. I'll see if I can find a link to the orig listing... I don't wanna post this without crediting the person or at least linking to wherever. But I found some commands which let you list all meshes and textures loaded at a given time; as well as list the stacks and update-registrations for running scripts.

[not for nothin, but I thought this forum WAS for telling Ma Beth about our findings... where else is there to do it?]

[Monika Fiolek]

I'd like to know what those values are too.

[Trish]

No idea what he might have changed them to but if you double click on the NAVM it brings up a separate screen in which will see what refering to, same as what allows to convert to esm ... presume that is where he made the change as they are in the 1st col at bottom. i am still using v4.0 myself.

[Elle H]

Vague information on this find is vague. I'll get that app and look at this myself >_>.

[Tinkerbells]

Those are the 2nd and third 'flags'. I too experimented with these, and thought I found something but it turned out not to make a difference. I'm fairly certain I posted the results a while back. I seem to remember one being changed to something in modded cells, but changing it back didn't help. An example is that vanilla cells have 003A6813 for flag1 and that is changed to all 0s.

I found another one of those Vanilla NVMIs... for Wilderness cell -9,14. Like Helgen's, it was identical to Vanilla. So I think it's safe to say that those ten NVMIs which are always written on a save, if the plugin contains navMesh, do not cause any problems.. and shouldn't cause any if deleted. Since they don't take up much space, I doubt there's an overwhelming need to do this, and would just leave them - especially if there's a risk of damaging other data by doing that (as it would have to be done in Snip or other 3rd party app).

But earlier today I did a little looking into the NAVM records. It appears as though the ones that are auto-gen'd when finalizing a cell (and/or saving the ESP when it contains navMesh,even unfinalized), are identical to Vanilla. I also have decoded nearly the entire NVNM subrecord's data structure. Check it out:

This is the original NVNM from HelgenExterior (one of the cells which has an NVMI always auto-gen'd by the CK). The NVNM subrecord is what the NAVM record consists of; as I said before, it's basically the geometry.

Spoiler

0C 00 00 00 3C A0 E9 A5 3C 00 00 00 ED FF 04 00 0A 00 00 00 BA F3 81 46 68 95 97 C7 01 89 00 46 2C 58 81 46 2A FF 97 C7 93 9B 00 46 D5 A0 83 46 27 FF 97 C7 14 82 00 46 1A 39 81 46 0F 62 97 C7 6A 8E 00 46 00 00 80 46 83 26 97 C7 4B A1 00 46 95 82 81 46 5C 47 97 C7 5A 8A 00 46 05 86 82 46 E6 75 97 C7 06 77 00 46 53 06 83 46 82 86 97 C7 C6 74 00 46 00 00 80 46 F6 6B 97 C7 25 9B 00 46 EE 45 81 46 1B A4 97 C7 91 4A 01 46 08 00 00 00 02 00 00 00 01 00 04 00 02 00 00 00 04 08 00 00 09 00 03 00 08 00 07 00 06 00 FF FF 00 08 00 00 09 00 01 00 00 00 FF FF 00 00 07 00 00 08 00 00 04 00 03 00 05 00 06 00 FF FF FF FF 00 08 00 00 02 00 06 00 00 00 05 00 FF FF 00 00 00 08 00 00 06 00 02 00 07 00 04 00 FF FF FF FF 00 08 00 00 03 00 04 00 08 00 03 00 FF FF 01 00 00 08 00 00 00 00 03 00 09 00 FF FF 01 00 02 00 00 08 00 00 01 00 00 00 00 00 00 00 90 8C 0D 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 40 35 E8 43 00 A7 D8 43 00 00 80 46 2A FF 97 C7 C6 74 00 46 D5 A0 83 46 83 26 97 C7 91 4A 01 46 08 00 00 00 00 00 01 00 02 00 03 00 04 00 05 00 06 00 07 00

Here's the breakdown of what it all means:

Spoiler

0C 00 00 00
?- dunno
- value of 12 if used as a short or int
- seems to be the same for every NAVM

3C A0 E9 A5
?- seems to be 2-2byte shorts, possibly a max/min of some sort
- values of -24516 (3C A0) and -23063 (E9 A5)
- not coordinates
*- seems to be the same values for every NAVM

3C 00 00 00
- FormID for Tamriel WRLD record

ED FF 04 00
- Cell coordinates in the worldSpace (listed Y, X); -19y (ED FF), 4x (04 00)

0A 00 00 00
- # of vertices in the NAVM, value of 10 short or int (0A 00/00 00)

BA F3 81 46 68 95 97 C7 01 89 00 46 2C 58 81 46 2A FF 97 C7 93 9B 00 46 D5 A0 83 46 27 FF 97 C7 14 82 00 46 1A 39 81 46 0F 62 97 C7 6A 8E 00 46 00 00 80 46 83 26 97 C7 4B A1 00 46 95 82 81 46 5C 47 97 C7 5A 8A 00 46 05 86 82 46 E6 75 97 C7 06 77 00 46 53 06 83 46 82 86 97 C7 C6 74 00 46 00 00 80 46 F6 6B 97 C7 25 9B 00 46 EE 45 81 46 1B A4 97 C7 91 4A 01 46
- Coordinates of vertices; listed XYZ, XYZ, etc
- uses 4bytes float numbers
- above has a starting value of 16633.86x (BA F3 81 46), followed by -77610.81y (68 95 97 C7), and ends with a value of 8274.642z (91 4A 01 46)
- above lists a total of 10 vertices' coords (total of 30 coords, 10-XYZs)

08 00 00 00 02 00 00 00 01 00 04 00 02 00 00 00 04 08 00 00 09 00 03 00 08 00 07 00 06
?- connected vertices (00 through 09 for a total of 10 vertices)

00 FF FF 00 08 00 00 09 00 01 00 00 00 FF FF 00 00 07 00 00 08 00 00 04 00 03 00 05 00 06 00 FF FF FF FF 00 08 00 00 02 00 06 00 00 00 05 00 FF FF 00 00 00 08 00 00 06 00 02 00 07 00 04 00 FF FF FF FF 00 08 00 00 03 00 04 00 08 00 03 00 FF FF 01 00 00 08 00 00 00 00 03 00 09 00 FF FF 01 00 02 00 00 08 00 00 01 00 00 00 00 00 00 00 90 8C 0D 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00
?- Specific edges, their cover data, and preferred/water flags
- FF FF FF FF then 11bytes
- 00 FF FF 00 then 13bytes
- 00 FF FF 01 then 10bytes
- it may be 00 FF FF FF FF 00

40 35 E8 43 00 A7 D8 43 00 00 80 46 2A FF 97 C7 C6 74 00 46 D5 A0 83 46 83 26 97 C7 91 4A 01 46
?- Seems to be a max & min of some sort
- then two sets of XYZ coordinates
- uses 4byte floats
464.416 (40 35 E8 43), 433.3047 (00 A7 D8 43)
16384.0 (00 00 80 46), -77822.33 (2A FF 97 C7), 8221.193 (C6 74 00 46)
16848.42 (D5 A0 83 46), -77389.02 (83 26 97 C7), 8274.642 (91 4A 01 46)

08 00 00 00 00 00 01 00 02 00 03 00 04 00 05 00 06 00 07 00
- # of tri's in the NAVM, value of 8 short (08 00)
?- 4bytes of 0s for buffer
- then lists each tri in the NAVM (01 00, 02 00, etc)
- total of 8 tri's listed 00 through 07

So there you have it... NAVM refs solved (for the most part.. heheh). I haven't tried manually adding vertices & tri's yet.. but I see very little reason this can't be done. Though I also see little to no reason to DO such a thing. I figured you guys might like to know what's in that record, and that it most probably has nothing to do with NavMesh Bug.

One thing I discovered while doing this.. if you try to r-click/edit a NAVM ref in the cellViewWindow, it pops up a little window which allows you to name it ("ID" and an empty box); but it also has a little checkbox with "Initially Disabled" next to it. I haven't fooled around with this yet, and I assume it's for areas which come into play later or earlier in the game (such as the ship, or if Helgen had wreckage that were later removed).

My point is that if there's a simple little toggle-box for disabling the NAVM, which is pointed to by the NVMI, could it be that this toggle is temporarily tripped for some reason to cause the NavMesh Bug? I say temporarily, because I proved that the navMesh remains intact and usable, but AI packages are broken during the onCellLoad (or similarly timed system event). If that switch was turned on then off again, that would cause the effects we see by NavMesh Bug. Question now is how do we test this, prove it, and/or make something feasible to correct it?

[EDIT: type-o and this addition.... I also looked at the same NVNM after adding a single tri to the NAVM. This is how I decoded it all. The point is that new vertices are simply tacked onto the end of the data block, as well as the couple other changes as noted.]

[Laura Elizabeth]

You mean this?

Type: NAVI
FormID: 00012FB4
Flags 1: 00000000
Flags 2: 00000000
Flags 3: 000E0028

[Sarah Kim]

Yea.. those are the ones, but it was for the NAVM record I believe. Either way it wound up not making a difference... no matter what I did to them. My guess is that it either affects something that one can't really see in-game, or it's legacy data leftover from the games of yore.

[EDIT: seems my "f" key is a little sticky today...]

[Kellymarie Heppell]

Haven't seen any NAVM in there, just that and a bunch of NVMI entries. Unless I'm not looking in the right place.

[Sandeep Khatkar]

One thing I discovered while doing this.. if you try to r-click/edit a NAVM ref in the cellViewWindow, it pops up a little window which allows you to name it ("ID" and an empty box); but it also has a little checkbox with "Initially Disabled" next to it. I haven't fooled around with this yet, and I assume it's for areas which come into play later or earlier in the game (such as the ship, or if Helgen had wreckage that were later removed).

That disable box has no effect in Skyrim. It's a leftover from Fallout. It used to be possible to toggle a navmesh via scripting, but that's no longer possible now. I doubt it has anything to do with the navmesh bug because that information was easily toggled before and nobody ever mentioned it helping.

Functionality to do this has been replaced in Skyrim with collision boxes set to the L_NAVCUT type.

[Jani Eayon]

I mentioned this in another thread but I thought I would add it here as it may be another piece to this complicated puzzle. Forgive me if this has been mentioned before I haven't read all 3 previous incarnations of this thread.

I have a dungeon that has 2 cells. The first one that connects to the world is fine when I first enter, but when going back out through it the navmesh is broken. The strange part is I am also seeing what I assume are bad roombounds/portals. In the halls where my roombounds connect there are spots where the game will not draw the other room, as if the portal were slightly askew or offset. Saving and reloading fixes the navmesh and the bad portals.

Of course when I load up the CK the portals and roombounds are all well. And in the second interior cell I haven't noticed any navmesh problems, which figures as it is the one that the majority of players would only enter once, while the first cell they have to go back out through, possibly with an NPC escort.