esp vs esm and navmesh bugginess?

[davidlallen]

I am very frustrated by multiple problems with NPCs navigating in my one interior. See my npc's are stuck with a four second cycle for details. There is a rumor that changing from an esp to an esm, using fnvedit, will miraculously cure such problems.

 

I am confused about how to use geck with esm's. I have used it successfully for a month with esp's. Using fnvedit, I flipped the esm bit on my mod, saved it, and then changed the file extension to esm. Is that what I am supposed to do? Now when I load the esm into geck, I cannot save as esm. It gives me a save-as dialog and insists I save as esp. It seems very awkward to have to use fnvedit or file explorer every time, to work with esm files. Is there a way to save an esm in geck?

 

Using the esm, I seem to have *different* bugs. The NPC's do not always get stuck in the interior when the game is an esp, but it is pretty frequent. In 4-5 runs with an esm, I have not seen this; so it "seems" better but there is no proof. On the other hand, there are some things which got worse. I have two different conversations between two NPCs using dialog packages. In the esp, both work fine. In the esm, the last topic is never triggered. Instead of five topics, I only get four. This happens for both conversations.

 

Is anything really supposed to be different when switching from esp to esm? Is there any truth to the rumor that navmeshes work better in esm? How could this be?

Edited January 2, 2011 by davidlallen

[Ez0n3]

Ya, there's a navmesh bug that carried over from FO3 - forgot about that. You ESMify an .ESP when your're all done and ready to release the mod or for testing purposes. If you just flip on the ESM flag using FNVEdit, it becomes a "pseudo" master. For all intent and purpose, it's a master, but a real master is a little different I believe. Flipping the ESM switch also fixes head correct color, body incorrect color on NPC's. It also allows you to make plugins that use your mod as the master.

 

Finding cover and finalizing the navmesh before an ESMify will let you see the final result. Once it's an ESM, it can no longer be edited. It has to be changed back into an ESP to make changes.

 

Make a copy of the .esp, load it up, finalize the navmesh, rename it to .esm and then flip the ESM flag. Test, delete the .esm, rinse and repeat.

 

I think there's a way to flip the ESP/ESM flag using the command line, but I'm not sure which program does it, might be FNVEdit. Then you could flip it, test and flip it back - just to rule out the ESP bug.

 

Edit:

Renaming it to ESM won't do anything in itself, it's just for consistency. You can leave the ESP extension, it doesn't matter. Just the flag matters.

Edited January 2, 2011 by Ez0n3

[davidlallen]

Make a copy of the .esp, load it up, finalize the navmesh, rename it to .esm and then flip the ESM flag. Test, delete the .esm, rinse and repeat.

 

Pleh. That is awful. Does anybody know why the game treats a navmesh in a esp differently from the same navmesh in a esm? That makes no sense to me from the programming standpoint.

 

I will experiment a little around this to see if it is a magic, but painful, cure.

[davidlallen]

So, I took exactly the same mod through ten runs of the NPC travel package. Watch, load, watch, new game, watch, etc. The first five were as an esp, the second five were with an esm. The NPC got fatally stuck in two of the five esp runs and none of the five esm runs. This isn't statistically significant but it "seems better" as esm.

 

It already takes a few minutes to save in geck, launch FNV, and load a save. Adding the step of converting to esm in fnvedit makes it take even longer. This is painfully slow to test changes. I have some partial workarounds, such as creating a quest stage which ends after each package. This way I can "setstage <formid> <stage>" in console and get past each travel, in case the guy got stuck. I wish there was a better way, and I wish somebody could explain *why* an esm should reduce the frequency of navmesh problems.

[Ez0n3]

That "fix" (if you want to call it that) has been around for quite some time. Which is usually the tell-tale sign of something completely out of the hands of modders (IE: hard coded). I have no idea why it works, you would need to have access to the source to know that. If the issue was outside the EXE, some modder would have fixed it by now ;)

 

I dug up the command thingy which consists of copying two instances of FNVEdit.exe to the ./Fallout New Vegas/Data/ folder. Rename one to "FNVMasterRestore.exe" and the other to "FNVMasterUpdate.exe".

 

Running FNVMasterUpdate will flip the ESM flag on all mods that are ticked in FOMM and FNVMasterRestore will undo it.

 

NOTE:

Should make a backup of FalloutNV.esm, just in case.

Edited January 3, 2011 by Ez0n3

[davidlallen]

Thanks for the info. Does this mean that every quest mod or mod with any new interior, has to be distributed as esm? It seems that many mods like this are esp, so they must not have this problem.

[Ez0n3]

The newest update for FNV causes FNVEdit to try and alter the FalloutNV.esm file. So if you do use the FNVMasterUpdate thing, make sure you backup FalloutNV.esm as it will most likely be auto-saved when it shouldn't. That should get fixed if and when FNVEdit is updated.

 

If the mod adds a new navmesh and/or new NPC's, it should be ESMified. My guess is that mods with navmeshes/NPC's that are still ESP's, the author is either unaware or doesn't care. For some, the navmesh doesn't flake out until after the cell has been loaded at least one (IE: it's ok the first time through). If it's not a place that's visited over and over, it can be easily overlooked.

[apostate9]

The newest update for FNV causes FNVEdit to try and alter the FalloutNV.esm file. So if you do use the FNVMasterUpdate thing, make sure you backup FalloutNV.esm as it will most likely be auto-saved when it shouldn't. That should get fixed if and when FNVEdit is updated.

 

If the mod adds a new navmesh and/or new NPC's, it should be ESMified. My guess is that mods with navmeshes/NPC's that are still ESP's, the author is either unaware or doesn't care. For some, the navmesh doesn't flake out until after the cell has been loaded at least one (IE: it's ok the first time through). If it's not a place that's visited over and over, it can be easily overlooked.

 

I did this to fix a mod I made, and it occurs now that .esm files do not modify existing content, but only add new content. Hence, there are rocks in front of the door to my bunker where I deleted them. How is this being surmounted by other modders who add navmeshes, but also change the vanilla cells?

[davidlallen]

A mod can delete items as well. I do this all the time. What is the problem you are having?

[Quetzlsacatanango]

You shouldn't delete vanilla references. Disable them or move them belowground or otherwise out of sight.

Deleting them is known to cause weirdness.

Make sure you are masterizing your plugin with fnvedit in order to properly create the ONAM records.