When Fallout was at version 1.4, some of us modders were struggling to make navmesh really act right in our custom .esp-based interior cells. It seemed that it would work for a while, and then after leaving the cell and returning, mobs would start acting like they saw no navmesh in the cell. It required a game restart to get mobs in the cell to start pathing in there again.

It was around the release of patch version 1.5 that we realized that these problems would magically disappear if we converted our .esp files into .esms.

When patch 1.6 came out, I'd personally thought that the problem was resolved with it. I know now that I had not tested completely enough and I was mistaken in that.

So recently (its patch 1.7 right now), a post got my attention here on the board, and I went in and tested thoroughly, and discovered the problem to still exist.

So now I have done a bunch more testing. I first tested the 1.7 executable and made a video showing how I could get the problem to happen reliably with my cell.

Then I uninstalled Fallout 3, removed all mods, and reinstalled it from my disk (EU english version). Then, for testing, the only mod I loaded was my mod which contained the custom interior cell (aaphalanxbunkerinterior) and it also contains follower changes (its Phalanx-MainFollowerModule.esp).

I ran my test within the completely unpatched game. The symptoms were identical.
Patched it to version 1.4. The symptoms were identical.
Patched it to version 1.5. The symptoms were identical.
Patched it to version 1.6. The symptoms were identical.

After finishing patching back up to version 1.7, I converted my .esp into an .esm using FO3edit. The symptoms were gone.

A video showing my demonstration of the problem (using the 1.7 .exe) is here: http://www.youtube.com/watch?v=0d2rt1_qUMY . It's 7.5 minutes long. the video was recorded with more mods loaded than were in my tests with 1.0, 1.4, 1.5, and 1.6 but it doesn't matter, the symptoms did not change based upon whether or not I had my regular set of mods loaded.

I remain hopeful that this problem may be fixed in the future, and we can have .esp files that work right with navmesh in new interior cells.

If this problem still exists when I'm ready to include a new interior area in my mod, my personal plan of action is to cause all new interior cells for my mod to exist as an.esm file with the correct .esm file extension (not a stealth .esm). Then, my main .esp file will carry that .esm as a master. It may be necessary to script the doors in and out of such a cell to enable followers to enter and exit reliably, if my recent experience with Broken Steel's citadel door carries over into this situation.

I'll link the video here when it's done at youtube, and I'll throw a bug report into their software forum after that I guess :/

I noticed this exact problem in a mod I made. I used the trick of making a master without doors and a plugin with doors, which solves the follower entering a custom cell issue. But in my .esp I went back and editted the navmesh that exists in the master and the NPCs exhibit this behavior when they never did before.

Thank you for taking the time to test this at depth Tarrant, I doubt we would have ever realized it otherwise.
I use Phalanx as a staple in my mod list, I don't think there is any better follow-enhancement mod in existence!

My assumption was that with MasterUpdate (essentially turning all the plug-ins into masters) would resolve this altogether now. I really don't anticipate a patch for that at this point - we will be fortunate if we get a patch for the MZ bugs (which I think would be the focus of any last patch IF there is to be a last patch). Given they are still working-up the content for the PS3, I am hopeful that after the PS3 DLC's are done, we'll get that final patch.

If not, is there really any work-around for this sort of bug? I know you solved the follower-enting-a-new-cell issue, but pathing seems like a much more "in the binary" sort of operation.

Miax

I think the problem is not limited to interior cells! I navmeshed a unused area of the Pitt and run in the same problems. As esp it works the first time (no strange spawning or lockups). As soon as i fasttravel away and come back the creatures are stuck.

Is it converted to an esm with FO3Masterupdate no problems at all. I tested it with Patch 1.7.

Just make your new-interior-area cells and their navmeshes live in an .esm, I guess. Thats how I anticipate doing Phalanx' interiors at this point.

