Yes, the crash upon reentering the interior cell after you were in it once before and left is pretty much what I've been on about and what's been fairly widely reported.

Although due to the nature of the Open Cities mod, outdoor cells bring about the same result.

This thing with mapmarkers you seem to have stumbled on is interesting. I'll have to see if a run with OCS and the mapmarkers temporarily deleted gives me a different result.

.
http://www.gamesas.com/user/176330-arthmoor/, this thing with the MapMarkers may be a red herring, so be careful what you commit your time to. In my case, a large model was linked to the MapMarker which, in turn, was linked to an XMarkerHeading [edit]And my test results were subsequent to disconnecting the link between the tower model and the MapMarker[/edit]. The point of the design here is that the MapMarker locates (on the map) a landmark (to whose exact location it is inappropriate to fast travel), while the linked XMarkerHeading marks the teleport spot for the player. I also had a working HorseMarker in there for a while - and around the time the problems started with the game terminations, my horse started arriving at a location other than the HorseMarker. What that indicates to me is that not all the objects are loading with the cell and, as I gradually par down the complexity of the cell by removing objects of my own, the extent of this problem is reduced. however, if the game really stresses the system, things don't get loaded and say, on a fast travel to the MapMarker, either the MapMarker doesn't load before curtain-up or the linked XMarkerHeading doesn't load before curtain-up; down she goes, or Hello Bill - whichever ye prefer.
.
I suspect that something like the OnCellLoad event -but perhaps at a parent level compared with the OnCellLoad event- is not getting sufficient priority to complete assigned child-processes when there is high demand (and competition) for resources from other processes. This could explain a lot of other stubborn, persistent problems as well.

Constant CTDs here too, especially when enemies try follow me between interior cells. I've double-checked everything and still the CTDs remain, so I blame you Befsada!

This happens actually even without Navmeshes, large interior cells linked to worldspaces other than Tamriel result in CTD.

Amethyst Deceiver: I agree with RealmEleven in that the next step would be to discern the differences in the process you used versus my above test process which you said worked as expected. Theoretically, if you repeat the exact process in your mod as that successful test, and it still causes the bug, then something other than navMeshes may be to blame for your particular problem. I assume you didn't originally create the mod preCK, right?

Trainwiz: I had similar issues that you describe (regarding the game freezing at the loading screen and sometimes CTD)... my problem was usually caused by meshes (eg: NIFs containing collision data from the 'old' format, as opposed to the new havok system). PreCK, I had similar problems as well, regarding navMeshes... but that was because GECK didn't create all the necessary data (I think it never created the NAVI grup at all, as well as some missing subrecords). Unless your problem is caused by meshes, I doubt this helps.. sorry. If the navMeshes are the cause, it sounds like you may need to do a clean re-install of the game and CK cuz SOMETHING'S fubar (and few if any people report freezing, just CTD/broken AI).

JustinOther: I don't see an ONAM in the update.esm's header... is it embedded in a place where TESvSnip doesn't recognize it? That app sees ONAM subrecords in other records, but they usually are in sounds or loading screens. I have had SOME success altering ESM data with another ESM (without this ONAM thing), but the results were always unpredictable so not good enough to use. For those having problems with this type of plugin arrangement, the possibility of it causing the drama should be definitively ruled out by testing the mod with said data in the ESP not the ESM. As more comes to light about the ONAM thing (again, I never modded FO3 so am unfamiliar with this implementation), then we can work it into the plugin structure... but this is all just my opinion, stemming primarily from my lack of ANY knowledge regarding ONAM lists and how to use them (thus having no confidence in their efficacy).

Arthmoor: I'm not trying to sound elitist, and I don't think I ever said I have one answer or there is one bug... quite to the contrary. I keep saying that this 'navMesh bug' is most likely caused by several DIFFERENT things... only the results seem the same so everyone assumes it's caused by one thing (so that leads me to believe YOU are the one who claims there is only one bug... seeking one fix). Have you tried the aforementioned test yet, which Amethyst Deceiver successfully tried? That is as basic a navMesh system as there is - and if you can't get that to work then you probably have issues with something OTHER than navMeshes (or it's a bug specific to your system's particular installation/config). But if you CAN get that to work, then we can reverse engineer at what point things went awry in your or whomever's circumstance.

Also, symptoms don't constitute a bug. I found one cause for one bug, namely when doing a 'recast auto-gen' in an area already containing navMesh (and possibly any navMeshes in adjacent cells included) causes said existing navMesh data to become corrupted. That is A bug... but it may not be THE bug which affects your mod.

