NavMesh Bug(s): Part III : V - Skyrim

» Wed Jun 20, 2012 12:17 pm

There is one more observation concerning actors I thought might prove interesting. Those mannequins sometimes load with their texture and mesh in two different places. When they do, a save followed by a reload can move the texture to the actual location of the mesh. This particular glitch can be partly fixed by moving the position-correcting code from the OnCellLoad() EVENT to the OnCellAttach() EVENT suggested by http://www.gamesas.com/user/764276-sluckyd/. The update to 1.5.26.0.5 may have fixed something here as I could not get this to work beforehand.
.
However, this fix only works for the cell load - as in when you enter the cell. When you wait, for example, some of the mannequin meshes that were previously in the same place as the corresponding textures wind up moving to a different location (allowing the player avatar to clip right through the mannequin). In fact, if you meagerly open the wait dialogue and then decide not to wait, this drifting of mannequin meshes still occurs. The same goes for sleep - or aborting sleep. Placing the position-correction code in either the OnAttachedToCell() or OnInit() EVENTs can seem to improve things - but if added to both simultaneously there appears to be interference between the code in the two events and the mannequins do not make it to their destinations.
.
So, if actor positions are corrected during the OnCellAttach() EVENT and OnCellLoad() EVENT, as suggested by http://www.gamesas.com/user/764276-sluckyd/, I think this might work around some of the issues for regular actors. This fixes mannequin positions as far as cell load due to entering the cell goes. However, I still don't know how to prevent the wait and sleep menus from causing the mannequin meshes to drift. When the save is reloaded after this drift, the textures are repositioned at the last location of the meshes and neither OnCellAttach() nor OnCellLoad() events seem to fire when the savegame is loaded. Another troubling aspect is that even when the player avatar is active or idle in the cell with no menus open, this drift continues to occur on its own. In fact, it can be observed directly by bringing the player avatar mesh into direct contact with the mesh of a mannequin in a corner. Once the mannequin mesh begins to separate from the mannequin texture and drift, it will push the player avatar back until it gets sufficient clearance to go around (or, perhaps, overhead). This, by itself, is a problem. Hopefully, it just might be something broken or misconfigured in the mannequin "AI". It could also be something deeper. A question which might be worth looking at...?

Exiting and re-entering the cell, which I think http://www.gamesas.com/user/766649-amethyst-deceiver/ also suggested, trips the OnCellAttach() and OnCellLoad() EVENTS - offering a temporary workaround in-game. However there appears to be no useable event that will trigger when the savegame is loaded...? I've had a play around with the OnLoad() EVENT attached to the mannequins themselves, but this seems to fire continuously, when it it launches the position-correction code, as if some of the mannequins are trying to drift away from the set marker destination. This tussle between this OnLoad() EVENT drift and the position correction function causes the mannequins to flicker on and off in the vicinity of the marker or destination.
.
This raises one more question: http://www.gamesas.com/user/176330-arthmoor/, http://www.gamesas.com/user/764276-sluckyd/, or anyone-else; Have you encountered any visible actors (other than mannequins) that didn't clip properly and you could literally walk right through them?

» Wed Jun 20, 2012 12:06 pm

I've not once walked right through them. This is one of those things I would notice right away if it did happen. The only true actor weirdness I have seen, is one of the khajiit caraven members walking whilst slowly descending into the ground til you can't see them. I don't know what caused that but it's only happened once.

» Wed Jun 20, 2012 3:35 pm

This raises one more question: http://www.gamesas.com/user/176330-arthmoor/, http://www.gamesas.com/user/764276-sluckyd/, or anyone-else; Have you encountered any visible actors (other than mannequins) that didn't clip properly and you could literally walk right through them?

No, that's never happened to me, not even with the mannequins.

» Wed Jun 20, 2012 5:30 am

This raises one more question: http://www.gamesas.com/user/176330-arthmoor/, http://www.gamesas.com/user/764276-sluckyd/, or anyone-else; Have you encountered any visible actors (other than mannequins) that didn't clip properly and you could literally walk right through them?

this has happened to me on several occasions (it only happened after patch 1.5.26). i can recreate it almost every time (although i can only trigger it from using a custom armor that uses invisibility spell)

the actor will run in place and you can walk through them. eventually they snap back to normal and everything is fine again (also fixable by using wait)

this also happened on a regular basis during patch 1.4 for mannequins only.

» Wed Jun 20, 2012 8:28 am

this has happened to me on several occasions (it only happened after patch 1.5.26). i can recreate it almost every time (although i can only trigger it from using a custom armor that uses invisibility spell) the actor will run in place and you can walk through them. eventually they snap back to normal and everything is fine again (also fixable by using wait) this also happened on a regular basis during patch 1.4 for mannequins only.

.
So waiting has the opposite effect on non-mannequin actors when their meshes and textures separate. It makes sense given the differences. I take it that this mesh drift with mannequins is another bug returning from the crypt (1.4...). Thank you, http://www.gamesas.com/user/766649-amethyst-deceiver/, for the confirmation.
.
Thanks http://www.gamesas.com/user/176330-arthmoor/ and http://www.gamesas.com/user/378305-terra-nova/ for your input. Here's a picture of what's happening:
.
[img]http://realmeleven.net/ActorClipping.png[/img]
.
It is beginning to sound like part of this problem may have a kill switch in the "Actor AI". But I think I might be guilty of being overly optimistic on this one!
.
And, Terra Nova, that sinking feeling with actors used to be an issue with NavMesh taking a dive beneath the landscape. I've currently got http://realmeleven.net/Whiterun/NaughtyLetrush.png outside Whiterun Stables (and http://realmeleven.net/Whiterun/JustSproutingFromTheGround.png). If we take a http://realmeleven.net/Whiterun/RoadSurfaceAboveHole%28WhiteRunStablesSinkingStablehand%29.png in SkyCK, the NavMesh seems pretty normal but closer inspection may raise the question of which ground we happen to be talking about. http://realmeleven.net/Whiterun/HoleInProfileBeneathRoadSurface%28WhiteRunStablesSinkingStablehand%29.png, we can see a hole beneath the road and it is conceivable that if Skyrim is still suffering from the same sinking NPC bug that affected Fallout 3, then this dual layering of the ground at least prevents actors from disappearing altogether - at least, it probably does so somewhat longer.
.
The issue which may be related is disappearing textures and/or meshes. Here's a http://realmeleven.net/Whiterun/WhiteRunTextureFailure.png. The problem occurred as a consequence of stressing the system while the game was running - and I think I might have stressed the game further by sprinting all the way down from Dragonsreach. I saved the game and restarted - which fixed the problem. http://realmeleven.net/Whiterun/WhiteRunTextureFailureShowingMeshLocations.png. This too was solved the same way - which led me to wonder if some of this monkey-business might not be something more like http://www.gamesas.com/topic/1362474-compatibility-with-other-mods-tips/ which crops up in some comments from http://www.gamesas.com/user/176330-arthmoor/ and http://www.gamesas.com/user/325100-kuertee/ in script related issues discussed on that thread.
.
[EDIT]Fixed broken link[/EDIT]

» Wed Jun 20, 2012 6:17 am

And, Terra Nova, that sinking feeling with actors used to be an issue with NavMesh taking a dive beneath the landscape. I've currently got http://realmeleven.net/Whiterun/NaughtyLetrush.png outside Whiterun Stables (and http://realmeleven.net/Whiterun/JustSproutingFromTheGround.png).

Louis Letrush is a separate issue. The one buried up to his waste is supposed to be on a horse and for whatever reason, that horse has vanished underneath him. The quest itself is bugged and is spawning generated clones of him. That's all been fixed by the USKP so you won't see any MORE Letrush clones, but it can't get rid of the existing ones.

» Wed Jun 20, 2012 4:35 pm

ive just come to accept that i own a Letrush farm outside whiterun. I want a mod that allows me to harvest his clones like crops.

» Wed Jun 20, 2012 5:43 am

Everyone: It took longer for me to correlate and type up the info I had to give ya's the other night than I thought it was gunna. I wanted to post it before the weekend ended, as I know some of you may have had time to work on modding, but it was like 3am and I was gettin' pretty tired. I knew I wasn't gunna be available earlier today/this morning to elaborate on that last post is my point... sorry for the vagaries it may have contained. I also apologize for the bad resolution and lack of narration in the video... but you can see what you need to. I may remake another video, and with a follower this time; better res too.

