Introduction
You wouldn't remove an official Fallout 4 DLC and expect your game to work right, would you?
Hint: No. No, you would not.
Well, mods are downloaded. Mods are content. Mods are plugins to the Creation Engine. Just like official DLC. Size does not matter.
There are technical differences, of course -- localization, for one. But the Creation Engine isn't designed with plugin removal in mind. Furthermore, a developer specifically took the time to write out that mod removal isn't supported. It was written on the official Creation Kit Wiki way back when it launched for Skyrim and carried over to the FO4 side when the site split for both games.
Prior to The Elder Scrolls V: Skyrim, mod users had the ability to remove mods in the middle of the game without the issues faced by mod users today when they do so. Fallout 4 has several new systems that further complicate mod removal.
Inter-mod Communication
A load order challenge is that some mods use scripted inter-mod communication to communicate with other mods for either compatibility purposes or because of asset dependencies. Scripted inter-mod communication is essentially blind. The script will not know another mod is in your load order if the mod it needs to look for has not initialized.
While you can save and reload to initialize a quest that pushes a script, a stable Load Order Framework will help to ensure all properly-implemented scripted mods should initialize properly.
Mods that use inter-mod communication or version control generally implement the changes using OnPlayerLoadGame() on a Reference Alias or Actor.OnPlayerLoadGame() in a Quest Script.
OnPlayerLoadGame() is a challenge for end-users for two reasons:
1 It will not fire until the player has saved and reloaded that save.
2 It is 'registered' which creates persistence and will continue every time the player loads the save, even upon removal of a mod (which will create runtime errors), until it is unregistered.
Treat mods as DLC and do not uninstall mods and continue on the same save, these include such mods as Settlement Menu Manager and their dependent mods, Workshop Framework and their dependent mods.
On Bethesda.net, mods that do not have the appropriate keywords added to their mod page title cannot be listed as Mod Requirements on another mod author's mod page so be sure to pay close attention to the wording of descriptions. If you have questions about a mod's dependencies or requirements, politely ask the mod author. It is always best to go to the source of the mod if it is ported to console. Many porters have so many mods to maintain that they have little time to communicate with their user base.
For technical information see Inter-mod Communication and OnPlayerLoadGame() on the official Creation Kit Wiki.
Persistent References
Persistent memory is an efficient way of storing data structures so they can be accessed when necessary.
A reference is an object added to the world. It has a form ID and is given a unique ID for each game called a PRID. It is either temporary, which can be unloaded from memory, or it is persistent and stays in memory at all times so that various functions and data structures can have access to it. There are several levels of persistence that will bake data into saves and thus cannot be removed or changed when updating.
Examples of persistent references:
- Quest mods that add new dialogue or AI Packages, use vanilla NPCs, or add new NPCs with new dialogue
- New settlement mods and new settlements that add new NPCs that are set to "persist location"
- Improperly created quest mods that do not
Stop()quests and unfill their reference aliases when completed - Random encounter mods or alterations to vanilla random encounters
- Workshop mods such as Workshop Framework as it is an overhaul of the settlement system and parts of the settlement system are already persistent in vanilla
- Mods that alter HC_Manager (Survival Mode)
- Mods that add new NPCs or collectibles to the world such Beantown, Interesting NPCs, or PAWA
- Scripted mods that spawn weapons, ammo, or other objects into the world
Other forms have their own rules on what persists in memory, these are just for references that are added to the world.
Return to a save prior to installation of anything you need to remove or simply start a new game. You cannot remove some levels of persistence from a save once it has already been baked in.
Additional Reading:
You can read more about world reference persistence here on AFKMods and about script persistence here and here at the Creation Kit wiki.
Script Injection
"Script injection" is a layman's term used to describe the use of adding an object to a form via the Papyrus functions AddForm() and/or Merge().
Robot Parts Mods
Robot mods that give us additional parts and colors for robots are called object modifications, just like weapon mods such as barrels. Instead of going through any removal functions -- many do not have them or use Revert() -- start a new game or go back to a save prior to installation. It is safer all around to do so.
Robot mods can also come in the form of ModCols, which are those robot mods in a collection that acts as a specialized level list. Those ModCols can only be modded once per load order.
Weapon and Armor Mods
Weapon and Armor mods that have been set up properly and to be conflict-free use AddForm() for the leveled item lists and Merge() for the instance naming rules index. There is no such function to "unMerge" from the instance naming rules.
New weapons and armors that script-inject cannot have a chem or holotape for removal, and there are several level list object modification mods that use Revert(), which will strip all mod-added objects from a list. It is safer to start a new game or go back to a save prior to installation if you no longer wish to use the mod.
Weapon and armor mods can also come in the form of ModCols, which are those mods in a collection that acts as a specialized level list. Those ModCols can only be modded once per load order.
Workshop Menus
Workshop menus are routinely script-injected using AddForm() in order to avoid conflicts. Because of bad modding practices at the beginning of Fallout 4 modding and user-error complaints, mod authors began using chems and holotapes to mitigate workshop menu breakage.
Removal of a script-injected workshop mod without using a chem or holotape will destroy a workshop menu.
There are recovery mods; however it is best to go back to a save prior to installation or start a new game if you have to remove a workshop mod -- there are other reasons than script-injection as to why this is necessary.
Additional Reading
See Broken Workshop Menus article at Bethesda.net (archived)
Texture Overhauls
Texture overhaul mods are a matter of preference. Fallout 4 only has 2 GB/1.86265 GiB of reserve space, so choose wisely or don't use them at all.
Those that are listed on Bethesda.net and those that come with BA2 archives have a blank plugin. Plugin removal is not supported by the Creation Engine, therefore, treat archived texture mods the same as any other mod and go back to a save prior to installation or start a new game if you have to uninstall.
Xbox One Users: Avoid BC7 compressed textures and 4k. DirectX on Xbox One does not support BC7 block compression, and there are issues with the gamma when using sRGB. See for more information about BC7 and 4k, see 4k Texture Problems.
PC players: That does not mean you should unpack your archived textures or scripts. Are any of the vanilla game textures or PEX files outside BA2 files?
Nope.
Things are archived for reasons. Do not unpack downloaded BA2 archives. It is not good for performance and several types of scripts and script functions fire out of order. Plus, having only archives instead of loose files makes load order management much, much easier. Just examine the archives first with B.A.E. to ensure they've not been packaged with Actor, ObjectReference, or ScriptObject as these base game scripts should only be overwritten by F4SE and the Creation Kit will grab them when packaging. Newer MAs are sometimes not aware and upload these dirty archives.
Workshop Power Grid
Without getting into technical details, workshop power grid corruption is a bad thing. You don't know if you have it until your game is crashing as you scrap items. The corruption has been described as 'ticking time bomb' and the 'Scrap Crash' by several prominent mod authors.
It is the silent destroyer of saves.
You can avoid the corruption by:
- Remembering that mods are DLC and shouldn't be removed in the middle of a play through (especially new settlements and workshop object mods such as Creative Clutter, Dead Wasteland, PWR: Powered Water Resources, etc)
- Avoiding disabling powered objects or the workshop workbench with Place Anywhere
- Avoiding mods that allow you to move the workshop bench
- Avoiding mods that overload the grid, like the abandoned mod Settlement Electricity Overhaul (SEO)
- Avoiding using "wire tricks"
For those of you who like to do wire tricks for your builds: Do not expect support for any breakage; do not expect your save's integrity to remain intact. And for the love all that's (un)holy, do not tell people, "My game's just fine!"
Because it isn't.
You can read more information about the scrap crash that occurs with power grid corruption in the FAQ.
Have questions? What's your opinion?
Do you update in the middle of a playthrough or wait until the next game in order to avoid persistence errors?
What crashes have you encountered by removing mods in the middle of your game?
Have you ever had the scrap crash by removing a powered object the wrong way, after doing too many wired objects through walls, or using a mod that overloads the power grid?