A new .esm will be distributed in the zip called Phalanx-Interiors.esm or something, and mainfollowermodule will have that file as one of its masters. That way, I can script within mainfollowermodule and those scripts will be able to reference REFs within the interior cell.

The doors may be interesting, but yeah.

I'm looking at ThePitt.esm now. It's got both interior and exterior cells. Are you sure that the cell you edited is not an interior cell? If you're not sure, tell me the name of the cell and I can check?

Its DLC01Pittworld 1,-2 / 1,-1 / 2,-2 / 2,-1 / 0, -1 / -1, -1 I am pretty sure its exterior. Here a http://www.flickr.com/photos/sesom_07/3856461054/sizes/o/ of the navmesh in Geck. The creatures (dogs) at the right side before the building are the troublemaker. As long they stay in the great navmesh in the miiddle or are at the street no problems. As soon they are in the position in front of the door (as shown), they run only when it is an esm after fasttravel.

Looking at the image, I understand what you're describing.

That cell is in one of those mini worldspaces. hmmmm. Not sure what to make of it.

That video is up, now. 7.5 minutes of... well.. doing stuff in Fallout 3 I guess. http://www.youtube.com/watch?v=0d2rt1_qUMY

You did a hell of a testing, Tarrant!

It's people like you who get things solved.

So, the reccomended couse of action is to create the calls and navmeshes in .esm format, and then adding the NPC and the doors as a .esp? What would be the problem if everything was a .esm? Followers?

By the way, the problem has a randomness component, hasn't it? Because I did another mod that added two new interior cells with NPCs, and they seemed to work fine. I had no reports about them...

aw heh =p I don't feel like I solved anything tho! I just needed to be sure I was really seeing what was there. Shoes taste crappy.

I don't know for sure what the positively best thing to do is. I have actually been wondering if all that HAS to go into the .esm is the navmesh. I am just not sure. I haven't gotten to try many different things, I wasn't even working on level design at the moment.

For the time being, my own plan is to put the level into an .esm. Walls, doors, statics, navmesh, cover ,etc. Like, build the whole level in one place, the .esm. At least that keeps it organized and in one place.

When I talk about door maybe needing to be scripted, I mean the teleporting door that leads into the cell. I'm not sure if that door will pass followers correctly, as there was a weird thing I had to fix with Broken Steel lately. If the teleporting door works without such a thing, then great. We'll have to see.



edit: anything that the user needs to be able to move around in his load order must live in an .esp. Anything that another mod is capable of changing. Basically, a mod that makes changes to things that are defined within fallout3.esm belong in an .esp, is how I see it.

Yes you want your navmesh in the .esm. Your doors need to be in the .esp.

Custom NPCs should be an .esm as well to prevent the white body/tan head problem.

Ok. I'll take this course of action for my mothership Zeta mod: I'll create the "structure" (Cells & navmeshes only, doorless) in a .esm, and then I'll add the doors, NPC, scripts, clutter, activators, ?and furniture? and quests in a separate Esp, except for the NPC that use custom things.

Tarrant, you didn't solve it, but you confirmed it. Without confirming it first, it's hard to solve anything!

You know, I think I'll have to try this exactly the way you say.

Moving my two custom human followers into the .esm will take some planning to do right, as the .esm versions won't be savegame compatible.

I wonder how weird this splitting-out will go, considering that their REFs are already defined and are being referenced all over the place in conditions and scripts within the .esp.

Packages that are defined as part of the custom NPC's object definition would need to live in the .esm as well, I believe.

This is very interesting advice, thank you!

Have you tested this extensively? I'm going to have to try it with mine as well.

This could be a huge bit of knowledge for the community...

Miax

I struggled with a mod for a week trying to figure it out. This was the solution that finally solved all the issues I was having. It may not be universal, but containing all navmesh edits in one master then placing the doors to the interior cell in an .esp allowed followers to enter and ensured custom NPCs wouldn't freak out and stop recognizing the navmesh inside after fast travelling. When I later went back and tweaked the navmesh in the plugin, my NPCs stopped recognizing it. Removing those edits and putting them in the master file (after reconverting of course) returned the NPCs back to life.

