Meek: I can't answer your questions, as I can't even get the bug to show when I try my hardest. Sorry.

Arthmoor: I think you misunderstood me or the tone of my posts. I wasn't trying to imply that everyone is wrong and I am right; simply that what I do works... everytime, while whatever others are doing, doesn't. I specifically said (more than once probably) that only SOME people's problems may be attributed to things other than a bug. What few anecdotes on several threads I could actually find regarding specifics, usually involved things which may be fixed by my suggestions. Not for nothin', but keep in mind that not so long ago, mass-hysteria blamed a 'bug' for all their grey-headed actor blues.... now that the proper method for gen'ing the head meshes has become widely known, how many people have been complaining to Ma Beth about the 'grey-head bug' lately?

Version number, and I think others will agree with me on this, doesn't matter as the bug is supposed to have existed (albeit in a lesser form) before the v1.5 patch. Problem solving is problem solving, so even if version DID affect things - my ability to help is not likewise affected, I assure you. Also, I doubt being Super Lucky has anything to do with programming; as I was under the impression it's a science (the creative application of which being an art). Although... if my laptop DOES prove to be magically delicious, I may need to take a sabbatical from modding so I can find a place in the world where that would be vastly profitable.

Now... if you can give me a link to your mod (or email me/PM/whatever?) or some other mod which is KNOWN to have this bug, I'll be happy to take a look at it. (Did you say 'Open Cities' is known to be afflicted?) Until then, I still ask that at least one person with this problem use the above test procedure so that I/we can establish some kind of common ground. I think we need somewhere to start, and having mutually functioning basics is my logical choice. Also, be sure to test with a clean saveGame.

Corrupted saveGames have caused crazy stupid buggy behavior in a LOT of things (not just NPCs), oftentimes for something seemingly innocuous. Keep in mind that other mods' errors may be to blame or corruption, though you may think it's your mod. I believe if one is going to mod, all development and testing should be done with a clean game (no other mods) - to ensure zero conflicts or interference. This also applies to troubleshooting and bug-hunting... only mods KNOWN not to cause drama (like 'glowing ore' for instance) may be added back in; but at least TRY with a completely clean game before anything else.

Regarding the mod you spoke about above: you mentioned you had some auto-gen'd Vanilla cells... was that for a different mod, or have you tried it with hand-editing? Did you do it with a squeeky clean saveGame? I know these are basic questions, and I assume you've done it correctly or how I explained it... just want to make sure. (how many posts I've had in comment sections because of simple things overlooked by veterans...)

i created 3 separate interiors from scratch in the CK on patch 1.5 using Slucky's method above, and can confirm that all 3 are working perfectly with no CTD during fast travel.

i will now attempt to retrofit my file (98%made during patch 1.4 and final save with re-finalized navmeshes with patch 1.5) and redo all navmeshes the same way described by his methods above. will post back in a few.

Amethyst Deceiver: That's good knews! At least I can say SOMEONE has proven me not a liar! heheheh It may not answer the ultimate question if mods made a certain way BEFORE v1.5 are somehow the cause. I think someone said they got v1.5 to work as long as the navMesh was created over from scratch (eldiabs I think? maybe another thread..); but at least now we know that method above works for v1.5 (and the earlier version, as my tests showed).

Arthmoor: Something I just found out, then verified.... if you auto-gen a navMesh in an area that already has some created, it deletes and/or changes some of the data from the non-auto-gen'd navMesh. In my case, I have an interior cell which has several individual areas; These areas were created at different times, so I did the navMeshes for them separately (select the objects/structural then do a recast auto-gen). Now that I already finished the couple areas with water, I noticed after doing other areas that the 'water' toggle was shut off for the areas that I set... while yet OTHER areas were set to be water AND preferred (how and why.... now THAT'S a true bug! unless one isn't suppose to go about navMeshing the way I did that is).

The only reason I noticed was because I placed a bunch of fish (the random spawning kind, as well as indiv salmon and pond fish)... but the only ones that showed up were the pond fish (they always just sit wherever you place them). I looked at the navMesh.. and there it was - changed to something other than what it should have been. Through testing I found this was caused by auto-gen'ing (or maybe find cover.. I'll have to look to make sure which), but not re-finalizing... I made sure of that.

My point is that I think you said the areas you auto-gen'd didn't already have navMesh, even though it WAS in a Vanilla cell.... is that correct? If so, by auto-gen'ing your little area, there's no telling what data was changed elsewhere in that cell and the adjacent ones (by what I now believe is at least one TRUE bug). Some people may not realise that by finalizing a cell, the adjacent cells' data is also saved. NOW we may be getting somewhere.... I'll post back when I find out for sure whether it's auto-gen'ing or find cover; just take me a sec.

