I wouldn't count on Bethesda commenting at this point on a Navmesh bug. Todd Howard stated at QuakeCon that they have already moved onto the next project, no more DLC content is coming. There was a small window in which they were accepting bug reports and feedback in the spring when they were still working on the v1.5 release, and we got some of the fixes we wanted. The v1.6 patch fixed the critical Master/Plug-in bug, and we _thought_ it also fixed the pathing problem. In any respect, I think there is little chance of a bug fix at this point for FO3 Navmesh from what I have seen and heard.

Miax

My main goal of the prior post was to get many people simultaneously to make the same request so that they will take it seriously and not blow it off. I also am not saying the product should be 100% perfect, just satisfactory. Which (IMHO) it isn't. Its like saying, "here you go make your own boat, I'll supply the rotten wood and toothless saws." This problem is huge, and resides in the GECK (the GECK cannot make navmeshes that the game likes) or in Fallout3.exe(the exe can't import/add navmeshes properly). The GECK needs a new patch to emulate what other Bethesda supplied content can do or they should take it out of circulation, cause it really doesn't work at all let alone perfectly. I would argue that in its current form, the GECK is almost non-functional for its intended use which is to make pluggins or ESPs. Which really can't be done. If it were their intension that everyone make ESM files, then I would just shut up. Maybe I'm just a hard-azz, but it bugs me when people or organization blow off their accountability for stuff that they should be accountable for. I personally have wasted 40-50 hours on this myself. But a dev who wrote the code for this probably could fix it in a short time.

I hope I don't sound too tyrannical. Its just that I love working on mods and want to be able to create something usable to the general community.
I think I'm going to get a lot of flak for this....

Nah, not flak.. but I do think you are exaggerating just a bit. Yeah, navmeshes seem screwy but there are literally thousands of mods on the Nexus that work just fine, granted most of them aren't navmeshes. So in that respect the GECK works just fine. It's got a bug, it's not completely unusable.

So let's do whatever we can to see if they can look at it, but let's keep it sensible.

In so far as making utilities, it does work pretty good. But I can't imagine there are any working ESPs that use NPCs or creatures, are there? If so, why do they work and ours don't?

One thing to remember is that this is not an issue that shows up right away, it only shows up after you enter/leave the custom/pre-fab cells more than once. We also don't know if using a Master file and FO3Edit to rebuild the ONAM records will fix it or not, thats one test I think we need to run and test extensively. I will do testing myself tonight on the connection between the wasteland and my mod (starts with a metro entrance).

My impression is that we need to study this more and fully characterize the problem, and see if we in the community can fix it ourselves or if we have to work around it. I for one am not going to assume that we can "entice" Bethesda into fixing an obscure Navmesh issue in the GECK - it just isn't realistic in my view. We are much better off fully understanding the issue and seeing if we can fix it or find a work-around of some fashion. That's our best hope.

Miax

Could http://geck.gamesas.com/index.php/Navmesh_Disabling have anything to do with it? Maybe the NAVM froms are somehow not enabled as they should be. :shrug: Just a shot in the dark... If that's the case and EnableNavMesh [xx]xxxxxx would fix it, it would mean a plugin's load index would have to be predetermined before writing a script to enable those forms as their Form ID's wouldn't be fixed as they're determined by load order. If only NAVM records could have Editor ID's and enable parents. Also, has anyone tried making errant NAVM recods persistent?

Looks like they can have editor ID's as well as be persistent. I'll see if a script enabling a persistent NAVM records with ID's compiles. (they don't need editor ID's either)

FO3Edit won't save a NAVM record made persistent and they don't need to be persistent to be enabled/disable by a script referencing them by Form ID. The test script compiles using the Form ID's although I haven't checked to see how well it works and it still wouldn't work unless the form ID's were kept to their index as they're referenced by the script. If all missing NAVM records were injected into Fallout3.esm, their Form ID's would remain constant irregarless of load order.

To test, select a cell exhibiting the problem and select all NAVM records present with FO3Edit (temporary subgroup) and "Change Form ID" selecting Fallout3.ESM as the target plugin. Then write a script which uses the EnableNavMesh command once for each injected NAVM form and maybe it will make the missing info appear? If that works, anyone with new cells would want to ensure their injecting NAVM's have unique form ID's so as to not leave the possibility of another plugin claiming the same [00] form ID's.

By the way, an ESM'ified plugin can have an ONAM for an injected form. If the injection/scripted method doesn't work as an esp, it might as an ESM or the other way around.