RealmEleven: Regarding your buggy mannequins, I released a fix for those problems weeks ago, located here - http://skyrim.nexusmods.com/downloads/file.php?id=10652. (it has since been improved to v2.0, with help from Daemonjax - who also released an alternate version which goes even further than my generic fix) Them mannequins acting a fool doesn't necessarily have anything to do with navMeshes, as my fix only alters the Vanilla script. That isn't to say buggy navMeshes aren't the cause of the actual 'wandering' (mannequins across the room or floating when you return)... but I know my fix works around the issue (as well as other issues). [if you want to fix it yourself, simply change "onCellLoad" to "onCellAttach" - but the other mannequin bugs will still affect you. The source IS included with that fix, if you want to mess with it or recompile for reassurance.]

It almost sounded like you got your mod's navMesh working though (by deleting a map-marker-linked object I think you said?). If you think the bug is still there because of the mannequins' strange behavior, try that Script Fix and then retest your mod. Also, thanks for jumping in here trying to help sort this out! Another rational and patient mind is always welcome.

Also, by deleting the navMesh data, I use TESvSnip; the entire NAVI grup, and each NAVM record contained in each one of your areas' cells. The areas' cells are located under the CELL and WRLD grups, just keep expanding the branches until you see REFs and NAVMs. I don't know if the CK deletes all the data, so I use the 'Snip' method to ensure thoroughness... should I have to resort to such measures. [one last thing: the CK crashing probably has little to do with anything... it crashes for many people - myself included. Usually it's when I compile a script several times... eventually it comes up with some error then CTD. Just fire it back up and save frequently! ..and for most script testing/tweaking, don't load any plugins or skyrim.esm - just open the CK and the Papyrus manager.. so much quicker]

EVERYONE: I know most everyone has problems with this, and that the issues which arise are seemingly identical (CTD with v1.5, broken AI pre1.5). But this doesn't mean that it's caused by some singular yet wild & crazy bug: I can guarantee this because I use a clean install of Skyrim and the CK (no injectors, no processors, no modman software, no INI tweaks, no mods other than my own)... and what I do works every time, without fail. So to say something is wrong with the game itself is a flawed statement, as obviously not everyone's game IS.

In order to help straighten this out, I believe everyone must be patient and start with common ground. Amethyst Deceiver has done that by trying a simple test method I posted on this thread (but may be a page or two behind by now); now we can see where her 'buggy' mod diverged from the working test mod... hopefully pinpointing what is causing HER problem. Some people's problems may be caused by simply not creating a viable navMesh, while others may not have finalized... but until people stop repeating the known symptoms and start trying solutions/alternatives, as well as giving details for how they made the mod, we (well you... my s- works) may be waiting a while for Ma Beth to resolve this (if ever... you have to consider that it MAY just be something that simply can't resolved).

Also, it would help if I/we had specifics regarding the process you used; namely whether your navMesh is contained in an ESM or ESP, whether you used auto-gen, does your mod work if all navMesh data is deleted, have you tried using a simple setup (the test method above for instance), etc etc. Your game itself may need to be cleanly re-installed if you EVER used any processors/injectors; more than one person on my mods' comment sections had very strange problems, even relating to crashing when going through certain doors, caused SOLELY by some injector. Even after they 'uninstalled' said software, the problems persisted until they clean re-install the whole game; added back in their mods, and no problems.

If you are just too exasperated by contributing to a solution, which can become frustrating at times, maybe it's best if you work on other aspects of your mod while waiting for a fix. I don't mean that in a bad way, but if comments start to get more inflammatory/repetitive rather than helpful... it's almost always better to take a few steps back, breathe deeply, and divert your attention away from the nuisance. You may have to resort to releasing a beta version of your mod sans navMesh; the preCK version of my navMesh-less Player-Home is probably still the single-most downloaded indiv file of any Player-Home. My point being that people may still find your mod enjoyable and useful, and are likely to cut you slack if they know it's a pre-release pending a bug-fix; that Player-Home of mine STILL doesn't have mannequins and weapon racks (heheheh) but MANY people still use it and/or keep up with it because they know/believe I'll add them in future updates.

[EDIT: type-o corrections... heheh I've been outta school for twenty years and the spell check doesn't work on the quick-post thingy for some reason.]

The CTD bug started happening immediately after the CK and Skyrim updated to 1.5


i just thought of something which may or may not be relevant. during the 1.5 update my skyrim game updated before the CK. and in this between time i was working and saving on my mod (which means skyrim data was at 1.5 while CK was still 1.4)

What if t boils down to stressing the system? Problems that are sometimes there and then aren't sound like those dreaded multi threading problem examples I remember from my parallel programming classes.