I am not sure i get this.
I have that bug crash if i zone in a second time. 2 Rooms not vanilla have auto navmeshed them recaste base than hand modified checkt no warnings finalize green verticals by the doors.
And what is now the way i should use too not get that bug?

[EDIT: nar80.. forgot to answer you - knowing what I know now about auto-gen'ing, I'd say that's what it is (read below), but you say those areas aren't Vanilla. Do you mean the specific little area inside a cell doesn't already have Vanilla navMesh, or do you mean you only autogen'd your custom cells? Also, CTD is oftentimes caused by load-order changing or not having certain resources your saveGame expects to be still install... this seems to have been exacerbated by the v1.5 patch but thankfully I haven't updated yet. To answer your question regarding getting rid of it... deleting the navMesh data should do it, but then you have to find out how to successfully replace them with ones that don't crash. At least two people have verified that freshly-made navMesh using v1.5 will work as expected.]


I just verified that doing a recast auto-gen of just a small area inside a cell, which already has other navMesh in it, causes some data to be changed. (find cover wasn't the culprit) Since I only know that it erases my water settings for ALL my water, and that it seems to pick random little patches to set to water and/or preferred (or both), I don't know WHAT other data may be compromised by this action. I also don't know if it was the 'recast' type of auto-gen which causes it or any other type would as well. Perhaps someone knowledgable on such things (or even from Ma Beth herself!) could enlighten us as to whether doing a 'selective recast auto-gen' is a KNOWN no-no? If it isn't I think we found at least one piece of the navMesh bug.

My point is that by doing that recast of a small section, as the wiki suggests (as I recall, though I could be wrong), it damages the entire area's navMesh; the extent of which (at least in my case) is limited to the water/preferred thing. BUT you have to remember that my fish never appeared when those navMeshes were reverted back to non-water... I don't know if it's because fish need a water mesh or if your bug has finally struck me (though I didn't have to leave then return/etc for it to happen). So I dunno if it messes with data in other ways which could be affecting your actors.

Hand-correcting the 'damaged' areas also fixed the problem I had with insect spawns at the same location.... never showed up until now. I dunno if that is because they needed a certain navMesh under them as well, or if the bug caused it too, or whatever. If it allowed my fish to show up and my insects to correctly spawn, then maybe it would help fix any problems some of you may be having with other actors/etc which use navMesh for whatever reason.