If someone else doesn't get to this first, I'll give it a try, but that wouldn't be right away. Sounds interesting... one could toss a script on a trigger so that whenever the player enters the cell, it kicks it in. I hope it doesn't need to be done if the player sleeps/waits after arriving in the cell tho.

It would be awesome if it works as this has been plaguing anyone whose plugin(s) introduce new cells. An XMarker - Activator with a OnLoad block or trigger should ensure they're enabled even if the player sleeps in the cell or leaves then returns. An injecting NAVM record's cell info seems to remain intact while still allowing one to reference the fixed [00] form ID(s). The master NAVM record, [NAVI:00014B92], also doesn't seem to mind referencing injected NAVM's.

Wellll actually, if this does turn out to be "it", it's probably news to Bethesda, and maybe we'd see the issue get fixed in the next patch.

(still ain't checked, tho... sorry heh).

Next Patch? There's going to be another?!

That sounds like a long-shot to me, but if we do indeed find a fix, someone with contacts with the devs will have to get the suggestion slipped in - though I very highly doubt we are going to see another patch update unless they patch to fix the MZ problems.

<--- Keeping fingers crossed

Hopefully it's not too late. If so, I guess it will help the next generation of GECKers.. but with Dragon Age coming out soon, and having a complete and much more robust toolkit included at launch.. not sure if it will help me any.

Ok! I had to try it out in my troubled Pitt outdoor cell.

http://www.flickr.com/photos/sesom_07/3856461054/sizes/o/

The creatures at the right in front of the building (sorry a little small i know) were stuck when i fasttraveled away from this cell when i play it as esp. As esm all works as it should.

So i disabled in geck this little part of the navmesh were they are standing and enabled the navmesh with the activatorscript i made to simulate their respawn which i also used before.

They are moving now. But only in this small part i just activated. They ignore the greater part completly (i didnt try to disable this one for now)

I know my case is a little special because i am working in the miniworldspace cell of The Pitt. But i think it adds to the observations.

I understand what yer saying.

I've wasted a terrible amount of time fighting this problem myself.

At the same time though, what I *think* happened is this:

- They didn't know the problem was there at game release
- They didn't know it when the GECK came out and when they made the tutorials.
- They either still don't know why it acts this way, or, there's some reason they can't tear into it and fix it this second.

The things that you say about the public-version GECK being disfunctional are correct on a level (and also make the GECK be at odds with the information in the tutorials).

I think that what happened was, despite their best intentions, this problem snuck up behind them and smacked them in the back of the head. I can't resent them for that, or feel like I should delete the GECK, or cancel my mod's development. What they did give us was too nice for me to treat them and their game like that.

They have fixed MANY other things in their patches, improved many things. They wouldn't have skipped this just to torment us.

All things considered, I wish they would talk to us more than they do. Other than that, well, it is what it is.

I highly doubt it has anything to do with enabling/disabling of the navmesh. Why would the navmesh get disabled because the cell was loaded, unloaded, loaded again, and an NPC was using the Navmesh during the unloaded portion, and they happen to change packages after the final load? (That is currently decided upon cause, right?). That... that wouldn't make sense to me at all... but that's just me...

Actually, when I put it that way... I wonder if the NPCs aren't getting stuck in low level processing, and .esp's get handled differently. [/random theory]

pkleiss, wow... you're over-exaggerating. Though its understandable, as you've obviously been testing it tell your hair falls out, but its also unfounded. They gave us the GECK for free, and no one forces us to use it but our own addicted selves. Just sayin, not flak'n.

*keeps fingers crossed* Maybe there'll be a 1.8 for GOTY which adds a fix for this most perplexing issue. It might have been part of why followers wern't allowed to come with to the new areas...

If you want, link me to the latest version of a plugin with a cell exhibiting the NAVM issue and I'll set it up as described, then rebuild NAVI so we can see if it works.We can hope. 1.8 for great justice!

[prefereably with grenade/missile targeting in VATS so I can drop Fake Patch] >_>

From all I've seen, Zeta's problems are in the ESM and not the .exe, so if they do anything for Zeta I'd bet it will be an updated Download much like there was for The Pitt.
When RC's drawbridge extends naturally, followers use the enabled NAVM. If using a mod which retracts that drawbridge, followers won't follow after it re-extends ...I seem to recall reading. That NAVM's can be disabled or enabled just makes me wonder as followers behaving as though there is no NAVM just might indicate there really isn't. Why they'd not be enabled by default would still be a mystery, but It's worth a try, right?

Wellz, they fixed an issue that affected Broken Steel in one of the patches released after Broken Steel's .exe patch.

They've been fixing other things as time goes on. I know this because I'm some sort of weird follower-watcher, or something. I pay attention to them and I notice when they behave differently because of their patch changes. For example, I feel sure that they stim themselves more aggressively now, and they move better when they fight (running backwards meaningfully), and other things.

As a result of one of their patches, I even had to change my weapon selection scripts. I had to make it interfere with the followers slightly less (I no longer needed to dump 'resetai' on them to get what I needed), plus, I had to speed up the internal timing of one part of it. The overall performance is higher now than before.

So sure, I don't feel like it's a stretch that another patch could be forthcoming. They seem to like fixing and improving things and not telling people that they've done it. Well, I NOTICED. YOU CAN'T HIDE YOUR IMPROVEMENTS FROM ME MUAAAAHAHAAHAHH!

I am pretty sure its a combination how NPCs or creatures are evulating the navmesh in their AI. The dogs in the upper right corner of my cell behave differntly in esp and esm (tested without any navmesh enabling).

In esp form they are runing away from the player and attack sometimes later. In esm they attack immiedetly. Their package is a DefaultSandboxEditorLocation512. Only another observation to add.

Okay I'm going to give this a try now, I have a pretty good test environment here in that I can always, inmistakeably reproduce the symptoms on demand.

Well, here is what I did, and what I found.

I did up my navmesh as explained, and then, added 2 commands on my followers. One to disable that navmesh, and one to enable it (result scripts FTW).

With Fawkes in my test cell, BEFORE I caused the pathfinding failure by leaving the area and returning, I tested the commands out. He would indeed stand there and be unable to path to me after I issued the disable-navmesh command, and then he was able to follow again after I did the enable. I did not need to resetai on him or anything, he was automatically seeing and non-seeing the navmesh each time I issued the command.

Then, I left the cell for my little run-around-the-world. When I returned, I found that the commands did nothing for Fawkes' behavior, he remained stuck and unable to follow. resetai did not help him, for what it would have been worth.

Have you tried with the ESM flag toggled? Maybe if the injecting NAVM's have ONAM's or lack thereof it would make a difference. It would seem they're getting disabled somehow by an unseen hand. o_0 I've experienced a few weird things with references enabled states with 1.5+ .exe's. Try toggling their "initially disabled" flags maybe? Was there a NAVI record in the plugin when is was saved in the GECK? For Oblivion, one could always ~tpg to see the pathgrid from within the game while ~tnm (FO3's equivalent) gives me a CTD every time. Maybe ~tam (ToggleActorMover). Crap! >_<

