In the other thread there is also CTD when exiting interior cells (I am having them on my mod). Hopefully they will look at this aspect also. Someone on Nexus reported a fix was to redo your interior navamesh and mine is massive and I really don't want to have to redo it.

As soon as I cut Windhelm back out, yes. There's an unrelated crash with that when approaching on foot, which I'm sure you could see as bad given the rest of this

Well if completely gutting and rebuilding the navmeshes can be confirmed to fix it, well, best get to it then. I don't particularly want to do that either but if it works, I guess busting out TESVSnip to hack them all out is the way to go. If you think redoing one interior is bad, redoing 4 whole cities is substantially worse.

I'll probably wait since I have 2 other large cells to navamesh still....I'll do them first and hope they get a fix so maybe I won't have to redo the one I have finished already....here's hoping....I don't envy you since yours are much larger than mine. good luck!

I'm about to start navmeshing my house mod, so since I didn't to any of that prior to 1.5, is there anything specific I should be aware of? From what I've read here this problem only exists on exterior navmeshes, so the interior part should be a breeze?

Makes no difference. The issue affects navmeshes wherever they're found. You'll probably run into the same thing I did. I started off inside the farmhouse, left, went over to Dragon Bridge. Came back, tried to go back inside, BOOM.

Crap. And 1.5 didn't improve that at all?

That was with 1.5. With 1.4 all it would do is cause NPCs to stand around looking like goofballs.

Of all the threads I've read related to this topic, I have yet to see any mention of specifics regarding what type of mod is afflicted by this "navMesh bug". So my first questions are:
1 - Is the mod ESM, ESP, or both?
2 - In what file is the navMesh data stored in?
3 - Is the custom navMesh causing problems located in an interior cell or exterior worldSpace?
4 - Does it alter any Vanilla navMesh (besides linking to it)?
5 - Was it "Finalized"?
6 - Was it auto-gen'd?

I believe this "bug", or at least some instances attributed to it, are actually caused by improper creation of navMeshes in a mod. There are several specific things one can do to cause problems with symptoms similar to what peope describe.

- navMesh in an ESM is asking for trouble:
This is generally to be considered incorrect as ESMs are not supposed to alter the data of other ESMs... this means a mod's ESM which alters or links to Vanilla's navMesh (ie: altering Vanilla's ESM's data). I found that putting ALL navMesh data in the mod's ESP file prevents TONS of errors, buggy behavior, unpredictability (regarding AI), etc. You MAY be able to get this (ESM navMesh) to work, but eventually there will be a 'bug' or some change from a Skyrim patch will render it useless.

- auto-gen'ing over ANY Vanilla navMesh is asking for more trouble:
This is because there is a tremendous amount of hand-tweaking that went into the Vanilla navMeshes (generally speaking). If you reset an entire cell's Vanilla data, you risk breaking questlines, patrol paths, and buggy AI in general; not to mention that cell may become unlinked to adjacent cells. This may be what causes some instances of AI 'trapping' (where actors will seem to converge or become trapped in a certain area). If you mess with Vanilla cells (interior OR exterior), only hand-add more vertices and tweak the ones there already... then find cover/finalize.

- "Finalize" button after making ANY changes to the navMesh is necessary:
If not, any new changes may not take effect while some of the new data may interfere with existing data. I believe it is best to use the "Find Cover" then the "Finalize" button; to ensure everything is updated. If the cell is never finalized, especially for exteriors, AI will NOT recognize it. After 'finalizing', check the borders of your cells for the thick green lines where it should meet with the adjacent cell's navMesh... if you don't see these, no actor will cross that line.

- do NOT try to marquis-select vertices when editing navMeshes:
ESPECIALLY in exteriors. This is because oftentimes there are more vertices UNDERNEATH the relative position you are trying to mass-select. Then, when you go to make your legitimate changes, it also changes something in the next cell or half a building away. I found it easiest to hand-select each vertex then 'A' or move them (or whatever you are trying to do); or select each triangle (cntl-select for multiples)... unless I KNOW the area underneath has NO navMesh.

= I found the FO3 GECK wiki to be VERY informative regarding navMeshes and everything you may want to know about them (but the Skyrim wiki may not contain yet). This information hasn't really changed (if at all) and is widely available... so doing one's homework may solve a lot of "bugs".

