I'm pretty sure you can just place NPCs with an .esm to avoid the white body problem but you can 'manipulate' them in the .esp.. such as adding AI packages. Not 100% sure, but I did have some guards that I added a new patrol route in an .esp and it worked fine.

You're right...

I should exhaust all possibilities before I take a drastic resolution. It's just that the mod has been paralyzed for so long that I'm dying to contiue it x_X

I'm going to restart a game right now and see what happens.

Done the testing and I confirm:

In a new game with mods active: The Problem Persists.

In a new game with all mods disabled except for the official DLC (and the mod in question): The Problem Persists.

Dunno if it is useful for anyone else.

So, I can now proceed with the ESM/ESP splitting, I guess, but at least I don't have the doubts now.

Very well then

I just remebered that I also did the FO3Edit Masterupdate and then Masterrestore as well, perhaps that fixed it for me all along and I just thought it was starting a new game.
<--- Bows his head in shame that his advice did not work when he was so (over) confident that it would.

Thank you for testing this!

The ESM/ESP splitting is a new twist for mod compatebility, but I'm grateful that you and Tarrant tested and confirmed this.

The splitting process for an ESM/ESP pair is not complicated anymore, as mentioned above FO3Edit has a clear process for this in Section 6.6 of the manual.

It's just going to be somewhat inconvenient putting stuff in ESMs, but as something we only really need to do in final testing and release, we can still put stuff into the ESP during construction of the mods and only split them out during final testing/pre-release. Tarrant is already at that stage, where I'll just leave all of mine in the ESP until much later.

Miax

Something that svcks is that I know something DID change with that patch to 1.6. When I had tested back then and thought it was fixed, it really was acting fixed for the group of interior cells I was working with. I was using a test which had always brought the problem out before, and it had stopped showing the symtpoms at the 1.6 patch. The trouble was that I didn't do the correct test with my large cell. I did CHECK my large cell but I didn't do the necessary visitation to some wasteland cells after visiting it, and then returning to it.

I don't really understand what's going on in its head . As far as I know, maybe there's a deliberate limitation in the game that isn't allowing more than a certain amount of .esp-generated navmesh to live. But then, when you move to .esm , nothing like that happens. I don't know! I wish someone who DID know would let us know so like... we wouldn't be in a state of half-understanding what's happening.

This description fits perfectly with the problem in my Pitt exterior extension.

Hmmm... I've finished designing another level and now would be the time to "jump" to the ESP file and place the doors and NPC, BUT something occured to me.

If we place the doors in a separate ESP from the navmesh... How do we finalize the cell navmeshes so it can create the door portals (green triangles)?

I'm wondering the same thing too. And for that matter, if you have things in the esm that the npcs in the esp need to use, such as a chair, how does the npc even read that reference if it's in a completely separate file?

Ugh, thats a Very good question - and problem with putting the Navmesh and Doors in different files.

I wonder if we really need to put the doors in the ESP... someone mentioned it was necessary, but I can't recall why at the moment.

As mentioned in the other thread... what I personally did was finalize again in the .esp where my doors are. Worked for me, YMMV.

well, I deleted my doors, converted the esp to esm with fo3edit, loaded it as a master in geck (got some errors on load-up, because I have scripts that reference the deleted doors), readded the doors, tried to save a new esp.. and geck crashed... juuust great.

I thought you said that editing
Guess that solves it then!

Testing time!

Removed as this post was bogus.

I'm already using it... with no luck X_x

Do you use Vista? I am totally numb with confusion as to why this would manifest itself on one system and not another. If I don't use UFO3P, none of my custom NPC do a damn thing. With it, I cannot get the problem to manifest. Since you use UFO3P, can you get a custom follower to go in and out of Megaton? If you can, I'll be more than numb, sliding into catatonic. Also, I load UFO3P right after fallout.esm, my mod coming third in the load order in FOMM. I only load those three.

... and for the record, I'm not using UF3P, and I don't seem to be getting the errors (except in excessively large cells with equally large navmeshes).

[Edit]
... and now a thought occurs to me. pkleiss, did you ever try getting the error, and then saving, exiting the game, and restarting it with the same mods loaded? Maybe a simple reload pops the NPCs in the head...

I'll try that now... testing...done

