[Lindsay Dunn]

http://www.gamesas.com/topic/1345681-navmesh-bug/page__st__180__p__20343514__hl__navmesh%20bug__fromsearch__1#entry20343514 | http://www.gamesas.com/topic/1358688-navmesh-bugs-2/ | http://www.gamesas.com/topic/1361767-navmesh-bugs-part-iii/

New thread to continue discussion NavMesh related issues, patch efficacy, work-arounds, etc...

http://www.youtube.com/watch?v=RlNBVOcuW3M

A fix for the issue of .esp-based navmeshes reloading from the masterfile (or not at all) is in the works. This is getting addressed.

[sally coker]

??????? NavMesh Bug & Poltergeist Effect: Coincidence OR Connection ???????


I'm writing this in OpenOffic.org's Writer which I know won't terminate when I'm most of the way through composing my post. Please forgive me if I come across as a little terse or even downright rude. This sort of thing is just plain frustrating. No, that's an understatement, I think infuriating would be a better description.
.
Back on topic: Poltergeist Effect. You know; place dozens of loose items and moveable statics all over the interior cell, set the Do Not Havoc Settle checkbox and link to a collision box with primitive set to L_Prop et parfait. Until some poor sorry user tries to actually use the plug-in and finds all the items bouncing around the cell as if animated by some wild poltergeist party.
.
I think we all know this problem, no? Some of us, including yours truly, have blamed it on the mannequins and their tendency to wander and their tendency to let their collision surfaces go wandering – even though they are set to ghost. It's a reasonable enough conclusion to jump to, but at the end of the day, it's only coincidence – which is not good enough to establish cause. Period.
.
Which brings me to the point of this post; another seemingly related coincidence. Anyone who knows my input on this forum knows how I like to harp on about version control – maybe not in those exact words, but I think we all get the picture. Every little change I make produces a whole new version of the plug-in and they all stand lined up in order of backup date and time. So, when the Elder Scrolls Poltergeists last stopped by to party, they left something interesting behind.
.
I can say with some certainty that I managed to trigger the problem in a cell which did not previously have the problem. The only change made was the addition of a NavMesh island totaling four vertices and two triangles. The interesting bit is that this addition increased the file size by roughly 80 kB. Then I did a number of things which I could only describe as idiotic. Perhaps it would be more meaningful to say that, for some unfathomable reason, I deviated from my precious procedures. After deleting the two NavMesh triangles that seemed to be "causing" the problem, I found that the poltergeist effect would not go away. So, instead of writing off the current version and rolling back to the last working version, I decided to ignore the little ghosties and work on other aspects of the plug-in.
.
It gets even better. The Creation Kit actually got around to fixing the problem all by itself about four versions later – which reduced file size from 473 kB to 394 kB. Well done Bethesda. There are a number of coincidences here:
.

• The problem coincided with a NavMesh alteration (but not the solution)
  
• The problem coincided with file bloat
  
• The solution coincided with the disappearance of said file bloat
  