I also found that auto-gen'ing a navMesh then hand-tweaking is the easiest, quickest, and most fool-proof way to get it done.
- if it's for an interior cell with NO existing navMesh: open the navMesh toolbar, then click the 'NavMesh' Pulldown, choose 'Generation', then choose 'Recast'. Using the default settings, this generates a near-usable mesh everytime (unless you have strange islands, water, or questionable slope).
- if it's for an a section of interior, but you don't want to change the entire cell's navMesh: select all the architectural/structural objects and obstacles, then follow the above directions [EDIT: select ONLY the structural/obstacles of the area you want to auto-gen, NOT the areas that are already done. Delete what is already there before auto-gen'ing an existing section again. You will almost always have to connect this to the the other areas and tweak by hand AFTERWARDS.]

What it all comes down to for ME is this: I haven't seen ONE instance of the navMesh bug in my mods (and I don't use other mods which would have navMeshes)... ever. When the CK first came out, the info on navMeshes from GECK's wiki was helpful and then the CK wiki helped tie it into Skyrim. But I still had problems with my first attempts, always getting these "bugs" everyone keeps referring to. But then I remembered what I know about ESMs, ESPs, and how everything works together - so I switched my navMeshes to the ESP and I haven't had a single problem SINCE. I hope this helps at least a few people, I have no doubt that it will.... but I assume everyone's problems aren't caused by the same thing, whether it be an actual bug or just 'operator error'.

Something I have noticed is NPCs just disappearing from levels. You have to reload the game for them to come back. Anyone notice this?

That's not the case since Fallout 3 and the advent of ONAM lists which have recently been http://i.imgur.com/VaIrx.png. All Fallout DLCs were, and I'd wager Skyrim's will also be, ESMs with NAVMs and ONAM lists. Oblivion's DLCs were all ESPs as an ESM couldn't alter cell children of its master(s) without the ground vanishing, thus ONAM lists include exclusively overridden cell children (including NAVM) allowing successful overrides in an ESM flagged plugin whether False-Flag ESP or bona fide ESM.

Currently, however, the CK doesn't seem to be able to create ONAM lists(might be one of the parameters?).

I've a sneaky hunch this would not happen if your plugin had an ONAM list.

UL/Link? I can add an ONAM list with *FO3Edit as an experiment.

*See http://skyrim.nexusmods.com/downloads/file.php?id=3562

Yeah I'll shoot you a PM, its not my mod but its one that I was testing.

ONAM'ified version linked in PM reply. Post here with your findings?

Note: Form count is off and CELL forms are un-zlib'd after operating with TESVsnip. Not as familiar with it as I am *Edit.

1. ESP, in both cases for me.
2. In the .esp file, which is the only plugin file the mod has.
3. Both, but exterior worldspace is far more noticeable as broken.
4. Yes, it's necessary to do so in order to fill areas between where the vanilla mesh ends and your actual cell border is at.
5. Yes, they all were.
6. Only two in Riften and one in Whiterun was.

All the advice you give, it's been followed. This isn't some phantom bug that a bunch of incompetent users are generating by some twisted accident of fate. It's very real, it's well documented, and that you haven't seen it yet just tells me you're EXTREMELY lucky or not testing for it correctly.

Easiest way to see it in action under 1.4.x was to edit/create navmeshes, go somewhere >2 cells away from the edited area, then come back. It was painfully obvious when the bug struck.

Take Open Cities Skyrim for example. All navmeshing in Riften was done properly. Two cells auto-gen'd, the rest done entirely by hand. Proper cover edging and finalization. All connections in place, all door linkage in place. Come to the city. Walk around. Everything appears normal. NPCs going about their business. Guards on patrol. Exit out the north gate, walk up to the nearby bandit fort. Turn around, come back to the city. Whole new ball game.

With patch 1.4, NPCs would be standing around on one of two balconies, unable to navigate anywhere else. Many NPCs would simply appear to have vanished, I never did figure out where they ended up. That was the extent of it though. Even if you fast traveled away and then fast traveled back.

With patch 1.5, this changed for the worse. Now, you visit the city, everything is fine. The trip to the fort and back is also fine. Everyone having a great time. Fast travel out, fast travel back in. CTD. Every time. Without fail. The same has been confirmed across many house mods, village mods, and other efforts which necessitate navmesh editing. You visit once, everything appears just fine. You leave, then try to fast travel back, CTD.

