Tes4Mod:Plugin Merging

FYI: This merging has nothing to do with Bash-mergeable plugins...

Intro
Why merge? First of all, some people want to use more than 255 plugins or 400 plugins and BSAs. For others, fewer plugins is neater and better all around. Regardless of the reason, merging is a practice that requires care and attention. Maintaining patches is like maintaining a load order, but, once created, a merged plugin should not be updated as frequently. If it is being updated frequently, it is time to find a different group of mods to merge.

Caution!!!

A few things of which you should be aware...

Patches for mods are name-dependent.  If formIDs were preserved in the merge, the patch's dependency can be changed from "mod XXX.esp" to the name of the merge containing "mod XXX.esp."  However, formIDs are often not preserved that well and patching done by scripts (dynamic patching) does not allow for that name changing.  This is another reason why it is usually not advisable to merge quest mods (i.e., the Lost Spires or Gates to Aesgaard.)  Double-check the mods you are merging to see if other mods are "looking out for them" before creating the merged plugin.  This is also, yet another, reason not to merge the Unique Landscapes mods.
Merging mods with multiple masters is sometimes a little more complicated that just sorting the masters after merging with TES4Gecko.  When the merged plugin is originally created with the out of order information, some references may be messed up.  Make sure to check out records with dependencies with TES4View after making these types of merges.
Voice files are also name-dependent.  For example, if you merge all of the unofficial official mod patches together, including USIP, you need to change the "Unofficial Shivering Isles Patch.esp" folder in the Sound\Voice folder (Data\Sound\Voice\) to " ."
Use TES4Gecko if merging patches for mods with different voice files.  TES4Gecko would rename all of the sound files to match the name of the merged plugin, which would not correspond to any files in the data folder.
I typically try to keep merged plugins categorized to a specific load order group.
Example issue: and that would be script conflicts with Adonnay's weapon mods.  You need to first go into TES4Edit and append an X or some other distinguishing suffix to the editor IDs of overlapping scripts in one of the plugins.  It does not matter which one you choose.  Otherwise, when TES4Gecko prompts you to change names to resolve conflicts for issues other than scripts or cells, saying yes is normally okay.

Merging Preparations

Tools

The utilities used for merging mods are TES4Gecko, TESSnip and TES4Edit. Wrye Bash and TESCS can be helpful as well, when extra tweaking is needed to smooth out the merging process.

Deciding what to merge...

In order to avoid load order issues, merge groups of similar mods together. They are usually in the same place in a correct load order. If you see a mod is not in the usual area, check the merged mod out with TES4View to see if it can be safely loaded in the position of the latest loading mod that was merged into it. Otherwise, make to merges or leave the odd-ball out of the merged plugin. The simplest and safest types of merges are merging hotfixes or simple additions into the original mods. Common examples are merging each of the Unofficial Official Mod Patches' plugins into their respective mods and merging Enhanced Water - SI into Enhanced Water. One common aspect of these patch merges are that these patches are loaded immediately after their dependent mods. They do not handle mod compatibility. Merging other types of patches is more complicated, and often advised against.

Don't Merge