You were right PoHa, just the mere fact of saving, exiting and resarting the game made the NPCs work right - all without UFO3P used. But that still doesn't explain why with it, I can't get the error to occur.

Hmmm. I think I'll try to get the error again with UFO3P installed -> better testing = better solutions right?

Well, F*** Me - I got the error using UFO3P. Son of a ...

So now I'm in the same boat as everyone else. Man I must have tried that 10 times in the past, but this time it occured. Guess I'll remove my post about UFO3P then and make my GD mod an esm.

BTW- the cell I use is large with lots of navmesh triangles. I guess the question now is how many triangles is too many.

EDIT: OK so I took my original cell with its 1445 navmesh triangle and optimized it -> 1197 triangle, tested, got the error.
Then I began removing navmesh triangles: 940 -> error, 487-> error, 280 -> error.
I'm not willing to test below 280 triangles because it isn't worth it to have that as a limitation on navmesh triangles. In the end I didn't even need to use fast travel to get the bug. Just leaving my custom cell area for the vanilla area and returning caused the error.
So the current solutions (if you can call them that) are to either save, exit, reload an esp or make your mod an esm.

PoHa - How few triangles do you have that you don't get this error. Have you tried leaving a custom cell for any vanilla area and returning? I am trying to help out but its seems that I just keep getting different manifestations than everyone else. I can't believe I couldn't reproduce this before cause now I can reproduce it in the simplest of ways. Everytime tonight (and I have tested 12 different ways) all I have to do is go to a vanilla area, return, and the NPCs are fubar. Going to different cells within my mod doesn't seem to affect it though. :shrug:

Yea, I've mostly been testing custom to vanilla transitions, but I think you've struck on something. I have a "gate house" that transitions from the Wasteland to my custom worldspace, and all the other interiors (minus 1, but its inconsequential) are linked from this worldspace. The transition interior is a mere 55 triangles.

These are the exact same symptoms I'm having. Vanilla to custom cell = breakage, but not custom cell to custom cell. I've also noticed that it only takes one NPC breaking to cause a cascade of breaks. My follower broke in the cell at night (no npcs around), I waited until the morning, and all the npcs popped out of their doors just standing there. An NPC who breaks also won't trigger the others to break until their next package change. If they break at 7:30 during dinner, the other npcs will continue eating and won't break until the time they switch to their sleep package.

This sounds funny, but I am glad to hear it! Only for the sake of duplicating the problems I've found, not that your cell is skwewy.

Honestly I think we could use some feedback from Beth on the issue, see if it's a GECK problem, a FO3 problem, or just user error. Not that I expect it at this point, seems like FO3 is pretty much done for.

I don't think this has anything to do with the number of triangles. JoystickMonkey (from Bethesda) stated in the past that 2,000 is the max - and that the more you have, the higher the cost on performance (of the computer needed to figure out where to path NPCs). You can get up to 2,000 safely, some Beth cells get very close to that. The GECK will error-out over 2k.

Does the problem go away if converting the plug-in to a master?

Miax

I have been thinking the same thing. I tried earlier to get Bethesda to look into a bug (it was a small one though) and even though it was a systemic error, the response I got was that they didn't support user mods, even though the bug was everywhere including their own content. It made me think that the person reading my note either didn't read it carefully, or didn't care. If we could, as a community, request that they look into this, that would be the first step. Hearing a problem from one person isn't taken as seriously as when a whole community has the same issue. And this issue affect everyone who makes an esp that contains either a creature or NPC. Aside from utilities, virtually every mod will have a creature or NPC, so this problem is systemic with the entire community. Basically, no modding can be properly accomplished with the current state of affairs. I am no lawyer, but I do believe that by distributing the GECK and maintaining this website goes to show that Bethesda has a defacto contract with the community to provide a satisfactory product, which I, for one, do not think it is.

Anyway, lets organize a community request that they look into the matter. Does anyone else agree? Or am I spitting into the wind?

I'm not sure how you would go about it any more than already has been done. I'm not against it or anything, but I'm not going to take the position that they are legally obligated to make some free optional toolkit 100% perfect otherwise I'll sue! That's just silly.

But yeah, I'd like it to work and if they can look at it and see what the problem is that would be great. I believe we have enough accounts to suggest it's on the software end and not user error.