Arthmoor: One piece of my advice wasn't followed... you said there were Vanilla areas auto-gen'd over right? Any time I did that, it caused problems... strange problems; the Whys and Wherefores are beyond the scope of this posting. I suggest 'snipping' out those cells' navMesh data (from both the world/cell GRUPs and the navi GRUP) thus returning them to Vanilla; then test in-game. If it works correctly (as it should if those areas are what causes the bug), then try hand-editing those areas. Any auto-gen'ing of Vanilla areas ALWAYS ended in disaster for me... thankfully I found my solution before I released a buggy version (or one without navMeshes altogether is what I actually would have done).

I released the first non-nilla Player-Home (Overlook Tower) on Christmas Eve, then remade the entire thing from scratch using the CK when it was released. I anticipated problems from GECK's data (wrong or missing) interfering perpetually when the CK couldn't clean it up; which some preCK mods seem to be afflicted with. I'm actually still updating it (as the preCK version was never complete due to obvious limitations at the time); but my point is that thousands of people have been using that mod uneventfully for months (and over a month postCK, with navMeshes). I also check for the bug the way you say, as well as every other way I could think of... but still no bug. [http://skyrim.nexusmods.com/downloads/file.php?id=4514]

The only thing I can think of which may cause it for others and not me is if their mods have CUSTOM worldSpaces (non-Vanilla). My Tower only has interiors, and the preCK mod I made which DOES have custom exterior, I haven't remade postCK yet. BUT my Tower mod alters like a dozen Vanilla navMeshes (the home links to every major location in the world, all Vanilla exteriors)... so this bug should manifest, should it not?

Also, I experimented with navMeshes briefly when the CK came out; I found that it seems each mod's navMesh is laid over the top of other mods' (I tested to see if one mod altering Whiterun for instance, would affect my mod's navMeshes, it doesn't). If this is true for Vanilla's as well, NPCs may be getting 'trapped' or lost/etc in parts of your custom navMesh which lie outside of Vanilla's. This would account for it working initially, but then when the cell is reset or loaded the AI somehow uses the 'top' navMesh (ie: the altered one which may have errors or conflicts). I noticed that many areas in Vanilla don't have navMesh when one would think there should be... maybe whoever created them knows something we don't? (perhaps regarding slope, overhead objects, or whatever other reason would cause them to prevent NPCs from 'going there')

It shouln't make a difference, but I still run the previous version of the game-engine (1.42704 I think it is), and whatever version of the CK which came with that... I always wait a few weeks after ANY software is updated (not just Ma Beth's games, but anything). I think this is a matter of legacy code and new code not playing nicely with each other. I never modded FO3, as it was too different from Oblivion modding (and I didn't have the time to learn then)... so I can only talk about my GECK experiences with Skyrim (navMeshes didn't work at ALL in GECK).

One example of this I found while making my mannequin mods - the Vanilla script is written to have three poses, and when the mannequin is activated it should give you the choice to enter the Inventory or change the pose. Those lines of code were commented out before release, but never deleted. Having fixed the 'bugs' in the Vanilla script for mannequins, I wanted to enable poses, so I did... but if the three properties "pose01" 02 & 03 are kept with those names, the poses play buggy. But if those properties are named something else (anything else really), the poses work as assigned. Why is that? I dunno... but doesn't it sound legacy-related? [http://skyrim.nexusmods.com/downloads/file.php?id=10652 and http://skyrim.nexusmods.com/downloads/file.php?id=10578]

But what I called the "wandering mannequin bug" happens onCellLoad (just like your 'navMesh bug')... actually a lack thereof - mannequins wandered when a Player enters an area in which the cell is already loaded, but has previously left (leave the area then return... just like your move 2 cells then return thing). For whatever reason (what I believe is the REAL bug.. that NPCs perpetrate AI that isn't assigned to them), mannequins wander whenever they aren't under thumb... the fix was to change onCellLoad to onCellAttach (thus forcing the actor to be moved to its linked REF everytime the Player enters the area again). Since mannequins are actor NPCs just like everyone else, it may be possible to find a workaround using a similar fix for ALL NPCs, eg: editing the default script to fire onCellAttach... if no other solution can be found.

My point is that I think it's possible that either the game-engine, the CK, or both have legacy code that is interfering with some of the intended new operations. Regarding what JustinOther said about the ONAM stuff and FO3, that may be true and what is intended... but the fact remains something is still wrong. If you noticed in the preview video of the CK in the days just before its release, the CK was still named "Construction Kit" in the upper left corner of the screen in one or more scenes. I assume this means they hacked up Ye Olde CS instead of hacking GECK... if this is the case, there are bound to be REALLY old limitations lingering and still in-effect, even moreso than if GECK was upgraded (since it seemed to fix so many Oblivion-modding issues from the CS). The 'grey head syndrome' on custom actors in ESPs (ESMs work fine) may be another instance of legacy limitation, though that seems (to me) to be more an issue of the way it was implemented rather than old code interfering (not correctly linking cntl-F4 gen'd meshes to their ESPs).

