Here is a tutorial on how to create a Merged and Bashed Patch for your mod list in Mod Organizer. Mod Organizer 2- https://github.com/TanninOne/modorganizer/. Activity for Mod Organizer I have the same problem but with two displays, I have some ideas to fix it though. Michelle Price posted a comment on discussion General Discussion. PHASE 2: SKSE Plugins, Bug Fixes, and.ini tweaks. Here we go with part two! First, we're going to make sure Mod Organizer can handle NMM links.
|
For TES and Fallout Bethesda games, primarily Skyrim
Introduction
Bethesda role playing games using the Gamebryo engine, including The Elder Scrolls games (TES4 and TES5) and Fallout games (Fallout 3, Fallout NV, and Fallout 4), have a limit of 255 plugins (roughly 140 for Fallout New Vegas). While this may seem like a lot, most heavily modded games need more plugins than allowed with this limit. This small guide outlines the primary methods for merging existing plugins and for creating plugins that merge conflict resolutions and content for multiple mods.
There are multiple methods that can be used to merge all or portions of esp plugin files to allow large collections of plugins to fit inside the plugin limit of Bethesda games. Some of these methods create or merge compatibility patches for multiple mods using a single esp plugin, thus reducing the need for multiple esp plugins to provide compatibility patches for various pairs of mods.
The techniques below are listed in order of increasing complexity. With the exception of the Wrye Bash methods below, all the techniques described here require a good understanding of TES5Edit (or equivalents for other games including TES3Edit for Morrowind, TES4Edit for Oblivion, FO3Edit for Fallout 3, FNVEdit for Fallout New Vegas, FO4Edit for Fallout 4), and the record structures of plugins.
Until recently the only tools that could provided automatic merging of mods for Bethesda games were TES4Gecko which automatically merges Oblivion plugins, and FNVPlugin which merges Fallout New Vegas plugins.Mator'sMerge Plugins provides very capable mod merging tools that can be used across all the Bethesda games that are much more capable than any older merging tools. The x in xEdit stands for the first three letters of each of the separate editors for each of the Bethesda games. Merge Plugins requires the most recent version of xEdit which is available at the Fallout 4 reference above.
This guide does not cover the use of patches created by SkyProc or other similar tools. In Skyrim, SkyProc is used by several active Skyrim mods (e.g., ASIS, Dual Sheath Redux) to create mod-specific patches.
The rest of this guide discusses several tools used for mod merging and conflict resolution.
Merging Mods Without Conflicts
Automatic Merging of Multiple plugins with Merge Plugins
Mator's Merge Plugins utility has evolved to where it provides a simple way to do even complex merges. It is now possible to merge Fallout and Oblivion plugins, a particularly useful feature since Fallout NV cannot handle nearly as many plugins as other Bethesda games. The FAQ in the Nexus description for the Merge Plugins is also quite valuable since it covers the major issues associated with merging plugins including problems caused by changing FormIDs (as discussed later in this guide). Support for this utility is available as part of Mator Utilities Support on the STEP site.
Merge Plugins
Mator's Merge Plugins utility can be used to merge theoretically any installed mod with any other installed mod following 'The Rule of One', which requires that the behaviour of the assets after the merge are identical to their behaviour before. This includes mods containing Papyrus scripts (.pex files), NAVM/NAVI (navmesh) records and FormIDs (new objects created by the plugin).
A very thorough tutorial on installing, configuring and using Mator Merge Plugins Standalone by Gamer Poets can be found here Merge Plugins: Start to Finish.
For mods that don't create objects used by other mods that aren't being merged, the resulting merged mod should be free of any problems. Examples of mods like this are (note the examples are old and will be replaced shortly with some newer examples)
- Atlas Map Markers plugins in Skyrim) with multiple plugins to support different DLCs, and
- Immersive Patrols with multiple plugins for different NPC categories that can be encountered.
The current version of the Merge Plugins utility can also merge mods without changing the FormIDs, thus preserving the capability to use items in these mods without the need to revise all the mods that use these items. This also preserves items that already exist in saved games.
The Merge Plugins utility also works well with mods that provide items like armor and clothing. The only issue with these mods is that if the mods being merged change sufficiently when updated then a new merge of the underlying mods might not preserve all of the objects in a players inventory, as discussed in the Q: My hair's gone?! My armor's gone?! My weapons are gone?! My face is gone?!?!WHAAATTTT?!!!?! question in the FAQ for the older script version of the mod. This won't be an issue if FormIds were not renumbered.
Merges of mods with conflicts uses the standard Rule of One approach that is also used in the Bethesda engine itself. The latest loading plugin that affects each object will be included in the merged plugin. A check for conflicts can be done manually by looking at the records and subrecords in xEdit or by using the Conflict Filters capability in xEdit described in section 4.3 of the FNVEdit Training Manual.
If the plugins being merged are compatibility patches, particular care must be taken since these patches typically need to load later in the mod load order and because there might be conflicts across different compatibility patches that need to be resolved. If this automated technique is used, it is a good idea to create one plugin that combines the optional patches for an individual mod vs. creating one plugin across many different mods since the automated method uses the simple Rule of One to handle conflicts. If the plugins being combined are from the same mod, always start with the plugin for the main portion of the mod if it is being merged. For large mods with multiple compatibility patches it's usually best to merge only the patches. The advantage of including the main mod is that there may be intentional overwrites in the DLC or optional capability plugins, and if the main mod is included then by adding the main plugin first the combined plugin will have the correct records.
The merged mods created by the Merge Plugins mod can merge plugins with navmesh records, but if more than one of the plugins includes navmesh overides some additional steps are needed before using the newly merged plugin. These steps are described in this post and this post in the A Real Explorer's Guide to Skyrim topic. These require deleting navmesh records in the plugin and then opening the merged plugin in the Creation Kit. An excellent detailed example of how to do this is available in one of the documentation forums for the Skyrim Expanded Towns and Villages mod.
Using LOOT (Load Order Optimization) to maintain proper load order
The patches created by this method will not be in the normal 'LOOT' list, so it is recommended that the load order assigned by LOOT should be checked, and if necessary the LOOT GUI can be used to cause the mod to load later. The STEP guide includes a set of LOOT rules for sorting Skyrim plugins.
Automatic Merging of Plugins that can have Conflicts
Automatic Merging by the Skyrim Executable
This STEP forum topic, which includes a pointer to this Afkmods post by Arthmoor, discusses the record types that are automatically merged by Skyrim itself. For these there is no need for any additional merging. There are not many such record types, but it is important to know which ones are included.
Wrye Bash for TES games and Wrye Flash for Fallout games
Wrye Bash can create a bashed patch containing resolutions for some of the conflicts between plugins. Key capabilities of the bashed patch are:
- some plugins can fully merged into the bashed patch, and these plugins can then be disabled,
- some tweaks can be added to the bashed patch, avoiding the need for a plugin to set these (e.g., crime radius and maximum number of companions in Skyrim), and
- a few data record types, such as leveled lists, can be merged automatically in the bashed patch avoiding the need to manually create a compatibility patch for these.
Documentation on creating a bashed patch with Wrye Bash is available in the Bashed Patch section of the General Readme for Wrye Bash (use the '?' icon on the bottom of Wrye Bash to display this file) and in the Wrye Bash Pictorial Guide. There is also a video on this and additional discussion on Wrye Bash in the STEP Wrye Bash guide. The bashed patch can automatically resolve and merge several types of conflicts between mods.
The data record merging used in the bashed patch handles several types of conflicts. Like the xEdit Merge Patch discussed below, for records that are part of 'leveled lists' it can properly handle situations when one mod changes a subrecord and another mod changes a different subrecord and also when when two or mods change the same subrecord. In addition to resolving conflicts in leveled lists, Wrye Bash can also automatically resolve some non-leveled list record types when two mods change the same subrecord. For example, if one mod changes an NPC skill level to 50 and another mod changes the same skill to 60, the bashed patch will choose one of these changes or use a compromise value based on both (e.g., 55). In performing this task it uses Bash tags (for more details on the tags see here) to help determine which mod's records should have precedence when there is a conflict. These tags can be assigned manually in Wrye Bash, by using the BASH tags sutodetection script for xEdit, and (when implemented) automatically assigned to a mod when LOOT is used.
The Skyrim version of Wrye Bash does not merge nearly as many record types as the versions for TES4 (Oblivion) or Fallout (Fallout 3 and Fallout New Vegas). Wrye Bash for Skyrim handles record types for leveled items, leveled NPC, Names, Item Stats for armor and weapons, and a very small set of game settings (GMST). The only game settings it handles are ones explicitly included in the bashed patch menu; it does not include any GMST records from mods. It remains, however, the best way to merge leveled lists and leveled NPCs, but with the WB limitations in Skyrim other utilities are often needed to supplement its capabilities. An experimental version of Wrye Bash for Skyrim is available that handles a much larger set of hash tag types; once this has been tested Wrye Bash will be able to handle some of the merging that is especially tedious to do manually.
Mator Smash
Mator Smash currently in development, as discussed in the Mator Smash subforum on the STEP site, is being developed to provide a much more complete capability for merging mods managed with tags.
xEdit Merge Patch
TES5Edit (and the equivalent xEdit programs for the other Bethesda games) can automatically create a Merge Patch that merges some potentially conflicting records across multiple mods. In Skyrim it can only work with a few types of records and is primarily useful as a starting point for creating manual patches. With the emergence of the Merge Plugins tool discussed previously there does not seem to be any need to use the xEdit Merge Patch.
Using this capability of TES5Edit is quite different than using the Merge Plugins mod described above since here TES5Edit is being using to create a set of merged records that only include records for which the mods being merged have conflicting entries while above it was merging entire mods when the mods had no conflicts. It can handle plugins that include scripts. This is described in section 4.8 of the FNVEdit Training Manual (the most recent available documentation for TES5Edit) and in Sharlikran's 'Merge Patch' video. As the video points out, when using this TES5Edit (and the equivalent programs for the other Bethesda games) feature make sure to remove the Leveled List records and the leveled NPCs from the Merge Patch (note that unlike the edit programs for other Bethesda games the TES5Edit Merge Patch does not currently include leveled NPCs). It is recommended that Wrye Bash be used to take care of leveled list merging, as described above. Like the Wrye Bash bashed patch, the Merge Patch needs to be recreated whenever there is a plugins are added or updated that would change the patches automatically produced in the Merge Patch. The documentation on the Merge Patch suggest manual review of the patch to fix conflicts that the automated Merge Patch process was unable to fix.
In TES4 and the Fallout games the Wrye Bash bashed patch is sufficiently comprehensive , more configurable, and intelligent that the Merge Patch isn't typically needed. In Skyrim, however, the TES5Edit Merge Patch is quite useful, especially since it takes care of portions of compatibility patching that Skyrim Wrye Bash doesn't. In addition to Leveled Item, the TES5Edit Merge Patch includes the following record types: Ammunition, Armor, Container, Faction, Magic Effect, Misc. Item, Scroll, Weapon, and Non-Player Character (Actor).
Creating a Merge Patch is straightforward. Load TES5Edit (or the equivalent programs for the other Bethesda games), and select 'OK' after removing the checkmark for the bashed patch if there is one. Right click in the left window and select 'Other' and then 'Create Merged Patch'. When prompted for a new module name enter a new name for the merged patch. After the patch is created disable and/or delete any previous Merged Patches. In addition, the Leveled Item object class should be removed and the patches reviewed to make sure they are reasonable changes; most of the time they are.
Manual Merging of Mods with Conflicts
Manually merging plugins with TES5Edit
TES5Edit can be used to manually create a single compatibility patch merge plugin that provides compatibility fixes and parameter changes across a large set of mods, that merge complete mods, or combinations of these. Manual editing is the most complicated and flexible of the methods being discussed here. It is briefly described in section 4.7 of the FNVEdit Training Manual. Since this is a manual process it can be used with plugins that have conflicts and those that have scripts; script records can be copied to the patch merge plugin like any other record. Manual Editing is easiest with plugins that do not have new FormIDs; if there are FormIDs they need to be renumbered. Manual editing is especially simple with small plugins that change a few parameters originally set by the main game esm file; of course, these are also the plugins that are easiest to combine with the automated methods discussed in the previous subsection. For example, in Skyrim the 26 Moon Size Tweak mod has two plugins each containing a single record. Merging these two plugins into a single plugin or even into an overall plugin containing Patches is particularly easy. Of course, the Merge Plugins TES5Edit Script mod described above can be used to further simplify this merge process as long as there are no conflicts. Generally speaking, actual manual editing (vs. using tools like the Merge Plugins TES5Edit Script) is needed when there are conflicts that can't be resolved automatically. This occurs frequently, but not always, when merging compatibility patches, and when creating compatibility records for mods that have compatibility problems but don't have existing compatibility patches.
In some ways the most difficult problem with manual merging is to decide which plugins to merge; it can be difficult to correctly merge complex plugins when there are conflicts on multiple subrecords. There is limited documentation on the types of errors that are typically encountered when doing this. In general the easiest mods to manually merge are ones that are small or don't have complex record structures.
Manual merging involves four types of actions:
- 'Copy as Overide', as described on page 33-34 in the FNVEdit Training Manual, is used to copy a single record from a mod into a patch plugin. When there are conflicts this is used to get all the subrecords from a mod into a patch plugin, typically followed by manual editing of selected individual subrecords in the patch as described below. The FNVEdit Training Manual suggests that this is done after using a conflict filter; this is useful when a lot of mods are being edited at the same time but isn't needed when a patch is being created or edited for a few specific mods.
- 'Copy as Deep Overide' is used to simultaneously copy multiple records from a mod into a patch plugin. When there are conflicts this is used to get all the subrecords from multiple records of a mod into a patch plugin, typically followed by manual editing of selected individual subrecords in the patch as described below.
- 'Edit' an individual subrecord, as described briefly on the bottom of page 36 in the FNVEdit Training Manual, is used to change the value, text, or reference in a single subrecord in a plugin.
- 'Drag and Drop' editing of individual subrecords, as described on page 35-36 in the FNVEdit Training Manual, is used to copy the contents of a single subrecord from a mod into a patch plugin. When creating a patch this is often the most commonly used action type.
When manually merging care must be taken with GMST (game setting) records as discussed in this post by EssArrBee. The procedure for merging these records is:
Merge Plugins - Page 79 - File Topics
- Right click Game Settings->Add->GMST - Game Setting.
- Put in any FormID that start with the load order number (e.g., if the mod has 4D in the load order add 4DXXXXXX).
- Go to the mod whose Game Setting is being merged, get the Editor ID (a text name) of the Game Setting, then add it to the Editor ID line for the new FormID just added to the merged plugin.
- This should make the other records with that game setting show up in columns in TES5Edit, and the setting values can then be dragged and dropped from the mod with the desired Game Setting value.
An Example of Using Copy as Override and Drag and Drop to Change a Subrecord for a Patch Plugin
Drag and Drop editing is commonly used in creating patches. An example for using this in creating a patch is a patch for to resolve a conflict between Acquisitive Soul Gems (ASG) and Animated Weapon Enchants (AWE). AWE changes the shader subrecord for the Soul Trap spell, while ASG changes many other subrecords. The steps used to create the patch are described below.
- Open TES5Edit
- Select 'Acquisitive Soul Gems.esp' and Animated Weapon Enhants.esp then click [OK].
- Expand 'Magic Effect' under Acquisitive Soul Gems.esp and select the '0005B452' node.
- Right-click on Acquisitive Soul Gems.esp column and select 'Copy as Override into...'.
- Select '<new file>' and click [OK]. In the resulting text box type 'ASG-AWE Patch'.
When you do this a new column appears on the right titled 'ASG-AWE Patch'. Scroll way down until you see the row heading 'Enchant Shader' under 'Magic Effect Data'. If you look on that line you will see that three of the columns have 'EnchPurpleFXShader' entries and one (AWE) has 'wpnSoultrapFXS'. You want to drag 'wpnSoultrapFXS' entry from the AWE column to the entry on the same line in the column to the right ('ASG-AWE Patch'). When you do this it will replace the 'EnchPurpleFXShader' entry with 'wpnSoultrapFXS'.
Guide to make a patch for solving conflicts
A small guide is available with screenshots and recommendations on patch creation. It has not been reviewed in detail yet, but it does ave some useful suggestions.
Using ModGroups to Simplify Manual Conflict Resolution
See this thread in the STEP forums and this post in the AFKmods xEdit thread. This capability is available in xEdit 3.1.0. More examples need to be added to this section about using ModGroups.
Patch Load Order
While potentially the patches created by these four methods could be merged, it is suggested that the plugins be kept separate to simplify maintenance (there will always be need to add new records and edit/remove old ones). Any merged plugins created should be loaded near where the original mod was loaded, as discussed in 1.3. The Merge Patch from 1.2 should be loaded prior to the bashed patch. Typically any manually created Patch Merge plugins from 1.4 are loaded either after the mods they reference or after the Merge Patch and before the bashed patch.
Issues in Changing FormIDs
Every different type of object in the game has an 8 digit hexadecimal number called a FormID, a unique identifier for that particular object type. As mentioned above, when merging some plugins the FormIDs for objects created by a mod (vs. the vanilla objects in the Skyrim.esm or Update.esm plugin or one of the DLC esm plugins) need to be changed. If the resulting merged mod includes all uses of these FormIDs, then there aren't any problems since the merging process changes all references to these FormIDs to use the new values. However, if there are other mods that reference one of these FormIDs that are not included in the merged plugin, there is a problem since those mods reference the old FormID value which is no longer exists. This is why the suggestion was made above to merge plugins from the same mod; this usually insures that all references to FormIDs created by the mod are included in the merged plugin. A merged plugin does not actually need to contain only plugins from the same nod, but for all the mods included in the new merged plugin all uses of any FormIDs created by these mods must be included in the merged plugin.
As mentioned above, this issue is also discussed in the 'Q: My hair's gone?! My armor's gone?! My weapons are gone?! My face is gone?!?!WHAAATTTT?!!!?!' question in the FAQ for the Merge Plugins TES5Edit Script mod .
Many mods do not introduce new FormIDs in their plugins, and as long as there are no conflicts among these mods merging their plugins can be fairly straightforward (unless there are issues with merging scripts; this does not typically happen with mods that use small scripts).
1. Introduction
2. Overview
3. xEdit Basic Use
4. ModGroups
5. Conflict Detection and Resolution
6. The Method
7. Mod Cleaning and Error Checking
8. Managing Mod Files
9. Mod Utilities
10. FO3Edit FAQ
11. Appendix
12. Cheat Sheets and Quick Reference Charts
13. Scripting Functions
14. Scripting Resources
15. Tutorials
16. xLODGen
17. DynDoLod
18. xEdit What's New and Version Info
Contents...
• 8.1 Overview
• 8.2 Adding Master Files to a Plugin
• 8.3 Adding ESL flag to a Plugin
• 8.4 Adding ESM flag to a Plugin
• 8.5 Changing Mod FormIDs
• 8.6 Merging a Plugin into another Plugin or Master
• 8.7 Converting a Plugin into a Master
• 8.8 Splitting a Plugin into a Plugin/Master Pair
• 8.9 Comparing Two Versions of a Mod
• 8.10 The ESL Flag
• 8.10.1 Important dangers when compacting FormIDs
• 8.10.1.1 First Important danger when compacting FormIDs
• 8.10.1.2 Second important danger when compacting FormIDs
• 8.10.1.3 Third Important danger when compacting FormIDs
• 8.10.2 When it is safe or not safe to add the ESL Flag
• 8.10.3 Adding the ESL flag
• 8.10.4 Adding the ESL flag for mod users
• 8.11 How ESL enabled games handle FormIDs for ESL flagged files
• 8.11.1 How ESL enabled games address records within plugins
• 8.11.2 The ESL address format
• 8.11.3 The Downside
• 8.11.3.1 Example 1
• 8.11.3.2 Example 2
• 8.11.4 Example 3
• 8.11.4.1 ESLifying plugins
• 8.11.4.2 ESLifying Plugins the easy way
• 8.11.5 Compacting plugins
• 8.12 Credits
8.1 - Overview
This chapter is dedicated to mod authors, and describes a number of functions and actions that xEdit provides to make mod authors lives easier and their products more standardized. Like the chapter on Mod Cleaning and Error Checking, these functions hole mod authors produce products that will be less conflicting with other mods, and will open doors to possibilities that mod authors may not have known existed. Actions like merging mods, splitting them apart into Plugin/Master pairs, adding Master file references and more are documented in the sections below.
8.2 - Adding Master Files to a Plugin
To reference a record from ExampleMaster.ESM in Plugin.esp you need to add ExampleMaster.ESM to the MASTer list in the File Header of Plugin.esp. This allows the plugin to add/change items found in the ExampleMaster.ESM. xEdit does this by adding a new master to the MAST sub record in the file header and correctly renumbering the FormIDs in the module. This can be very handy for mod authors, as it simplifies the process down to a few mouse clicks, so the mod author can focus on more important things like modding!
In this example we showcase Saiden Storm's Weapon Effects mod and the taylorsd's Better Frag Grenade Physics mods, two excellent enhancements to Fallout3. Here we will add the SS Weapon Effects.esm Master file to the Better Frag Grenade Physics plugin, so that we can add one of Saiden Storm's cool plasma blasts to a frag grenade for kicks! To start the action, select 'Add Masters' from the context menu as shown:
This will present the File selection menu, from which you can Check the Master file(s) that you want to add as references in the Plugin's header as shown:
Once xEdit adds the master file as a reference in the Plugin, you see results similar to the screenshot below showing the Messages Tab log-entry:
Note that 'SS Weapon Effects.esm' has now be added to RealFragGrenade3.esp, making it possible to attach one of Saiden Storm's Weapon Effects explosions to the grenade effect in Better Frag Grenade Physics. The View Tab shows the specific entry:
Note: If you plan to release a mod to the public, then you should ONLY do this with permission from the modauthor, in this case Saiden Storm. If you wanted to use his weapon effects in a mod of your own and release it, you need permission!
Below Elminster describes why this function is important for mod authors wanting to add master file references to their own mods:
Elminster
'With FormIDs it's important to realize that the FormIDs that xEdit shows you are NOT the ones that are actually written into the module file. The FormIDs that xEdit shows you are 'load order corrected' ones, while the FormIDs in the file itself are 'file specific' ones.
FormIDs are made up of 2 parts, the first byte (2 characters) is the 'module index', the last 3 bytes (6 characters) are the 'module specific ID'.
Mapping from 'file specific' to 'load order corrected' FormIDs and back only affects the 'module index' and leaves the 'module specific ID' untouched.
An example, suppose you got a bunch of modules loaded:
• [00] Fallout3.esm
• [04] MasterA.esm
• [10] MasterB.esm
• [15] MasterC.esm
• [20] Plugin.esp
And lets suppose the MAST sub record in the File Header of Plugin.esp lists:
• Fallout3.esm
• MasterB.esm
• MasterA.esm
If you now see a record in Plugin.esp that overrides a record from Fallout3.esm, then you would see a FormID like 00123456 for it. In this particular case that record would also have the same (00123456) FormID inside the Plugin.esp module file.
But if you have a record that overrides a record from MasterA.esm, e.g. with a FormID like 04ABCDEF (you can see the 04 as 'module index' matches the load order of MasterA.esm) then it would be saved as 02ABCDEF in the Plugin.esp module file, because 02 is the index of MasterA.esm in the list of MASTer files in the File Header of Plugin.esp.
And an override for a record in MasterB.esm (e.g. 10654321) would be saved as 01654321 in the Plugin.esp module file because 01 is the index of MasterB.esm in the list of MASTer files in the File Header.
Last but not least, a NEW record in Plugin.esp which belongs to Plugin.esp and which xEdit would show you e.g. as 20FEDCBA gets stored as 03FEDCBA in the file (because 03 is equal to the number of entries in the MASTer list, as indices into that list start at 00, 03 is one higher then the highest valid index into that list).
You will also notice that it's not possible to have an override record for a record from Master3.esm in Plugin.esp or in any other form reference such a record, because there is no way to map a load order corrected FormID of 15A1B2C3 to a file specific one that's valid in Plugin.esp.
To reference a record from Master3.esm in Plugin.esp you need to add Master3.esm to the MASTer list in the File Header of Plugin.esp. But if you just go there and do that manually, then you've just added Master3.esm with the index 03 to the file. Which means that all the records that used to belong to Plugin.esp are suddenly considered override records for records from Master3.esm and will show up with 15xxxxxx FormIDs instead of 20xxxxxx FormIDs! A real mess.
If you instead use the Add Masters function, then xEdit will not only add then new entry into the MASTer list, it will also renumber all (file specific) 03xxxxxx FormIDs into 04xxxxxx FormIDs first to preserve their meaning (which is 'this record belongs to this file').
There are rare cases where editing the MAST list directly is what you actually want. e.g. when splitting an .esp into an .esm/.esp pair. In that case you would make a copy of the .esp, rename it to .esm, load it alone into xEdit to set the ESM flag in it's header, then restart xEdit to load both the .esm and the .esp and modify the MAST sub record in the File Header of the .esp by adding the .esm as last entry. After restarting xEdit and loading both files you will see that all records in the .esp are now considered overrides for the same records from the .esm'
8.3 - Adding ESL flag to a Plugin
Load the module you would like to add the ESL flag to and click the plus by the filename to expand the contents. Click File Header, right click in the View Treeview and choose Edit to be presented with a list of Flags.
Check the box next to the ESL flag and click Ok.
Click okay to save the plugin.
8.4 - Adding ESM flag to a Plugin
Check the box next to the ESM flag and click Ok.
Click okay to save the plugin.
8.5 - Changing Mod FormIDs
There are times in which you may need to renumber the FormIDs for all records in a plugin to avoid conflicts. This can become necessary if two plugins share the same FormIDs (or some of them), which can result in bad conflicts in-game. Renumbering FormIDs from will change all FormIDs of records belonging to the Mod-file (but not any override records which might be contained in that mod file) so that they start at the specified value.
This Function is useful if you have multiple modules that you plan to update in the future, but also want to always provide a merged version (e.g. using FO3Plugin). By assigning non overlapping FormIDs to the different modules, you can make sure that no FormID reassignment of conflicting FormIDs has to take place when merging.
To renumber the FormIDs of a Mod file, Right-click on that mod file in the Navigation Tree to present the main context menu (A). Then select, 'Renumber FormIDs from…' from the menu as shown in the screenshot below:
When selected, the function will present a, 'Start from…' window asking you what number you want to start the renumbering at as shown below.
Normally a FormID is 8 characters long, with the first 2 representing the mod file's index and the last 6 the reference's specific index within that specific mod. Thus pick a number between 100000 and FFFFFF in hex:
Once the new module specific start FormID (in hex) has been input (A) and the OK button selected (B), xEdit will begin changing the FormIDs and present the output in the Messages Tab as shown in the screenshot below:
When changing the FormIDs of a huge mod like Reykjavik by Alexander Sigurðsson, the process took 3-4 minutes on a high-end computer. The results shown in the Messges Tab reveal just a few examples of xEdit renumbering a FormID, discovering all references to it in all mod files, and correcting the numbering to prevent conflicts.
Note: Changing the FormIDs of an existing module will make it SaveGame incompatible and will break any other module that uses this module as master! If you have any dependant modules, you need to have them all loaded into xEdit at the time you change to FormIDs so that they will all be updated accordingly.
8.6 - Merging a Plugin into another Plugin or Master
One of the common tasks that many mod authors face is the need to merge mod files together into a single plugin or master file. Many mod players also like to merge all of their favorite plugins into a single master file (one modder affectionately calls it, 'BORG.esm'). xEdit can be used to accomplish both of these needs, and will ensure that the resulting plugin is synchronized correctly against it's combined references, and that the load orders are correct. The process is illustrated below, starting with loading FOMM and ordering the files correctly as shown below:
In this example we will be merging Skykappa's Destructible Building Materials 3000 ( WIPz) (here-after referred to as DBM 3000) into the 500 Rads Bar (WIPz), so that the Bar can utilize the destructible building materials. Note that Skykappa's DBM 3000 is a modders resource, and was released by the author to be used in other mods for the low price of mentioning in the mod's credits.
Load order is important when merging mods together, mainly because xEdit is very precise about the numbering and order of FormIDs and references amongst mods. Its is Very easy to conflict the FromIDs of mods being merged together (as is discussed at depth below). As such xEdit requires us to place the mod that is receiving the content (A) Below the mod being assimilated (B) in the load order of FOMM. This is important, but if you get it wrong don't worry, xEdit will warn you about it (also shown below).
You can also merge many mods into one at once, you don't have to do it one-by-one if you happen to have several mods that needs to be combined together (as in when a modder lumps everything into one giant BORG.esm). The only requirement is that the assimilator (BORG.esm) is at the bottom, below the assimilates. Once you have the load order correct, exit FOMM to save the load order.
Now launch xEdit, which should offer the list of mods in the correct order with the assimilator at the bottom as shown below:
Note the load order is exactly as we specified in FOMM. If everything is checked, you can always Right-click in the Master/Plugin Selection window and click, 'Select None' to clear all the checks. Then select the assimilator and assimilatees (A). Click okay to load the mods into xEdit (B), which yields the following output:
Note how the only files loaded are the main Fallout3 master files and the mod files we are merging together (B and C). We are now in a position to merge the DBM 3000 into the 500 Rads Bar!
To execute the merger, first open the assimilatee's (mod being copied) by Left-clicking on its plus sign (A), and then selecting all of the record headings within the mod (B) using the mouse and the shift-key. Next Right-click at (B) to render the context menu, and select, 'Deep copy as override into…' (C) As shown below:
This action performs our traditional, 'Copy' of the material we want to merge, and will present you with a menu option where you can select the file you want to merge these records into (our traditional, 'Paste'):
When presented with the, 'Which files do…' menu, select the mod that you want to Paste the content into (A), and select OK to perform the merge (B). You may be prompted to add the copying mod as a master, select, 'Yes' to this (C).
You will now be presented with the output, which can be seen in the Messages Tab:
Note how the 500 Rads Bar now has Bold text over its name, indicating that new records have been copied into to and that it is marked as modified (A). The Messages Tab displays the output of any master connections we made during the process (B), and any errors that may have occurred (none in this example).
If you now open the two mods, you will see how the references from DBM 3000 are duplicated into 500 Rads Bar. Each record can be seen in the View Tab down to the variable and reference level, as shown below:
Each record can be compared in the View Tab as desired; showing that each has been copied into the 500 Rads Bar and will now save as part of that plugin. Any errors that occur will show up in the Messages Tab, and may likely prevent a merger from taking place. If you see errors in the Messages Tab, you should assume that the mods did not merge and you'll need to address the errors noted.
With the merger complete, it's time to save our newly-combined mod file! This is done most conveniently by hitting, 'Alt-S' or closing xEdit. Either will present you with the Save Changed Files window as shown below:
Simply ensure the mod you just merged together is Checked for saving (A), and click 'OK' to save the mod. Also note that the only file xEdit wants us to save is 500 Rads Bar, while DBM 3000 is not shown. This is correct behavior, indicating that we copied stuff into 500 Rads Bar and effectively did nothing to DBM 3000.
If you get the load order wrong in FOMM when trying to merge two mod files, xEdit will present you with the following error:
Note that the error is very specific about the load order issue, in an attempt to better guide you into the right load order for whichever mods you are trying to merge. If you see this error, exit xEdit, correct the mod load order in FOMM, re-launch xEdit and perform the merger operation again.
If you don't see any errors through the process or after saving, exit xEdit and either test the combined mod file or load it up in the GECK so you can start adding destructible building materials to your mod! Have a nice day, thank you for playing.
8.7 - Converting a Plugin into a Master
Converting a Plugin (ESP) into a Master (ESM) file is a simple process that can be doing using xEdit in less than five minutes. The file extension of a Plugin as well as the ESM flag within its file header must be changed in order to make the transition to a Master file. The screenshot below starts the action by launching xEdit:
First you need to de-select all of the mods using Right-click in the Master/Plugin Selection window (A). Then click/check just the mod your converting (B), in this example we're converting Antistar'sWeapon Mod Kits plugin into a master file. Click 'OK' (C) to load xEdit with just the mod being changed as shown:
Note that Weapon Mod Kits is successfully loaded into xEdit (B), and that it is the only file listed aside from the Fallout3 master files (A). You are now ready to convert the Plugin into a Master file.
To make the conversion, all we have to do is change one flag in the File Header, which can be accessed by Left-clicking open the Weapon Mod Kits record in the Navigation Tree. Immediately beneath name of the mod is the File Header row (A) as shown below. You will then see the File Header data printed into the View Tab (B):
The File Header record is divided into different sub-headings and variables, including the Record Flags, Version, Author, mod Description and any Master file references that the plugin requires. We will be changing the Record Flags variable by Right-clicking into the open space next to it (C), which will render a small context menu. You can then click, 'Edit' (D) to change the values. Doing so will present a warning window as shown below:
This window is a default/standard in xEdit, and exists to make sure that anytime you are about to change a mod file for the first time, you know about it. It may seem annoying to some, but often the worst conflicts between mods come from changes that a mod author did not intend to make. Simply select, 'Yes' (A) to move along.
You will next be present with a menu of available/known flags that you can select:
Note that many of the flags are blank or unknown, because literally the community does not know what those flag values mean. Fortunately the flag we need is the first one on the list (A), simply Left-click it and then click, 'OK' to save the flag settings.
With that you are done! Note the File Header text is now Bold (A) indicating a change, and the Record Flags in the View Tab (C) show that the ESM flag is set (B).
Once done with xEdit, you will want to change the file extension from Weapon Mod Kits.esp to Weapon Mod Kits.esm so that the extension matches the File Header flagging. The GECK and Fallout3 don't really care about the file extension (ESP/ESM), what matters is that File Header flag. The Extension is for humans to keep them sorted correctly! Now all you need to do is exit xEdit or press, 'Alt-S' and Save your new Master file as shown below:
It is also possible to change a Plugin to a Master using just FOMM or other tools, but there is always the potential of problems with ONAM records. ONAM records are special records created that allow Master files to communicate with one-another when references need to be passed. xEdit ensures that as part of the conversion process, these ONAM records are built and correctly ordered. This is why it is better to make the Plugin to Master conversion using xEdit.
8.8 - Splitting a Plugin into a Plugin/Master Pair
Splitting a single Plugin (ESP) into a Master (ESM)/Plugin (ESP) pair can be useful in many situations, especially when a mod author wants to share resources from one Plugin with other Plugins. The only way to share resources between Plugins is to convert those resources into a Master file. The split is a two-part operation in which you first split the single Plugin into a duplicate Plugin and Master at the file (windows explorer) level. You then change the Flagging on one of the two duplicates to turn it into a Master, and change the flagging on the Plugin copy to make reference its new master file. The action begins in windows explorer as shown below:
With the mod copied, the next screenshot shows the paste:
This will create a duplicate of the WeaponModKits.esp Plugin. This may seem a very basic part of the process to duplicate, but was done for thoroughness and for those who can't read English and depend on the diagrams for the process.
Now we need to re-name the copy to make it our Master file version.
You will be presented with a warning about changing the file extension, which is a common windows warning. Simply select, 'Yes' when prompted. The screenshot below shows the last part of the duplication process:
You will then be presented with the output; both a Plugin and Master file that are identical at this point. The screenshot below shows the Master (A) and Plugin (B):
With the file duplication part done, it's time to launch the Fallout Mod Manager ( FOMM) to set our loading order for the new Master file as shown below:
Once FOMM is loaded, find the WeaponModKits.ESP (B) and WeaponModKits.ESM (A) versions of the mod in the list and ensure that both of them are Checked/Selected to load. The screenshot shows how FOMM will look when first loaded after the split, showing the ESP (B) is still checked (as it was before), while the new Master we just created is not yet checked (A) as shown below:
Here you must also ensure that the Master (ESM) version loads Before the Plugin (ESP) version as this is a Fallout3 requirement. The recommendation is to move the Master (ESM) higher-up in the load order before all other Plugins, and load the Plugin (ESP) version of Weapon Mod Kits somewhere below the Masters. With that done, close FOMM and load xEdit. Your new load order with the Weapon Mod Kits.esm loading before the Weapon Mod Kits.esp should be visible in xEdits as shown below:
To load just the Master and Plugin, first Right-click in open space (A) and select, 'None' from the context menu as shown above, and then check-off just the Weapon Mod Kits.esp and Weapon Mod Kits.esm files (C), and click, 'OK' to load them into xEdit. This will load just the two Weapon Mod Kits files and the Fallout3 masters into xEdit as shown below:
Note that both our Master and Plugin version of Weapon Mod Kits is loaded and ready for conversion (A). The loader confirms a successful boot-up in the Messages Tab (B), indicating we are good to go for the conversions. Next we need to set the Record Flags to ESM (or Master) as shown below:
With the File Header block of Weapon Mod Kits.esp selected (A), Right –click in the open space next to the, 'Record Flags' section (C) which will render a small context Menu. Select, 'Edit' (D) from this small menu to add the ESM Master flag, which effectively converts the Plugin into a Master. Before you can proceed however, you will get a warning message from xEdit about changing the mod's contents. This is normal and provided for your protection. Simply select, 'Yes' (A) to continue.
The screenshot below shows you the Flags menu that is rendered:
This, 'Edit Value' menu shows you all of the known (and unknown) flags available for setting in a Fallout3 mod file for Record Flags. Many of the flags are known and can be selected, while a few still remain unknown. The only flag we care about is the, 'ESM' flag (A), which you should check-off and then click, 'OK' (B) to accept the new flag values.
Once done you will be presented with the outcome as shown below, which now has the Weapon Mod Kits.esp entry and its File Header in Bold text (A) in the View Tab, indicating the change. In the Right-hand View Tab (C), the Record Flag row is now also in Bold text with the new, 'ESM' flag now populated with it (B) as shown below:
Next we need to add the new Master version of Weapon Mod Kits (ESM) into the Plugin version (ESP) as a master file reference, so that the Plugin references the Master. This will allow the Plugin (ESP) to use the Master (ESM) records going forward. The screenshot below shows you the first step in the process of adding a Master reference:
Note that we're changing the File Header section just as we did when adding the ESM master flag, but this time we Right-click in the Master Files row (B), and then selecting, 'Add' from the context menu.
This will create a new, blank Master File reference in the Weapon Mod Kits Plugin that you can now assign to our new Master file as shown below (D), which we can then modify as needed. For our example we need to assign the new master file entry to Weapon Mod Kits.esp. To make the change simply Right-click in open space to the right of the, 'MAST – Filename' entry (B), which will render a small context menu. Then select, 'Edit' (C) as shown below:
Clicking Edit will open a, 'Edit Value' window, allowing you to type-in the name of the Master file you want to assign as the reference (A). Click, 'OK' when done (B) to save the reference, which will take you back to the View Tab.
You should use the same case that the master file does, in this case, 'WeaponModKits.esm' to ensure that there are no conflicts. And with that we're done! Note that the WeaponModKits.esm is listed next to the, 'MAST – Filename' entry (B), and that the File Header also has Bold text (A) indicating the change as shown below:
And for the final step, you need to save the changes. Use, 'Alt-S' or close xEdit to present the Save Files window as shown below:
With this, you now have a Master/Plugin version of Weapon Mod Kits, and the process works exactly the same for any mod that you want to split. You can change the esp file extension to ESM, then open and save it with the GECK and it will tick the ESM flag on, but won't produce ONAM's like xEdit will which are needed for any overrides to Fallout3.ESM's references. Unless your Plugin has no CELL and/or WRLD group, you're better off using xEdit.
Note: An .esp can be the master of another .esp.
Note: If you have a Plugin with multiple masters, you'll have to edit your GeckCustom.ini 'bAllowMultipleMasterLoads=1'
Note: The GECK won't edit .esm's, so you have to ESP'ify, edit in GECK, then ESM'ify.
8.9 - Comparing Two Versions of a Mod
One of the common tasks that mod authors face is to compare two versions of their own mods, either during construction or in subsequent updates. There are also times when mod authors encounter difficult to solve problems with a new version of a mod, and need to revert back to a previous backup. The xEdit compare function can provide a valuable and convenient way of copying data from one version of a mod to another, without having to sort through records that don't belong to their mods. Whatever the case may be, this section is devoted to teaching you how to compare two versions of a mod file, and how to copy records over if the need arises.
For this section we feature Quarn'sUnofficial Fallout3 Patch, which has helped to resolve countless bugs in Fallout3 and has improved the gaming experience for thousands of modders. To start the action, launch xEdit and select One of the two mod files that you wish to compare as shown below:
As shown above, by Right-clicking in open-space in the Master/Plugin selection window (A), you will render the selection menu (B) where you can, 'Select None'. This will un-check everything on the list. Then select just One of the two mods (C) and Click 'OK' to load it (D). The screenshot below shows the result:
Here we have just One of the two mod files loaded along with the Fallout3 master files it depends on. We will need to hide these master files from view so that we are Only looking at the mod file that we want to compare.
To hide the master file references from view, we need to select each one of them in-turn with a Right-mouse click (A), which will present the main context menu. There you can select, 'Hidden' (B), which is the last option on the list as shown below:
You won't see any outward-change in the in the xEdit view afterwards, but you can confirm that they are marked as hidden by Right-clicking on them again – you will see a Check-mark next to, 'Hidden' menu option indicating that they are hidden (from filters).
Next we need to load the other version of the Unofficial Fallout3 Patch mod file we're comparing (the new/current version). You can do this by Right-clicking on the loaded-version of the mod (A), which will present the main context menu. Select, 'Compare to…' from the context menu (B) as shown below:
Selecting 'Compare To' will present the, 'Open' window as shown below, where you can select the current version of Unofficial Fallout3 Patch (A), and then, 'Open' (B) to load it into xEdit as shown below:
The 'Compare To' version of the mod is loaded as read-only into xEdit, so you will not be able to make any changes to it, but you can copy from it into the version of Unofficial Fallout3 Patch that we loaded into xEdit at boot time. You can change the order and load either/any version of the mod first, so that you can edit/copy records into whatever version you loaded.
Once the Compare To function loads the other version of the mod as read-only into xEdit, you will see a view similar to the one below. Note the two versions that appear together in the Navigation Tree (A), and no errors noted in the Messages Tab (B):
With both versions of the mod now loaded with the Compare To function, the last step is to apply a Filter to find the changed records between them. Note that with the Fallout3 master files now listed as, 'Hidden', they will not show up at all after we apply the filter – which is exactly what we want.
To apply a Filter Right-click in open-space (A) in the Left-side Panel to render the main context menu. Click, 'Apply Filter' (B) to open up the Filter menu as shown below:
The main Filter window will render, where you can select the Mod Comparison Filter Settings as shown in the screenshot below:
Selecting the, 'By conflict status for this particular record' (A), 'Identical to Master' (B), 'Override without Conflict' (C) and 'Conflict status inherited by Parent' (D) sets the Mod Comparison Filters. You can then select, 'Filter' (E) to apply the filter.
The Mod Comparison Filter should process quite quickly in most cases, unless you're working with a very large mod file. The screenshot below highlights the status bar, which will tell you how far along the filter operation are towards completion:
Once done, the screenshot below illustrates the result. Both versions of the mod (at the top level) have Yellow backgrounds in the Navigation Tree (A), indicating that they are not identical (of course). In the Message Tab we see that now errors were encountered by the Filter (B), along with some statistics:
Opening one of the mods in the Navigation Tree and selecting a record highlights the similarities where they are identical between the two mods with Green backgrounds (A) and records that are different with Yellow backgrounds (B).
At this point we are done with the comparison. You can browse through the Unofficial Fallout3 Patch records between the new and old versions, and compare the differences at will. If you don't need to make changes, you can simply close xEdit when done.
If however there is a need to copy records from one version of the mod to the other, the process below will guide you through the steps. There are a few limitations to be aware of, such as you can't drag-n-drop records from the version you loaded at boot time into the version you loaded with the 'Compare To' function, but you can still copy from that version as shown below:
Here we Left-click-and-hold the record we want to copy with the mouse (A), and drag it horizontally to the mod we loaded when xEdit booted-up (B). Dropping the record into the row will copy that record (and all of its attributers) into the other mod. The screenshot below shows the results, with both sides now identical (A) and the background of both now Green (B) indicating they are indeed duplicates:
The screenshot below illustrates how xEdit will prevent you from drag-n-dropping records from the loaded version of Unofficial Fallout3 Patch into the 'Compare To' version (which is loaded read-only). Note how when trying the drag-n-drop, you get a blocked-circle (B), indicating that you can't drop records into the read-only version:
When you're done making changes, you'll need to save them. You can either close xEdit or press, 'Alt-S' to render the Save Changed Files window:
With that, we're done with mod comparisons and updates! Of course you should not change the Unofficial Fallout3 Patch as that is for Quarn to do, but there is no harm in experimenting with the mods to learn the process (just make sure to have a backup of the files before you do!).
8.10 - The ESL Flag
8.10.1 - Important dangers when compacting FormIDs
8.10.1.1 - First Important danger when compacting FormIDs
Before you consider compacting a file whether or not you are a mod author or user understand compacting a mod changes the FormIDs. Once the FormIDs have changed that is the same as uninstalling the mod. Making certain changes may not affect anything while other changes will have a serious impact on the game and your save game.
The range of FormIDs is limited for ESL flagged files. Since there isn't much to work with as the FormIDs are renumbered you should consider this. They are renumbered sequentially. Once the process finishes you could end up with a FormID that is the same as the previous version, but the record is an entirely different record type then it was previously. Which may not just cause issues but render the save game unusable because of the changes unless you revert back to the version of the mod prior to compacting it.
The bottom portion is blurred out because it is part of a 2 part question. The first being the effect and support of uninstalling a mod and the second the effect of changing a script and continuing to use the same save game. Smkviper is a Bethesda employee and Papyrus specialist for Bethesda having written in part of fully written the Papyrus engine.
While many people do uninstall mods and continue with a save game and it usually works fine, once you do, no matter what happens, any further testing is invalid and before reporting any issue to any mod author you should make a new save game. Period.
8.10.1.2 - Second important danger when compacting FormIDs
Patches to the mod will no longer be compatible because the FormID changed. It is not good modding practice to change FormIDs and then require other mod authors to create new patches. This is inconvenient for both mod authors and mod users. Example 2 below shows how a FormID that would not qualify for an ESL flagged file changes. This is what would happen for patches. Once the FormID is renumbered the patch can not find the old FormID anymore.
8.10.1.3 - Third Important danger when compacting FormIDs
You should not compact FormIDs if the mod uses GetFormFromFile(). The script will not be able to find the Form used by the mod author when he created the script. Below is an example from GetFormFromFile - Game in the CK Wiki. This is another example of how a FormID that does not qualify for an ESL flagged file could be renumbered as shown in Example 2 and cause the script to malfunction.
In the above example 0400ABCD would not qualify to be in a file with the ESL flag. It would be renumbered and would be given the next available number in sequence as mentioned. For example it could be changed from 0400ABCD to [FE:004][005].
Sometimes mods use Bethesda Archive Files or .bsa or .ba2 files. Some mod authors do not provide the source for their scripts. To look for the GetFormFromFile() function you will need to extract the script files and if the source is not provided you will need to decompile the .pex files first.
This is not practical for users to look for in a mod. There are no utilities that will automatically look at the plugin, search for all the scripts used, and then go through a process of finding this function for the user and warning them of the dangers of compacting the file.
8.10.2 - When it is safe or not safe to add the ESL Flag
8.10.3 - Adding the ESL flag
• When an ESL flagged file also has the ESM flag and contains a new CELL or WRLD record, any mod (patch or otherwise) also altering the new CELL or WRLD record can cause items to disappear.
• Any file with the .esl extension will have the ESM flag forced at runtime. Files with the .esl extension will also have the same issue with CELL or WRLD records as mentioned previously.
• Compacting a mod and adding the ESL flag that has not been released to the public is safe.
• Compacting a mod and adding the ESL flag that has already been released to the public is not safe because compacting changes the FormIDs. Refer to Important dangers when compacting FormIDs.
• After compacting a mod with NPCs you will need to generate the FaceGen data for the NPCs with the Creation Kit because the FormIDs changed.
• After compacting a mod with custom voiced actors or NPCs, you will need to rename the Voice files because the FormIDs changed. Remember the file name for voice files is not contained in the plugin. You have to know what it is already or make a blank empty file with the CK in order to see what the CK will name it. After you know the name the CK has chosen then you can rename the voice files accordingly.
• For mods that use xEdit or zEdit scripts. Adding the ESL flag to mod files you will be processing with xEdit type scripts can impact how the script works. You should process the files without the ESL flag. You should be able add the ESL flag after the process completes. If you are required to run any xEdit type scripts each time you add or remove files in the Data folder this can impact how the script functions. You may need to remove the flag and add the flag prior to and after running the script which could be tedious.
The issue having both the ESM and ESL falg (or .esl extension) and CELL or WRLD records does not seem to affect Fallout 4. There is no word on whether or not this will be addressed by Bethesda for Skyrim SE.
8.10.4 - Adding the ESL flag for mod users
• Normally adding the ESL flag to simple weapon or armor mods is safe because they usually do not have patches and are not masters of other files.
• Adding the ESL flag to patches is safe because the patch only affects its masters.
• Adding the ESL flag to a mod that has a patch should not matter unless you compacted the FormIDs. If you did refer to Important dangers when compacting FormIDs.
• When adding a new mod to your load order and if you review Important dangers when compacting FormIDs first prior to compacting FormIDs then you should be able to compact the mod and add the ESL flag.
Adding an ESL flag to any .esp file that qualifies to have the flag is not safe to do when you do not know how that will affect the mod. There is no list of mods safe to flag and it is not appropriate to constantly ask mod authors whether or not it is safe to add the ESL flag to their mod. If you read through the section Adding the ESL flag and do not understand what any of that means then you should be cautious of adding the ESL flag to your mods.
If you feel you must add the ESL flag and have no other resources telling you whether or not it is safe then it is recommended to flag one file at a time and test it in game. If the mod malfunctions then you can remove the flag and revert to a previous save game.
8.11 - How ESL enabled games handle FormIDs for ESL flagged files
You might have already noticed FormIDs in some tutorial (for example removing cities from JKs Skyrim), while getting items via console cheat (player.additem) or somewhere else but dont know what they actually are. Heres one example:
The interesting part is on the far right side: Base Form and Ref Form.
Lets stick with the tree that Ive marked in the screenshot for a moment. The Base Form (00051126) is an entry in Skyrim.esm and stands for TreePineForest05. It doesnt say anything about where the tree is located, about the size of the tree, its rotation or anything else. The entry in Skyrim.esm just defines a few basic parameters of that tree type like the type of the entry (TREE) and where the 3D model of that tree is located in the meshes folder of the game (LandscapeTreesTreePineForest05.nif).
Now, if you got a mod (or the vanilla game) that places this kind of tree somewhere in the game world, that specific tree (like the one that is clipping through the floor in my screenshot) gets a Ref Form, which in this example is 0D00517E. For this you can define its position in the world, its size, its rotation and lots of other properties. The Ref Form is the FormID well be looking at. It can be divided into two parts:
[0D] [00517E]
The first part might look familiar for anyone using Mod Organizer 2 or any other mod manager that shows the load order of plugins like MO2 does. It defines where in the load order a mod is located using a two digits hexadecimal number. The mod with the lowest number gets loaded first, the higher ones are loaded later and overwrite the earlier ones. Your typical load order would look like this:
As hexadecimal digits go from 0 to F (F stands for 15) and as we got two digits, the largest number you can put together is FF = 255, just like the largest number for the decimal system would be 99. This is where Skyrims theoretical plugin limit of 255 comes from. Its actually a bit less than that but that shouldnt bother us here. This limit is what forces people to stop adding mods to their game or start merging them which gets trickier the more mods you want to add.
8.11.1 - How ESL enabled games address records within plugins
Now, what about the other six digits?
Those are used as addresses for entries (records) within plugins. The tree from the screenshot got 00517E, another tree might have 00517F, some NPC added by the same mod could have 077F20 and so on. These addresses within plugins are hexadecimal too, so the last address and highest amount of objects in one plugin would be FFFFFF, which is 16,777,215 in decimal. This means that a mod author could theoretically stuff over 16 million things (TREEs, NPCs, BOOKs, ACTIvators,...) into one single esp file. More than that isnt possible as we would be running out of addresses again but who needs that many objects within one plugin anyway.
8.11.2 - The ESL address format
So, were maniacs who already added as many mods as possible to our game and already start to get Too many plugins errors from various tools and the game itself. But, of course, theres at least twenty more immersion mods out there that NEED to be added to our mod list. And then theres those 50 patches for all our mods we forgot to install earlier.
In the past this would have been the point where we would have fired up the (undoubtedly cool) tool MergePlugins and trial-and-error our way through our modlist in order to combine as many mods as possible, just so we stay below the magical FF/255 mark. But now theres an alternative. Skyrim Special Edition does not only understand master files (those .ESM files from the main game and large mods) and regular ESP plugins (any other mod) that all count towards that 256 plugins limit but also ESL files (I believe the Creation Club mods come with these) and ESP files with the so called ESL flag. And while pure ESL files suck as theyre always loaded first and cant really be sorted, those ESP files with the ESL flags are gold and exactly what we need. They behave just like regular ESP plugins and even look the same from outside but theyre not loaded in a regular load order spot like [A4] or [0D] but theyre all squished into the [FE] spot, which now is a whole new address space by itself.
[FE:0A8]
This is what the load order address of an ESL flagged plugin looks like. And this is what a bunch of ESL flagged plugins in your load order would look like:
Wait, what? Mod 4011?
As [FE:FFF] would be the highest address for an ESL flagged plugin and as the FE-part always stays the same as thats the position of the whole bunch of ESL flagged plugins in the regular load order, FFF is the maximum amount of plugins we can have in this address space. And thats a whopping 4096 of them!
This effectively means we're not limited to 256 plugins anymore but to 254 (as the FE-slot is blocked) plus 4096 = 4351 plugins!
8.11.3 - The Downside
As you might have guessed there has to be a downside. And of course you are right. As the address of the plugin itself in the load order now takes up five instead of just two digits, theres less digits left to address stuff within the plugin. Instead of six digits (000000-FFFFFF = over 16 million) for records we can use for NPCs, TREEs and other things inside our plugin we only got three digits (000-FFF = 4096) left. This gets clear when we compare them side to side:
At a first glance this doesnt seam too bad as 4096 is still a large amount of records within a plugin. But theres a few problems that might be in the way. Let me demonstrate with three examples:
8.11.3.1 - Example 1
The hypothetical plugin in position [A4] we want to flag as ESL has three records 000001, 000002 and 000003.
A plugin like that can be easily flagged as ESL as theres less than 4096 records and the records would still fit well into the ESL address space. There would be no issues and apart from setting the flag nothing else would have to be done. The result would look like this:
As the addresses within the plugin would not change, any patches or addons with that plugin as a master would still find the records inside theyre trying to reference to. In case you're wondering if the game notices the missing zeros, it does not. Leading zeros are ignored. You can test this by setting the weather via the ingame console with fw 0010a243 and with fw 10a243. The result will be the same.
8.11.3.2 - Example 2
The hypothetical plugin in position [A4] we want to flag as ESL got three records: 000001, 000002 and 0FA322
A plugin like that cannot be flagged as ESL just like that. The records 000001 and 000002 would be fine just like in Example 1 but 0FA322 does not fit into the three digits address space of an ESL flagged ESP. The consequence of this: we need to compact the plugin to be able to fit in all its records. Theres a feature in xEdit that does just that. If we did that, the following would happen:
See More Results
Again resulting in
Mod Organizer 2 Merge Plugins Hide
Now all records fit into the three digits and the ESL flag would be set. You can do this to small patches and other uncomplicated mods that got no patches or addons themselves. Once such a compacted plugin got another plugin thats referencing to it we got a problem tho. Something in the other plugin could try to reference to 0FA322 but it would not find anything at that address anymore as that record was changed to 003. This could lead to various annoyances or even crashes. In the end, we would have to manually edit the patch/addon and change all entries of 0FA322 inside them to 003. Which would be really annoying as even small plugins not only got 3 records but dozens or hundreds of them. Still, if we know exactly that a plugin got no patches or addons that rely on it, compacting is still a viable way.
8.11.4 - Example 3
The hypothetical plugin in position [A4] we want to flag as ESL got more than 4096 records. This is usually the case for quest mods, large player homes and compilations like Immersive Armors. As our address space within an ESL flagged plugin is limited to 4096 entries we simply cannot set the flag or compact the plugin. Bad luck.
8.11.4.1 - ESLifying plugins
Now, what do we have to do to make use of ESL flags? First, we should ESLify all plugins that can be flagged without any further changes. For this we will need xEdit, just get the latest version from github. With xEdit there is an easy way to scan your load order for plugins that are small enough and dont need to be changed in order to get the ESL flag.
8.11.4.2 - ESLifying Plugins the easy way
This can be done for all plugins that are like in our Example 1 above. Youll need to start xEdit with the arguments -PseudoESL and -autoload. PseudoESL will display all flaggable plugins, no matter if they already got the flag or not, with [FE:XXX] load order numbers. This will be useful in a minute. Autoload skips the initial dialogue where xEdit asks you which plugins to load.
In Mod Organizer 2 you would go to the executables menu (the gear icon top left) and add SSEEdit.exe as a new executable like displayed on the left hand side. In Vortex it would look like on the right side.
Now start xEdit with those arguments. For MO2 this works by starting QuickESLCheck from the dropdown menu, in the Vortex example it would be named SSEEdit-eslcheck but its really up to you how you name the link. After loading has finished were presented with our load order. We will now see three types of plugins:
• Plugins like CFTO-Lanterns.esp arent interesting to us as -PseudoESL didnt give them a [FE:XXX] load order number. This means they cant be just flagged as ESL.
• Plugins like JKs Windhelm Relighting Skyrim Patch.esp got an [FE:XXX] load order number but they also got the <ESL> tag. This means theyre already flagged as ESL.
• Plugins like Higher Bounty Rewards are what we need. They got the [FE:XXX] load order number thanks to -PseudoESL but dont have the actual ESL flag yet.
We will change that. Click on Higher Bounty Rewards.esp (or whatever plugins like that show up for you). On the right side of xEdit you will now see some properties of that plugin like the Form Version, Version and Author. What were looking for is the Record Flag line. The one of Higher Bounty Rewards is currently empty. Right click the empty space and choose Edit. xEdit will present you with a couple of record flags you can set. Of course we will choose the ESL flag and hit OK.
You can now do this to all plugins that got [FE:XXX] load order numbers but no <ESL> flag yet. If you got a large mod list already type [FE into the search bar at the bottom to hide all the regular non flaggable plugins like [86] CFTO-Lanterns.esp, then you will just need to look for lines without the <ESL> flag.
Once you are done simply close xEdit. It will show a window with all plugins you have changed. Make sure all of them are checked and hit OK.
Thats really it, theres nothing more to it.
I re-do this check once in a while after adding a bunch of new mods to keep my modlist as ESLified as possible.
8.11.5 - Compacting plugins
Since the functionality to compact FormIDs is available from xEdit the process will be shown. However, it is not recommended for end users that are unaware of the dangers of compacting FormIDs. For more information see Important dangers when compacting FormIDs
Once you have flagged all possible plugins with the easy method above you should be fine for a while. At some point if you run into Skyrims plugin limit again, what you can do is a bit more dangerous so really think about the plugins you do this to. Again review Important dangers when compacting FormIDs.
Start xEdit the regular way, right click any plugin and choose Compact FormIDs for ESL. Now three things can happen:
• If you try to do this to a plugin that already got the ESL flag the option wont even show up
• If you try to do this to a plugin too large to be flagged as ESL youll get an error saying The file contains too many new records for this operation and nothing happens
• If you try to do this to a plugin with few enough records you will get a warning
If you get this you have found a plugin that can be compacted. The first line just tells you how many records will be changed. However, you should pay close attention to the second line of that warning. This tells you what kind of records will be changed and thats really important as some kinds of records will somehow break if you try to compact them. According to ElminsterAU you should really avoid compacting plugins when one of the following record types would be touched:
• INFO
• NPC_
If that is not the case for your plugin make sure the file you are compacting is not a master of other modules. Because after compacting the plugin the FormIDs will have changed and other modules that depend on this file as a master will not find the records they are looking for anymore.
If you are sure about everything hit yes. xEdit will compact the plugin and lists all changes in the right side of the window, looking like this:
Now, if you are really thorough you could write down all the changes that have been made. Then you could compact plugins that are reference the module as a master. You could also check all patches for the plugin and update the FormIDs like 00B868 in the above example to what they were changed to during the compacting process. If you are diligent and knowledgeable enough you could compact any plugin that qualifies and save even more space in your load order.
Every update to the compacted plugin or plugins related to it will break everything for your current save game.
8.12 - Credits
• elwaps, for creating the additional information about .esl files