If someone can tell me how to do those spoiler things, I'll post up some of the documentation I made of what I called the Riften Experiments. Those were the several hours of working with just skyrim.esm loaded in the CK, tinkering with the Tamriel-Riften area (to reproduce and test NavMesh Bug as manifest in the Open Cities mod). It's way too extensive to just post outright... this way, those who don't give a rat's fast don't have to look at it.

ThingyPerson: First of all, isn't all modding and video-gaming frivolous? Being a black kettle... I'll answer your question - yes, yes I am. That mod's currently hidden because I haven't gone back to remake it in the CK yet, and I don't want to be responsible for a GECK'd mod corrupting people's saveGames/whatever. Just so you know... it was "Bibi Vidi Vici Veni".

Having been the first to post a non-Vanilla dungeon, first custom worldSpace, first custom interior cell, and the first non-nilla Player-home; not to mention posting the documentation on how I did it all (helping others to start modding preCK)... I believed I earned the right for self-proclamation and frivolity. Although, now seeing all the broken mods and Users' saveGames corrupted beyond measure... I kinda feel like Gaius Julius might have, could he have seen what his empire eventually turned into.

RealmEleven: I agree with most of what you said, and I think there are a couple things about mannequins that I may help clear up for ya. The texture doesn't separate from the mesh... I'm not sure that's even possible; what happens is the entire actor wanders (mesh, texture, scripting, objects they are wearing, etc). The reason you can walk right through them (yes, I know exactly what you're talking about), is that they are flagged as 'ghosts' - this means their collision is shut off. What you actually activate is a collision trigger box... which is placed on top of the mannequin, and is invisible.