I want to help everyone, but if I can't replicate the bug then my hands are as tied as they'll ever be. Can someone tell me a mod that is available which has this bug in it.... or try using my mod to see if IT is affected? I found workarounds to several mannequin bugs (which I also don't believe are actual bugs, but code limitations, operator error, or both), so it may be possible to find a workaround to THIS. So far I know the above user's ESP mod has it, but Van areas were auto-gen'd so the cause may be something other than a bug. (is that mod available somewhere for download so I can finally see this bug for myself???)

@SluckyD - if you still have 1.4 installed on both game and CK, you can create a test cell (with idle markers to test ai), drop an npc in it to sandbox the idles, and link it however you like in tamriel worldspace. navmesh it the way you normally do, and then save it as an ESP (saving as ESM/ESP combo has been the only known workaround to 'fix' the bug, so you will not be able to replicate it this way).

to perform the bug, enter your test cell, observe the npc (all is good), then exit back to tamriel, fast travel somewhere else, then return to the test cell (NPC is either standing in place doing nothing or disappeared entirely)


here's the catch. if you did the ESM/ESP combo to avoid the navmesh bug, everything was peachy fine until patch 1.5

if you are using 1.5 in game and CK, any changes to the cell or navmesh on the ESP will result in instant CTD on 2nd fast travel regardless if the navmesh is editing vanilla ones or not (although some people have had success by starting over rebuilding all their navmeshes from scratch, some not so lucky). again, ESM is unaffcted.


the only workaround i know of to avoid both Navmesh bug and Bride of navmesh bug is to have ALL your navmesh in the ESM and nothing edits or touches the vanilla navmeshes (all NAVM records are new, not vanilla edits). obviously these conditions severely limit the types of mods that can be applied to, but there isnt much choice in the matter at the moment

Amethyst Deceiver: I just did everything you said and no bug. I know, I know... "he didn't do something right". Well here's what I did...
- started CK with just skyrim.esm
- created a new worldSpace
- created a new interior cell
- I made a quick enclosure and placed a door (in both)
- then made clones of some NPC (Delphine I think).. as in I made a new object (edID: aaDelphine, nonunique and without all the extra script and AI packages, just sandboxCurrent)
- I placed three of her each custom area, both the worldSpace and the interiorCell; also plenty of idle markers to trigger AI
- I placed two doors in WhiterunExterior4 (Tamriel), linked each one to my custom areas
- I did a recast auto-gen of both navMeshes (int and ext), hand tweaked them so the door markers were inside it, then finalized
- I moved the door markers in Whiterun to be inside the Vanilla navMesh, then finalized that cell
- saved it and ran Skyrim with the plugin enabled
= no bug.
I did what you said to reproduce it; I entered my exterior worldspace through my door, saw my three delphines (oracles? heheh) sitting/drinking/etc like they should have been, then I exited back to Tamriel. I then fast-travelled to Solitude, then fast-traveled back to Whiterun (which is like a cell or two away from where I placed the doors). I went back to the worldSpace, and the three delphines were still there doing what they do. My follower Lydia was with me the whole time, as expected.

I then went to my interior cell, saw the other 3 del's doing whatever, left, fast traveled to Winterhold, fast-traveled back. Instead of going straight there, I rode my horse several cells away first (to ensure whatever would have kicked in, since it didn't with the other attempt going straight there), then returned. Entered the interior cell, 3 dels, correct AI, no bug. Lydia was with me the whole time, no NPCs in town or the surrounding areas were affected.