• That interior cell has way too many mannequins (which still aren't quite right just yet)
  
• The http://www.gamesas.com/topic/1367549-navmesh-bugs-still-around/ continued to play after the problem was resolved

.
It would seem, at first blush, that the NavMesh bug is part of a separate fault. The persistence of the file-bloat coincidence may suggest that the Poltergeist Party Effect has something to do with duplicated loose items or moveable statics - but I am trying to apply logic in the absence of all the facts, which is hilariously illogical in itself. However, there may well be some hints at direction for testing - to acquire those missing facts...

[Naughty not Nice]

The question that has been in my mind for a long time is what is the source of that bug? what is the reason that the navmesh bug happens?
nobody ever wondered what is the source of the bug.

[Cheryl Rice]

I'd like to know if beth is working on this at all... new features for skyrim are nice and all but I'd love for skyrim to work properly first... I know they claim its in the works but they have fallen silent on it for the most part.

[Emma Louise Adams]

That's the last we heard on it. They're working on a fix. You know as well as the rest of us that typically they don't discuss what's going on behind the scenes. No, the beta group hasn't heard anything else on it either.

[Chrissie Pillinger]

It's a complex problem. There may even be more to it than just programming code. This kind of thing takes time. First they'll come out with something that terminates when the required criteria are not met (done - I think) then, the next step is to build a multi-tier error-management algorithm that resets progressively higher classes of variables in the hierarchy until all variable ranges fall within the specified limits whenever the error response is executed. At this stage, the average user won't be able to see the bug - but it still hasn't been fixed. It just means that variables filled with values outside the specified range no longer terminate the program. On the scale of the engine involved, I'd say something like this would take at least 2-3 months. The next stage is to piggy-back a reporting program off error management and get statistically significant quantities of data identifying which algorithms are malfunctioning and in what context. There goes another month for coding and a month for for data acquisition. Once the data is in, maybe a week to anolyze and almost two months to fix all the problem areas identified. That takes us out to another 6-7 months, minimum (from the 1.5.26.0.5 release), before we are likely to see a complete solution to a complex software problem like this, and that is assuming that the very obvious implications of co-operative bugs do not apply in this case.
.
This might sound like a lot of effort for very little reward, but remember that this football team of bugs has been reported in other Bethesda games sharing the graphics engine, and so fixing this will ensure that when Dishonored, Fallout 5 and TES VI come out, they won't be afflicted either. In other words, fixing this bug contributes heavily to everything Bethesda is doing in first-person RPGs.
.
Of course, I could be wrong about this bug and my projected time-frame for fixing it - and it wouldn't be the first time either. So, here's to hoping I am wrong - and the more "egregiously" wrong the better, I say!

[NAkeshIa BENNETT]

found a new bug:


FYI for those of you who are making custom balconies in skyrim worldspace - if you create a NEW navmesh in tamriel (form ID beginning with 01), fast traveling from that navmesh into a custom worldspace will cause your character (and all followers) to "float" above the worldspace with no way to get into the playable area (even using tcl will not work). fast travelling into the custom worldspace from the vanilla navmesh (regardless if its been edited) will work 100% fine

this affects both esm and esp btw


EDIT: the reverse "purgatory" trick works (scripting a game.fasttravel to a vanilla tamriel coc marker i.e. riverwood and then back to the coc marker in the custom worldspace). it will load 2 loadscreens, but it doesn't take that long, and it likely won't happen very often in-game. i doubt the user will notice it.

[Kelvin Diaz]

lol, my mod has 3 balconies in Tamriel worldspace (haven't linked them yet, still working on it)

I think you can put bounding box around them (the balconies) and disable the fast travel that way. I'm sure I seen that somewhere, but I don't know what type of box it used.

[Anthony Santillan]

related to the above posted new bug, even after using the "cell launder" trick, all actors inside the custom worldspace will spontaneously die (i'm assuming they are still up in the air by the time you fast travel properly, then they fall to their death on load)

[GRAEME]

while trying to fix my previously mentioned navmesh elevation bug, i accidentally stumbled upon a very interesting find.

it is possible to script a "laundry trick" that sends all actors in the cell to a vanilla xmarker sitting on an EXTERIOR tamriel navmesh (anywhere nearby will do fine, just not a parented worldspace) using moveto() and then moving them back into the cell onto a dedicated xmarker placed where you want them to stand. this launders out the navmesh bug to some degree (high percentage of success so far in my tests). the small bit of code is set into a while loop and only completes when the operation is done and all actors have successfully been called by the moveto both ways.

i placed the script onto a door in the Event OnCellAttach function call.

the reason why i chose to use OnCellAttach instead of using OnActivate on the previous door, is because i do not want the script to start running until the cell is loading. it's already been proven that the navmesh does not disappear at all, and SluckyD has a theory that cell borders "breaking" is what causes the actors AI to bunk out. but i have an alternate theory that the navmesh just takes too long to load. the actors load before the navmesh does and they either simply get lost in Oblivion or stand around doing nothing, even after the navmesh loads (since they have already been "initiated" without a navmesh under their feet).

this also explains why only some actors break and not others, or if all NPCs break, but somehow miraculously your follower can still navigate with you (since in this case the follower loaded after the navmesh)

the laundry trick sends all the actors out of the cell onto a safe zone (tamriel navmesh) and then by the time they come back, the navmesh is ready to go. my tests have proved successful with a high percentage so far.


i have another theory that esm's handle memory way differently than esp's, which is why CTD's happen so much more often on esp's than on esm's. the fact that "purgatory trick" and the "laundry trick" work on esp's and are totally unnecessary on esm's supports this theory.

i think Realm11 posted way back that he thinks the navmesh bug is memory related, and now i think he is right. these tests provide some evidence to back up the theory of memory usage vs navmesh loading.

[Ownie Zuliana]

my script (actually this one is attached to an auto-teleporter trigger box, i got confused with another script in the above post - havent slept in days):

Scriptname DCVR_AH_FallsixitScript extends ObjectReference  Import GameObjectReference Property AHHorse  AutoObjectReference Property Chicken1  AutoObjectReference Property Chicken2  AutoObjectReference Property Raefik  AutoObjectReference Property Laars  AutoObjectReference Property Nadya  AutoObjectReference Property PlayerHorseMarker  AutoObjectReference Property AHHorseMarker  AutoObjectReference Property ChickenMarker  AutoObjectReference Property RaefikMarker  AutoObjectReference Property LaarsMarker  AutoObjectReference Property NadyaMarker  AutoObjectReference Property DummyMarker  AutoObjectReference Property DummyHorseMarker  AutoEvent OnCellAttach()    GetPlayersLastRiddenHorse().MoveTo(PlayerHorseMarker)	ResetPos(AHHorse, AHHorseMarker)	ResetPos(Chicken1, ChickenMarker)	ResetPos(Chicken2, ChickenMarker)	ResetPos(Raefik, RaefikMarker)	ResetPos(Laars, LaarsMarker)	ResetPos(Nadya, NadyaMarker)EndEventEvent OnTriggerEnter(ObjectReference akActionRef)	If (akActionRef == GetPlayer())        FastTravel(DummyMarker)        GetPlayersLastRiddenHorse().MoveTo(DummyHorseMarker)	EndIfEndEventFunction ResetPos(ObjectReference akActor, ObjectReference akMarker)	If ((akActor as Actor).IsDead())		(akActor as Actor).Resurrect()	EndIf	If (akActor.IsEnabled())		Utility.Wait(0.2)		akActor.MoveTo(DummyHorseMarker)		Utility.Wait(0.2)		akActor.MoveTo(akMarker)	EndIfEndFunction

in my experiments, this script works with at least 80%-90% chance of success.

[Kelvin]

http://www.gamesas.com/user/766649-amethyst-deceiver/, thank you for the script (above). I'd really love to disagree but I think you're right about actors getting loaded before all the NavMesh is in. I can back that up with an observation of my own. I have a number of cells which are completely and totally NavMesh free; not a single vertice anywhere in the cell. When I send my avatar there, the follower does not follow. However, when the NavMesh bug is in play in a properly navmeshed cell, the follower turns up in the same odd location every time and either cannot move from there or may be able to wander a little bit in a given direction and then stop. Some of the navmesh seems to be there and, it seems, some isn't. If this is so, then here is always only one place where the navmesh shows up, although it's extent may vary - which speaks to resource availability and which can also vary. Coincidence? I think that part of the problem is that things stop loading when the resources are short. Statics which should be there are not (e.g. some parts of Blackreach I've mentioned before) and I've currently been removing statics from one of my own mods which have a tendency not to load.
.
If the navmesh continues to load, after some of the actors make their appearance and bug out, then the follower would always be able to overcome the navmesh bug once sufficient time has passed for all the navmesh to finish loading. This isn't happening when I experience the NavMesh bug. If someone can tell me how to get the console commands functioning on my system, I might be able to say something more definitive. At the present time, I can only open the console with the tilde key and type in commands. If the command is incorrect, the console faithfully reports the fact once I hit the Return/Enter key. However, when the command is entered correctly, the return key pressed and the console exited, the command is simply not put into effect - although there is no error notification. But that's another story from the kind or primate who'd rather use the Creation Kit to put in a load door to get somewhere tricky than a console command....
.
What I'd really like to know is how to instruct the game to purge resources and slow down the load process so that modified cells load properly. While I'm at it, it seems that part of the problem is that object classes which need to load sequentially may be handled simultaneously on separate processes or "threads". As we have seen from the problems to date, non-moveable and non-item statics need to load first and, until this process is complete, actors should not start loading all - for obvious reasons. Likewise, moveable statics and loose items should load last and should not even begin loading until every actor has been loaded and correctly positioned or the consequences can be disturbingly messy if, for some reason, actors are getting shuffled around the cell during positioning. Yes, this may well extend load times but that would be so much better than the kind of problems caused by incomplete loads - assuming, of course, that this is the problem (as opposed to a football team of bugs all working in concert)
...

[Floor Punch]

May have nothing to do with the resource issue but have had limited success with getting cells to load when use roombounds .. still testing but in one case with the bounds (hate the things myself) was able to get a dungeon to load fine, without either get ctd on trying to load save or when go there everything falls down and goes boom. No idea if related but the bounds do (supposedly) restrict what is loaded at any given one time. What am planning is try to put 1 bound (room and door) at start of dungeon and see what happens (one that works has bounds throughout the dang thing (got carried away I know).

Edit: Well put 1 roombound in plus portal and the mod now loads with 80+ other mods active. Without can't load a save without CTD. Now to go there and see what be what.

[bimsy]

Just had a run in with the poltergeist effect when adding a door near the windhelm market. The whole marketplace went ballistic.

But yeah I actually had a question I hoped you guys could answer.
So, if I re-finalize a vanilla navmesh after adding a door, will the re-finalize procedure inflict the navmesh bug on the modded vanilla navmesh?

[Flash]

viltuska_rebooted: Sometimes I've seen a simple re-finalize operation destroy the navMesh in a Vanilla cell that wasn't even changed or added to. I believe that's non-NavMesh Bug related though. My point is that the more you mess with navMeshes the more chances some error will occur... so minimize the amount of edits & finalizes/etc you do, and ALWAYS test you mod after doing so. This way you can revert to the previous version quickly to resolve the issue, without worrying about other changes to the mod being lost. The only way to know if something will really cause NavMesh Bug is to test for it; although we DO know certain cells ALWAYS have it..

Amethyst: that's something else... the laundry trick... heheheh. I just finished my real-time sailing script for my Gokstad mod (now available for download btw), and found a couple things about how fast Papyrus can be pushed and what affects that rate. Papyrus itself can run VERY fast... .01 or quicker in some cases. It's when there's competing scripts (which everyone knwos about), OR excessive demand on texture/shadow/AA and other non-script stuff. I explain it in that mod's comment section on the Nex; but I'm starting to believe that resource starvation is good possibility for causing a LOT of problems. But the script HESITATES if the system is taxed in ways OTHER than what shows in the fps rate; what runs at 35fps on my system does NOT run on someone's who is getting 45fps... for reasons as yet discovered. (I suspect other mods' scripts and texMem being overloaded)

This may explain why SOME people STILL have wandering mannequins while using my Fix. If they have a huge room full a millions of items and actors... then starvation may trigger it; and how many mods/people have THAT many objects in one place? I guess one way to test this theory is to create a plain area with mannequins (with the Fix running), and test it. If it works, add TONS of stuff to that area to intentionally tax the resources. If it triggers the Wandering Bug, then I believe we have a winner. I know this doesn't sound like it has anything to do with navMeshes... but system resources are universal. If one aspect is affected, others most likely are as well.

Next question would be how to prevent it (the theoretical overloading upon fast-trav-return).. rather than CORRECTING it ex post facto. I suppose we could napalm every script with a wait called during onCellAttach... but I doubt that would help. This sounds more and more like a hard-coding issue that simply cannot be entirely worked-around.. at least in my opinion.

About the cell-borders... I recorded enough evidence to convince myself that this is the case, but only in ONE direction. Going INTO a Bugged cell works (given the actor's AI is "reset" after being broken); but actors AI breaks again the instant it is told to move toward leaving it. I call this the 'Roach-Motel Syndrome' heheheh - actors go in.. but they don't come out! But the navMesh itself isn't affected.. actors can roam around normally after the broke AI is reset, which is why your Laundry Trick may work. Have you tried leaving the cell with followers (or have an actor patrol out) after doing the Laundry Trick?

By the way... you should put the lines calling for lastRiddenHorse inside an if/endif which tests for lastRidden=none. If there is no lastRiddenHorse during that game session, and there is no check, the VM returns an error. No big deal I think, but it may add up & somehow affect things. I discovered this during my sailing scripting adventure... as I call that command to allow Player to bring its horse on the ship while sailing.

[Steven Nicholson]

i can for sure confirm that over-taxation on scripts will cause papyrus to go on strike

even with preventative scripting in place, adding 20+ mannequins (in my custom cell) will undo whatever the script is trying to prevent. but when i rolled that back to 12 or less, it worked fine 100% of the time (minus the occassional off pose, but they dont wander). i guess the engine doesnt want to run OnCellAttach 20 times simultaneously, + however many other cellattach events are on other scripts when the scene loads.

not surprisingly though, when i converted to esm, even with 20+ mannequins they all behaved much nicer and stayed put most of the time. again, i believe this is because esms handle memory much differently thn esps.


i can also +1 on the taxation overload theory using the results of those old experiments we did in season 3. back when i was testing out the navmesh bugs by creating a new cell with 3 actors and simple navmesh, i was unable to get the navmesh bug to trigger (so i thought i was onto something). turns out when i tried the same approach to a new mod's cell (which by now has a metric crap ton of stuff in it) none of the tricks work, not even the laundry trick anymore (well sometimes it does, but the percentage of success has dropped below 50%). on the plus side, i think this debunks the legacy F'd in the A theory.

and yet again, unsurprisingly, flawless performance once converted to esm.

ever wonder why it takes a hell of a lot longer for a cell with custom navmesh to load in the loading screens?




i think the root problem is the esp's memory architecture, because none of these problems are an issue on an esm (except for the strange disappearing architecture thing, which i think is a different bug altogether, something related to record-conflicts)


so the question is, when using esp, how much is too much? seems like it takes only a relatively moderate amount of push to send it into Oblivion, and adding a navmesh seems to tax more than anything

[Tiff Clark]

What do you guy's recommend as the best way to convert to esm?

I already tried changing the .esp to .esm in the file name, load up in the ck then click save. This ended up with half my mod being deleted (thank god I made a backup).

I suspect that an esm can only contain certain data because the main things I noticed that did not survive the conversion process was anything to do with my quests. Am I correct in this presumption?

- Hypno

[Gavin Roberts]

esm cannot contain location data for a vanilla cell

the same thing happened to me when i changed one of tamriel's uninhabited cells to my custom location. leave that stuff for the esp (it works fine in the esp). general rule of thumb, if anything in the esm even touches or looks at vanilla data with even the slightest twitch of an eye, it will cause problems. just make sure everything in the esm is 100% non-vanilla


i think the reason for this is because there is no way to override the vanilla data via ONAM (without further hackage)


alternatively, if you cant avoid this issue, you can convert the esp to esm via tessnip although it will not compress the file size

[Cameron Wood]

Cheers for the quick reply Amethyst.

If it won't cause too many future issues, then I might convert using tessnip. I am not too bothered about file size, the way I see it, had the ck just worked then I would have just uploaded the esp as is anyhow

- Hypno

[Ernesto Salinas]

While script-stress probably affects various things, I'd like to reiterate that certain cells will still be plagued with NavMesh Bug no matter what. My Riften & Whiterun Experiments were done with NO detail added... just some navMesh and some actors. Those cell-border breakages are still seemingly irreparable.. no matter what detail settings, number of objects in the scene, or how many scripts are running.

So hopefully, we can discover some kind of line which not to cross... in order to prevent stress-related bugs which simply add to our drama. My ship mod's discussion is making it sound like this 'stress-line' is around 30-35fps. This is changing ONLY graphic/detail settings... not making any changes in the script whatsoever. As to what the stress-line would be for numbers of simulaneous scripts running (millions of actors/mannequins firing onCellAttach), I have no idea... I'd be willing to bet that it depends primarily (but not entirely) on one's CPU and RAM availability.

But again, this system-stress theory only exemplifies SOME aspects of NavMesh Bug and Wandering Bug.... there ARE other things which still affect proper performance in certain situations. And why is it around 30-35fps? My best guess right now is that 30fps is the magic number for human visual perception, slower rates cause flickering/lag. The devs may have added code to the game-engine somehow to revolve around 30fps or above; since they may have assumed everyone would keep their systems at that level of refresh-rate. This doesn't sound likely... but since noone from Ma Beth ever informs us as to what's going on or what they've already established, anything goes.

[Kortniie Dumont]

I haven't posted in the Holy Navmesh Thread for yonks ... so just a bit of anecdotal on the stuff-not-always-loading theory.

I was making some dialogue and scene changes ... After a while I thought I'd better test. I always test in the same cell, a vanilla cell that I have not edited (at all). I coc to the cell and wander the PC over a short distance to a nice spot to watch my npc walk towards me (I do the same test, in the same place, every time). Except - this time - the NPC was no where to be seen ...

I was just about to quit to desktop when I thought ... hang on, I definately haven't moved the NPC from its starting point (or deleted it by mistake, or anything similar). So instead, I quit to menu and coc'd again

And there was my NPC, in exactly the same place as it had been on the other roughly 100 tests I had run.

The even more strange thing is that there is a script (on an Alias that uses the PC) that checks whether PC (alias) and NPC (alias) are in the same cell and if they are uses a GetDistance which, when small enough, triggers a Scene.

Except when the NPC did it's disappearing act - and yes, I waited long enough - the Scene did not start ... I check the log files, but found no errors indicating that Aliases were not filled, nor that scripts were attempted which failed. (And no, I do not use a 3d-Loaded event, just a normal OnUpdate). But the NPC was not there, not the model and not even an invisible ghost ... just not there.

So; stuff not getting loaded - whether because of memory issues or something else (and this is just a vanilla cell, as it happens on the outskirts of Windhelm ... so no 1,000,000 items to contend with and no other mods running) - definately occurs

(obviously I can't replicate this "feature" ... despite having redone the test around 20 times since ... the NPC happily loads every time).

*shrugs*

[JERMAINE VIDAURRI]

h4vent: you might-could test our 'overload theory' by doing your in-game testing while having raised your game's detail level higher... enough to cause visible lag (below 30fps). I use FRAPS to monitor fps without any problems, but recording video with it DESTROYS fps (by like 40 or so). If you can get the 'missing NPC' to replicate by doing that - we've found the cause for your particular episode (and possibly others').

What get's my briefs in a bunch is how the NPC was there after having gone back to the Title Screen (Main Menu), then reloading the same cell in the same game session. Whenever I've tried that in my testing, any statics I moved (by my sailing script, in-game) were either nowhere to be found or in the exact place I left them before I exited back to "Main Menu". I have to do a 'qqq' then restart the game to test again. I think this is due to the 3D having loaded, but Skyrim's garbage-collection never resetting it when going back to the Title Screen... obviously non-related to navMesh issues. Perhaps because your actor is moving by AI, and not brute-forced with a script like mine, yours works... I dunno. But it IS strange it only happened once.

This reminds me that I could only get the NavMesh Bug in Riften to trigger, like it does for everyone ELSE, only ONCE (using a custom test-mod, not Open Cities or anything else). Perhaps it was because of detail settings or background programs... but I could NOT get the 'party-balcony' to manifest in a custom mod outside that one instance. I experienced OTHER symptoms of NavMesh Bug though... proving to me that the cells ARE still affected somehow, just not the same way or different behavior shows for whatever reason.

I just went to video my boat mod, but FRAPS caused way too big an fps hit, and my script-timing was ruined (causing my boat to 'sink' - which seems to happen below 30-35fps). When recording was shut off, the fps shot back up to 60 (from 25-30) and the boat immediately began operating perfectly. Since FRAPS records directX video in real-time, it could be either the GPU causing the bottleneck (I don't know anything about raw video capture/programming), the CPU (as I think Skyrim only uses one core), or my sysRAM. I doubt it's the sysRAM, as Skyrim doesn't use it all and mine never gets maxed out.. though it's possible there ARE still excessive read-writes going on without it maxing.

To see if the CPU is to blame, I'll be testing my mod while rendering something big in 3DSMax... to see if non-Skyrim-related stuff may be causing some of our problems. (64bit so it uses ALL my cores at 100% unless other progs ask for 'time') I'll let ya's know if I find anything significant - if so, you KNOW the odds of this affecting OTHER aspects of the game are highly likely.

ALSO: I'd appreciate it if anyone could tell me how to get debug text/info showing vidMem usage/performance (like Oblivion did w/ setDebugText 13 or whatever it was). It'd also be nice to see what scripts are running and when too... plus the other choice info that function gave us. Even if it's only written to a log file somewhere...

[Manuela Ribeiro Pereira]

ALSO: I'd appreciate it if anyone could tell me how to get debug text/info showing vidMem usage/performance (like Oblivion did w/ setDebugText 13 or whatever it was). It'd also be nice to see what scripts are running and when too... plus the other choice info that function gave us. Even if it's only written to a log file somewhere...

Unfortunately they compiled all of those useful commands out of the code. They didn't just disable them, they actually removed the underlying code behind them.

[Janette Segura]

Is there something in the command 'Wait here' and then 'Follow me', that re-activates the navmesh ?

I was just testing the new navmesh (it still doesn't work right) for my mod and as usual, my followers get stuck when leaving. I used the commands above and then they started folloeing me again. Just wondering if there is something in the script that somehow re-activates the navmesh. I don't know s**t about scripting, so maybe one of you guys could have a look and possibly find a workaround.

[jessica Villacis]

tamb0: sounds like you found more evidence supporting my opinion that navMesh isn't damaged, but AI is broken when the cell-border merges break. One can still get actors to move within a Bugged cell (using a script to reset their AI, after it's broken during the onCellAttach). Actors may also still ENTER that cell, but they stop in their tracks when they try to leave; they do NOT walk to the cell-border first, they stop where the last patrol marker before the cell-border is.

Extending that to apply to a follower, you re-enabled/reset their AI by asking them to follow again. I assume they stop following as soon as Player leaves the cell; and they should follow into that cell if originally coming from the other side (though you can't test that if you're talking about an interiorCell which, I believe, shouldn't be afflicted at all).