One of the major pitfalls of modding is how to get something done. When you are first learning the tools and methods at hand, your first impulse is to do whatever is easiest. You want an NPC to have a certain weapon? Just edit him right? WRONG. Some rock formation or city building is in the way of what you are adding, so you should just delete it right? NOPE.
Would be mod authors quickly learn that there is more than one way to skin a cat when it comes to implementing changes in their mod, but a lot of them ignore what I see as the golden rule of mod authoring; don’t edit a vanilla resource unless you have no other way to implement your changes. This requires quite a bit of learning and trial and error so that you have a lot of tools to work with.
Let’s take custom voiced followers for example. One of the most used and detailed tutorials out there is found on Deck16 and is a very in depth and very useful tutorial, but as far as I can tell it’s great at one thing; showing you how to break the follower system for any other follower mod that uses this process. The key issue here is that the tutorial tells you that it will show you how to duplicate the quests that handle the follower functions, but instead just shows you how to edit the vanilla quests and never comes back to how to clean it up and by doing so will cause any mods that follows this tutorial to break each other. This tutorial has you add conditions to the base follower quest which means you have now edited that quest form, and as modding 101 teaches all modders and mod authors alike; any mod loaded after yours which edits the same thing will undo your changes.
Instead I found this simple tutorial that with some fleshing out actually emulates a follower perfectly. I haven’t tested this method with any follower interface overhaul mods, but it should work with them. It at least does work in game perfectly on vanilla.
Another common example is the courier delivery system. A lot of folks follow a similar tutorial out there that again, alters conditions and basically lines up all similarly built mods to get shot like in Indian Jones and the last Crusade when all the Natzi’s line up on the tank and get killed with the same 9mm parabellum round. Instead a simple, single line of code in your quest stage that adds the delivery item to the courier can solve this:
(WICourier as wicourierscript).AddItemToContainer(NoteAlias, 1)
Even more basically speaking a simple edit to a weapon’s damage, an NPC’s inventory or outfit, or the placement of vanilla items can be conflicted by other mods which affect the same resource. all of these can be resolved with code. Heck even Immersive Armor’s implements a start up script which adds all of it’s items to the leveled lists via script rather than having to fight with prioritization through a Bash Patch. Ultimately scripts are your friend when it comes to adding and changing things. Here’s a small list of script lines that can be added to the start up stage of your handler quest (quest that starts at the start of game but just runs some functions rather than an actual “quest”
ActorRef.GetBaseActor().setoutfit(MyOutfit) ; this sets a new outfit to an NPC without editing them
ActorRef.AddItem(MyWeapon) ; adds a weapon to the NPC
ActorRef.RemoveItem(Oldweapon) ; removes their default vanilla weapon
Bear in mind you have to define what “MyWeapon” and “OldWeapon” are (see Scripting 101) but you get the idea. Any opportunity you have to affect change with code rather than with edits is a good thing and makes sure that your change actually happens and that another mod isn’t getting overwritten or overwriting your stuff.
Even altering the placement of a boulder or editing NavMesh placement can be problematic. Even if another mod isn’t deliberately moving something because of their mods’ needs (in which case compatibility patches may be needed between your two mods), another mod could easily be leaving behind a dirty edit, and there is no way for you to deal with it simply by editing the object in your mod, because if that other mod is loaded after yours, it will just move the rock back to it’s vanilla placement (the dirty edit spot). To resolve this issue, you can once again use scripts to manually disable the object in game. I do this with objects from Solitude overhaul mods like JK’s Skyrim. I have Legacy coded to disable ObjectReference ID’s from JK’s which are blocking the museum or floating in some way. This way I don’t need a patch for JK and I can ensure 100% that those objects will in fact be disabled.
Navmesh is another tricky beast because if you delete a vanilla navmesh triangle, and another mod’s NPC tries to path through it the game will crash. To avoid this I always build onto existing vanilla navmesh, move existing parts and never delete. If I have to overhaul an entire area I literally move the entire cell’s mesh down and out of the way and rebuild it fresh.
Ultimately you never want to delete a vanilla object. Instead set it to initially disabled, and to make doubly sure it stays disabled, have it set to Enable State Opposite of parent and link it to the player. This way, any time the player exists (which is always), the item will remain disabled, even if something tries to manually enable it. TES5Edit will actually set this automatically to any object you have deleted in the CK when you run the Undelete and disable references pass which is one of the 3 major debug passes you should always make in xEdit (undelete and disable, delete identical to master forms and check for errors)
Ultimately you not only need to be thinking about what is the easiest way to make your mod, but you also need to think about how to keep it the most compatible with vanilla, other mods AND how best to ensure that your changes are in fact preserved, and these tools and tricks will help you get there.