What if the bug (both the CTD and the pre 1.5 one) occurs more often the more stressed the system is (no time to process everything).

Non tested theory:
Very simple test cell --> no problem
medium stressing cell with lets say 3year old CPU --> problems
medium stressing cell with i5 or i7 sandy bridge --> no problem
medium stressing cell but removing stuff (what RealmEleven did) --> loads with less problems
complex mod like open city --> no chance of getting it working on any current pc without problem.

I did some work on an exterior home a month back and also edited the nav mesh without being careful at all and I can't remember any problem (maybe I didn't notice it and I also had no time to test it with 1.5 yet)
I have a i5 2500k @4ghz

Well if SLuckyD has some ancient CPU we can throw this theory out the window

heheh... not really - i5 2.27g (half decent when I got it like 2 years ago). I run Skyrim on med-high settings without any problems, though sometimes it takes a hit to the fps during high-action scenes with lots of particle effects and whatnot.

Here is a link to the actual test mod I made using the above procedure. It's just a custom cell, a custom worldSpace, a custom actor (placed 3 times in each area), some idle markers/furniture to test for AI, and the structures and doors. I auto-gen'd the custom area's navMesh, then hand-tweaked before finalizing them. I placed the Tamriel door markers inside the Vanilla mesh then finalized that cell (WhiterunExterior4... fast travel to Whiterun, walk the road toward Honningbrew and you'll see two floating doors on the right)
http://dl.dropbox.com/u/67168394/aanavmeshtest.esp

If you guys don't wanna mod the test yourself, may ask that some of you try the above ESP to see if it shows you the bug or not? If it doesn't, you may have done something to cause your problems, if it does - then I assume your problems are caused by your specific installation/config (or by other mods, injectors, etc).

@sluckyd - the difference between my 2nd test as opposed to the 1st test was only stuff not related to navmesh. when i deleted every NAVI and NAVM record and started over i rebuilt it the same way.

i will download the mod and test it out. also do you mind if i "update" it in CK version 1.5 to test the other theory - aka The Legacy SOL Effed in the A bug

And I'm telling you there is a bug. It's been verified countless times. It's there. Period. You've got all these people chasing ghosts, and it's not a productive use of anyone's time at this point.

Bethesdas has acknowledged the probelm, as reported, is real. That's all we could ever ask for. It is *NOT* fixed, there is no magic bullet process that will work for only a select few people. Let's let the developers fix it without clouding up the issue with a pile of BS that leads nowhere.

I for one am not going to waste any more time deleting and rebuilding navmeshes that take hours to reconstruct from scratch. I have better things to do.

Here's my test report:



I downloaded Slucky's test esp (created in CK patch 1.4) and loaded it into the game (skyrim patch 1.5) with no other mods enabled (absolutely none whatsoever)

coc'd into whiterun hold from the main menu (didnt bother loading a save to ensure cleanest possible test)

walked over to the 2 test doors. one is to an interior cell, one is to an exterior enclosed worldspace

tried the interior cell first. walked around checked out the 3 delphines (LMAO).

tried the next cell (exterior enclosure). walked around and pestered the triple delphines again. walked out. instant CTD

reload auto save. walked out again works fine (this is exactly how the CTD bug works)


just to make sure it wasnt a fluke, i tried it again 3 more times. it CTD's every single time i exit the custom worldspace (when not initially loaded from a save), but never when i exit the interior cell.

now just for added measures, i opened the file in the CK (patch 1.5)


i added a map marker in front of the doors, named it test area and gave it an icon of settlement.

nothing else was touched.

save and exit. (note, the esp is now legacy-patched into 1.5)


opened the game did everything as before. same CTD bug on exit of the worldspace door.

reloaded this time i tried the fast travel map marker.

same deal CTD every time i fast travel to the map marker, but works again if i reload the save.



final verdict: the CTD bug is DEFINITELY real and it is by far worse than the previous navmesh related bugs combined (IMO)

this test also confirms my F'd in the A legacy theory


all navmeshed legacy mods are completely ****ed

http://i.imgur.com/VaIrx.png. It lists only overridden cell children, (LAND, NAVM, REFR, ACHR, PGRE, PHZD, etc.). TESVSnip, isn't yet prepared, evidently, for that subrecord data. Other instances of ONAM in other record types are entirely different. http://skyrim.nexusmods.com/downloads/file.php?id=3562, as an ESM with an http://i.imgur.com/XFRca.png, works perfectly for users even if contested while, without an ONAM list, it crashes when another mod conflicts. That's proof enough to me (along with Beth's official plugin now bearing an ONAM list) to suggest a plugin moving stuff around in its master(s) should be an ESM (although we currently don't have the means to create ONAM lists) but it would be great if a plain ol' ESP could cut it with no ONAM list.