I know this to be the case, because my SPODUM mod does away with the old trigger-box system... and removes the ghost flag - and voila, you have an actor that's scripted to act like a mannequin. Without the wandering fix, they wander as expected - but you can't walk through mine as you describe... you can even still attack and kill them (that's what makes them disposable). Essentially, the actor you walked through wandered, but its collision-box didn't or it wound up in a different spot. Have you even seen a 'wandered' actor/mannequin, and somewhere nearby or elsewhere in the cell there was a mysterious, invisible column or beam you bump into?

I know about the wait thing triggering the Wandering Bug for mannequins... BUT, and I just tested this, upon first-arrival it DOESN'T. This is referring to the pacing mannequins in the video... not the ones in Vanilla Player-homes ...and that's while running the wandering fix. I think I alluded to this in my last post, but was unable to elaborate. I'll recap these results below..

About the onCellAttach vs onCellLoad... the 'Attach' is what fires whenever Player enters the cell containing the scripted object (I THINK that's what "attaches" the cell..); while 'Load' only happens every couple times Player enters said cell. I believe it's intended to eliminate the need for loading the cell one had JUST left should they decide to go right back to the area they just came from (which, as we all know, is a huge part of gaming). Basically, it's to save time waiting for the load screen to finish when you enter buildings then exit more than once (though just one example).

Arthmoor et al: (side note - I know who you're talking about... I was just being facetious heheh) I was unable to elaborate in my PM and post the other night.. about my findings. So here's some more details and my tentative conclusions. When I messed around with Riften (without your mod loaded, just skyrim.esm; my "Riften Experiments"), I found the following - and this is basically the good news I had:
(of course this is all after doing the fast-trav-return... unless otherwise stated)

1- Only one cell, of the three I navMeshed and placed actors in, triggers the NavMesh Bug... that's Wilderness 42,-24 (the cell which contains BOTH your party balconies). This cell does NOT have ANY Vanilla navMesh in it. The video shows this (actors on the balcony); using the Open Cities mod, which was left completely unaltered with the exceptions of the mannequins and their patrol markers I added to the cells.

2a- In a cell which DOES have Vanilla navMesh, placing an actor inside a custom-made navMesh will cause that actor to wander to the CLOSEST Vanilla navMesh in that cell, unless scripted to a marker (how weird is THAT?). This is why SOME actors wind up outside the city's walls... because it's the same cell, and that navMesh (outside) is Vanilla. The end of the video illustrates this.
2b- If an actor is placed the same as in #2a, and their AI does NOT enter #1's cell, it will work as expected (AI works fine, no wandering, no outside the wall)... as shown in the video.

3a- In a cell which does NOT have Vanilla navMesh, placing an actor inside custom navMesh causes that actor to sandbox in-place.. BUT only if scripted to be forced back to that marker (eg: wandering fix). If not scripted, that actor will wind up on the balcony (that is NOT to say that ALL actors on the balcony are there because of this, as I'll explain in a moment). This is shown in the video as well.

3b- ALSO (same cell/actor); if after fast-trav-return, one waits in-game for any length of time (and apparently if you just open the wait screen, etc) that same actor wanders (is forced to the party balcony like the others).

4- Actors who aren't placed in that center 'nilla-less' cell (#1 above), will NOT enter it if their AI is programmed to. This probably accounts for more of the actors outside the gate (end of the video). Since you said some actors are placed indoors, then enter into the area on attach (? or is it load? init?)... when they enter the cell, their behavior defaults to #3a above... breaking their AI and sending them to wander up to the balcony.

5a- BEFORE fast-trav-return, followers work perfectly normal (as everything is known to on first-arrival). After the Bug is triggered, a follower would stop right at the cell-border as-if there were no navMesh.

5b- BUT; followers may be told to "wait there" INSIDE that Bugged #1 center cell, but NOT just anywhere inside. I was only able to get a follower to go about 30-40 feet inside it, then she refused to go any further - as if there were no navMesh where I pointed. Note that she 'waits there' inside the area she had refused to follow into not a minute before, and is inside the 'broken' cell (the center/nilla-less one.. Wilderness 42,-24).

= The party balconies being the destinations of choice may seem significant, but I'm not so sure it is. I think it may just be circumstantial... it may just happen to be the closest navMesh in the cell not 'damaged' (or overlooked, misinterpreted, etc). Without knowing what IS damaged and why, there's no telling why the party balconies. I DID try deleting your balconies'navMeshes (and unlink the doors)... the actors who appeared up there just wander elsewhere (further bolstering my 'wandering' theory, as opposed to a marker or whatever being responsible for those specific locations).

*** I think #2 above occurs because of something directly related to navMesh; which may be obvious to some, but I always try to remain open-mindedly objective in all things. I believe this is the case because actors ALWAYS wind up on VANILLA navMesh in these cells (the cell with the North Gate, and the one with the Southern Gates)... unless that actor is scripted to an certain marker.

Though if the entire cell's navMesh was damaged, the actor wouldn't spawn next to the walls but over 50ft or more away (and NOT re-enter the damaged cell)... so I think we can rule that out. "Why these cells and why Vanilla navMesh?" you may be asking. I think the "anathema cell" (that center cell with no nilla-nav), being linked to the adjacent cells, infects them by association - but seemingly only partially. I'll go into why I believe this may be possible a little more in a sec.

*** It SEEMS that only the custom navMesh in a 'hybrid' cell (Vanilla & custom navMesh) is damaged, ignored, or whatever it is that's happening.

Fast-travelling away then returning, as well as moving several cells away then returning, triggers the onCellLoad event. Am I assuming too much by insinuating the NavMesh Bug, being triggered under the same circumstance as required by onCellLoad, is actually caused by something happening when the cell runs its LOAD ROUTINE... and no other time? Remember that 'waiting' only triggered wandering after the 'Load' event. We know when one first visits an area, everything is fine (regarding NavMesh Bug and Wandering Bug)... which means the data itself is valid, and can be processed correctly.

Now if the data is correct (error-less, finalized navMeshes), and the game-engine (as a whole) CAN operate correctly (first-arrival works perfectly), I think we need to look somewhere other than those two things for a cause. Seeing as those are two HUGE things, not much is left; what IS left are scripts and AI. BUT... I already know through my Riften Experiments that navMesh CAN be damaged by using certain procedures, yet it still remains to be seen as to what ramefications that has in-game. I also know that it may, in fact, BE a problem in the game-engine... regarding how a certain record or subrecord is interpreted under certain conditions.

What I'm leading up to here is that maybe the complete lack of Vanilla navMesh in a particular cell means a certain subrecord wasn't written for that cell (a NAVI perhaps?). By finalizing a custom navMesh in the area, a non-Vanilla subrecord would have been generated... enabling AI in that cell (as seen on 'first-arrival'). NOW, if the game-engine is coded to interpret things a certain way during 'Attach' routines versus a different way during 'Load' routines (or Inits, etc), could that be causing our drama? (eg: during certain routines our custom subrecord is somehow treated differently than the Vanilla subrecords)

Another suspect for causing an 'anathema cell' (if ever there is such a thing) could be the LAND record for that given cell. Perhaps it has certain data which the engine sees during a Load routine... and determines it isn't compatible and discards it. But wait a sec - doesn't the onCellLoad event fire during 'first-arrival' (ie: BEFORE fast-trav-return)? If that's the case, then that may eliminate the "Load" theory. I doubt this is it though... I'm leaning toward a NAVI subrecord, if anything of this nature IS the cause.

Though our drama clearly happens during that onCellLoad event, it may only be because something remote is triggered during it. What this could be, I'm at a loss for at the moment. And what of the part about actors not moving but sandboxing - but then wander after an in-game "wait"? It's also getting late again (4am), so tomorrow I'll explain what I found regarding how navMeshes in certain cells can be damaged by using certain methods or orders of doing things. [part of my personal philosophy is that tomorrow comes when you wake up or the sun rises... whichever comes first]

Rest assured that you WON'T have to change the way you create navMesh (given you follow the generally accepted methods, like the wiki), but something as seemingly mundane as as saving the ESP before finalizing a navMesh, then again afterwards... trust me, it gets VERY strange - but it's ALL ONLY in that ONE cell... and the only difference I can perceive between that cell and any other is the absense of nilla-nav.

By the way, I've only looked at Riften in the CK; I tested other cities in-game (with the OC mod, not my experiments) and saw what you were talking about... but decided to start on Riften - because the balconies were such a conspicuous indicator. I predict that other troublesome areas will all be in cells with no Vanilla navMesh (that is originally... not to say deleting one reproduces this), and will conform to the above criteria for behavior... ie - based on whether or not the cell has nilla-nav, or if it shares a merged cell-border with one that doesn't. Keep in mind, that this is having already excluded mods which can be fixed by using an ESM (ie: custom worldSpaces and interiorCells).

» Wed Jun 20, 2012 6:13 am

this may or may not be related to our current soap opera, but i've been messing around with a teleporter map that uses the game.fasttravel() in the script. and i noticed that this does not work on esp files.

when i tested this code in a navmeshed esp, i ended up in some plane of Oblivion (all black with no way to get out, cant even see menu although can hear it opening up and can hear other NPC footsteps around me).

maybe this is the player experiencing navmesh bug in 1st person (i wonder if this black realm is the purgatory that NPCs go to when the navmesh bug hits). when i switched the file to esm, it worked perfectly fine, just like the navmesh bug.

» Wed Jun 20, 2012 7:08 pm

SLuckyD

[spoiler][*/spoiler] are the tags.

@RealmEleven - you are aware that the Louis issue is unrelated to the navmesh right? Also you didn't have navmesh turned on in those screenshots. If that spot was sunken in, that no doubt the other NPCs that walk by would drop down too, but I haven't seen that happen yet.

» Wed Jun 20, 2012 12:10 pm

http://www.gamesas.com/user/666599-realmeleven/ - The menu that Daemonjax added to SLuckyD's Vanilla Mannequin Script Fix allows you to reset the mannequins to their start positions by going to the original location of the mannequin (their pedestal), clicking activate on the activator, and choosing the Do Nothing option. It's just the mesh of the mannequin that is moving around, not it's activator.

I should mention, Daemonjax told me the menu was always there when he was running tests on getting it working, bethesda just never figured out how to get it right. That, or they ran out of time...lost interest..who knows. Funny stuff. Love it when modders fix the developers screw ups. DJ also fixed the critterspawn script that was acting up and a couple of people on this forum told me worked properly, when indeed, it did not. It is a recurring bug that can be easily re-created.

Any way, hats off to all of you trying to find another solution to this issue. Perhaps we will get lucky with a future patch and crazy, drunk uncle related to the bride of navmesh will not show up to the reunion.

» Wed Jun 20, 2012 9:22 am

For me, I'm not wasting my time on hackish solutions like splitting things into a .esm/.esp pair. Nor am I going to deal with having to put up with MasterUpdate. If Skyrtm modding seriously comes to that level, then I won't waste the effort in producing anything that would require a navmesh edit beyond really small simple locations. Just like you, spending time on a lost cause is out of the question. If this sort of thing results in lots of people deciding the same way and Skyrim is reduced to a whole lot of smaller mods, some of us will just go back to modding Oblivion where these headaches don't exist.

Should this happen, I'd predict the quick death of the Skyrim modding forum. The only reason it's still alive and well right now is because Bethesda is still actively trying to fix things. People have lots of patience in that scenario, but if it's announced that this bug won't be fixed, count on an exodus the likes of which you've never seen.

Wow, that sounds like serious words

...I REALLY hope the Navmesh bug gets fixed...even if it means that all actual house/quest/etc mods would need to get updated, and/or start a new savegame...

But in a positive note, after all the effort on creating the Workshop and releasing the CK, I highly doubt Bethesda would leave things like that.

» Wed Jun 20, 2012 8:57 pm

I think everyone knows there is slim chance of everyone just abandoning Skyrim. The game is just that good, even without huge world changing mods. Bethesda knows there are very few modders willing to undertake projects of that scope and even fewer who can complete them. It would appear to me that the typical modder posting on the Steam Workshop is oblivious to the Navmesh bug and likely to stay that way. It would be a terrible shame for Skyrim to lose those few modders who are actually capable of producing the larger scope mods.

However, the truth is that Skyrim is full of bugs and most players just learn to slog through them and keep on playing. I'm sure Bethesda wants to fix them all, even though we all know they never will. I just hope this one is one of those that get fixed sooner rather than later or not at all.

» Wed Jun 20, 2012 5:15 pm

A guy on Nexus told me that this bug could be fixed or avoided by making an esm is that confirmed?

» Wed Jun 20, 2012 3:49 pm

SLuckyD

[spoiler][*/spoiler] are the tags.

@RealmEleven - you are aware that the Louis issue is unrelated to the navmesh right? Also you didn't have navmesh turned on in those screenshots. If that spot was sunken in, that no doubt the other NPCs that walk by would drop down too, but I haven't seen that happen yet.

.
Thank you http://www.gamesas.com/user/378305-terra-nova/, yes I am now aware that Louis Letrush has other issues, but I've seen this affect other Actors (e.g. Sigur) and if the lower terrain layer with the depression in it loads first, followed by the NavMesh followed by an actor dropping in at the wrong time and place, the actor may occasionally settle in the hole before the last two layers of terrain are loaded. I think that it's probably not supposed to happen this way but this might explain that sinking feeling that some of these actors exhibit once they find their way beneath the top terrain layer. I think http://www.gamesas.com/user/176330-arthmoor/'s explanation also makes a lot of sense and does seem to explain the multiple Louis Letrush actors. But the fact remains that other actors are also sinking from time to time and, since Fallout 3 (and possibly earlier than that), actors have been disappearing beneath ground level - sometimes for NavMesh reasons and sometimes for other reasons.

» Wed Jun 20, 2012 3:58 pm

http://www.gamesas.com/user/666599-realmeleven/ - The menu that Daemonjax added to SLuckyD's Vanilla Mannequin Script Fix allows you to reset the mannequins to their start positions by going to the original location of the mannequin (their pedestal), clicking activate on the activator, and choosing the Do Nothing option. It's just the mesh of the mannequin that is moving around, not it's activator.

I should mention, Daemonjax told me the menu was always there when he was running tests on getting it working, bethesda just never figured out how to get it right. That, or they ran out of time...lost interest..who knows. Funny stuff. Love it when modders fix the developers screw ups. DJ also fixed the critterspawn script that was acting up and a couple of people on this forum told me worked properly, when indeed, it did not. It is a recurring bug that can be easily re-created.

Any way, hats off to all of you trying to find another solution to this issue. Perhaps we will get lucky with a future patch and crazy, drunk uncle related to the bride of navmesh will not show up to the reunion.

.
http://www.gamesas.com/user/766649-amethyst-deceiver/ has a http://www.gamesas.com/topic/1354348-finally-figured-out-how-to-permanently-disable-mannequin-movementpose-issues/page__fromsearch__1. Although I have my prejudices towards triggerboxes (they used to be somewhat process hungry and I assmume they still are), I think that the idea of putting something in the environment that triggers a position correction (based on player location) is brilliant.

» Wed Jun 20, 2012 11:28 am

the trigger box was a terrible idea (caused very bad lag for some users when triggering 12 mannequins to reset, running all 12 scripts simultaneously). i have since changed it to wall trigger (manually activate)

» Wed Jun 20, 2012 4:37 am

A guy on Nexus told me that this bug could be fixed or avoided by making an esm is that confirmed?

That's a workaround, and as I've said before, not a good one. Converting a mod into an esm throws off everything about load ordering that's been established. Plus, you have to have ONAM lists, which can't be generated by anything other than FO3Edit, which is NOT built to handle Skyrim files.

» Wed Jun 20, 2012 8:18 pm

the trigger box was a terrible idea (caused very bad lag for some users when triggering 12 mannequins to reset, running all 12 scripts simultaneously). i have since changed it to wall trigger (manually activate)

.
I still think the idea is a stroke of genius. You see, it doesn't have to be a triggerbox. You could use a door with an autoclose routine and trigger the position correction every time it is activated by the player. That's just one idea. The player opening her/his inventory in the cell could be another way to manually correct things. Then there are events; and I am still looking for an object and event combination that will fire when the player comes out of the wait menu and when the player comes out of the sleep menu...

» Wed Jun 20, 2012 1:39 pm

Perhaps Beth can allow the CK to handle ONAM lists..

» Wed Jun 20, 2012 12:26 pm

That's a workaround, and as I've said before, not a good one. Converting a mod into an esm throws off everything about load ordering that's been established. Plus, you have to have ONAM lists, which can't be generated by anything other than FO3Edit, which is NOT built to handle Skyrim files.

Sigh ... sorry I didn't read all posts....

SO just a work around and not a fix ... and is there any other voice from Beth coming to fix this?

» Wed Jun 20, 2012 11:26 am

Terra Nova: Thanks... I thought it was something like that (spoiler stuff), couldn't find anything in a quick search though. Also, I agree with you about Ma Beth adding the functionality to create ONAMs; I kinda forgot to voice my opinion on that during the earlier heated debate (regarding Steam adding the ability to use ESMs/etc).

RealmEleven & Amethyst Deceiver: If the script is too slow when only moving a dozen boxes and their mannequins, the script sounds like it needs to be optimized. Did you say that the activator runs a script, which activates all the mannequins' scripts? Doing it all from one script would be better than using a global, or doing cross-script property references wouldn't it? [moveTo(getLinkedRef()) on each one] But regarding a function to run after a wait/sleep... you may have to edit those scripts directly, or maybe reference those scripts' States (getState I think it is) to see what's going on when.

Also, regarding the fastTrav script sending you to Obliv... did you call it while inside a cell flagged as 'no travel fro here'? That MAY have caused drama if that were the case. Also, I never heard of the NavMesh Bug affecting Player... or was that the point you were trying to make...

Prometheus_ts: the workaround is fine without an ONAM list if the ESM doesn't alter Vanilla (leaving those records and navMeshes in the ESP); the problem is that mods altering only Vanilla don't have this option, unless using the precarious ONAM technique. I think they tested that last scenario out (Vanilla-only mod with an ESM), and had good results - but that was like 200 posts ago and I don't recall. I assume the problem with that (aside from the controversial software issues) is if you have hundreds of records changed, it becomes overly-tedious to MAKE the ONAM list... I dunno as this really isn't my bag.

ElDiabs: yea.. we left the Vanilla messageBox as it originally was (eliminating the need for an ESP). The script's code which called it was commented out in Vanilla, as were the parts about changing the poses. I believe they couldn't get poses to work properly, and rather than spend more time on it, they commented out those lines anticipating fixing it in the future. Daemonjax and I simply beat them to it... and expanded the functionality to 10 poses, not just 3 (at least my versions do.. I think DJ's do too); also the ability to toggle their AI so they sandbox/animate poses in-place if you want.

About the critters... I had problems with some spawning in my Tower mod. The butterflies seem to be frozen and don't move. The other insects (dragonflies, etc) I could only get to spawn period when placed over a 'water' navMesh. Strange, I know... but if I moved them 3ft away, over land navMesh - they wouldn't spawn. I dunno if that's similar to the problem you or others may be having with them; but I know I got my critters a-spawnin' without script-aid or changing anything but their placement.

OK... so here it is, the documention of what I found relating to navMeshes in Tamriel-Riften. These tests show that ONE cell is causing all the trouble in that area, and that the adjacent cells are partially affected by it. They also illustrate several ways to induce errors in navMesh, many of which may not appear to have any negative effects in-game. Unless you have a bunch of time on your hands (or you're hourly, bored, and have access to the net.. heheh), I've already summed up my basic opinion on what all this means (my past two posts)... but there may be more details in here which help to better explain why I believe what I do.

Exact procedure used in the experiments below; regarding how to trigger the Bug in-game.

Spoiler

EXACT TEST PROCEDURE USED FOR ALL TESTS:
- I ALWAYS load the ESP to test with Skyrim, but DON'T load a saveGame.
- I use the console to coc to whiterunexterior04 (no apparent reason, other than it isn't the modded area.. just to ensure consistent testing).
- I exit out of the dialog with the guard, open the console and "tmm 1" (to turn on all map markers).
- Then I fast-travel to Riften Stables, enter my door to go inside the city, walk the sidewalk straight ahead until I get to the SE gate, exit my other door to outside the walls, then fast-travel away.
- I travel to Solitude, then to Morthal (to reassure the new cell-loads are enough to trigger buggy behavior), then back to Riften Stables.
- I then enter my door to inside the city again and record the results. Sometimes I fast-travel a second time to double-check; and the results are always the same the second time (so are not recorded).

The Rise & Fall of Family-NavMesh Bug: Volume One - The Lost Volume
- Sadly, was lost forever. I had started to right a rebuttal post during the heated debate, but seeing the futility in it and more value in actually doing something to help, I opened the CK and messed around. I documented it thoroughly, just as the other tests shown below... but I typed it all out at the end of that rebuttal post (in Notepad++, in the same TXT file). I was called away from the computer and shut it down hastily... clicking "no" to saving the post. No longer intending to post it, I just deleted it - but I forgot that Test One was documented at the end of it. I tried and searched for auto-backups or temp files.. but it was gone forever.. and still is. (I use Total Commander; when I delete something, it does NOT go to the recycle bin..)
- The tests below sought to replicate Test One's results.. which were just like everyone reports - actors on the balcony. As you'll read below, the subsequent tests couldn't replicate that symptom... but found all kinds of OTHER drama.

The Rise & Fall of Family-NavMesh Bug: Volume Two - The Whole Story
- This volume is the full record of the Riften Experiments... unedited. It recounts modding the Vanilla Tamriel cells INSIDE the walls of Riften; to simulate conditions found in mods such as Open Cities.

Spoiler

2a1
I load the CK and load Tamriel-Riften; then dragged the renderWindow up to the stable area, placed two doors, and linked them to each other. I moved one of them and its marker inside the walls next to the catapult. Saved it. (edited cell's name is RiftenCityNorthGateExterior)

2a2
I do the same thing near the SouthEast gate... two doors, etc. Saved it. (edited cell's name is RiftenCitySouthGateExterior)

2b
Then I open the actor Delphine, change her ID to aaDelphine, and click OK (save). I remove all scripts, the essential and unique flags, all faction data, all AI packages, and all inventory items. Then I add the "defaultSandboxCurrentLocation1024" AI package, then ok/save the actor.

Then I placed 9 instances of her on the path between the 2 doors inside the walls. I make sure there are at least two Delphines in each cell with my doors, as well as the center cell, all where navMesh WILL be (but aren't yet). Each time in placing her, it shows texture errors; which are benign (purely esthetic and won't cause crashes or other buggy behavior)... this is the Grey-Face Syndrome, as I didn't auto-gen the head meshes for the 'new' actor.
I then test this ESP as-is.. NO NAVMESH.

Two Delphines were outside the North city gate (sandboxing normally), four more were inside the city (stuck in the spots I placed them), three more were outside the gate when I left the city (sandboxing normally). After fast-trvel-return, they were all doing the same thing in the same spots. I already knew that NPCs placed outside navMesh will automatically be teleported to the nearest(?) navMesh in the cell; if there is no navMesh they simply stay in the spot they are placed and do nothing.

2c
Then I created some navMesh inside the city... a simple path starting from the North gate door I placed, but NOT crossing a new cell yet. The first two Delphines were inside this navMesh, while the other seven were not. I finalized, no errors; confirmed the two doors 'greened' their tri's (they did), then I exited the navMesh toolbar and saved it.

Tested again: first entry had the two navMesh Delphines sandboxing normally where placed, four stuck on spot and 3 outside the South gate (as before). Fast-trav-return and the first two Dels were now outside the North gate sandboxing normally (as if no navMesh were added yet, like the first test). The others elsewhere in the city were still the same as before.

2d
Then I created more navMesh inside the city, this time on the South side near that gate... up to the nearest cell-border. This one contains three Dels. Finalized & saved, no errors. Tested again.

This time the same for the Northern Dels AND for the Southern Dels... worked fine first visit, second visit has them outside the walls (yet still sandboxing normally). SO FAR - I believe this has absolutely NOTHING to do with navMeshes... it seems to me to be a fine example of the "Wandering Mannequin Bug" - as it fits all the criteria:

If you doubt this hypothesis, keep in mind that mannequins are actors just like the rest of em - only with their AI and whatnot stripped (and they are specially scripted, but that's beside the point). My Delphines are exactly like my mannequins, except they are sandboxed instead of mannequin-AI'd. Keep in mind that I spent like two weeks working with mannequins/actors and eventually fixed them (though the actual Wandering Bug prob'ly took like an hour to figure out.. other drama became aggravatingly extensive to solve).

2e
Based on Test One, NOW is when I expect it to get interesting. I navMesh the cell between the two cells already done. I do NOT place the vertices close enough to the cell-border to allow merging... to test the cell as-is (finalized, yet not 'merged' to adjacent cells). Testing shows the previous results, with the 'center' four Dels still in the spots I placed them (well one was a few steps away.. but close enough for government work, eh?).

This jibes with 'Wandering Syndrome' as well... since no other navMesh exists in that center cell, they were nearby their original placement.. some or all being slightly off. I DO find it interesting that actors seem to choose Vanilla navMesh over user-made... BUT only the South Dels appear/spawn on "preferred" navMesh, the North Dels appear in the trees next to the door (NOT preferred).

2f
In the Test One, THIS was the critical point right here... connecting that middle cell. Surprisingly, it finalized and saved without errors. Tested it, aaannnnd... they all did exactly as the previous test with ONE exception - strange as it is, one of the Northern Dels appeared outside the Southern Gate (instead of the Northern). No biggy... still kinda-sorta chalkable to the Wandering Syndrome, but what's disconcerting is that she crossed two cell borders to get there. I've never heard of cell-crossage before, BUT all my wandering-mannequin testing was interior (single-cell)... so it MAY be possible for all I know.

Retesting this showed that actor which crossed the cells behaving normally (DIDN'T cross the cells this time)... indicating this is intermittant buggy behavior; the worst kind, as you never know WHAT is damaged or WHEN it'll all crash down on you.

3a
I then reproduced the above experiment, in it's entirety, from scratch. This is actually the third time.. my first time's documentation was tragically lost, so this the first attempt to repeat it. This one doesn't have a balcony, yet the Test One did. There are too many specific differences like that to accurately recount from memory exactly what is was that first ESP did to trigger something like the navMesh bug you describe.

***** The only difference in this third time from the second (the Test Two explained above), was that I DON'T SAVE THE ESP OR EXIT THE NAVMESH TOOLBAR... UNTIL THE ENTIRE THING IS DONE. Whereas the above, successful test, I exited the navMesh toolbar and saved the ESP between each cell's changes... this one I did it all in the same "navMesh session" and without saving the plugin until the end.

***** I SAVED THE ESP WHILE THE NAVMESH TOOLBAR WAS STILL OPEN - another possibility for being the culprit. During the save, the following, a seemingly innocuous error popped up:
[[PATHFINDING: BSNavmesh::GetMatchingEdge() for (Navmesh 0x01000d70, Tri 0, Edge 2) - Bad matching triangle index: Navmesh 0x00103128, Tri 38]]
Seemingly innocuous because errors happen when making custom navMesh (they're even in Vanilla... all over the place)... just correct em and move on (leaving the Vanilla ones as-is, at least I do). One would assume to treat THIS error the same, correct?

Immediately doing a "Check NavMesh" in the center cell popped up the error:
[[PATHFINDING: Navmesh 01000d70 Cell 'Wilderness' (0000BCD0)(42,-24) in WorldSpace 'Tamriel' (0000003C), Triangle 17, edge 0 has bad Portal (Navmesh 000e0bf2 does not have a triangle index 17), Clearing the portal]]
It immediately asked: [[Found 0 triangles with high priority warnings, delete all?]]

I clicked yes for the hell of it; as one is generally instructed to do, regarding navMesh errors during checks. This deleted the merged cell-borders between the center cell and the North & South cells. It did NOT delete any tri's or visibly damage anything else... just made the thick 'solid green' line go away (ie: it broke the border-merge without changing anything else or moving the vertices/edges/etc).

I then re-finalized the center cell and saved the ESP (without closing the navMesh toolbar)... both uneventfully this time. The borders turned solid green again. Testing surprisingly showed the SAME results as Test Two (no NavMesh Bug, but Wandering Syndrome). Perhaps doing the check and correction fixed the expected error of NavMesh Bug (I don't remember doing that in Test One). Looks like Test Four is next...

4a
Recreated the Test Three exactly (from scratch), but without checking and correcting the navMesh after the errant save. 8:11, finished loading CK and began modding the test at 8:12. 8:23 - same error saving the ESP as Test Three; and again, it was saved after the entire thing was finished, and without exiting the navMesh toolbar. Ran the test in-game, 8:28 - same results as Test Three.. no NavMesh Bug. At least I'm getting pretty fast at navMeshing and all this stuff...

Next test will feature an island navMesh to simulate the 'party balcony'... where NPCs all wind up in some mods. One of the Delphines will be placed on it, also placed with a new static, since Tamriel-Riften doesn't HAVE that balcony. I will also save the ESP at the beginning of the CK session, in the middle, and again at the end... all using different filenames (so I can go back and test each without having to remake the whole thing to get back to point x).

5a
Modded the first part of the basic test... making and linking the four doors, placing the balcony, creating aaDelphine and placing nine of her (one of em on the balcony) inside Riften. Everything except the navMesh. I then saved the ESP.

5b
Saved the ESP again (new name), after making the navMeshes but NOT finalizing them yet (navBar still open). I had to say yes when CK asked if the cells were finalized, as it sensed they should have been (common edges)... answering no would exit the CK without saving (I tried it once.. during Test One I think). This particular version (5a2 5b) needs to be recreated, as I didn't write down the error (thinking I had already seen it, trying to save time... "complacency kills" ... I know I know).

5c
Saved the ESP again (another new name) after finalizing all three cells - as above, North South then center (navBar still open). This time there were no errors when saving... as there should have been like in Tests Three and Four. Same in-game results as them though - no NavMesh Bug... but still the Wandering Syndrome (as expected). The balcony-Delphine stayed up there the whole time... sandboxing away, never joined by any of her fellow clones.

6a
This test will use version 5a above - the actual ESP this time, not just the procedure (though still in a new CK session). This time, instead of saving the ESP after creating (but not finalizing) the navMesh, I created & finalized it, THEN saved it. It popped up these four errors:
[[PATHFINDING: Navmesh 00103128 Cell 'RiftenCityNorthGateExterior' (0000BCAF)(42,-23) in WorldSpace 'Tamriel'(0000003C), Triangle 33 and 34 have opposite normals but are linked]] [[PATHFINDING: Navmesh 00103128 Cell 'RiftenCityNorthGateExterior'(0000BCAF)42,-23) in WorldSpace 'Tamriel'(0000003C), Triangle 33 Edge 1 and Triangle 34 Edge 1 should be linked, but they are not]]
Another error, same exact as the first (opposite normals, same cell and tri's.. EVERYTHING the same)
Another error, same as the second (should be linked but isn't, same cell/etc), but for Tri 34 Edge 0 and Tri 33 Edge 2.

Where the hell did THAT come from?! Check this out... tested it - everything's fine for the first entry (as ALWAYS), fast-trav-return to Riften Stables: my door is wide open. I've never seen THAT before (although in my Tower mod, I do recall something similar.. but it went away somewhere in the process).

I had to close the door, then open it again before it let me inside the walls. Everything else was as the above Tests.. sandboxing Delphines, with the ones placed in cells containing Vanilla navMesh spawning outside the gate instead of where I placed them (ie: on Vanilla navMesh). In other words.. still no NavMesh Bug, just an open door.

7a
This test will use version 5b's ESP (everything including navMesh, but not finalized yet). The difference will be trying to finalize the center cell FIRST, as opposed to the North and South cells first THEN the center (as ALL the above have done, except maybe the lost First..).

I tweaked a couple vertices that looked like they wouldn't line up at the cell-borders then saved it with the navMesh toolbar still open. I then finalized the center, then the N & S, and saved it... all without errors.

Testing it, everything worked as Test Three, Four, and the others... but one of the Northern Dels was missing upon trav-return. I'll have to go back and double-check the past two tests, as I may have missed her (I didn't actually count.. they looked like they were all there).

Ran the same ESP again, after exiting Skyrim then restarting just to make sure... the Northern Del was still missing. I even tcl'd inside all the static buildings and walls - couldn't find her anywhere. She SHOULD have been just outside the Northern gate, in the trees with the other one, or just inside the gate (by my door) should she happened to have been where I actually placed her.

I ran Test Six again, to double-check the Delphines.. none missing, but the door was wide open again (so THAT wasn't a random occurance). Running Test Five again, there weren't any missing either - same results as listed above.

8a
Uses version 5a... no navMesh. Created all the navMeshes from scratch, finalizing the center first instead of N/S cells first. After finalizing was uneventful, I tried to save the ESP; with the navMesh toolbar still open, to keep the testing consistent. It popped up the same error as Test Three (though the actual Tri data is different because the tests use completely different navMeshes):
[[PATHFINDING: BSNavmesh::GetMatchingEdge()for(Navmesh 0x010012d3, Tri0, Edge 0) - Bad matching triangle index: Navmesh 0x00103128, Tri 40]]

Nice... What did THIS version have in store for me? Surprisingly, nothing new in-game.. same as Test 7a - in that one Northern Del was missing again. All others were where they were expected.. all still sandboxing.

8b
This isn't really getting anywhere closer to what I witnessed in the missing Fabled Test One. So I tried running a "Check NavMesh" on the center cell (since it showed that error during saving), still in the same session of the CK as 8a above.

As expected, it popped up the same error as the above Test Three (pathfinding/bad portal/0 tri's found/delete?)... this time I said no (whereas in Test Three, I picked yes - which deleted the merged cell-border). Immediately running another check on the same cell showed NO ERRORS; and the cell-border was NOT deleted as it was in Test Three.

Now it gets REALLY interesting... when trying to save the ESP after that 'check nav' - with the navMesh toolbar CLOSED for the FIRST time (to try and move things along), it pops up the the same error as Test 5b, about two cells' navMeshes sharing a common edge but aren't connected and asking if the navMeshes were finalized (the one which needs to be recreated to specifically document word-for-word). This SHOULD only be expected if the border-merges were essentially broken; as in Test 5b, the cell-borders were never merged (so the same symptom should manifest).

If you answer no (to 'is it finalized'), it threatens to shut down CK... so you have to pick yes or it won't save but exits CK altogether. It then pops up another error just like it; the first error was for cells 42,-23 and 42,-24 while this second error is for cells 42,-25 and 42,-24. This indicates the problematic cell is 42,-24; as the other cells' data is included in the ESP, just like ALL the cells which are adjacent to those you ever finalize. If the other cells were to blame, one would expect they would trigger similar errors, yet they don't.

So after that save finally finishes, I immediately opened the navMesh toolbar again. I saw it deleted the merged cell-borders, as implied by the type of errors recieved during the save; THOUGH not the actual tri's or vertices, but only the 'solid green' line (ie - it broke the border-merges). Again, this only happened in cell 42,-24... the adjacent cells' borders were still intact.

I also just realized that the error said 'share a common edge' whereas the above error said 'should be linked' (in Test 6a)... implying some kind of connection between the different Tests, yet a SPECIFICALLY DIFFERENT error. I KNEW I should've typed out that exact error...

For thoroughness, I tested it as-is, with the center cell not 're-merged' to either N or S; expecting it would have them all sandboxing as usual (since they aren't scripted/whatever to leave outside of 1024gu of their placed location). I was correct... they were; the center cell ones were in the spots I placed em (because the cell has no Vanilla navMesh for them to 'wander' to)... and the N/S cells' being outside the walls; ie - NOT where I placed them, but on Vanilla navMesh (expected as per the Wandering Syndrome).

8c
After the test, I went back to the CK (still the same session) and finalized all three cells again - center first. They all re-merged the cell-borders uneventfully, and it saved with no errors; again, with the navMesh toolbar CLOSED. Tested it in-game... same results as the last one (Test 8b). One would only see the difference between Tests 8b and 8c when NPCs are supposed to cross cells; I would expect 8b they would NOT cross the broken cell-border, while in 8c they would. I can't test this without using a saveGame... unless someone knows how to quickly materialize a dedicated follower (like Lydia) using the console.

The Rise & Fall of Family-NavMesh Bug: Volume Three - The Summary
- This is the precise summary of the Riften Experiments, test by test. It tries to filter all the vital information into a concise outline format, though doesn't contain specifics (such as word-for-word errors).

Spoiler

>"The Riften Experiments"<

ALL TESTS
Details: doors are always placed and linked the same way, the custom actor (aaDelphine) is always created the same way, the actors are always placed in the same general spots (unless otherwise noted, like the balcony) which is about 30-50ft apart (2-3 per modded cell), (if navMesh editing took place for that test) the navBar is always left open during saving unless otherwise stated

Results: all doors always turn their navMesh tri's green, all doors work normally for Player (not tested with a follower)

In-game: I always use the same procedure to trigger NavMesh Bug in Riften (as described in a separate section)

Secondary In-game: always tested by exiting Skyrim if running, re-starting it with the test ESP again, and performing the same procedure to trigger NavMesh Bug

TEST 2b

Details: JUST doors/NPCs, No new navMeshes added yet, no Vanilla cells finalized, NPCs placed in specific areas with NO navMesh, some cells which have NPCs placed in them contain Vanilla navMesh in other places (but the NPCs aren't placed on it)

In-game: NPCs placed in cells containing Vanilla navMesh (but aren't placed inside it) will 'wander' to the nearest(?) one, NPCs placed in a cell with no navMesh whatsoever will become stuck on the spots they were placed on. They even do that on the FIRST arrival of Player to the area, not only upon fast-trav-return.

TEST 2c

Details: Added navMesh to the cell with the North gate (with the placed doors linking outside with in), finalized that cell, saved with navMesh toolbar closed, that cell contains 2 instances of placed actors inside the custom navMesh

In-game: Same as Test 2b except - the 2 actors placed in the 'Northern' cell (with custom navMesh) sandbox normally where placed on Player's first entry/arrival, after fast-trav-return the Northern actors had 'wandered' to Vanilla navMesh outside the walls (though NOT on "preferred" navmesh tri's)

TEST 2d

Details: Added navMesh to the Southern gate cell (with the other linked doors), finalized that cell, saved with navMesh toolbar closed, that cell contains 3 actors inside custom navMesh (leaving only the 4 actors in the 'Center' cell (Wilderness Cell 42,-24), which doesn't have navMesh yet)

In-game: Same as Test 2c except - the 3 actors in that Southern cell were now sandboxing normally (as the Northern ones did, and still were), upon fast-trav-return the Southern actors spawned next to my outside door on the preferred Vanilla navMesh (as opposed to off to the side like the Northern actors do)

TEST 2e

Details: Added navMesh to the Center cell (but not close enough as to form merged cell-borders with anything), finalized that cell (no merged cell-borders), saved with navBar closed (as above), that cell contains 4 custom actors (leaving ALL custom actors placed inside of custom navMesh, over 3 finalized cells)

In-game: Same as Test 2d except - the last 4 actors (in the Center cell) were now sandboxing as all the others were (which is expected, should the NavMesh Bug NOT occur), THIS ILLUSTRATES "WANDERING BUG" (as discussed in a separate section). I consider this, Test 2e, to be successfully (no Navmesh Bug)... as the Wandering Bug is to be expected under the given circumstances; BUT NPCs won't be able to cross the cell borders, so is no viable.

TEST 2f

Details: Moves vertices in the Center cell close enough to merge the cell-borders, re-finalizes just the Center cell, saves with navBar closed

In-game: Same as Test 2e except - one of the Northern actors (upon fast-trav-return) spawned at the Southern outside door instead of the North woods (I have NEVER seen Wandering Syndrome which spans TWO cell-borders.. not even ONE)

Secondary In-game: ran the same as Test 2e (uneventfully and successful), having been the second time trying the SAME thing but getting different results isn't very encouraging (and implies a genuine game-engine problem, probably non-related to NavMesh Bug)

TEST 3a

Details: Recreates the entire Test Two experiment from scratch (identically) EXCEPT - modding the entire thing without saving the ESP until after all the navMeshes were finalized, and not closing the navBar when saving (as opposed to closing the navBar and saving the ESP between each cell's changes and finalizings)

Results: Finalizings were uneventful, saving the ESP triggered a navMesh-related "pathfinding" ERROR regarding a "bad matching triangle" - this broke the merged cell-borders of ONLY the Center cell.

Immediately after the save finished, performing a "Check NavMesh" (the button) triggers another navMesh-related "pathfinding" ERROR regarding a bad portal (and automatically "clearing" it) then asking about deleting "0" warning tri's (which was answered YES).

Immediately re-finalizing the Center cell successfully re-merges its cell-borders.

In-game: Successful/same results as Test Two (2e, and 2f when working correctly the second time)

TEST 4a

Details: Same exact test as Test 3a, recreated from scratch, except NOT doing the "Check NavMesh" and re-finalizing that cell and resaving

Results: Everything the same as Test 3a

TEST 5a

Details: Modded everything except the navMesh... JUST the linked doors, a static for a 'party balcony' (the same balcony that is troublesome for Open Cities), the custom actor, and placing the custom actor 9 times in Tamriel-Riften (1 of them on the balcony)

Results: Not tested.. same results as Test 2b would be expected, as this essentially repeats it

TEST 5b

Details: Added the navMeshes to Test 5a WITHOUT finalizing any cells, saved it to a new ESP with the navBar still open

Results: Not tested in-game (same as Test 2b kinda, expected to sandbox.. but not cross cell-borders). During the save, CK asked if the cells were finalized (it sensed they should have been based on edge closeness)... I had to answer YES (answering no would exit the CK without saving).

TEST 5c

Details: Finalizes all 3 cells (North, South, then the Center), then saved to another new ESP with the navBar still open

Results: No errors saving (as there were in Tests 3a and 4a)

In-game: no NavMesh Bug and it had the expected Wandering Bug

Secondary in-game: same results as the original

TEST 6a

Details: Uses the actual ESP from Test 5a above except - I created the navMesh, finalized, then saved the ESP (as opposed to creating the navMesh, then saving, finalizing, then saving again) with the navBar still open

Results: Saving it triggered 4 ERRORS, all navMesh related, regarding opposite normals and 'should be linked' edges (2 each).

In-game: same results as Test Two except - the door I placed outside the gate in the North cell was wide open... and had to be closed before being able to open it again to teleport

Secondary in-game: Same as the original results... the open door was NOT an isolated instance

TEST 7a

Details: Uses the actual ESP from Test 5b above except - finalizing the Center cell before the North and South cells (same as Test 5c except the cell-finalizing order), navBar open during save

Results: All cells finalized without any errors and saved the ESP without any errors

In-game: same results as all the above (successful) EXCEPT 1 of the Northern actors was completely missing. I searched everywhere, including tcl'ing inside of the wall and building statics, nowhere to be found.

Secondary in-game: same results as original - 1 Northern actor still completely missing

Third in-game: successful.. nothing missing, everyone sandboxing (though having wandered)

Fourth in-game: successful again.. nothing missing, still sandboxing

The third and fourth tries were both done without the CK running (which takes up an additional 30-50% of my system RAM, on the 20% windows takes up). This may make a difference, but I don't see how... it's the only difference between the tries that I can identify.

TEST 8a

Details: Uses the actual ESP of Test 5a above and created the navMesh from scratch, except - finalized all the cells Center first, then the North and South (same as Test 6a, except the cell-finalizing order), saved with the navBar still open

Results: During saving, it triggered the same ERROR type as in Test 3a ("bad matching triangle"), though the tri data was different since the navMeshes were created independently. In-game, the same results as Test 7a, ie - the same Northern Actor was missing.

TEST 8b

Details: In the same CK session using Test 8a, ran a "Check NavMesh" (the button in the navBar), saved the ESP with the navBar CLOSED (for the first time)

Results: Triggered the same ERRORS as the check in Test 3a (bad portal/ delete 0 tri's?), this time I answered NO. I immediately ran another "Check NavMesh", which showed no errors, and it did NOT break the merged cell-borders (like it did in Test 3a).

When trying to save the ESP it triggers the same ERROR as Test 5b (finalized? ..about the edges which should be connected but aren't), clicked yes (no exits the CK), same ERROR again but for the other cell-border.

Opening the navBar back up, the merged cell-borders were indeed broken (as indicated by the above errors).

In-game: Testing WITHOUT re-finalizing shows the same results as Test 2e (normally sandboxing, then Wandering Bug after fast-trav-return).

TEST 8c

Details: Re-finalizes the Center cell using Test 8b (in the same CK session), saves the ESP with the navBar CLOSED

In-game: No errors during finalizing or saving. Same in-game results as Test 8b (successful), though one would notice NPCs would now cross cell-borders (theoretically)

TEST 9a

Details: Recreates Test 7a (using Test 5b's ESP, but finalizing the cells in a different order than Test 5c), except - the navBar is CLOSED when saving (Test 7a was saved while still open).

In-game: No errors during finalizing or saving. Same in-game results as Test 8b (successful)

TEST 9b

Details: Continues the same CK session as Test 9a. Physically moves the North doors to other navMesh tri's, moves one actor from each cell to another navMesh tri in that cell, adds 3 more actors - but placed in areas NOT navMeshed (one in each cell). Refinalizes the North cell (to account for the moved doors).

Results: Both doors changed their tri's green, no errors finalizing or saving, saved with closed navBar.

In-game: Successful. Actors placed on spots where there were NO navMeshes automatically spawn where there IS navMesh, in the same cell (I don't think it's necessarily the closest navMesh.. didn't appear that). These same actors will spawn outside the walls upon fast-trav-return (which IS apparently to the nearest Vanilla navMesh), just like the other actors (which were originally placed inside custom navMesh) and in the same places.

TEST 9c

Details: Continues the same CK session as Test 9b. Runs a "Check NavMesh" on each of the 3 cells (no errors), then runs a "find Cover" on each cell (no errors), then finalizes each cell (no errors), then save with navBar closed

In-game: Same as Test 9b, except - 1 of the Northern actors was completely missing.

Secondary in-game: Same as the first try but this time I found where the missing actor went... it's still in the same cell, and still on Vanilla (not custom) navMesh, but this one was on the other side of the cell (behind the stable). I don't know if I just didn't notice in previous tries with missing actors... I'll have to go back and try again.

later, separate test: verified that actors spawn at the NEAREST Vanilla navMesh after Player returns from fast-travel.

The Rise & Fall of Family-NavMesh Bug: Volume Four - The Epilogue
- This is a summary of a bunch of related information, my conclusions and ideas, as well as a record of Vanilla errors that I ALWAYS get in the CK.

Spoiler

VANILLA ERRORS WHEN LOADING THE CK (including those specific to the Tamriel-Riften area):
I opened the CK, loaded only skyrim.esm. It ALWAYS shows the Vanilla error -
[[MASTERFILE: NavmeshInfo 00028e37 has no parent space, ignoring]]
I always click "yes to all" for that (there are several other errors which ALWAYS happen too).
*** Errors that happen BEFORE this one are ALWAYS caused by the mod being loaded.
*** Errors that happen AFTER you press "yes to all" are also ALWAYS caused by the mod being loaded (not Vanilla).

After it finishes loading, I select Tamriel worldSpace, and load RiftenPlankside01 cell. It shows the Vanilla error [[MODELS: Could not queue model Marker_Horse.nif]] - clicking only "yes" it eventually comes up with the Vanilla error [[MODELS: Bone 'HarnessLeftBone' not found for part 'Harness.nif', Requested by 'Horse' model 'RiftenCarriageHorse (0009B7BA) ->Horse (00072A08)'.]] It then shows the exact same Vanilla error, only for "HarnessRightBone" instead of left.

So there are three Vanilla errors, all relating to the stable's horse, when (what I call) 'Tamriel-Riften' is loaded. These three Tamriel-Riften errors ALWAYS occur when loading this area... but they don't cause game-changing bugginess. The horse marker error is the same ANYWHERE in Skyrim, and has to do with the NIF the marker uses, or so I believe.

VANILLA BUG RELATING TO NEW/CUSTOM ACTORS:
If you "edit" an existing actor, with the intent of making it a custom 'clone', you must change the ID name to something unique FIRST, then click OK/save. THEN you reopen the new actor and alter the rest of the data.

If you try to remove the scripts, flags, etc before having 'saved' a new actor, it doesn't really remove them... you HAVE to ok/save the actor, then reopen it, and THEN remove the scripts & essen/unique flags, etc. I found this bug back during my mannequin research.

WANDERING MANNEQUIN BUG/SYNDROME:
A non-persistent actor (no quests/etc) who isn't tethered by AI/script/etc to a marker (and also forcibly returned to said marker each onCellAttach) will 'wander'. 'Wandering' is when actors spawn in places other than where you want them to, upon fast-trav-return... or enough cell changes.

This 'bug' is NOT unique to mannequins, as the now-a-misnomer suggests... it was only the first manifestation of it (as far as MY research was concerned), and was named to describe what was occurring. It does, in fact, affect ALL actors... if improperly modded; and potentially those whose AI packages are broken somehow.

It's 'fixed' (worked-around) by assigning the actors to markers through scripting, AI, whatever; OR by having them sent to a marker every onCellAttach (which is the actual mannequin fix). The ACTUAL BUG is that an actor without 'proper' AI/markers will wander AT ALL; as opposed to just staying in the spot they are placed on using the CK (as I think they did in Oblivion).

I now just refer to it as "Wandering Bug/Syndrome"... no more "mannequin" because it affects more than just them; and "syndrome" because it describes their preventable behavior, as opposed to the actual mechanism and underlying cause.

FAMILY-NAVMESH BUG (proper):
If I am correct, this is a CK PROBLEM - PROBABLY NOT A GAME ENGINE PROBLEM... and it is what seems to be SEVERAL bugs, all relating to navMesh somehow and are discussed later on. In other words... whatever they did in the game-engine to correct it didn't work BEEEECAAAUUUSSSE the engine wasn't ultimately to blame. Now that the game-engine is semi-rolled back (who knows what was axed and what was kept), people are still having variants of the original v1.4 navMesh bug. It IS possible that the game-engine is to blame, for reasons explained in another section.

I am now officially endorsing everyone's label for it!! I'm officially admitting NavMesh Bug is real (that's right - it's capitalized now), BUT it seems to be caused by TWO OR MORE THINGS. Also, if I am correct - I know of FIXES for some of the causes, BESIDES the ESM stuff... I'm talking purely ESPs here. These 'fixes' are simply changing the EXACT method of how one makes their mod (specifically regarding navMesh). It doesn't require you to change your mod, just the precise order in which you create it. It also doesn't work in some or most instances; but may help a few.

I am willing to conceed that mostly noone is doing anything wrong, in fact - it's the way I sometimes do mine. There will be some who are simply making mistakes which cause errors and bugs, but those are different and aren't the scope of these tests. I try to minimize strange happenings or lost data through frequent saves and only changing small areas per session... then restart the CK to cleanse the memory, reset everything & what-not (I only have 4gig). I learned my lesson with Ye Olde CS; and it seems the 'garbage collection' routines of newCK are still buggy (among other phantom crash bugs, etc).

I believe THIS may be the prime reason why some people's mods work, while others' don't... and why it's seemingly tied to the SIZE of the navMesh. If you edit multiple cells' navMesh, you increase the odds of triggering NavMesh Bug - depending on HOW you edit them, which cells are finalized when, and how/when you save your ESP. This ULTIMATELY seems to be triggered only in certain cells... and there's more than one troublesome cell. Someone editing only one cell's navMesh reduces their chances IMMENSELY... here's why.....

CAUSE 1 - Certain cells are anathema.
My Tower mod places doors throughout Tamriel... the only location I couldn't get to work was Ivarstead. I simply placed a door and a couple ingredients and flora, then finalized the navMesh (just like a dozen other towns). No errors, but when saving the ESP - Ivarstead's navMeshes BLEW UP... as in tons of little islands where before there weren't.

I'd have to go back and check which cell it actually is (for further testing that specific area). Since that happened (but way before these Riften Experiments), I have gone back and tried again... and this time it worked uneventfully - and is now working in-game (though NOT in the currently available/posted version of the mod). This implies a session-related bug; which I have yet to try and replicate... I was just happy it worked the second time I tried.

This is echoed in the Riften Experiments. The Wilderness Cell 42,-24 (the 'center' cell, between the North and South gate cells) seems to be the PRIMARY SUBJECT causing drama in Riften (at least ONE of em), though I only changed/tested those three cells.

CAUSE 1 FIX - unknown... but it MIGHT be able to be fixed in some cases, I just don't know exactly what I did that semi-fixed it yet... because I don't know what specifically CAUSES it yet; just that certain cells cannot be altered as normals cells usually are (even so much as re-finalizing them WITHOUT any changes or additions), though some may not be changeable AT ALL.

CAUSE 2 - Specific order an "Anathema Cell's" navMeshes are finalized in.
As shown in these Riften Experiments, when finalizing certain cells first (before others which are adjacent), certain errors can sometimes be replicated... which cause in-game bugs.

CAUSE 2 FIX: These errors don't exist when using a different finalize order (ie: save the troublesome one for last).

CAUSE 3 - Saving the ESP while the navMesh toolbar is either still open or closed.
Also shown in the Experiments, it DOES matter.. though seemingly only in troublesome cells. It seems that if leaving the navBar open while saving the ESP, errors are likwly to occur.

CAUSE 3 FIX: Save the ESP with the navBar closed to minimize errors.

CAUSE 4 - Whether the ESP is saved before or after the cells' navMeshes are finalized.

CAUSE 4 FIX: Save the ESP after creating navMesh but BEFORE finalizing any of the cells, then again afterwards.

CAUSE 5 - Performing a "Check NavMesh" on an Anathema Cell which has been damaged already.

CAUSE 5 FIX - unknown... doing the check or not seemingly results in the same thing in-game, but doing the check DEFINITELY CAUSES MORE ERRORS AND BREAKS merged cell-borders of the Anathema Cell. NOT doing the check doesn't necessarily mean the errors weren't still there anyways, as the results in-game may simply be coincidental (eg: not enough to trigger full-blown bugginess).

» Wed Jun 20, 2012 6:32 pm

Here's a link to all the actual ESPs used in the above tests... if anyone gets ambitious enough to test it on their system and compare results with mine.
http://dl.dropbox.com/u/67168394/Riften%20Experiments.zip

I don't think is explained Test One's strange results anywhere. So.. here it is really quick. (this is what first caused me to suspect a single cell was causing NavMesh Bug)

I basically did the same things as in Tests Two and Three... BUT when I tried to finalize the center cell's navMesh, one cell-border wouldn't merge (solid-green lines). I tried moving the vertices closer, still didn't work. I tried finalizing the adjacent cell, to which it would be merging, but still no solid-green line. So I saved it, thinking something session-related was to blame.

A ton of errors came up during the save, involving navMesh data. Again, I documented this but that file was lost forever. Just to be thorough, I tested it in-game... and it showed the NavMesh Bug as you guys describe (most actors up on the balcony). I exited the CK and reloaded the ESP, loaded the cells again, and opened the navBar. Re-finalized the center cell, worked fine this time.. no errors. Ran a checkNav, no errors. Saved the ESP, no errors. Tested in-game... still had the NavMesh Bug.

What makes this strange is that all the tests I tried later couldn't replicate the actor-on-the-balcony thing. I tried several different ways of doing the same thing, and some caused similar errors, but NONE of them outright refused to merge cell-borders.. couldn't duplicate that either. My conclusion regarding this particular aspect of my findings is that session-related functions are ultimately to blame for corrupting an ESP's navMesh data... which may account for some instances of NavMesh Bug.

» Wed Jun 20, 2012 1:28 pm

tl;dr: There's a navmesh bug.

» Wed Jun 20, 2012 11:11 am

@sluckyd - the script i wrote is a "kill it with fire" failsafe that removes all items, deletes the duplicates, disables the mannequin, re-enables the mannequin, puts back all the items and re-equips them. also my script manages 30 armor slots instead of 10, and calls the function on all 12 of the mannequins in the home (that are loaded at once)

since this kind of reset wasnt necessary to call multiple times per play session so i changed to a wall-switch, leaving the user to fire it at their discretion. it never lagged for me, but some users were reporting a slight "freeze" at the edges of the trigger bound.

anyway this is starting to get off topic, let's talk more gossip on the Navi Shore dysfunctional family. my prediction is that daddy nav will get remarried. we'll just have to find out if the bride-to-be decides to play nice or just turns out to be an abusive alcoholic