This is using version 1.4.23.0 of the CK, and 1.4.27.0.4 of the game-engine. (the updates from like a month or so ago) Let me know if I didn't do something I was supposed to, regarding making the mod to test or the procedure to replicate the bug. It's either I messed up replicating it, I'm doing something fundamentally different in my test mod than you are, or something more diabolical is at play (like third party software interfering with your game install, corrupt game files, etc). Keep in mind that this bug is supposed to have existed before v1.5, just in a lesser form (heheheh "bride of" ... nice), so I don't think version really matters - just thought I'd tell you in case it does.

EDIT: I did NOT alter the Vanilla navMesh, I only finalized them with my doors in there. I only auto-gen'd my CUSTOM areas (the interior and exterior). This may have pertinence, but I forgot to add it a minute ago.

either i want whatever it is you're drinking (The SluckyD Potion of Immaculate Luck) or more realistically, you're doing something right that the rest of us are missing. in which case PLEASE post a detailed tutorial process on the wiki, because if it is indeed an issue that is bypassed by correct procedure, that would be infinitely better than having bethesda fix a problem that may not even need to be fixed. bethesda's attempt to fix the navmesh bug in patch 1.5 broke more than fixed for those of us who were doing the navmesh the "standard" way (the way i described above)

i don't know if creating a custom worldspace in addition to the interior has anything to do with it or what, but there has to be some step in the procedure that you are doing differently that may be the key to the bug afterall (for those using esp only).

right now for my mod, i am using an esm and that isn't affected all this nonsense, but has its share of downsides. and i know some people do not have the luxury of using an esm at all

heheheh.. that's actually what SLuckyD means: Super Lucky Dave, though I was born this way... no secret potions.

But NOW you get the point of my posts (here and on other threads on the Nex)... that SOME problems may not be caused by a bug, but inadvertantly by operator error. This isn't to say that there is no bug, just that I can't replicate it - yet I have working mods... so whatever is done to evoke said bug should be rendered null. I posted the exact procedure above... I'm not sure how much more detail I can include (except maybe the actual architecture/objects I used, but what impact would that have on the bug?).

As far as ESMs having downsides... the only one I can think of is adding stuff to it after an initial release; but that kinda defeats some of the purposes for having an ESM. But even changing it later is easy (convert it back to ESP with TESvSnip, edit in CK, save, then convert back to ESM)... but the author must be aware of the ramifications (eg: items in storage/etc). I think a lot of people are misunderstood regarding what an ESM's functions are (as opposed to an ESP). Rather than go into a long-winded lecture on my theories regarding this, I'll leave it up to you to decide whether I should elaborate.

In the test I just did, I made an exterior worldSpace (and an interior cell) because I already knew interiors worked fine (from my Overlook Tower mod... not a single problem or complaint). That mod uses ESM/ESP though, so I had to make a little test from scratch to ensure ESP-only works, but the same results nevertheless. But it seems that many problems can be categorized two ways: either it's altering Vanilla navMesh (or anything Vanilla really) in an ESM, or it's something the mod author is doing (or not doing).

In the first case (ESM related), ESMs should only have unique objects and references in them... they shouldn't alter another ESM or anything Vanilla. It may REFERENCE Vanilla/other, but not ALTER it (eg: placing a new instance of a Vanilla NPC in your custom interior is ok, while changing a Vanilla NPC's hair style is not). I know someone said this may have been resolved (since FO3), but I know through my testing that it isn't necessarily the case; and that by adhering to 'the olde ways', I cannot get this bug (and others) to show no matter what.

In the second case (ESP-only problems), I believe it may be a couple different points you may want to look at:
- finalizing both your custom cell AND the Vanilla cell it's linked to
- do not auto-gen any navMeshes in Vanilla, only change it by hand when necessary, adding indiv vertices or moving existing ones (optimally not touching it at all)
- make sure the doorMarkers for both your custom area and Vanilla are both inside a triangle of the navMesh, AND that the tri turns green after finalizing
- if finalizing brings up ANY errors, you've done something wrong (this only happens to me when I have inverted meshes, like for underwater kinda stuff)... usually it's fixed by deleting those tri's and recreating them, then refinalize (tweak/repeat until no errors)
- make sure you don't run other mods while testing, and that you have a relatively clean saveGame to use (this may also solve a lot of problems)... way too many mods have game-breaking errors in them, especially those from preCK days (and their authors have tried to get away with using the old, corrupt plugin files).

