LOL maybe daddy will cheat on the wife and the other woman will give birth the Navmesh bug bastard child.

heheheh... you guys are incorrigible. I guess I could 'enable' you guys a bit more...

I started experimenting with Whiterun last night... results are ALMOST consistent with Riften, except one glaring difference. The "Anathema Cell" (one which seems to cause the NavMesh Bug, and 'infects' adjacent cells) in Whiterun HAS Vanilla navMesh, whereas Riften's didn't. This blows my "nilla-less theory" outta the water. So it seems that skank bridezilla has indeed slept with brother of NavMesh Bug... Also, the cell I expected to be troublesome (based on the Riften Experiments, the nilla-nav-less cell), worked perfectly... it was the cell NEXT to it causing drama.

Something I DID find encouraging, I'm going to go back to test in Riften. In Riften, I didn't use patrols to truly test AI, only currLocSandbox... so it was unclear the extent of the AI breakage. In Whiterun, I used the Delphines but linked to patrol routes. I tested four cells, WhiterunExterior04, 05, 02, and 03 (the four which include the main gate, Breezehome, and the two JUST south (half inside the wall, half out). I placed two Dels in each cell, then sent one of them on patrol to another cell, and patrolled the other inside the same cell as placed.

The 04 cell (the main gate of Whiterun), is the one which seems to be Anathema... but has plenty of nilla-nav. Cell 05 (the cell containing the front door of Breezehome, and heads north from there) is the only cell in the whole Whiterun area which has no nilla-nav whatsoever. Cell 05 ALWAYS works... no Bug except when the Del set to patrol into Cell 04 is broken (on fast-trav-return); at which time she just stands in one spot (sometimes walking around searching for her proper path, but stops eventually not finding it).

Actors placed in Cell04 are ALL broken; ones placed and set to patrol intracell spawn in nilla-nav (as they did in Riften). Dels set to patrol outside Cell04 either spawned with the intracell Dels or spawned in the cell they are set to patrol to; upon a second fast-trav-return, they spawn in the opposite place (if the other cell, they would spawn outside the gate on nilla-nav inside Cell04), if the 1st FTR found them outside the gate they would spawn in their target cells the 2nd FTR (sometimes standing still, sometimes briefly 'searching for NavMesh in all the wrong places' heheh).

Now where it gets interesting in THIS volume of The Rise & Fall.... those actors all had the mannequin script attached to them (ie: they were set to be forced BACK to their linked ref onCellAttach and chosing 'do nothing' when activated). All of them did this dutifully; except in the Anathema Cell 04 (as I would have expected them to, but they didn't). Upon FTR, they spawned outside the CUSTOM navMesh (either on nilla-nav, or outside the cell completely) as they do without the script (I tried it both ways).

When they are activated (forced by User back to the linked ref, which is the patrol marker); they DO force back as they should. Check THIS out: the ones set to patrol intracell started patrolling normally (inside the 'broken' Anathema Cell)!! The ones set to patrol outside still were broken (and again, either on nilla-nav or in the cell to patrol to).

THIS leads me to believe that only the cell-borders' merges are broken... the navMesh itself is still intact and functioning (as partially shown in the Riften Experiments). During the making of the Whiterun ESPs, I encountered outright breakage of the cell-borders after running a "Check NavMesh" on the Anathema Cell. This breakage was fixed by re-finalizing the cell, yet without editing the navMesh whatsoever; in-game the problem was NOT fixed, but behaved as described above.

*** My conclusions based on these new experiments are that CELL-BORDER MERGES may be the ACTUAL damage being done to navMesh somehow. I also found MORE evidence that running a 'check-nav' on an Anathema Cell reliably FORCES that breakage; as well as more evidence supporting that certain orders of doing things (session-related functions; such as saving the ESP, finalizing, etc) help damage something as well.

Also, that NPCs can still forcibly function properly inside a damaged cell - but NOT using regular game AI or scripting (the cellAttach didn't work, but the activator-forcing script DID)... this kinda supports the theory that something is being misinterpreted or 'broken' during the onCellLoad event (and possibly during Attaches too).

The only similarities between the two NavMesh Bug-struck cells in Whiterun & Riften are these: cell-border merges are broken, custom navMesh is abandoned for nilla-nav (upon AI breakage), and perhaps some session-related functions in the CK. I STILL think CK is responsible for the drama - and the game-engine merely falters over the strange data...

None of this helps those who would give up or detract from the hunt... so don't even bother posting your derision - you know who you are. Just keep playing 'armchair-modder' and hope 'ev-ting be aw-ight-ie' (as some say in the Caribbean).... keep waiting for the one-button fix, and the one-sentence explanation. These findings only serve to explain why your broke-down NPCs appear in the actual places they appear; as well as helping to explain why some mods work and others don't (eg: because only CERTAIN CELLS CAUSE DRAMA.. not the entire municipality), and to further narrow down the ultimate cause.

Here's my notes, not nearly as long as Riften's... as I can kinda see when results start repeating themselves. If anyone wants the ESPs linked to Dropbox, lemme know. Also, at the bottom, are some notes on the actual NVMIs (subrecords of the NAVI record in the NAVI grup)... in an attempt to see if there was anything glaring which may have stood out - nope. But the data structure seems to be fairly simple... so maybe someone more proficient in ascii/hex-recog should glance at it for inconsistencies (between an Anathema Cell's NVMI and a normal cell's).

Spoiler

VANILLA Errors & Specs
= loading WhiterunExterior04 in the CK triggers the "horse errors" (MODELS:Bone Harness Right/LeftBone). This cell is the main gate to Whiterun.
- there is no Vanilla navMesh on the interior of the walls/gate.
= loading WhiterunExterior05 triggers a texture error (like the grey-head bug), then a MODELS:Could not find the model path\00073FD4.nif; also for 00073FD8.nif, 0007C4D3.nif, 0007C4D2.nif, another texture error, anothr model error for 00073FD4.nif, another one just like it, 73FD8, 7C4D3, 7C4D3, 7C4D2, 73FD4, 7C4D3, and the horse errors (not a marker, just the two harness)
- WhiterunExterior05 is the only cell in Whiterun which has no nilla-nav whatsoever. This is the cell which contains the front door of Breezehome.

WHITERUN EXPERIMENTS
("=" indicates the results testing in-game)

1a
- placed two doors near the main gate, linked em, moved one and its marker inside the gate (yet in the same cell
- created navmesh in that cell (wrExt04) and three others (wrExt01 & 02, and wrExt05 being my expected troublemaker)

1b
- finalized all four cells; 04, 02, 01, 05 (counter-clockwise from the main gate)
- no errors, all cell-borders merged to solid-green
- save the ESP, navBar closed

1c
- created the Delphine clones, placed 9 of them (3 in 04, 2 in each of the other cells)

= everything worked fine, except one delphine from 02 spawned outside the walls (about 20-30ft away fro mwhere placed); all others still sandboxed in the cells but had wandered slightly (though still on custom navMesh, except the one outside the wall)

2a
- same setup as Test One, except not saving the ESP until the very end (with navBar closed)
- also adds some dwemerFacadeBridges because Whiterun's interior landscape is too rough for NPCs to navigate correctly
- finalizing showed no errors, saving (navBar closed) triggers the following error:
[[PATHFINDING: Precomputed path init - Could not resolve location for Road Marker 000f077d, please verify its placement]]
[[PATHFINDING: BSNavmesh::GetMatchingEdge() for (Navmesh 0x00089ffd, Tri 5, Edge 0) - Bad matching triangle index: Navmesh 0x0010f682, Tri 15]]
same for 0x000ea081, Tri 299, Edge 0 for index 89ffd, Tri 11
same for 0x01000d77, Tri 0, Edge 0 for index ea081, Tri 310
same for d77, Tri 9 Edge 1, Index 0x0010f682 Tri 9

= everything same as above except - the 02 Delphine stayed where she was supposed to, BUT ALL THREE Delphines in 04 spawned outside the wall (ie: on Vanilla navMesh)

3a
- same as Test Two except saving before any navMesh has been made
- adds patrol markers and places actors in four cells with them (one crosses a cell-border and the other patrols inside the cell; for each cell, plus one extra actor in 04; total of 9)
- each patrol marker is then linked to a static deer skull, one placed for each patrol marker

= on first-arrival actors placed in cells with Vanilla navMesh spawn inside it instead of on the spot without navMesh where placed, actors placed in the cell with no navMesh at all just sandbox in-place... and wander slighty as expected

3b
- creates the navMeshes in all four cells, saves with navBar closed no errors

3c
- moves the vertices close enough to merge cell-borders, tweaks all the rest a little, saves with navBar closed no errors

3d
-finalizes them in the 04ccw order as above, no errors
- saves with navBar closed, no errors
= the three actors in 04 spawned outside the wall, all others spawned in the places they were supposed to, none of em patrolled while some tried to move but seemed a little stuck after a step or two

3e
- adds patrol idle time .25 to each marker
= same as 3d except one of the 04 Dels spawns inside

3f
- deleted the sandbox AI, added the defaultMasterPackage
= first-arrival all of them were patrolling as they should be; though it took several seconds for the AI to fully kick in, before that they seemed to studder and bump into each other
= fast-trav-return finds two from 04 outside the gate (facing the wall, not moving), the other one inside the next cell (05, not moving), and one in 02 wasn't moving either; all others were patrolling normally
= a second fast-trav-return finds three outside the main gate now, but the third isn't the one from 04, it's the one from 02 which was standing still before (the one whose patrol crosses into 04); the one from 04 just standing in 05 was there again (its patrol took it into 05

*** It seems WhiterunExterior04 is the Anathema Cell for Whiterun.

4a
- uses the ESP from 3c, changes the patrol idle time to .25, changes the AI tothe master package

4b
- finalizes the cells from 05cw, saves with navBar closed
- when saving, triggers the 'precomputed path init road marker f077d' error
= only actors placed inside 04, and have patrols that enter 04 are broken

4c
- moves one of the actors from 04 to outside the gate (onto Vanilla navMesh, patrol inside it too)
= the one placed in nilla-nav keeps patrolling normally; while the others placed in the same cell, but on custom-nav, spawn on nilla-nav after fast-trav-return.. while the ones with paths going into 04 were just standing in place inside their other cells
= also, of the two that spawn outside the gate, one of them keeps trying to walk through the wall (bumps into it, turns around a little, then bumps into it again, forever)
= a second fast-trav-return finds the outside spawner that just stands still, standing still inside 02; all else is the same

5a
- uses the ESP from 4a, finalizing the cells 05cw, saving with navBar open, same path-init error as above
= same results as 4b

5b
- deleting the custom-nav in 4a triggers the 'bad matching triangle error (0x01000d8c Tri0 Edge2, index 01000d8d Tri15) simply by scrolling over a little (not even saving)
- rebuilt the 04 navMesh, finalized no errors
- saving (with navBar open) pops up the road marker errors, and the bad matching triangle index error (01000d8f Tri10 Edge1, index 10f682 Tri19)
= one of the 02 actors stood still (the one that should patrol into 04) on first arrival, fast-trav-return finds all four actors with AI in 04 outside the gate
= second ftr finds the 05 actor standing still in 05.

*** It seems that actors whose AI enters an Anathema Cell will either spawn in their original cell or in the Anathema Cell (inside Vanilla navMesh), seemingly toggled between the two on alternate ftr's.

5c
- added mannequin scripting to the actors (to force them to their markers onCellAttach)
- saving with navBar open, it pops up the normal error, and the 5b bad matchtri error (same one), AND another one (01000d8c Tri2 Edge2, index 10f682 Tri4), and another (d8c Tri4 Edge2, index f682 Tri 2)
= in-game, first-arrival had most working normally, except the cross02-04 and 04-05
= ftr finds the inra04 outside the gate, the 04-02 in 02 (then walks a bit trying to find path, can't find it so stops), and the 05-04 in 05 (standing still)
**= activating them resets their position; if AI is ALL in 04 then it works, if AI crosses cells then it stands still in other cell (or walks a bit to find path, then stops)
= second ftr finds one of the intra04's still in 04 patrolling, others are stopped/searching in other cells, and one outside gate

5d
- running a checkNav on 04 no errors, on 05 triggers Pathfinding one common edge error.
[[PATHFINDING: Navmesh 01000d8c Cell 'WhiterunExterior05' (000095FB)(5,-2) in WorldSpace 'Tamriel' (0000003C) and Navmesh 01001854 Cell 'WhiterunExterior04' (000095FC)(4,-2) in WorldSpace 'Tamriel' (0000003C) have at least one edge in common but are not connected. Are the navmeshes Finalized?]]
then shows no more warnings after clicking yes
*** it BROKE the merged cell-borders between 04-05 AND 04-02 (ONLY the custom navMesh merges.. the Vanilla ones in 04 remained intact); another checkNav shows same error
- refinalized no errors, checkNav all the cells no errors, saving with navBar open only the marker error
= first-arrival had everything working perfectly, ftr had the same except the intercell patrollers to 04 were stuck in their other cells (one was searching)
= second ftr finds one intra04 outside the gate, 2 in 02 and 1 in 05 (all stuck, not even searching), with all the others patrolling normally




***looking at the ESPs in TESvSnip:
- NVMI is a subrecord under the NAVI (which is one record containing a subrecord for each navMesh reference contained in the plugin)
- each NVMI has the FormID of the navMesh it points to at the very beginning of the subrecord
- the byte immediately after it (the 5th byte) seems to indicate the presence of doors (02) or not (00), I don't know what 04 does (maybe 4 doors?)
- all NVMIs seem to have a common block going backwards from the 8th byte from the end (00 00 3c a0 e9 a5 3c, where the last 3c is the 8th from end)
- 16, 17, 18, 19th bytes from beginning seem to be the cell where it's located (2 bytes are cell coords)
- then four groups of zeros, an 02, then three groups of zeros (00 00 00 00 02 00 00 00)
- then it has the FormIDs of navMeshes it is connected to (back to back)
- next, navMeshes with doors seem to have their data in there, before the aforementioned common block (8th from the end)
- NVMI always ends in 00 00 00, then the cell coords (2bytes each) eg:fe ff 04 00, next to fd ff 04 00, fd ff 05 00, and fe ff 05 00 (test cells are 5,-3; 6,-3; 4,-2; 5,-2 NOT respectively)

Amethyst: I know it's off topic... but maybe your mannequin script is running a little slow because you kept the Vanilla slot system? Converting it to an array system sped it up for me and Daemonjax.. maybe it'll help seeing as your script triples the number of slots. The nilla-slots were pretty inefficient and took up a BUNCH of space.

If you DID convert it, and it's still slow; maybe the only thing that'll help is to divide the workload to indiv scripts (eg: using a quest to 'activate' them or something.... which would be started/linked to your button activator or whatever).

I think I may have made a breakthrough... can someone please try this and let me know of the results? I discovered this last night, and have been testing it all day; with near-perfect results.... my point being: this is NOT an impulse-post, this is for REAL... though my standard disclaimer applies (this may not help EVERYONE). If my results are conclusively verified independently, this would fix MOST instances of the NavMesh Bug; as well as prevent it from happening in a new mod. It also seems to permenantly 'innoculate' against recurrences (what I believe is caused by 'floating custom navMesh').

While this should work for any mod afflicted with the NavMesh Bug, it's mainly for use on mods which cannot use the ESM/ESP technique, which I personally believe is the preferred method should a mod qualify to use it. In other words, this is mainly for mods which alter ONLY Vanilla cells and have NO custom interiors or worldSpaces (which would qualify it for the ESM method).

POTENTIAL NAVMESH BUG FIX:
1- load your ESP in the CK; once ready, load one of your Bugged cells in the renderWindow

2- (in the cellViewWindow) connect a Vanilla navMesh to your custom navMesh (in the same cell) with new tri's, by SELECTING THE VANILLA VERTICES FIRST (then select a vertex on your custom nav and press "A"); >selecting your custom vertices first, then a Vanilla vertex, converts the whole NAVM to custom not to Vanilla<
* for 'islands' or places such as balconies, this may require you to have a few tri's which go vertical or inverted,thus causing errors on finalize/save; just ignore the errors and hit "yes to all"; just link your as-is navMesh... don't worry about the long tri's connecting or how actors will walk across it
* There cannot be navMesh refs which don't start with "00", make sure they are all merged into a Vanilla NAVM or deleted.
* If there is no Vanilla navMesh in the cell whatsoever, keep your entire navMesh for that cell in one single mass.

3a- finalize, save, test in-game; if it works skip to Step 6
3b- if it didn't work, reload the backup ESP (before you tried Steps 1&2)

4- delete all NAVMs which don't start with "00"; rebuild the deleted areas by ONLY ADDING TO VANILLA NAVMESH (or a single mass if no nilla-nav is present)
* ALWAYS check that the refs begin with "00" before testing in-game; if you highlight your custom nav first, then link it to nilla-nav, you MAY turn the entire nilla-nav into 'custom' nav (it'll ALL be in a ref beginning with "01" or "02"/etc). If this happened, you need to exit the CK and reload your ESP which still has nilla-nav refs in your troubled cells (start over again).

5- finalize, save, and test in-game
*** your ESP shouldn't have ANY non-nilla navMesh in Bugged cells... it should only have nilla-nav refs which are larger then Skyrim.esm's refs.

6- if working correctly, (in the renderWindow) delete the navMesh tri's you added/normally wouldn't have (eg: the two vertical tri's linking a balcony to the sidewalk below)

7- refinalize and save, test in-game
***** your ESP should now have custom NAVM refs for the areas you deleted at the beginning, but THESE refs should now work without the NavMesh Bug; other islands added should also be Bug-free

IF ANY ACTORS' AI IS STILL BROKEN:
- try deleting the actor and any references it is linked to; replace them fresh, save, test
= if still broken, you may have to completely rebuild that entire cell from scratch


I tested this for a few hours today, with several ESPs and under various circumstances. Occasionally, one or two actors will still remain "frozen" (standing on top of their linked marker); what causes this and why it's fixed the way it is... I have no idea. Only ONCE could I not get an actor to work.. no matter what I did to fix it; for this ONE actor I wound up repeating the entire test over... and it worked perfectly the second time (further evidence of a session-related bug).

You'll also notice that some mods may work with minimal effort, while some may require rebuilding the entire navMesh from scratch; my tests show both are possible. I think the amount of edits and saves have something to do with the latter... the less it's been tweaked and re-saved, the less likely it is to be truly effed in the a.

I also tested my method on Open Cities v.33.. I got about 60% of that mod working correctly - only because I didn't apply the fix to all the cells, and there are still some minor mistakes in the mod which relate to AI. In that mod, most of Whiterun and Riften are both working Bug-free in all my tests; outside that mod, they work fine as well.

I have a bunch of footage recorded (from both my experiments and from OC-fixed); I got the first-arrival (which ALWAYS shows perfect AI), the Buggy fast-trav-return (FTR), proof that only the cell-border's navMesh merger is what breaks, a partially fixed mod, a completely fixed mod, and some footage of how I actually fixed it in one instance (within seconds). I need to arrange and edit it down, then re-encode it for upload (about 15gig+ of video right now)... but I'm kinda sick of looking at this stuff right now, so I'm gunna hold off till tomorrow I think.

But if my results are verified, the NavMesh Bug will be all but completely done-for. All my tests show that it's the cell-border mergers which break, with intraCell AI remaining intact. Any AI package set to travel across a broken cell-border will be broken; although AI that travels INTO the broken cell works.. it's the RETURN leg of that patrol which breaks (causing the actor to stop moving at the last marker before border-crossing). Actors with broken AI will wander, unless linked and forced to a ref by script. Wandering actors tend to prefer the highest navMesh in the same cell (if no nilla-nav is present), they also spawn on Vanilla navMesh instead of custom (if the given cell contains both).

What it seems to come down to is the Bug seems to be caused when a custom navMesh reference is created in a Vanilla cell (ie: a NAVM which doesn't start with "00"). If this is correct, the mechanism behind merging navMesh refs together before/during the finalization process may be what damages or breaks the plugin (which I'm 90+% sure is the NAVMs which are damaged). I found that if you select the vertices of a custom navMesh (eg: one whose FormID starts with "01" for instance), then select one vertex of a nilla-nav and press "A" - then that entire nilla-nav ref will be lost... absorbed into the now-larger custom-nav ref.

All the above is taking for granted that you cannot use an ESM for your mod AND have eliminated all other possibilities for buggy navMesh; eg - save the ESP while the navBar is closed, save the ESP before finalizing a cell's navMesh (and after), do NOT run "Check NavMesh" on a Vanilla cell, do NOT run an auto-gen of navMesh in any Vanilla cell, do NOT run a 'selective recast auto-gen' inside ANY cell already containing navMesh, and ensure your actors' AI is properly set up. Just the few sentences in this paragraph may be enough to help some people cure their bug... the balance of whom should be helped by the above procedure.

If you want to see The Rise & Fall of Family-NavMesh Bug for yourself, here's the Dropbox link to the more pertinent ESPs:
http://dl.dropbox.com/u/67168394/NavMesh%20Bug%20FIXED.rar
[all edit the Tamriel cells inside the Riften walls; fast-trav to Riften Stables and go through the dwemer door you see in the middle of the road. Once inside, follow the actors down the sidewalk and around the corner. For the buggy versions, look to the left of the North gate before entering the city; once inside, walk all the way to the other gate at the south entrance (next to my other dwemer door)... you'll see the Wandering Bug manifest as the actors spawn outside the wall]

- 10f is fixed and working [all actors patrolling their proper routes]
- 11a is the same ESP as 10f, but with the 'floating custom' navMesh re-severed from Vanilla (as per Step 6; and is STILL working). [all actors patrolling their proper routes]
- 12a is basically 10f before the fix was applied... showing NavMesh Bug behavior but NOT Wandering Bug; as the actors are forced back to a ref by script after FTR (my mannequin script fix). [intraCell actors will perform AI as normal, interCell actors stop on their markers before leaving the broke cell]
- 15a is the same as 12a, only with the mannequin script removed (actors no longer forced to their ref after FTR)... this shows how actors with 'improper' AI will wander; both the NavMesh Bug with the Wandering Bug. [interCell actors stop on their markers; intraCell actors in cells containing nilla-nav will wander to that nilla-nav (eg: outside the gates), intraCell actors in cells with no nilla-nav will patrol as normal]

Again, I have video of all this and more... I'm just not enthusiastic enough at this moment to do it all up; especially since this would be youTubable if proven true! SOMEBODY at least try those ESPs linked to above... and having seen that it works, try it in your OWN buggy mod (or send it to me to experiment with).

[EDIT: you also need to be running my "living" version of the Vanilla Mannequin Script Fix.. or the actors I placed in all but 15a will NOT behave as I describe.
http://dl.dropbox.com/u/67168394/mannequinActivatorScript.pex]

Yeah, so no potential fix.

I'm going to give it a go.
Quick question,...how do I delete the navmesh that's already there, without deleting the vanilla navmesh ?
ie. how do I reset it to how it was before I started navmeshing ?

Terra Nova: If a mod can be made NavMesh Bug-free by using the ESM method, how is that not a already fixed? (barring the purist view which shuns all 3rd party hackage) This procedure was tested on nilla-only cells; because that's the kind of mod that still cannot be fixed with ANYTHING (except maybe the ONAM lists, but I don't remember).

TambO: hmmmm - that depends on what you did to the navMesh. In the cellViewWindow, select your Bugged cell... at the top of the list should be your navMeshes. Mouse-over each one to check for ones beginning with "01" or anything other than "00"... those would be the custom navMeshes.

Also, you can ADD to existing Vanilla navMesh... in which case, to revert it to the original state I would suggest deleting the NAVM refs (using TESvSnip, NOT the CK). Then loading the ESP in the CK should trigger the skyrim.esm navMesh to return.

Everyone: I know you're all skeptical... this has been going on for a couple months now (several YEARS for some). It would take no more than 5 minutes to download that RAR file, extract it, enable one of the working ESPs, and test it in-game.... you could be the first to say I'm full of krap should it not pan out. You're already reading forums for solutions and help (presumably.. unless you're the Pulp Fiction 'shepherd' heheh), so here's a solution I believe will work - TRY IT. Just try the example ESPs first!! If they don't work as I said, I won't post back to this thread ANY more... what more incentive could you need??

Tamb0, I use TESVSNIP to delete the navm reference for that cell. The vanilla navm is untouched and you can start over.

Dave, can you delete unwanted portions of the vanilla mesh without breaking it?

...to revert it to the original state I would suggest deleting the NAVM refs (using TESvSnip, NOT the CK). Then loading the ESP in the CK should trigger the skyrim.esm navMesh to return...

Not too sure what I'm doing with TesVsnip.
I loaded up the esp and expanded it. Can't see any NAVM refs. I do see a -
-GRUP (NAVI) - Navigation (master data). This expands to a sub heading NAVI. When I click on NAVI, I get this in the right hand pane -

[Record]
Type: NAVI
FormID: 00012FB4
Flags 1: 00000000
Flags 2: 00000000
Flags 3: 000E0028
Size: 35,740
Subrecords: 72

Do I just right click on the -GRUP (NAVI) - Navigation (master data) and select delete ? or select The NAVI branch and delete it ?

Sure... by selecting and deleting the indiv tri's. But I dunno if that would work to fix the bug or not, I didn't test it. You may not need to delete or change it at all... my tests showed if custom navMesh was connected to Vanilla (in the same reference/NAVM), it would work.

My point is that if you also have a non-nilla 'island' in that Bugged cell (even though it may not be LABELLED as an island), THAT'S what I think causes the bug... and should be deleted or merged into a nilla-nav as above. If you're getting buggy behavior from navMesh added to a Vanilla ref, and that buggy cell has NO non-nilla NAVMs.... I'd have to look at the mod; and would certainly change my opinion about what causes/fixes what.

I STILL believe not ALL problems are caused by ONE bug; as I've shown already. The MAJORITY of problems ARE... and this fix is for them; the possibility it may not work for some is due to what the problem actually IS (such as a cell-borders's vertices not being close enough to merge.. probably WON'T help problems such as that).

Tamb0, look for the Navm references under the cell references you are trying to modify. Interior cells are under cell, and exterior cells are under World, or something like that. It's like a treasure hunt looking through the groups for the right cell references if your mod is large.

Ahhh... you need more experience working with the raw data formats. The NAVMs are located in each CELL (under the CELL grup and the WRLD grup... expand ALLLLLL the way down until you see a bunch of REF, ACHR, NAVM. Now you need to find the cells you actually edited... when finalizing a cell's navMesh, new records are written for ALL the surround cells' navMeshes (though they aren't changed, they are essentially duplicates of what's in skyrim.esm). This may confuse you when you expand those records (WRLD/CELL grups)... "how did so much KRAP get in my mod when I only added a single door to one cell?"

Once you find the cell you actually altered, select and r-click the records to delete, then select delete (using the delete BUTTON has been buggy for me... sometimes deleting records previously but not currently selected). To be EXTRA thorough (though I'm not sure if necessary, I'd do it to make sure): select the NAVI record (under the NAVI grup)... select each subrecord - looking at the first four bytes of data (which is the FormID of a NAVM, in 'reverse'). The very first byte will be the LAST two numbers of your NAVM's FormID... the quickest way I found was to get that number (mouse-over the record in the cellViewWindow), then select each record - scanning that first byte for the last two numbers I'm looking for. But delete those NVMI subrecords which link to any NAVM you deleted. Then save the ESP; click yes when the CK asks to correct the number of records in the header.

For my purposes, I put the interior cells in esm and the exterior cell in an ESP. It's my external cell that suffers from the bug. I need to the vast majority of the vanilla mesh to make room for the building then create a great deal of new mesh to connect the patios. I think I understand your methodology of keeping the mesh under the vanilla reference. I hope i can make it work. Too bad there is no good solution for the custom cell besides converting to esm.

Thanks Folks,...mod is navmesh free
I'll try what SluckyD suggests and see if it'll fix things.

If the exterior consists of Vanilla cells, then yes - I'd put them in the ESP... along with ALL navMesh data (ALL cells, NAVMs and NVMIs), as well as ANY Vanilla refs you change (moved a tree for example). If you have a custom exterior worldSpace, that should go in the ESM. To be safe, ANYTHING I place (add) to Vanilla worldSpace goes into my ESP, as well as changes to the content in the ESM.

It sounds like its Vanilla you're messing with; in which case I've had plenty of success deleting a bunch of it.. then adding to it for my custom areas (my Tower mod alters like 4 nilla cells, one of which needed extensive 'nav-remodelling'). Others beside me have had success with Ye Olde ESM Methode... I'm fairly certain ElDiabs did with Deus Mons; and that mod's used by tens of thousands uneventfully (barring the occasional non-navMesh related conflct).

What it amounts to is that you may not need to jump through hoops to get your mod working... unless you're modding a KNOWN Bug-Zone (eg: if you use the ESM technique above, and it still doesn't work). Personally, I know Wilderness 42,-24 and WhiterunExterior04 (both in Tamriel worldSpace) are both buggy... what I call Anathema Cells. There's bound to be more... like one in Ivarstead I found buggy once. Why these cells... I dunno.

heheh.. I see noone's taken me up on my 'modder dunking-booth' yet... (try the test ESPs above, if they don't work as I describe I won't post back to this thread anymore). Though I just saw that TambO seems to be interpid enough to take it on... I hope my instructions are easy enough to follow! (the process is VERY simple once you understand the concept I'm trying to convey)

I'm working with both actually. Right now it is two custom interiors connected to adjacent exterior cells in the Tamriel Worldspace. Its really a pretty simple mod I guess, but it would be wonderful if I could make it all work in one esp so it will work right on the Workshop. I've remeshed the different pieces a number of times and it is still infected. It would be nice if I can at least get the exterior to be free of the bug. The interior of the Warehouse just has 4 merchants that are not really very affected. The Bedroom has two housekeepers and a housecarl. Its nice if the housekeepers actually move around and keep house, but I guess its not an absolute necessity.

i think this is worth noting here, but i have had some success with the navmesh bug by completely ditching navmesh linking altogether.

in other words, if you are using a custom worldspace, do not nav-link it to tamriel in any way shape or form. keep all of your custom navmesh in the esm, and make sure that none of it has any trace of vanilla records at all.


so how do you travel into your custom world if it's severed from tamriel completely?

in a completely unaltered vanilla navmesh you can place certain refernces which will be recorded in tamriel's base cell 00000076 (or something like that i cant remember the exact form id), and NOT the wilderness cell. these references can be doors, markers and trigger volumes.


that said, obviously placing doors means you have to re-finalize navmesh anyway right? possibly, but who says you even need a door at all.

i tried creating a fake door with a trigger volume set to player activation and a small script that does a game.fasttravel(yourRefMarker) and it works perfectly. the follower travels with you and does not get sent to have a cup of tea with Sithis in the Void (this was before i converted the file to esm btw, which before would ALWAYS cause the follower to disappear).
your teleporter and destination marker HAS TO BE sitting on a esm-based navmesh. teleporters will not work if you use them in esp navm's. otherwise YOU will be sent along with anyone else to Sithis' tea party.


obviously this has very limited use, but if your world or cell is 100% custom, you don't need to touch vanilla navmeshes EVER.

Hmmx .... only thing I can say is more info on steps would be appreciated SLD, heck with ucky. Have found that if use any existing area in the vanilla as a template to build on get a big failure. if build from scratch can make work until attach to the outside world which is why the tameril comments are interesting. Still luv'n this thread cause helping me get a handle on the new fubars ... ah FNV, ineffecient but worked ... more info please.

btw, if you have your cutom world/cell navm all in your esm with a door teleporter to a vanilla navmesh that has been finalized, and that navm record is also in the custom esm file as a navm record in a wilderness cell under WRLD without ONAM, it may work seemingly fine for you in your tests, but once you release it to public you will get users reporting missing architecture in totally unrelated cells elsewhere (gaping holes in the floor, or entire rooms/buildings/mountains/walls missing altogether). at first i thought this was just mod conflicts, but it is caused by a combination of your mod and other mods that also do this (regardless if the navm is in the esm or esp, as long as one mod has this error, they all get affected).

so for those who plan on going esm/esp, know that you are not 100% immune to navmesh extended family bugs seeking handouts, unless you can COMPLETELY isolate yourself from tamriel with no way fo that little bastard ever being able to find you. and that even if it seems to be no problems for you, you are probably cauing problems when your user installs your mod alongside other mods - usually multiple mods all conspiring together)

this is what i call the daddy-nav's-divorced-bride-seeking-alimony-to-feed-her-bastard-child navmesh bug. it's almost impossible to find on your own, but that little bastard WILL come knocking on your door eventually.


also note, that you can NEVER put a location edit to a vanilla nav'd cell in an esm. it will physically destroy your esm into ground bone meal if you do this in the CK, or it will crush it into bone meal behind you back if you do this in Tessnip (tessnip will compile the esm normally so that it is readable by skyrim, but it will be corrupt without you knowing and cause a LOT of problems for your users)

Ok, I tried the Riften test. Here's what I found. I'm using v1.4

All tests started in Whiterun. Fast travelled to Riften Stables. Entered via Dwemer door. Ran from 1 end of Riften (up alleyway as well) and back. Leave via Dwemer door. FT to Shors Srone and return. Enter Riften via Dwemer door.

I took my dog along for the ride.

- 10f. Numerous scantily clad Delpines standing still along the boardwalk. No response from any of them, just standing like statues. No collision. Vigilance entered and ran about with me. After FT, the first 2 said Uh ? and had collision, next three and balcony were inactive and had no collision. Last 3 said Uh? and had collision. Vigilance couldn't enter.

- 11a Same as above before FT. Vigilance entered, but wouldn't exit. I ran around shouting "Vigilance, here boy", but alas, he never showed up. He did show up at Shors Stone after FT, but wouldn't re-enter Riften via the Dwemer door. After FT, slightly different. Collision wise, the very same as 10f, but none of the Delphines responded with an Uh?

- 12a Delphine wearing a blue dress,...same results as 10f before FT. Vigilance entered and exited. After FT, the results were exactly the same all Delphines standing like statues. some with collision, some without. Vigilance entered, but would only move between 2nd and 5th Delphine. He didn't exit again.

- 15a Blue dress again, but surprise, surprise all Delphines walking about. All had collision and all mumbled hmm? when you bumped into them. Vigilance entered and exited. After FT. 2nd and 5th Delphine didn;t move, but were awake. 3 Delphines outside the boarded up gate and 1 outside the North gate.

I don't know what you can tell from this, but it seems it's still not working quite right after FT.

It was nice to finally see all the Delphines moving

Amethyst Deceiver: I only stick to keeping navMesh in the ESP because most of it is linked to Vanilla. It didn't occur to me to script entry into an area (though I planned to script fast-trav OUT of one eventually; for now it's done by the doors I keep mentioning in my Tower mod)... very clever workaround to the problem at hand. Is there some alias or quest you can call to get a follower's info? I'm sure there is... that way you could script the follower's entry too, and never WILL need to touch nilla-nav.

But I agree that nilla-nav in a mod's ESM causes strange things... and that sometimes it works for some but not others. That's why I keep it all in the ESP (I don't know enough about ONAM lists to use them with confidence). I extend the concept to include ANYTHING Vanilla.. just to cover all bases.

I also had success with deleting all the Vanilla navMesh data from my mod... that's what I did for the interim 1.524 fix I released. As I recall, followers still entered doors... I know I had them inside the Tower and working fine - and I never do that kind of thing with the console.. so it must've worked. After the 1.526 patch (which was like a week or two after I up'd that fix), I remade all my nilla-nav and refinalized all the cities' cells (over a dozen)... now all working fine. The only thing that would be lacking if I hadn't remade my nilla-nav is the ability to walk up to the front gate with followers, and they wouldn't go out on the roof-garden-mine anymore either. Other mods, which revolve completely around Vanilla wordSpace, aren't so lucky in location or limited range of movement... and we AAAALLLL know how cranky users of mods can get...

ch0k3h0ld: I would first try linking your interiors to a simple door merely dropped anywhere on Vanilla navMesh, then finalize that Vanilla cell. Finalize your interior; test in-game. If you do this, what happens in-game that makes you believe the navMesh bug affects you? Based on what I know (summarized over the past several posts), I would expect NPCs to wind up near a cell-border... or in an area which still has its original nilla-nav. (I think you said you didn't delete it ALL... just a lot) If you attach a script to force them to a marker and patrol (as the above ESPs do), I would expect those placed to patrol completely within your cell to work. Those set to patrol (or travel, etc) outside the cell, will stand in one spot... probably with other NPCs.

Is that what's happening, or do you have other issues?

if you use moveto (which works on esp navmeshes, but for player only) i don't know how you would call the ref id for your current follower that has filled the alias, or for multiple followers from a 3rd party mod (probably not possible at all).

game.fasttravel will automaticaly bring your whole party with you but can only be called on esm based navmeshes.

i think the important lesson to be learned is that going the esm/esp route is NOT the end-all workaround to the navmesh bugs and all its extended family. you still have to jump through several flaming hoops regardless if you put the navm in the esp or esm or most likely both.

esp based navmesh edits, experiment with slucky's methods
esm based new navm records (01xxxxxx form IDs allowed ONLY and in non-nilla cells), try linking with no hard-connection to tamriel (i.e. no nav-based door teleporters) and only scripted travelling



it may even be worth using dummy worldspaces as a buffer between your cells and tamriel worldspace (i.e. the custom worldspace acts as a "garage/vestibule" for your custom interior for ease of fast-travel and horse-parking, you can even simulate a faux-interior using the custom worldspace by turning off the extra world-crap you dont need)

Tamb0: Thanks for trying em out! The results you got in the last one (15a) sound similar to what I get. All the others... I dunno. You say none of them had collision?? They aren't mannequins... they're real clones of an actor... their collision should ALWAYS be exactly where you see their body. I've NEVER heard of that happening before. Are you running other mods when trying this... or loading a saveGame?

I forgot you probably wouldn't have the mannequin fix either, so here's the script. Just delete it after you're done if you don't want it (it's v2.0 living of the Vanilla Mannequin Script Fix..). That WILL make a difference as to what actors show up where and when; just put it in the Data/Scripts/ folder before running the game.
http://dl.dropbox.com/u/67168394/mannequinActivatorScript.pex

heheheh.. they're scantily clad in the versions running the script-fix - which forces them to equip whatever's in their inventory... which is nothing. The versions where they are dressed are defaulting to an outfit... something not possible the way I wrote the re-equip code in the script. I use the script to force the actors to a patrol marker... without it, they wander (as you saw in 15a). AH HA! That's why they stand still for you... the Vanila mannequin script turns off AI.. making the Dels stationary. Use that script above and I bet it works I described; this version keeps AI enabled (so the actor can walk around). You can force them back to their original markers by activating one and choosing 'do nothing'.

I should also clarify that the only navMesh I placed in Riften for those tests are that specific sidewalk where all the Delphines are placed.... if you tried to walk anywhere else, your dog will NOT follow. The South gate I am referring to is the one at the SouthEast... you'll see another Dwemer door there next to it if you're at the right one.

Amethyst: That's cool you got it working without sending Player to Oblivion... even better if you don't have to reference the follower! (you said they all go automatically on fast-travel... which I think I knew.. but..)

What if a custom world was linked to Vanilla through an interior cell, and not through an exterior Tamriel cell? As you said about the vestibule... you can make it look like an exterior or some kind of entrance-way; but Players would have to go inside a building, then transfer to a worldSpace... kinda time consuming with the wait screens (unless the vestibule is minimal and loads 'on-demand'). But if it works, this may be a semi-viable workaround for SOME mods.. until a permanent solution is released by Ma Beth. Totally defeats the purpose of mods such as Open Cities... but maybe SOME mods, less reliant on immersion, could benefit from it.