So if I am correct in this auto-gen thing, the fix for the afflicted would be to delete ALL navMesh data relating to Vanilla from your mod. It may be easiest to simply erase the entire naviGrup (as well as all the Vanilla navm ref's inside Vanilla cells), then re-finalize every area you have. Regarding your Vanilla areas, if this theory holds, you'd have to make your area by hand (as opposed to auto-gen'ing just that little area)... then finalize it of course.

Though it may not make a difference for the above, I STILL think anything altering Vanilla should be placed in an ESP... but that may help cure a whole DIFFERENT manifestation of the elusive "navMesh bug". Let me know if anyone verifies this stuff or has gotten their thing to work this way or some other.

They are custom cells inside my house it crashes if i go outside too (only the second time) and they crash only the second time never the first and never happens before the patch, only my mode is running nothing else. Ok i make a new mesh is no trouble hope that helps. "deleting the navMesh data should do it" what do you mean by that delet the mesh with the ck or do i need to edit some stuff too?

If i delete the mesh it works but if i add a new one handmade it crashes again but if i zone from the cell withoutmesh in on wich has one it never crash strange.

I'll PM you a link to the current copy. Although a bit of dilligent searching could probably get it to you just as quickly. It has disappeared entirely from the public eye for backup purposes.

Corrupted save games are not an issue here. I have done all my navmesh testing on numerous different freshly created characters. Benefits of also having built an alt-start mod

Yes, the Open Cities mod aut-gen'd a couple of navmeshes in cells that had none. I've never gone back to wipe them out and redo them, because it won't help. The entire city of Markarth was done by hand, with no auto-gen anything. Not even the balance optimization function. Hand placed verts, cover edging, finalization. Edited vanilla navmeshes where necessary to link to mine.

Further, I completely wiped out all traces of navmesh data in Live Another Life, then hand rebuilt the interior of the farmhouse, and hand edited the two exterior cells that farmhouse crosses. No auto-gen. Though it was obviously necessary to delete some triangles. That can't be escaped. Cover edging and finalization of course. LAL insta-CTDs upon returning to the interior cell after having left from the first visit to it.

Clearly SOMETHING is wrong though or the devs would not have stepped in to fix it. I am certainly not keen on spending a week rebuilding all the navmeshes in OCS after doing so on 3 cells worth of data failed to produce a working result.

Nobody called you a liar. Also, my navmeshes in LAL *HAVE* been recreated from scratch.

Correct. They were all preexisting vanilla cells. Except for the farmhouse interior in LAL, that's custom.

This talk of "the only true bug" is partly what's bugging me about your approach to all this. There's very clearly a documented ACTUAL bug, complete with video proof of it. The author of which has himself now stated is still happening with his mods too. We can't all be totally in the dark here with just one person knowing the One True Method.

BTW, unless I've missed something, the NPC face bug isn't fixed yet either.

i re-navmeshed everything in my mod from scratch.

deleted all traces of the NAVI record, all NAVM in cells and world, and started over doing every single navmesh by hand, foregoing any auto-gen.

this time also finalized the vanilla navmeshes that my teleport markers are sitting on in tamriel.

Final verdict: no dice. CTDs not only on fast travel but randomly in interior cells as well.

trust me i double checked all navmeshes, cover edges, finalized, the whole 9. i did it exactly the same way as described (and the same way that resulted in positive results when all interiors made from scratch)

this test is conducted using the esp-only version of my mod (the esm only version is totally unaffected by any navmesh bugs)



one of the cells i created in the earlier successful test used doors in the same part of tamriel worldspace with teleport markers sitting on the same vanilla navmeshes as my current mod

i would have to say my conclusion based on my test results and the discussion here is that pretty much all navmeshed mods made prior to 1.5 are SOL and EFFED in the A.

i can't even continue going on with the esm-only version of my mod because as soon as i update it with a esp, it will succomb to the CTD bug.


i want to add one more thing though, because you say that ESMs should never edit other ESMs but what about update.esm? that edits skyrim.esm (granted none of the records are navmeshes, but still)




this almost makes me want to quit modding for a while

I'm gonna guess my problems relate to this then.
I'm making a transport system, added in stations, which then connect to different dwemer ruins. I navmeshed them and the new pieces of the vanilla dwemer ruins. Now the new cells never load (the game hangs up on the loading screen) and in modified cells it either CTDs instantly, or the entire cell disappears. Like, all of it. I enter the cell and all the meshes will be completely gone.

this part bothers me ...

- created a new worldSpace

Now not entirely sure what mean by this to me it is greating a new space like Tameril or such .. most mods have issues with do not do this and if this is what have to do to get new things/Dungeons/Places to work tis a tad of a bummer. Now am testing a few that add in new worldspaces (according to my understanding of this word) and they work but those that mod T or existing spaces do not. Just trying to be clear on your steps here.

Exactly the results I got.

That's best practice, yes. But Bethesda also has the ability to generate ONAM records in the file header of a .esm file. These are a list of various vanilla records the .esm file is set to alter in some way. Necessary in order to avoid several problems that have existed for years. In Oblivion and Fallout 3, an ESM editing another ESM caused missing landscape and other non-persistent resources. In Skyrim, you get edits to vanilla references simply being ignored.

Mostly to do with worldspaces and cell issues though. An ESM can edit plenty of other things in another ESM. It's just the placed references that cause the most trouble, and all NAVM records are considered placed references.

this is so depressing

it's like watching a trainwreck happen over and over again. Only you've set up the train tracks yourself.

And built the train yourself too.

Suppose you could link it? I'll add an ONAM list and link it back.

here's a link to the published esm version (which currently works for the most part, but i cannot update it with esp because of the bug)
http://skyrim.nexusmods.com/downloads/file.php?id=5696

thank you

It's worth a shot *tinkers*

Amethyst Deceiver: Your mod has no overrides to Skyrim.ESM cell children, NAVM or otherwise, nor does the ESP override any of your ESM's cell children, so an ONAM list was not built as it's inapplicable. If you were to update the ESM's NavMeshes with the ESP, an ONAM list would be applicable.

I'd be very interested to experiment with a plugin overriding and linking to Skyrim.ESM NavMeshes to test ONAM, preferably a plugin with a CELL, WRLD, and NAVI groups only.

Do you think i will be able to dodge the bullet if i don't edit the navmeshes or cells in the esp until the bug is fixed for legacy mods?

right now the most pressing issue for my mod is i need to ad an update esp to override some of the quests and other non-cell/reference related data in the esm. these kind of edits do not require ONAM correct?

Not sure about dodging the bullet but, yeah, only cell children are included in ONAM lists.

.
Thank you http://www.gamesas.com/user/766649-amethyst-deceiver/. It sounds like you did a lot of work to get that confirmation. Now for the 64 billion dollar question: at what stage of redevelopment did the bug first emerge...?
.
I had just confirmed the previous version of the bug for myself when the Creation Kit updated. Now, the big issue is seemingly random program terminations ("CTD"s - in my generation a program hadn't crashed until it could no longer be restarted and had to be completely removed and reinstalled). I say seemingly because it is fairly consistent. I have an exterior cell with a MapMarker, linked XMarkerHeading, and modified NavMesh - and, http://www.gamesas.com/user/764276-sluckyd/, if I'd accidentally touched off an auto-generated navmesh, I'd have rolled back to a previous version and started the last edit from scratch. I've seen the kind of mess some of those auto functions can make of things so I avoid them like the plague. The interior cell is working quite nicely, the sorter pilot is functioning, I have another attached interior cell overpopulated with 20 mannequins (which are behaving much more predictably under the code I posted on the http://www.gamesas.com/topic/1358332-caught-mischievous-mannequin-monkey-business-on-camera/ thread). I'm also using a few load-screen models as they make easy props and are great for illusions.
.
With this in mind, the bug I am getting involves the occasional program termination when I fast transport from an external cell to the vicinity of my map marker. Anecdotally, this has only happened immediately after fast-traveling out of the area. I am also getting program termination whenever attempting to enter an interior WorldSpace from the vicinity of my MapMarker. Correct me if I am wrong, http://www.gamesas.com/user/176330-arthmoor/, but I think this also adds confirmation to what you were talking about earlier on this thread...?
.
One more little detail, we had a 500 millisecond power outage that dropped the computer like a soggy sack of fertilizer. After I got the system running, I got disabled a puddle model and a LoadScreen model in the exterior cell and the bug seemed to go away. It then, mysteriously, returned some time later. All this gives me a couple ideas about something that might be tried so I'll have a play with the MapMarker Radius and crash the game a few more times, then I'll reboot the operating system and see if the bug (if it survives the MapMarker tweak) has again decided to keep a low profile just after system startup.

Of course you would make a train anology...

For my first MapMarker tweak I was going to reduce or increase the radius to change whether the linked MapMarkerHeading and door teleport markers all fell outside or inside the radius. However, I found a little leftover from my initial large model LOD saga in the form of a link from the building to the MapMarker. I removed this link and proceeded into the game (with the Creation Kit still running). First, fast-traveling to my MapMarker from the exterior cell occurred without incident. Then, what crashed the game last time, entering the interior from this location; and the game did not crash. This took me to the mid level cell. I went from here to the upper level cell, onto the roof (still in the vicinity of the MapMarker) back inside (which crashed the game on the previous test) and now I have a couple of floating mannequins. So much for my http://www.gamesas.com/topic/1358332-caught-mischievous-mannequin-monkey-business-on-camera/! I descended through the mid level cell, down to the lower level cell (the lower level is yet to get any NavMesh), back to the mid level cell and then outside to ground level. By now the memory management should be fairly cooking, so I tried once more, re-entering the mid level interior space and no crash. Upon arriving on the upper level I was greeted by misplaced mannequins all over the place - confirming the system stress and something odd with the engine. So far, in all traverses through the upper level interior cell, the NavMesh behaved correctly with my follower bouncing from one misplaced mannequin to another like a pinball before grinding to a halt at my avatar.
.
Knowing that this state of affairs couldn't last long and that I better make the most of the opportunity to do some hassle-free experimental interior development, I exited the game and the Creation Kit promptly crashed!
.
Stay tuned, I have a hunch there's more to come...

I just repeated the testing procedure I described in my last reply on this thread, this time, without the Creation Kit Running. On the second ans subsequent returns to the interior upper level, only two of the twenty mannequins were displaced (one rotated and the other levitating a couple of game-inches of the floor). This left enough room so that my dutiful follower wasn't making like a pinball - and nothing crashed this time.
.
I've a hunch that the problem is intermittent, which may explain the discrepancy between the experiences of http://www.gamesas.com/user/766649-amethyst-deceiver/ and http://www.gamesas.com/user/764276-sluckyd/. On my rig, it occasionally turns up, and then goes when I do something to the plug-in - but not necessarily every time I do something to the plug-in. So I'll keep an eye out for this problem and the original two-step return NavMesh fault and report back if they return.