It really seems jumbled up. Changing a navmesh in a plugin breaks it, but putting doors in a master breaks them. I don't get it. :shrug:

Just one more question:

IF I follow this path and make the structure and navmeshes on a master file, and then make the plot, npc's and history on an ESP...

What will happen when I have to expand the story? I'll have to expand the master file to add more rooms and then go to the esp and add the new NPC, etc... But, if the master file is modified, will it generate conflicts with the ESP?

Hope not. Otherwise I've hit a dead end, because this project is supposed to be done in several months and updates. Not all in one go!

Nah that behaves well, in my experience.

Before you go and do the ESM & ESP modulation. Try what I posted before. My mod is still an ESP and my NPCs behave properly. The only differences between our two problems was that your OS is Vista and mine is XP and you have a DLC installed that I don't. That said, I strongly feel that if you started a brand new game - from birth - while your mod is still an ESP, you'll find that your NPCs will behave appropriately. Just use tgm (Toggle God Mode) and you should be able to get to where your NPCs are relatively quickly. If it does work, it will save you headaches down the road. If it doesn't then you will have only spent an hour or so testing it. You could even use the COC console command to get to your mod, and that wouldn't take long at all.

From the other point of view, if you add NPCs to you addon ESP down the road, you run the risk of having the same problem show up in your addon ESP. And that would svck big time as you would then need to make the addon an ESM as well.

I'm having second thoughts on SPECIFICALLY for my mod Phalanx proceeding in exactly this way because of the complexity of my 2 custom human followers. I'd have to go in and redesign some fundamental stuff to break their base definitions out of the .esp completely. And that's not to mention the terrible snafu I am envisioning when I move that REF into another file and hope that all the result scripts and packages pick up the changes...

There's another thing I think I will try that I have been shown how to do before. It's a special procedure that Eliminster showed me which builds an .esp and an .esm pair using (the awesome automated power of) FO3edit. It's not the same thing that Fo3MasterUpdate.exe does. You design as an .esp, and then when release time comes, you do this process to it. When you're done the process, your release consists of an .esm and an .esp. The .esm contains all of your brand-new content (such as new followers and your new navmeshes and new cells), and the .esp contains anything that's an override into your master, plus, I think it might also contain copies of the new stuff. Then, the .esp refers to the .esm as one of its masters.

It's a little CREEPY and if someone CAN just build a regular .esm and regular .esp and it works smoothly, maybe they should be doing just that.

I think I need to get with Elminster again and get him to walk me through that procedure ONE MORE TIME, this time taking notes. It's not for the faint-of-heart, ehhh...

And when your done, post your notes so others (like me) can use the info too.

It would be a great help . Thanks in advance.

Section 6.6 in the Tome is entitled, "Splitting a Plug-in into a Plug-in/Master Pair"

If that's not what you need or is wrong, please let me know.

Miax

That sounds like it. I hadn't had a chance to search the tome thingie yet. I'm staring at the icon on my desktop atm tho. I guess I will double click it.

heh.

I looked through it, and I thought that what Elminister and I had done was more involved than that.

I will see if doing it this way resolves all of the issues that I need fixed, tho. Those issues being the white bodies on my NPCs and navmesh-door-hell-mess-whatever.

Nods, well what you and Elminster were discussing back then was the process which is now called MasterUpdate - but you and he were doing it the manual way.

Unless there was another session your referring to?

Every function of FO3Edit should be in that manual with the exception of, "Apply Scripts Into", which I don't have good-enough examples to build a process around yet. I am also going to revise the chapter on conflict resolution per some detailed feedback from Martigen and Elminster that will provide a better description of what that process should entail. Other than that, the split process is in there and works - did it for my mod.

Let me know!

Miax