Let me know if you can or cannot recreate the above experiment bug-free; and of course if anything I've said is in error or outdated. I hope this helps... as much as a few egos would be bruised if it DOES work out, it'd be better to damage pride in order to save Ma Beth's time and efforts for other things. I hope the workarounds to the 'grey-head actor bug' has taken some pressure off of them... nothing harder than fixing a bug that isn't/may not be there!

for me, the only downside for the esm is that i cannot upload it to steam workshop and my entire mod (and all future mods of the same type) depend on it. my esm has only original records and no vanila edits. i do keep my navmeshes in the esm, but none of them touch skyrim's navmeshes so i have not had to finalize or edit the vanilla NAVM in any way (the new NAVM are all independently finalized and work fine both in patch 1.4 and in 1.5).

the reason why i would like to get this working in an esp is strictly for steam workshop, so that i can migrate everything into one esp and have it still function the same way.

i will try out the method you stated above with and without the worldspace and post my results (although i only have v1.5 installed and not 1.4). thanks for your insight though, and hopefully this is something that will be more useful than waiting for a fix from bethesda

I don't use the Workshop partly because of that... the limitations (ESM, loose files, whatever). But couldn't you ust rename your ESM to ESP leaving VERY explicit instructions for the downloading user to manually rename it after download? The Skyrim Launcher auto-enables any new mods, so nothing else would need to be done. .... or does this violate some agreement or legality somewhere...

If you have navMeshes in your ESM, and those areas are linked to anywhere Vanilla, your ESM has altered Vanilla navMeshes. I tested this thoroughly when the CK came out... simply linking and finalizing your interior alters Vanilla, even if you don't finalize or actually change that Vanilla stuff. You said your mod works though, so you should count your blessings.. but new updates to the game-engine may stumble over some of that data in the future (like the navMesh bridezilla bug there.. heheheh.. some mods worked before but not after).

as far as i know, uploading a false flagged esp will have the flag removed. also, steam does not allow more than 1 esp per upload. i thought of having the esm file hosted elsewhere, but i opted not to given that people seem to be easily confused by anything that isnt a 1-button thing on steam (i guess that was the whole "allure" of the SW in the first place). if SKSE mods on steam are anything to gauge by, this seems to be a somewhat accurate prediction.


as far as circumventing vanilla navmeshes in my esm, what i did was finalized all my exterior navmeshes (there are basically isolated islands) and if any vanilla navmeshes were finalized in the crossfire i delete those records in Tessnip. being that these navmeshes do not share borders, the unnecessarily finalized vanilla navmeshes don't need to be updated.

as for the teleport marker that sits in tamriel, i just placed them onto the existing vanilla navmesh without finalizing them. they do not have a green triangle, but they work fine even with followers and when i cause events for ai NPC to go to and from my interior into tamriel worldspace. i think i dodged a bullet on this one somehow, becasue i know some people have not been lucky with this exact same setup. but who's to say a future update that's supposed to fix the navmesh bug wont break this later on? (so far it still works with 1.5, but i am keeping my fingers crossed)

that's why i want to get to the bottom of this even if right now everything works fine in my mod navmesh-wise. but even still, what works for us may not work for other mods and there may very well be more to the navmesh bug than these steps.

That was another reason for me not using the Workshop... that people want everything one-click, while modding is NOT a one-click venture (unless the author is good... but there are several who aren't). Rather than have to jump through fiery hoops while holding hands doing it, I just made my mods as I know how and released em to one site (the better/working versions are up'd later to a second site).