Your test makes sense SLuckyD, and I'm with you in agreeing that the CTDs are probably related to more than just one issue.

However, I find it extremely odd that after they 'fixed' the esp navmesh AI bug, a new and improved door load ctd bug showed up. As well as the fast travel bug...but that's probably related to the navmesh in some way as well.

And the fact that a straight esm file does not have these issues is interesting, as the AI bug also could be worked around with using an esm.

Just saying...

Still though, in my own tests, deleting all of the navmesh data using TESVSnip resolves the ctds (and like you said, all of it, under every single cell). I'm just not up for redoing 5+ hours of navmesh over 4 interior cells and 1 exterior moving across 3 or 4 grids...

Going to wait and see if this gets fixed via a patch or if someone comes up with a magic pill. If not...I will eventually redo all of...won't be happy about it though.

i don't mind experimenting with these theories, even if they seem "useless"

at this point i am willing to drink Brynjolf's falmer blood, i am that desperate to get something working without starting over completely from scratch.

http://www.mediafire.com/?598etwk9c3ztmjm. Might make a difference?

if it's an esm i already know it will work. esm's are unaffected

http://www.mediafire.com/?k08qk9j0fyh5j8f. Also, I refinalized/saved it with the new CK and corrected a NAVM error reported.

PATHFINDING: Navmesh 000ea096 Cell 'Wilderness' (000095DE) (3, -1) in WorldSpace 'Tamriel' (0000003C), Triangle 208 Edge 2 and Triangle 383 Edge 2 should be linked, but they are not.

I just replicated your CTD result.

Stripped load order with only Skyrim.esm, Update.esm, and this test module. Suffered through Helgen, made my way to Whiterun.

Went through the first door to the cell test. 3 grey-faced Delphines sandboxing just fine. Left, went to the worldspace test. 3 more grey-faced Delphines, also sandboxing just fine. Exited... CTD. Reloaded the last auto-save it made. Continued the cycle. Every time, CTD upon the second loading of one of the affected navmeshes I visited.

The bug is real, as we've been trying to tell you.

i will check it out.


i actually downloaded the esm and tried an experiment with it to confirm that other theory (esm/esp combo corruption)

applying an update esp to that esm works totally fine if you add references to the cell, etc. but as soon as you touch the navmesh it will CTD like the others.

so i guess on my own mod i am ok with updating the file as long as i don't make changes to the existing navmesh (for now, but i don't know how much longer before i will need to expand and add more to the interior)

the false-flagged esp works fine

but what would the benefit of a false flag esp have over an esm?

doesnt steam erase the flag anyway when you upload it

can you alter false esps load order the same way as regular esps or are they loaded as esms

Said NAVM edit probably won't crash if the ESP also has an ONAM list. Still, ticking its ESM flag means the CK won't set it as "Active", so in order to further edit it. it would need to be esp'ified, edited with CK, then MasterUpdated with *Edit. If you link the plugin with the edit that crashed, I could ONAM'ify it too, for science.

Cool! The benefits is that the engine won't see the plugin as a different (if referenced by save(s)) and that it can be uploaded to the Workshop/Nexus with exactly the same name. Steam will keep the flag and ONAM list (See *http://steamcommunity.com/sharedfiles/filedetails/?id=7502). Uploading an "Active" ESM to Steam, however, will set the extension to ESP while leaving the internal flag alone.

*had to trick (bait & switch) CK to UL to WS

Edit: Wups. This post was supposed to be an amendment to the previous >_<

*wonders if CK has an -ONAMify parameter or ...something*

So I guess the next logical question here is what happens if you induce the creation of an ONAM list into a plain old ESP file that hasn't been false-flagged?

here is the update esp (contains navmesh edits) which is slaved to your first esm file you uploaded

https://docs.google.com/open?id=0B5JIGOz4VJQEYnRNOFVyT3BRNTJ2UUpLeVBxVmo0dw

That would be boldly going where no modder has gone before. For the Fallouts, at least, the presence of an ONAM list in a header was conditional upon it being flagged as ESM. The only experience any of us have with ONAM list addition is, however, using *Edit which will instantly remove the ONAM list in the event the ESM flag is unticked. I'd tried, with TESVSnip, to replace the header alone w/o the ESM flag and the header somehow got shoved into a group and malformed the resulting plugin... I'm dying for TES5Edit! *drools*Cool. Will ONAM'ify and link back.

*http://www.mediafire.com/?j37ddlx2kd0xjx3