things that do modify many cells or world spaces (i.e., ULs)
mods where doing a clean save would result in unwanted loss of progress (i.e., quest mods or item mods with quests to gain the items)
mods that are updated frequently (i.e., Reneer's Guard Overhaul)
mods with conflicting scripts (i.e., some pose mods)
mods with conflicting cell edits (i.e, some quest mods and landscape mods)
mods that are patched for compatibility with other mods (i.e., ThisMod+AnotherMod patches)

What's left...

game tweaks (i.e., hotkey mods)
graphical enhancements (i.e., face overrides, loading screens, retextures)
weather mods
Bash mergeable patches
mod optional add-ons (i.e., Supreme Magicka add-ons)
new item|weapon|clothes|armor mods that don't have item quests
patches for same mod or mod groups (i.e., Unofficial Official Mod Patches)

Merging with TES4Gecko

TES4Gecko automates 99% of the merging process. For most merges, it automates 100% of the process. It just has a little trouble with script conflicts, but merging mods with scripts can take quite a bit of work even merging manually. Therefore, it usually not recommended to merge mods with overlapping scripts. If the group of mods being merged do not conflict, it does not matter which numbers are put in the merge priority boxes on the left of the merging dialog (so long as the numbers are not the same.) However, if a mod needs to override another mod, the overriding mod should be given a higher number. As your load order should already be correct according to BOSS and your personal tweaks, most of the time numbers should correspond to the load order (which is how the plugins are listed in the merging dialog.)

Certain types of merges, such as new item merges, are probably updated with new mods more often than others. For these, it may be a good idea to create part merges. Make two or more part merges, where one contains mods that you are unlikely to remove and probably will not be updated. The other part merges will be those that get destroyed and recreated all of the time. When merging all of the parts together, always merged the "final" part merge with lower priority so that the formIDs for the records in the part merge are always preserve. This is a work-around for quest mods and item mods with quests. When you do a clean save, load the "final" part merge in the position at which the big merge was located. None of the information for the "final" part merge is lost because the IDs are the same in both the part merge and the big merge.

In the same manner as using "final" part merges, re-merging plugins in the exact same order also retains formIDs. However, if you have merged mods 1, 2 and 3, and 2 is updated. Re-merging mods 1, 2 and 3 could then have different IDs for some items in 2 or 3. 1's records still have the same IDs, and that is the idea behind part merges. In the same way, adding mod 4 on top of the merge of mods 1, 2 and 3 (resulting in merge 1, 2, 3, 4) does not change the IDs of the records of mods 1, 2 and 3 in the final merge. Merging the 1,2,3 merge onto mod 4, giving 4 a lower priority number, would not preserve any IDs.

Even if you don't keep an ordered list of every mod merged into each plugin, at least put which mods were merged into each plugin in the merge's description.

Using the Other Utilities

Checking Gecko's work

# Rename "Merged Plugin" something useful (i.e., "Merge - XXX.esp" or "Patch - XXX.esp")
# Open up the BOSS masterlist.txt file and add the merge's name in the right position (often the position of the latest loading merged mod)
# Run BOSS again
# Launch TES4Edit, check the merge's actual contents and clean it. (It is better if the plugins are clean before they were merged.)
# Launch TES4View (faster), check the plugin thoroughly for conflicts, making sure it is loaded in the correct position.

TES4Edit merging

# If mods have conflicting editorIDs, formIDs, change the necessary formIDs and update dependent records.
# Select all wanted records and use copy as new records into...(a new plugin that will become the final merged plugin.)

Recompile scripts (post Gecko merging) with TESCS:

# Launch TESCS
# Click on the scripts (Gameplay > Edit Scripts...) option
# Find the scripts that need recompiling. (Look in the merged plugin with TESCS.)
# Save them in TESCS' script editing dialog.
# Save and exit.

Merging Plugins with Masters

It is common to not micromanage your plugin merging process, launch Wrye Bash, and find that the merged plugin has an orange check box, indicating that its masters are not sorted properly. Unless the plugins were merged such that their dependencies were added to the merged plugin in accordance with the load order, this is the result. However, the fix is quick.

# Make sure your load order is sorted properly. (Otherwise, you may have to redo the following steps.)
# Launch TES4Edit
# Check the merged plugin. (There is no need to check anything else as TES4Edit will load any other required plugins.)
# Right-click on the plugin.
# Choose 'Sort masters' from the context menu.
# Exit and save the edited plugin.

See Also
TES4Gecko
TES4Edit
The Elder Scrolls Construction Set
Wrye Bash

External Links
A Guide to Merging with TES4Gecko - BethSoft Mods Forum
How Do I Merge Mods? - BethSoft Mods Forum <-- contains additional info about more specific merging topics
Merging Mods with INI Files - BethSoft Mods Forum <-- should be named "Merging delayer patches onto quests"
Merging Mods with TES4Gecko @TESNexus
Quick Q about which plugins can be merged with TES4Gecko - BethSoft Mods Forum