FO3edit is now injecting those ONAM records for you when you toggle the .esm flag, and it should be pulling them out when you un-toggle it. So, I can't test those 2 things independently.

FO3edit's actions on the file when I toggle the .esm flag DO of course fix it all.



There should have been no ONAM record for it when I tested. I don't know how to do a tremendous amount with the navmesh records, not quite sure what you're suggesting. I could send you the .esp if you wanted to look but, otherwise not sure...

It does act like the navmesh is simply being deleted from the game's mind.

It's worth a try. I've a few variations which I can try out in mind. It seems like 1.7 fixes everything else that's placed in the gameworld by an .esp but the NAVM's. Also, FO3Edit won't uninject the injecting records if you toggle the ESM flag and, even though the GECK will complain, it seems to handle injected records just fine. Too bad the ~tnm console command crashes the game or we could actually see if the NAVM's are there or not. Does ~tnm work for anyone?

http://www.finhosting.fi/~fallout/downloads/development/Phalanx-MainFollowerModuleNAVMESHCOMMANDS.esp

cell name is aaphalanxbunkerinterior. All followers will have that navmesh command sitting on top level. Phalanx will throw a few prompts in your face soon after you load this in-game, you can just get past them and save your game to make that stuff stop. navmesh's ID is 00666666.

I'll test in as many ways as I can think of and report back with my findings. Wish me luck!

Edit: Results look quite promising. I've got Jericho following me in and out of the Vault, through the cave, into the wasteland, back into the cave, then back into the Vault (aaphalanxbunkerinterior). Just went all over back and forth about 5 times with 1.7 and your plugin as an .esp.

I'll link to the result in a separate post momentarily after I clear out some records I added and didn't end up using.