To get around the one file limit, though... you could upload it as two separate downloads (like I do with my Player-Home), one for the ESM and one for the ESP/updates (since the ESM shouldn't really change once established, so is not needed to be downloaded every time). Of course the ESM one should be named something different than your ESP so they don't overwrite each other before renaming. But again, I don't use the Workshop, so I don't know if this would work, or if it's even allowed.

You may not NEED to use an ESM in the first place (as per your intentions). In my opinion, the only reason for doing this is to prevent items in Player-storage from being lost with each new update. [the custom container must be created and placed in the ESM, then it may be altered in future ESPs without fear of destroying Player's contents] This kinda goes the same for your actual areas (intCells or worldSpaces); any items dropped on the floor inside (or placed using placeatme or some mod) should be retained in future ESPs. This MAY apply to custom NPCs, dialog, questlines, etc.. but I haven't quite gotten that far to know if anything of that nature is broken or reset by ESP updates.

The only other reason for ESM may be to get around the 'grey-head actor bug'... but I thought someone worked out something for ESPs? (my mannequin mod uses an ESM, so I didn't have to go further with that bug) Aside from those two reasons, I'm at a loss as to why else you'd need an ESM. What you COULD do is have only your custom actors in an "addon" ESM, which is loaded with your main mod's ESP in the CK. These actors would be placed to worldSpace in your ESP, but the objects themselves would be in that ESM (unless you know of the workaround if there is one).

In the matter of your navMeshes: yea, deleting those ref's would work... but I recall it was a pain in the tookus. What I decided was the quickest and best way was to just do ALL navMeshes in the ESP; this eliminates the aforementioned problems as well as saving a little space (since your navMesh ref's will be duplicated in the ESP when finalizing anyways). You got lucky if your AI and followers work as expected, usually the Vanilla side has to be finalized too. Maybe you forgot to delete something... you got all the right cells' navm ref's AAANNNND the correct nvmi's in the naviGrup?

If you didn't erase the correct subrecords under the naviGrup though, it should still work since they only reference something custom... maybe that's why yours works without re-finalizing the Vanilla cell. The nvmi's are hard to locate, since the FormID of the navm it references is embedded inside the subrecord, but those are the ones which essentially tell the game-engine where to look I think (while the navm's are the actual geometry/configuration.. which is what causes the actual conflict/bug - in my opinion).

Let me know if you get just that basic experiment above to work though... that'd be the easiest way to see what's what.

i did not delete the subrecords in the NAVI GRUp and now im a little paranoid about it. (honestly i didnt even know about the NAVI subrecords until now, and that may indeed contribute a lot to the bug)

if i can get it to work as you describe in the above steps i will likely move my navmeshes all into the esp.

i think i gave up on steam workshop by now. i have a feeling i will need an esm regardless, since i do use custom containers and interiors for player home.

grey-face bugs can be worked around for those people using esp-only (it doesnt affect esm once again) if you create a temporary esm that has your finished characters, export face data as usual. then rename the export folders to reflect your esp file instead of esm. you will also need nifskope to reroute the textures from your esm folder to link to your esp folder. there may be an easier way to do this but this way will ensure you are exporting proper colors not only for the face but also parts like lips etc. if you have photoshop you can always manually add those missing export colors in yourself using the face-part alpha masks and layers and forego the whole esm workaround.

Vanilla cells that didn't previously contain navmesh data, yes. So there was nothing to mess up, and besides, I've already done everything else as you listed. I'm not going to go through the huge walls of text in the last few posts, but this isn't just limited to me. The data that exists currently is pretty much everyone EXCEPT you. Evidence therefore suggests that your experience is not the norm, but the exception, and the devs themselves have acknowledged there is a bug.

The navmesh edits I made in Live Another Life were minor. Two vanilla cells, neither one aut-gen'd. Just poked some holes in the existing triangles because I had no choice, otherwise NPCs would be trying to walk through the house and fence. Plus one interior cell with a hand built navmesh. I don't trust the auto-gen, it's proven utterly useless and I've always had to go back and tweak >90% of the mesh anyway because it makes stupid decisions, like putting triangles over beds, or on the roofs of buildings, that sort of thing.

You are also not using 1.5, so you're in no position to assess the damage this is doing to those of us who are.

In 1.4, small areas often performed correctly. Like the outdoor portion of the farmhouse I'm talking about. You'd never know there was a problem because the two NPCs did their routines. Step inside the house though, and you'll immediately note your followers have not come with you and anyone inside is stuck wherever they happened to be.

With 1.5, that graduates to a CTD as soon as you attempt to go indoors the second time you visit.

This simply is not a case of everyone but you doing this wrong. That defies all logic. There is a bug, and rather than try to dismiss it because you happen to be lucky, the rest of us would like it to be fixed for real.

Okay so I read through the thread and came out a little confused, just to clarify...

This CTD would not affect any mods created from 1.5 and on? So if I created a house mod right now and nav meshed it, it would be fine? So for new mods the whole Nav Mesh bug is gone and everything is fine, it is just the mods that were created before the fix that are having the new problem?