I've had an offer from somebody to make compatibility patches for Powered Power Armor, the condition being that I turn PPA into an .esm because he's not sure how to use an .esp as a master. I've looked into it, and I can pretty easily edit the header files of my existing compatibility patches to point to the new file, the problem is that everything related to my mod will reset for all of my users when they update to the new files - they'll lose all of their upgrades, and all NPC changes will be reset. Still, that's not the end of the world, but is it really worth doing? What advantages do .esms offer in terms of stability, if any? I'm sure I could explain how to treat an .esp as a master, so if I can do that and there are no advantages to adding most of my mod through an .esm, I'd rather go that route. I sort of remember an article about this, and can't remember if any of the problems associated with .esps apply to my mod (and I can't find the article).

This depends on just what your mod is doing. some characteristics:

An .esm's position in the load order isn't as easily adjusted as an .esps., unless the users are using FO3MasterUpdate. If you are editing the existing power armor objects instead of replacing them outright, it could mean that other mods in someone's load order would interfere with the operation of your mod and they'd have trouble stopping it - unless you went with an esm/esp pair. I don't see how an esm/esp pair would make those compatibility patches any easier.

For me personally, the main thing that using an .esm fixes is that navmesh in .esps doesn't work right if the navmesh is a certain shape. If you're not doing navmesh in your mod it's not as big a benefit.

A strange problem-sort-of with .esms I have seen is that, if I change an object in the world (one which lived in another .esm such as Point Lookout) I have to set it persistant ref or it doesn't look like I changed it in the world.

Its possible to make an .esp which carries another .esp as a master. I made several for my mod (Phalanx). If I recall right, what you do is, you add the master in via FO3edit, then load stuff up in the GECK and do your regular old editing, then after you save the file and close the GECK, be aware that the GECK strips the master out of your .esp. You then have to go back in using FO3edit and re-add the .esp as the master (by editing the header of the .esp), and then I think you do "sort masters". It's been a while but that is how I recall it.

I'm not sure what to suggest but that's some info about it.

I do it by flagging the master .esp with the ESM flag using FO3Edit, do the edits to the regular .esp, then take the ESM flag back out. Some edits can be done with FO3Edit which avoids the need for the ESM flag in the first place.

I've used Kristoffer's method to create the current patches that I have for PPA. Once you set the .esm flag the GECK pretty much thinks its an .esm. The reverse isn't true though - you need to both clear the .esm flag, and change the file extension to .esp, for the GECK to treat you file as an editable plugin. So I'd prefer to leave PPA as an .esp because I work on it a lot, and turning it into an .esm would mean needing to turn it back into an .esp every time I wanted to load it up in the GECK.

If I were to switch the mod to an .esm, I would split it into two files, and .esm and an .esp. Everything that was an override of something in another file would go into the .esp, and everything that was something new added by PPA would go in the .esm. But so far it doesn't sound like there's a good reason to do so.

I'd say pass on the guy's offer. If he can't be bothered to toggle that ESM flag - or worse, doesn't know how - then he's probably not the one you want working on compatibility patches to begin with

The main type of mod that absolutely HAS to be esm are quest mods. If you add NPC's, Navmesh, or alot of packages to anyone or anything, make it an esm. I have had so many stupid little issues with my mod when its an esp. But make it an esm and they vanish faster than a (Insert speed joke here).

I add scripts to a lot of objects, but no packages. The majority of this mod is in the scripting, which I'm guessing is unaffected by being either an .esm or .esp.

I had a case once where my Phalanx mod was causing a consistent crash in a certain savegame, at a certain moment, and it was one of my scripts doing it. The script was not doing anything particularly evil.

I used Fo3masterUpdate to toggle the Phalanx .esp to an esm.

That crash vanished.

Yea, so pretty much any mod that doesnt simply do something like add a gun to the game, or tweak a prexisting mod, or something small like that should be an esm. I'm really suprised more mods arent ESMs, some of the larger ones I see are still just esp.

I plan to ESMify my mod before release, but I've been working with it as an ESP over the ~20 months of its development. I have one Big quest done (195 stages), and it works very well as an ESP.

The Navmesh bug has been an interesting vex for me, as I can't replicate it easily and I think I should be suffering from it more. One of the big exterior areas that I created was an Oil Refinerly (adjacent to the airport, as oil is still needed for this). Had lots and lots of vertical scaffolding and walk ways that definitely violate the looping-overtop of other navmeshes. In some cases I have 4 level of navmesh that overlap vertically around the big distillation towers, and the navmesh tests work and NPCs chase my ass down in-game quite efficiently (hehe).

Still I don't think there is any way around becoming an ESM with it in the end do to all the little things that I can't see. I just find it annoying in having to change it back to ESP to edit it in the GECK, so I left it as an ESP for development. It may not be as big a requirement in New Vegas if the navmesh bug and other issues with ESPs have been resolved. I expect some will be, and can only hope that new issues are not part of the package.

If you untick the ESM flag in FO3/TES4Edit, you end up with a false flag ESM (kinda like an inside-out materupdated .esp). You can http://i196.photobucket.com/albums/aa150/JustinCoherent/Fallout%203/FalseflagESMasactivefileinGECK.jpg, and http://i196.photobucket.com/albums/aa150/JustinCoherent/Fallout%203/23-NAVIRebuilt.jpg said ESM with the official editors. Then you can at least skip the file extension changing part... :shrug:

Note: The GECK, upon saving a false flag ESM, will correct its file header. Since it's then a bona fide ESM, any consecutive saving of the file will crash the editor.
Note: The GECK, of course, doesn't build ONAM lists when it ESM'ifies. Saving the plugin in FO3Edit is necessary for any such plugin that overrides its master(s) CELL/WRLD children that the ONAM list may be rebuilt.

That's pretty much a deal breaker. I tend to save frequently while GECKing, and if I had to exit the GECK, fire up FO3Edit, clear the .esm flag again, then reload with the GECK after doing so...

I guess the .esm flag doesn't need to be set for FO3Edit or Fallout.exe, i.e. playtesting, so that at least saves me a step, so long as I don't forget and go open up one of my compatibility patches with their master flagged as an .esp. I guess there's still the risk of that though the way I'm doing it now.

It's a deal breaker for me to, as I'm paranoid about loosing work and save every 10 to 15 minutes. And honestly I don't see the benefit (at least for a single DLC-type mod with few connections to other masters) of keeping the mod as a Master during development. I don't need to worry about the Navmesh bug hitting me and can get around it when testing and don't care about the face/neck lines, whereas keeping it a plugin allows me to save alot and IMHO makes me a better modder specifically because "masterfying" the mod does indeed fix bugs and make it less crashy.

I feel that if I can make my mod stable as a plug-in, resolving all errors in the editor warnings file for every cell so that it loads clean, all scripts compile, saves clean and has only original/vanilla errors left in editor warnings, that I don't get crashes anymore. Let me caveat that by saying I'm not pushing the boundaries horribly far in what the GECK can do with a quest/adventure mod, there are many mods that Need to be a master in order to work well. I do intend to release my mod as a master when the time comes to ensure all the Navmesh bugs and issues are gone, its just easier working with it as a plugin in development for me.

Miax

You could just put in a Version Updater mod for people switching from the esp to esm that, when used, activates a container full of all the various items the player could've lost. I've done that for RobCo.
Testing isn't that hard. I test with the .esp version, then when it's stable and needs to be packed to redistribute just create a .esm copy of it using FO3plugin. No constant toggling of master flags, just "Open RobCo"->"Toggle master"->"Save as RobCo.esm".

Wait, what's this one? Do .esps sometimes cause mismatched face/body textures? I thought that was solved by Archive Invalidation Invalidated.

There's 2 probs with .esp files and npc skin color.

One of them you fix by editing your C:\Documents and Settings\USERNAME\My Documents\My Games\Fallout3\FALLOUT.INI and adding bLoadFaceGenHeadEGTFiles=1 to the GENERAL section in that file. The other one was introduced in like, .exe patch version 1.5 and to fix that, you have to make your .esp live as an .esm.

But it only happens to NPCs added by that .esp, right, not to existing ones that are edited by it?

Some time back, I stumbled on a neat little trick for developing esm mods. I'm not sure how well or easy it is for all types of mods, but it may suit your needs. You load Fallout3.esm, other dependencies of your mods and the esm you are working on. While you work, you save the changes into a new esp. When you are done, you use FO3Edit to merge the changes in the esp into the esm. After that, you can delete the esp (but you may want to keep a backup just in case), and start on the next step.