Multiple file Merge-Up Procedure

Overview

Merging three mods with dependents at once as "the next step" in complexity of "merging-up" after non-conflicting mods: Multiple file Merge-Up into a single plugin. The article builds upon the lessons of the article "Merged Plugin Guidelines for Personal Use".

Again, note that this is focused upon merging for personal use and not redistribution. The technique applies to any game, even though "Fallout New Vegas" (FNV) mods are used for the example.

CAUTION: This is a painstaking process. Details matter. Sometimes different terms are used to refer to the same plugin file. The choice of term is based upon which provides the most clarity in that context. If you are feeling the least bit uncertain or confused, stop, take a deep breath, and review the context and terminology. This procedure is not tolerant of mistakes. The basic procedure is fairly straightforward. The examples provide more specific information illustrating (by way of the figures) some of the complexity involved in the application of that basic procedure. They are lengthy due to trying to anticipate and point out common mistakes before you commit them. Including the "candidate selection" step, the entire procedure can take several hours.

For reference: ModA is the earlier (lower numbered) plugin in the load order, and ModB is the later (higher numbered) plugin which will be merged "up" into ModA using the general xEdit tool (renamed as "FNVEdit" for FNV). This follows the convention used in "Merging Mods with FNVEdit.pdf" (MUG) by Gribbleshnibit8. ModA will also be referred to as the 'parent plugin' or 'merged plugin' file.

First we will merge patches (but not "compatibility patches") to the individual parent (ModA) plugins for the main three mod plugins, then merge the newly "combined with patches" parent plugins into a single "plugin" file of all three combined mods (similar to a compatibility patch but actually a new master file replacing multiple other master files). A plugin can have many 'masters', but when merging there is only one 'parent plugin' at a time.

The general procedure will be presented first, followed by detailed examples with each 'parent plugin' as a separate "stage", and the final combining of all three parents into a single "merged plugin" as the fourth "stage".

Here we rely solely upon the "merge up" technique as laid out in the xEdit manual, and Gribbleshnibit8's "Merge Up Guide (MUG)". (See Programs and Tools for links.) This is because "renumbering of FormID's" always needs to be done when records are unique, except you do this by injection into the 'parent plugin' that is the object of your merge. Overrides are never renumbered, unless they are in plugins loaded after the parent plugin, and are overrides of unique records which are being injected. "Merging up" preserves and conforms to the FormID numbering in the parent, whereas "merging down" does not preserve the parent's numbering but instead conforms to that of the last plugin in the merge list, potentially breaking anything relying upon that parent numbering, especially in the case of "patches". This is the reason Mator's "Merge Plugin Standalone" tool does not process "patches".

Note that a "merge plugin" reduces the number of plugins that remain active in the "load order". It resolves any conflicts within ModB plugins merged up into it to only one "winner" record in the ModA 'parent' plugin, which makes it now the sole "winning" plugin.

A "merge patch", like a "bash patch", resolves record level conflicts (i.e. "compatibility patches") between multiple 'parent' plugins. It does not (in general) reduce the number of active plugins. It resolves conflicts between plugins where they "overlap". Only in the instance where the resolution results in all of the records of a plugin being incorporated into the "merge/bash patch", does it reduce the number of plugins that must remain active.

There is generally only one "merge/bash patch" file placed at the end of the "load order", though there can be one of each. In this latter instance the manually created "merge patch" is properly called an "override patch" and is placed after the automated "bash patch" in order to override the "bash patch" winning records with your preferences. (The same basic process applies. However, the merge "winning record" is selected among the conflicting plugins and NOT the "bash patch" file itself.)

Programs and Tools

• xEdit (aka TES5Edit and various renamed specific game version names) on GitHub.
• TES5Edit on Nexus.

• Tome of xEdit On-line Documentation.
• FNVEdit Training Manual PDF document (applicable to all games).

• Gribbleshnibit8's Merge Up Guide (MUG)

Details

For the purposes of keeping ESP names clear as to which are the original and which the "merged up" versions, we will call the first resulting "new version" of ModA as the 'merged plugin' or 'patched parent plugin', saved with the original filename. That is the file to be used in the load order, replacing the original ModA plugin, and as 'parent' for subsequent merges to the same parent. Changing the 'merged plugin' filename would cause the "missing content" message when you load a "saved Game" with the loss of items from that plugin from "actor" (Player and NPC) inventory.

Be sure you have the original of the 'parent plugin' backed up somewhere so you can start over if anything goes wrong.

With many plugins, it is highly unlikely we will get everything done in one session. This is often the case when you have to break the process down into more manageable tasks, so it becomes essential you document as you progress from the beginning. Then you will be able to tell what has been accomplished when you have to stop, and what remains when you resume. This should form the foundation of your personal project "ReadMe" document, kept in a "project" folder for when you package the result to keep it separate from the originals.

A "project" is simply a folder (to be turned into an archive file when finished) named so you recognize that it is a "customized" version of a distributed mod, or your own original mod. A consistent naming pattern will make it easier to locate such projects. As an example, I name my "merged plugin" projects "Merge - <mod name>" (i.e. "Merge - WeaponsModExpanded" or "Merge - EVE-WMX-IMPACT"), but anything will do. Bear in mind that the folder name does not have to match the plugin name, but it is usually easier to create the archive if the folder name matches what you want the mod archive to be named. The project folder can be placed anywhere convenient, including among your "downloaded mods" location. The finished archive file should be placed with all your other mod files so it will be recognized for installation and activation by your mod manager. At that time you should move the mods that were merged into your project elsewhere to avoid confusion, unless you need them to provide their asset files.

Preparation

This phase includes Candidate Selection Strategy, which will be one of the most important and time consuming portions of the process. Proper selection of files to be merged and those dependent upon them will prevent failed or poorly made merge files. This is best explained with specific plugins in the Example section.

• Individual plugins should each be separately loaded into xEdit and the "file header" record examined to determine all 'master file(s)' each plugin is dependent upon. 'Master files' need to load prior to each of their dependent plugins, and then need to be included in the list of "candidate files". In general the sorted load order should already have established the correct order for these files, but they need to be examined in xEdit to find any Missing Masters.

• If you have any ModB plugins that affect any of the ModA plugins you intend to merge in this project already in other "merged plugin" files, you need to deactivate the "merged plugin" and restore the individual plugins that had been merged and re-activate them. (Don't forget to sort your "load order" after.) They will need to be loaded in order for their FormIDs to be updated along with the other plugins. This is particularly true of plugins that indirectly reference records, like "Recipe" compatibility files. You will then need to rebuild the "merged plugin" files for them to function correctly.

• Once you have determined the 'masters' for the candidate files, you now need to determine if there are any 'dependents' (plugins that have the candidate file as a 'master'). If the candidate has dependents, then under the "Keep It Simple Stupid" (K-I-S-S) principle it should be excluded from the "merge plugin" list for later inclusion into your "merged/bashed patch" file. However, you will still need to load the dependent plugins so their 'master' (and possibly other) records get updated to reflect your new 'parent plugin' and the final 'merged plugin'.

• The easy way to determine dependencies is to deactivate the candidate plugin and see which others your mod manager also deactivates at the same time. These are that plugin's 'dependents'.
• The alternative method is to load all the remaining "active" plugins into xEdit at once and see which report 'missing masters'. Those missing the deactivated candidate plugin are it's 'dependents'.
• Repeat this "check for dependents" process for each candidate file. It is recommended to record these 'masters' and 'dependents' for reference later on; perhaps in your Project "ReadMe" file. See the sub-topic Overall Project Candidate List for an example of one way to record this information.

• Failure to perform these preparation steps can result in the loss of hours of work.

Multi-file Merge Up Procedure

Step 1. Load ModA related plugins.

• Load the target ModA 'parent plugin', and all the ModB plugins related to it (even those you do not intend to merge), into xEdit.
• Go up to and <Right-Click> on the "FormID" column header, select the right pointing arrow after "Files", and make sure "always by load order" is selected. (If this capability is not available, it means you are not using the latest version of xEdit.)

• <Right-Click> in any open, unused space in the left-hand pane and select "Remove Filter" from the displayed "Context Menu". This ensures nothing is being filtered out of our view.

Each and every plugin that will be merged directly into the parent will all be done at the same time and not in steps.

• Note that xEdit assigns it's own relative two-character hexadecimal "mod index" to the plugins it loads. All records shown will begin with one of these relative mod indexes (which appear to the left of each plugin name in [square brackets]). When referring to unique records in a plugin, we mean one which has the same "mod index" as that plugin (regardless of background color), and not the index of any other mod.

Step 2. Add 'Masters'.

Add any masters before ModA to ModA if missing.

• Add all the masters that are loading before each ModB plugin to each ModB plugin, EXCEPT any other ModB plugins themselves (as they will be dropped later once they have been merged). Especially add the ModA plugin as master to all the ModB plugins. This includes adding to related ModB plugins that are NOT going to be merged, so any references will be updated when FormIDs are changed. (If they aren't actually needed such added masters will get removed later when we "clean masters".)
• Sort the masters in each plugin after adding.

MfMUP Fig. 1-2n3

• Save all the plugins that had 'masters' added to them (by enabling/selecting the checkbox for each in the 'target' window that pops-up when you attempt to close xEdit).

(See Fig. 1-2n3. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

• Reload all plugins from Step 1, and check the added 'masters' are in each plugin's "File Header" before proceeding to Step 3.

The 'Add Masters' selection window should come up empty if all is correct, allowing you to 'cancel' it by clicking on the "x" icon in the upper right-corner of the pop-up window. Otherwise, add the 'masters' indicated, and repeat this step when all have been checked this pass.

Failure to perform this step can result in the loss of hours of work in the last step.

Step 3. Select ModB.

Select the first loading unmerged plugin (other than the 'parent') to be the first/next to be merged, and expand it so you can see the record types.

MfMUP Fig. 1-4

(Record types vary by plugin.)

• This is the order used to inject unique records for each of the "ModB" plugins (one at a time) to be merged, broken down into 11 sub-steps by record type:

1. All forms which are not record type: CELL, Worldspace, Dialogue, Script or Quest.
   • All record types to be selected in one plugin can be expanded and done at once, but if there are too many to fit on the screen, you may find it easier to break the step up into batches of record types for selection. Just remember to process them all in the record type sequence given, and inject them all at one time for each plugin to ensure they each receive a unique form number. Refer to the FNVEdit Training Manual section on "Merging a Plugin into another Plugin or Master" or "Gribbleshnibit8's Merge Up Guide (MUG)" if you have any questions.
   • You want to select all of these unique records (use <Shift+Click> and <Ctrl+Click>) before you:

   • review your selections to make sure you didn't accidentally skip/miss some and verify only unique records are selected,
   • renumber by right clicking on one of the selected records and selecting "Change FormID" from the "Context Menu", then
   • selecting the main 'parent plugin' (ModA) as the target file when the list of plugins appears.

   This will "inject" all the selected records into the "ModA" plugin. The consequence is the parent index number of the FormIDs for those unique records will be changed to that of ModA's index. (Any resulting duplicate FormIDs will automatically be adjusted.)

   • If selecting only one record to be renumbered, you will need to note the last "Changing FormID [<number>] in file <filename> to [<new number>]" message in the "Messages" tab of xEdit, add one to the "<new number>" in hexadecimal, and place that value in the "New FormID" prompt manually. ("<Ctrl+I>" Saves the FormID of the highlighted record to the clipboard.) The "starting value" given is not correct otherwise. This is only required when renumbering single records.

   xEdit may now prompt you with a message "There are overrides in later plugins, do you want to update them?" You should choose Yes to this and it will automatically fix them for your merged plugin. This function was added to xEdit for this very purpose. (Thank you Zilav).

   (You may find it necessary to scroll up and down the left-hand pane before all the updated FormIDs are displayed correctly in Bold Italics.)

   • Examine the "Messages" tab in the right-hand pane of xEDit for any errors.
   • Now process the remaining unique (white-background) form record types (following as sub-steps 2-11) in the same manner. It's important to process each record type separately so the FormIDs are updated properly.
2. CELL Persistent records (Expand "Cell" | < Block # > | < Sub-Block # > | < record # > | "Persistent")
3. CELL Temporary records (Expand "Cell" | < Block # > | < Sub-Block # > | < record # > | "Temporary")
4. CELL Parent Records (if unique) (Expand "Cell" | < Block # > | < Sub-Block # > | < record # > on "white-background")
5. Worldspace Persistent records
6. Worldspace Temporary records
7. Worldspace Parent Records (if unique)
8. Scripts
9. Quests
10. Dialogue Responses
11. Dialogue Top Level topics (if unique)
    • Examine the "Messages" tab in the right-hand pane of xEdit for any errors.
12. You want to collapse all record types for the plugin by "<Left+Click>" on the "-" sign to the left of the plugin name, and then "<Alt+Left+Click>" on the "+" sign that replaces it to expand them ALL again. (Recall that collapsed record types don't get copied.) When we are finished injecting all unique records, there should not be any records that do not begin with a mod index other than 00-05 or that of our "ModA" plugin. Anything else in an earlier loading "ModB" plugin should have already been injected and updated in this plugin. (If there are any, they will cause Step 6 to fail and you have to cancel the session: uncheck all plugins and "<Left+Click>" the "X" in the upper right corner of the "save changes" window to exit without saving, and restart Step 4 over. Take the time to check now.)

Step 5. Inject All ModB Records.

• Repeat steps 3 and 4 for all 11 sub-step record types of Step-4 for ALL the other loaded ModB plugins you intend to merge, working your way down from lowest numbered (earliest loading) to highest numbered (latest loading) in load order.

Examine the "Messages" tab in the right-hand pane of xEdit for any errors.

MfMUP Fig. 1-6

• Expand any record types in any of the ModB plugins that haven't been (i.e. collapse each plugin file and then <Alt+click> the "+" to the left to expand everything if not sure), and select all sub-records from the first ModB to the bottom of the other merged plugins loading after it (this will ignore/de-select the "File Header" records). This time records of all background colors should be included (white, green, yellow, and red). Place the cursor over any 'unique' sub-record, right-click and select "copy as override" into ModA; or to "<new file>" if you intend this to be a new merged plugin file with ModA as it's master. If you don't merge into ModA, then ModA's records are not included in the result.
  

  MfMUP Fig. 1-6a

(See Figs. 1-6 & 1-6a. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

• Note you have to select "sub-records", under the first "record type" level. This will cause the Cell "Block #" sub-record types to be selected but not their sub-records, but all other sub-records should be selected.
• (If you only have "deep copy as override" as an option, the problem is you didn't right-click on a 'unique' sub-record to bring up the context menu.)
• You may be prompted that this will change the FormID of other plugin records loading after. You want this to happen. It is why you loaded those plugins even though they are not being merged.

(The previous records you just injected in Step 5 will now have a green background color once the "copy as override" is done.)

Step 7. Apply 'Merge Overrides' Script.

Be sure to have used the "Copy as Override" command on the selected records in Step 6, before proceeding. It's easy to confuse these two steps as they are similar but have significant differences.

Now that all records in all the loaded, merged ModB plugins are overrides, you can now select them all (white-, green-, yellow-, and red- backgrounds), right-click on one and use the "Apply Script" command with the script "Merge overrides into master.psc" (bundled in TESEdit 5 v3.1.3+) to merge overrides into the parent (ModA) only.

MfMUP Fig. 1-7

MfMUP Fig. 1-7a

(See Figs. 1-7 & 1-7a. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

• xEdit will not merge overridden records by default; this script was created for this very purpose. (Thank you Zilav).
• You need to select the sub-records, not just the "record type" when using the script.
• The script will not copy 'injected' records even if selected. Don't worry about it.
• Try not to use "Deep Copy" as it doesn't always work as expected. Try with right-clicking on a different sub-record if that is your only option.

• Always check to make sure all records are merged (now either green- or yellow-backgrounds) when the script is done.

• Ignore red-backgrounds, which are "losing conflicts" and being dropped from the result).
• Orange/olive-text on red-backgrounds are 'Identical To Master'(ITM) "conflict winners" and won't be merged.

Step 8. Clean Masters.

• Right-click on ModA and select "clean masters" from the context menu.
• Repeat on any ModB 'dependent' plugins (ones which have ModB as a 'master') as well. Once the ModB master is deactivated, their dependents should be using the new ModA as their master. This may require adding ModA as a new master to the dependent plugin.

Generally this means working down through all the plugins loaded after "ModA" because you added "prior loading plugins" as masters to them in Step 2.

Never manually delete a parent from a plugin unless you are absolutely sure it is not referenced. Always use "clean masters" instead, as it won't remove a "master" if there are any references to it.

In some instances "clean masters" will remove plugins (like with TTW) when it should not; re-add them afterwards and "sort masters" again after saving and reloading.

Step 9. Check All Plugins for Errors.

Note that some plugins will not be in Bold Italics (indicating they were changed) prior to this step. The xEdit "check for errors" process will flag them as changed, so you may want to take a screenshot of this window first or otherwise note which files have changed by this point. You will need to know these file names in Step 11, the "Verify and Cleanup" step for copying to their own project folders.

1. Check for errors by right-clicking on each plugin, and selecting "check for errors" from the context menu that then appears.
2. Check in the 'File Header' for unexpected 'master files'.
3. The other loaded but unmerged plugins may have some of the ModB files we merged into ModA as 'masters'. As those records have now been injected into ModA, we have to make sure each unmerged plugin has ModA as a 'master' instead or it is added as needed, and then that we "clean masters" so the merged ModB plugins get removed. If they do not, it means we missed updating some record FormID, likely at step 6 - "copy as overrides" and have to start over.
4. If there are any remaining dependencies (evidenced by a master you expected to be dropped still being present in the plugin's "File Header" record) you can use the script "List records referencing specific plugin.pas" on that plugin to list them in the log window so you can fix them.
5. Once corrected, "sort" masters on that plugin.
6. "Clean masters" again on the ModA plugin, and re-check all plugins for errors.

If you are unable to remove an unexpected master dependency by "clean masters", then you will need to start over from scratch, by restoring all files modified by this procedure from your backups and beginning from Step 1 of this Stage again. Rethink the master files that you add to the plugin(s) having the problem.

Step 10. Save the Result.

• Save the resulting ModA as the original ModA's filename (or the "<new file>" name selected in Step 6 as the target of the "Copy as Override" or as a "<new file>" replacement version of ModA). This is now our 'patched parent plugin'.
  

  MfMUP Fig. 1-10
• Save any other modified plugins as well. These will usually be those un-merged plugins that had one or more of the ModB plugins as masters that should now be gone and replaced with ModA. Some may have have some records updated with new FormIDs from the ModA plugin as well.

(See Fig. 1-10. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

• If you haven't already in Step 9, take a screenshot of this window or otherwise note which files have changed. You will need to know these file names in the next (Verify and Cleanup) step.

Step 11. Verify and Cleanup.

The ModA file now includes the records from the other plugins we merged. Only our new version of ModA will be needed hereafter, so the ModB files that were merged into it can be left out. They will be deactivated/uninstalled from our "load order" once we check (once again) all the records have been successfully merged. However, do load the unmerged "ModB" plugins that were previously loaded.

1. When we have verified (as in Step 9) that the ModB merges into ModA are correct and complete, we should copy the new ModA 'parent plugin' file to it's new project folder where we have been tracking progress in our 'ReadMe' file.
2. In addition to ModA, various ModB plugins that were not merged have been changed (such as the replacement of the merged plugins as "masters" with the new ModA, or records updated with new ModA FormIDs). These should also be saved to the ModA project folder and added to the ReadMe file, as they are no longer the same as their original versions but specific this ModA version. They should be installed (overwriting the originals) when this package is installed.
3. There is still one further consideration: other 'asset files' (meshes, textures, sounds, etc.) that are part of the original plugins, both the 'parent' and any in the merged patches. Here you have a choice: either copy those asset files into the 'project folder' (starting with the parent's files, and then the patch files in the same sequence as they were in the "load order", overwriting any conflicts); or by noting that they exist in the original mod and have to be installed without that plugin. Whichever choice you make, record it in the "ReadMe" file so you don't forget it.

Note: This is just the general procedure and there will be times when you need to do some other records first. You'll get the "Requires master to be before" message and you'll have to determine what needs to be done first by going in smaller blocks. This will help avoid any "deal breaker" issues, and you should be able to handle any issues which come up.

However, it often helps to clarify how this procedure is applied to multiple files by seeing the actual process in action, which follows. Some steps have supplementary information specific to the plugins in that circumstance.

Example

The following "project" consists of combining a specific three sets of basically 'non-conflicting' mods (with admittedly some easily resolved overlap, after patching each) into a single 'merged plugin' file to be named 'EVE-WMX-IMPACT', for the purpose of reducing the number of active plugins.

• EVE: "Essential Visual Enhancements" for both Projectile and Energy Weapons (primarily "models and textures");
• WMX: "Weapon Mods Expanded" for an expansion of basic game weapon modification system of up to 3 items (such as extended magazines, silencers, or scopes) to all weapons;
• and IMPACT: which adds other visual effects and decals to ballistic weaponry.

As outlined earlier, first the patches affecting only the parent plugin will be incorporated, for each parent plugin individually. The final stage will consist of merging the three newly 'patched parents' into a single "merged plugin". These could all be done in one pass, but are broken down into separate stages here for clarity and to enable those following along to break up the modding session into manageable segments of time and incremental progress. As a consequence, you will find considerable redundancy in each stage. It was decided to make each stage complete in and of itself, for ease of reference when resuming after a period of time between steps, so you didn't have to keep scrolling back and forth through the entire article for the next step in the basic procedure.

The patches for each set will vary depending upon your individual game setup. These are actual choices, but merely representative.

The "Example Project" will show the importance of planning out the procedure, as various considerations in choosing candidate mods and when they come into play in the project will make evident.

Overall Project Candidate List

For the specific case of creating 'EVE-WMX-Impact.esp':

• Plugins under consideration by load order index (in hex). Not all are expected to be included in the final result, but initially you have to consider any that MIGHT be included or required as a 'master file'. This is a representative sample from an actual stable game of approximately 400 hours. The exact sequence position number is not important; only the relative position in the load order. Your load order sequence may differ. The final column is the Nexus mod number (and version) for reference, which should be appended to "https://www.nexusmods.com/newvegas/mods/" to access:

• You now need to determine if there are any 'dependents' (plugins that have the candidate file as a 'master'). If the candidate has dependents, then under the 'KISS' principle it should be excluded for later inclusion into your "merged/bashed patch" file.

• The result is in the first column: everything with an "m" must be loaded due to either having 'masters' which we are including in this merge, or related dependents of such masters not easily included in the merge due to other masters they have. We also indicate (with a "p") those plugins that will be completely incorporated into a "merged/bashed patch" and can then be deactivated. These generally are compatibility patches, and not good candidates for that reason, as well as unnecessary for the purposes of reducing the "active plugin" count with this procedure.

• Each of these "m" files will need to be loaded in Step-1 and have the appropriate ModA added to them at a minimum, but won't be included in the merge into their ModA.
• Only those plugins with a blank entry under the first ("Xcl") column will actually be merged at various Stages in this procedure.

The next section discusses how we arrived at these decisions.

Candidate Selection Strategy

As with most "complex" tasks, we start by breaking it down into smaller more manageable tasks. So, first of all we select some candidates to be merged, then determine their suitability for merging, and the masters they depend upon.

The procedure assumes the "load order" is sorted correctly and the game is stable when individual mods are loaded, with any "merge/bash patch" file deactivated; and all plugin files normally incorporated into the "merge/bash patch" and deactivated, now active while we are performing the merge procedure.

We are only interested in patches that fix or make a single 'patched parent plugin' compatible with others, following the "KISS" principle for this project.

In deciding a good candidate for merging, it's simply a matter of whether the mod in question is adding new content (like WMX or EVE) or is just overriding records or expanding on another mod (WMX-"Pre Order Packs", -DLC, -Modern Weapons). Since this is rarely "one or the other", we have to consider which predominates. Obviously, this means we have to examine each candidate in FNVEdit (xEdit for FNV) in order to determine which are unique (white-background) versus override (yellow- or red-background) records.

In the case of "WeaponModsExpanded" (WMX) and others you can break down like this.

• WMX, the DLC patch, and POP plugins are essentially modifying existing weapon records. They do add new content also; however this content is completely self contained and no other mods are generally going to alter WMX's main content. So they are valid merge candidates as they only affect the parent plugin, and are unlikely to have dependents in the future.

(In practice it turns out 'WMX-DLCMerged.esp' is a master for most of the other WMX related 'AllDLCMerged' compatibility plugins, like 'WMX-EVE-AllDLCMerged.esp' and 'YUP-WMX-PN-PNEO Patch.esp'. However these can successfully substitute our new 'merged parent' version of 'WeaponModsExpanded.esp' in place of 'WMX-DLCMerged.esp', so we proceed to include it. We are simply going to have to track more 'modified' plugins as an unintended consequence. But this would be a consideration that might change our mind in other circumstances.)

'EVE FNV - ALL DLC' is also editing weapons records, and adds its own content too. In this instance any patch to EVE for WMX is dependent on WMX as well because it doesn't just change the death effects, it also changes weapon mods and models. EVE also changes models/textures so there are conflicts which must be resolved with a patch between the two mods. But these patches only pertain to the weapons records themselves and not the added content by WMX. So the mods to EVE are "compatibility patches", and not good merge plugin candidates.

• The plugin 'EVE FNV - ALL DLC.esp' is a 'parent plugin' example deserving some more detailed explanation. Only one of it's dependents (WMX-EVE-AllDLCMerged.esp) has the same masters as the candidate plugins we intend to merge. The other two require masters not under consideration, so only 'WMX-EVE-AllDLCMerged.esp' is initially suitable for our purpose at first glance. However, that 'dependent' is a plugin that will be completely incorporated into a 'merge/bash patch', and thus gains us nothing in terms of "freeing up" available plugin slots. In addition, it has several dependent plugins of it's own that come after it with other 'master' file requirements outside of our consideration. This makes those secondary plugins "compatibility patches", adding a level of complexity to the initial appearance of simplicity. So, in the end like the others it will be excluded.
• But as both 'EVE' dependent plugins require 'EVE FNV - ALL DLC.esp' as a master, and 'WMX-EVE-AllDLCMerged.esp' and 'CCSP2_5C_WMX.esp' also require WMX or one of it's merged plugins, we will need to change their 'master' file entries after creating our new "combined merge plugin": 'EVE-WMX-IMPACT.esp'. So they will need to be included when we load related plugins, though not merged.

The same reasoning applies to "Impact", "WMR" and sound mods. They are essentially all modifying weapon records, while also adding some kind of new content on top. They are "compatibility patches", and not good merge plugin candidates, but need to be loaded so their 'master' records are updated.

The only ModB candidate for 'IMPACT.esp' is 'YUP + EVE + IMPACT.esp', which has both YUP and IMPACT as 'masters'. With two 'parent' plugins (one of which we are not going to merge) we apply the "KISS" principle and conclude it should be included in a "merged/bashed patch" file, and there are no patches to apply to this 'parent'.

Theoretically given this information, we could choose to take the compatibility patches and create a separate "merged compatibility patches" file which is a combination of all of them. (Easier said than done.) You would then be left with only the 'parent' masters, and ONE "Merged_WMX-EVE-IMPACT_CompatibilityPatches.esp". It's much easier to then merge WMX together and let FNVEdit update that one "merged patches" file in the process.

We would then be left with 4 potential ESP files:

• WeaponModsExpanded.esp (Containing, WMX, WMX DLC, WMX POP and WMX Modern Weapons)
• EVE-AllDLC (unaltered)
• Impact.esp (unaltered)
• Merged_WMX-EVE-IMPACT_CompatibilityPatches.esp (Containing any and all compatibility patches between them, including sound ('CCSP2_5C_WMX'), WMX-EVE, WMX-WRP, WMX-Impact, YUP + EVE + IMPACT, etc)

At this stage you could choose to compress the first three down into one "combined parent plugin", and then taking the "merged patches" file and merging it in with them last.

But this approach of merging the compatibility patches" into the combined parent merge is just going to be super messy and difficult and take more time that it is worth. Recommend leaving the compatibility patches for the "merge/bash patch" when the rest of the "load order" is complete.

Consequently, our strategy is to merge patches (but not "compatibility patches") into new 'merged parent plugin' ModA files. Then merge non-conflicting 'merged parent plugin' files to a new "combined merged plugin" file to replace them all. This will cause a "missing content" message upon loading an existing game, but as we will be retaining the FormID numbering of each individual 'parent plugin' we shouldn't lose any inventory in a "saved game".

Example Stage-1 (ModA Parent Plugin 1: 'WeaponModsExpanded.esp')

• Stage-1: Lets take the plugin 'WeaponModsExpanded.esp' (WMX) first for an example of the basic procedure and how it was done for the TTW version of that merged plugin. (The order of the 'parent plugins' in which we choose to merge patches is immaterial.)

Note: We want to merge patches together first, and make any desired conflict/preference changes. This will lessen your overall work load. This is optional, as they could all be done at once, but in practice it is better to keep each step as simple as possible to minimize mistakes.

In this instance, there is the main WMX file 'WeaponModsExpanded.esp' (which will be our 'parent plugin'), as well as the DLC-Merged 'WMX-DLCMerged.esp', Millenia Modern Weapons 'WMX-ModernWeapons.esp', and the Pre-Order Packs (POP) combined 'WMX-POPMerged.esp' patch plugins. The main WMX plugin is going to be the 'parent plugin', the plugin to which all the others that are modifying or patches of WMX are to be merged into.

"But what about 'YUP-WMX-PN-PNEO Patch.esp'? It patches WMX", is a natural question.

Response: This is an example of why you have to examine the "File Header" of each "candidate" for 'masters' first (Step-1). It's a "compatibility patch", so we will load to update it's master files both in Stage-1 Step-1 and later in Step-4, but not merge it. See the reasoning under the sub-topic Candidate Selection Strategy.

We will also load 'CCSP2_5C_WMX.esp' in Stage-1 Step-1 and later in Stage-4, even though we do not intend to merge it as it is dependent upon both 'WeaponModsExpanded' and 'WMX-POPMerged', so that it's 'master' file list will be updated to add masters coming before it, and later to remove the no longer relevant 'WMX-POPMerged' plugin and recognize the new "combined merge plugin" as a master when we "clean masters" later.

Example Stage-1 Step-1: Load 'WeaponModsExpanded (WMX)' related Plugins

Step 1. Load ModA related plugins.

• Load the target ModA 'parent plugin', and all the ModB plugins related to it (even those you do not intend to merge), into xEdit.
• Go up to and <Right-Click> on the "FormID" column header, select the right pointing arrow after "Files", and make sure "always by load order" is selected. (If this capability is not available, it means you are not using the latest version of xEdit.)

• <Right-Click> in any open, unused space in the left-hand pane and select "Remove Filter" from the displayed "Context Menu". This ensures nothing is being filtered out of our view.

Each and every plugin that will be merged directly into the parent will all be done at the same time and not in steps.

• Note that xEdit assigns it's own relative two-character hexadecimal "mod index" to the plugins it loads. All records shown will begin with one of these relative mod indexes (which appear to the left of each plugin name in [square brackets]). When referring to unique records in a plugin, we mean one which has the same "mod index" as that plugin (regardless of background color), and not the index of any other mod.

Example Stage-1 Step-2: Add 'Masters'

Step 2. Add 'Masters'.

Add any masters before ModA to ModA if missing.

• Add all the masters that are loading before each ModB plugin to each ModB plugin, EXCEPT any other ModB plugins themselves (as they will be dropped later once they have been merged). Especially add the ModA plugin as master to all the ModB plugins. This includes adding to related ModB plugins that are NOT going to be merged, so any references will be updated when FormIDs are changed. (If they aren't actually needed such added masters will get removed later when we "clean masters".)
• Sort the masters in each plugin after adding.

Stage-1 Step-2o Save all remaining added masters and reload them

MfMUP Fig. 1-2n3

• Save all the plugins that had 'masters' added to them (by enabling/selecting the checkbox for each in the 'target' window that pops-up when you attempt to close xEdit).

(See Fig. 1-2n3. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

• Reload all plugins from Step 1, and check the added 'masters' are in each plugin's "File Header" before proceeding to Step 3.

The 'Add Masters' selection window should come up empty if all is correct, allowing you to 'cancel' it by clicking on the "x" icon in the upper right-corner of the pop-up window. Otherwise, add the 'masters' indicated, and repeat this step when all have been checked this pass.

Failure to perform this step can result in the loss of hours of work in the last step.

Now would be a good time to "<Shift+Click>" on the "ModA" and all it's related plugins in the left-hand pane, and "<Right+Click>" to bring up the "Context Menu" so you can select "Check for Errors". If you find any you can fix yourself, you want to do so before proceeding any further. Otherwise, note the error for ignoring later, or consider excluding the merge of that plugin in this procedure.

Example Stage-1 Step-3: Select ModB

Step 3. Select ModB.

Select the first loading unmerged plugin (other than the 'parent') to be the first/next to be merged, and expand it so you can see the record types.

MfMUP Fig. 1-3

Note: In the case of weapon mods like WMX they often have compatibility patches. You want to have them loaded too when doing your renumber/injection, even when you have no intention of merging them. We do not consider these as "ModB" plugins. In this instance: 'WMR_WMX_Vanilla_S.esp' (a compatibility patch) comes before 'WMX-DLCMerged.esp' (a "ModB" plugin we intend to merge), so we skip the compatibility patch for this step.

• In this example, the first loading unmerged "ModB" plugin is 'WMX-DLCMerged.esp', so select and expand it. You can use <Alt+click> on the "+" sign to the left of the plugin name to expand all record types; or in front of the record type to expand all sub-records, at once. Then collapse (by clicking on the "-" sign to the left of) the record types you are not working on at the moment.

(See Fig. 1-3, which identifies important record information. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

Example Stage-1 Step-4: Basic Record Injection

MfMUP Fig. 1-4

(Record types vary by plugin.)

• This is the order used to inject unique records for each of the "ModB" plugins (one at a time) to be merged, broken down into 11 sub-steps by record type:

1. All forms which are not record type: CELL, Worldspace, Dialogue, Script or Quest.
   • All record types to be selected in one plugin can be expanded and done at once, but if there are too many to fit on the screen, you may find it easier to break the step up into batches of record types for selection. Just remember to process them all in the record type sequence given, and inject them all at one time for each plugin to ensure they each receive a unique form number. Refer to the FNVEdit Training Manual section on "Merging a Plugin into another Plugin or Master" or "Gribbleshnibit8's Merge Up Guide (MUG)" if you have any questions.
   • You want to select all of these unique records (use <Shift+Click> and <Ctrl+Click>) before you:

   • review your selections to make sure you didn't accidentally skip/miss some and verify only unique records are selected,
   • renumber by right clicking on one of the selected records and selecting "Change FormID" from the "Context Menu", then
   • selecting the main 'parent plugin' (ModA) as the target file when the list of plugins appears.

   This will "inject" all the selected records into the "ModA" plugin. The consequence is the parent index number of the FormIDs for those unique records will be changed to that of ModA's index. (Any resulting duplicate FormIDs will automatically be adjusted.)

   • If selecting only one record to be renumbered, you will need to note the last "Changing FormID [<number>] in file <filename> to [<new number>]" message in the "Messages" tab of xEdit, add one to the "<new number>" in hexadecimal, and place that value in the "New FormID" prompt manually. ("<Ctrl+I>" Saves the FormID of the highlighted record to the clipboard.) The "starting value" given is not correct otherwise. This is only required when renumbering single records.

   xEdit may now prompt you with a message "There are overrides in later plugins, do you want to update them?" You should choose Yes to this and it will automatically fix them for your merged plugin. This function was added to xEdit for this very purpose. (Thank you Zilav).

   (You may find it necessary to scroll up and down the left-hand pane before all the updated FormIDs are displayed correctly in Bold Italics.)

   • Examine the "Messages" tab in the right-hand pane of xEDit for any errors.
   • Now process the remaining unique (white-background) form record types (following as sub-steps 2-11) in the same manner. It's important to process each record type separately so the FormIDs are updated properly.
2. CELL Persistent records (Expand "Cell" | < Block # > | < Sub-Block # > | < record # > | "Persistent")
3. CELL Temporary records (Expand "Cell" | < Block # > | < Sub-Block # > | < record # > | "Temporary")
4. CELL Parent Records (if unique) (Expand "Cell" | < Block # > | < Sub-Block # > | < record # > on "white-background")
5. Worldspace Persistent records
6. Worldspace Temporary records
7. Worldspace Parent Records (if unique)
8. Scripts
9. Quests
10. Dialogue Responses
11. Dialogue Top Level topics (if unique)
    • Examine the "Messages" tab in the right-hand pane of xEdit for any errors.
12. You want to collapse all record types for the plugin by "<Left+Click>" on the "-" sign to the left of the plugin name, and then "<Alt+Left+Click>" on the "+" sign that replaces it to expand them ALL again. (Recall that collapsed record types don't get copied.) When we are finished injecting all unique records, there should not be any records that do not begin with a mod index other than 00-05 or that of our "ModA" plugin. Anything else in an earlier loading "ModB" plugin should have already been injected and updated in this plugin. (If there are any, they will cause Step 6 to fail and you have to cancel the session: uncheck all plugins and "<Left+Click>" the "X" in the upper right corner of the "save changes" window to exit without saving, and restart Step 4 over. Take the time to check now.)

Example Stage-1 Step-5: Inject All ModB Records

Step 5. Inject All ModB Records.

• Repeat steps 3 and 4 for all 11 sub-step record types of Step-4 for ALL the other loaded ModB plugins you intend to merge, working your way down from lowest numbered (earliest loading) to highest numbered (latest loading) in load order.

Examine the "Messages" tab in the right-hand pane of xEdit for any errors.

Example Stage-1 Step-5a: Proceed to Finish

Once we have proceeded to select and inject all 11 sub-steps of Step-4 for all three ModB plugins we are merging at this time, note we are now proceeding to Steps 6-9 because we are creating a merge of patches into the ModA 'parent plugin' in discrete steps.

Otherwise they could be deferred until all the records for all the plugins were ready for "copy as override" and the script "Merge overrides into parent.psc" into the final Stage-4 'EVE-WMX-Impact.esp'.

The advantage to saving after injecting all the related ModBs into each ModA parent plugin is that you can then check and test the individual new ModA merged parent plugin results before attempting to merge all the separate ModAs together into a single 'combined merge plugin'.

Example Stage-1 Step-6: Copy as Override

MfMUP Fig. 1-6

• Expand any record types in any of the ModB plugins that haven't been (i.e. collapse each plugin file and then <Alt+click> the "+" to the left to expand everything if not sure), and select all sub-records from the first ModB to the bottom of the other merged plugins loading after it (this will ignore/de-select the "File Header" records). This time records of all background colors should be included (white, green, yellow, and red). Place the cursor over any 'unique' sub-record, right-click and select "copy as override" into ModA; or to "<new file>" if you intend this to be a new merged plugin file with ModA as it's master. If you don't merge into ModA, then ModA's records are not included in the result.
  

  MfMUP Fig. 1-6a

(See Figs. 1-6 & 1-6a. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

• Note you have to select "sub-records", under the first "record type" level. This will cause the Cell "Block #" sub-record types to be selected but not their sub-records, but all other sub-records should be selected.
• (If you only have "deep copy as override" as an option, the problem is you didn't right-click on a 'unique' sub-record to bring up the context menu.)
• You may be prompted that this will change the FormID of other plugin records loading after. You want this to happen. It is why you loaded those plugins even though they are not being merged.

(The previous records you just injected in Step 5 will now have a green background color once the "copy as override" is done.)

Example Stage-1 Step-7: Apply 'Merge Overrides' Script

Step 7. Apply 'Merge Overrides' Script.

Be sure to have used the "Copy as Override" command on the selected records in Step 6, before proceeding. It's easy to confuse these two steps as they are similar but have significant differences.

Now that all records in all the loaded, merged ModB plugins are overrides, you can now select them all (white-, green-, yellow-, and red- backgrounds), right-click on one and use the "Apply Script" command with the script "Merge overrides into master.psc" (bundled in TESEdit 5 v3.1.3+) to merge overrides into the parent (ModA) only.

MfMUP Fig. 1-7

MfMUP Fig. 1-7a

(See Figs. 1-7 & 1-7a. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

• xEdit will not merge overridden records by default; this script was created for this very purpose. (Thank you Zilav).
• You need to select the sub-records, not just the "record type" when using the script.
• The script will not copy 'injected' records even if selected. Don't worry about it.
• Try not to use "Deep Copy" as it doesn't always work as expected. Try with right-clicking on a different sub-record if that is your only option.

• Always check to make sure all records are merged (now either green- or yellow-backgrounds) when the script is done.

• Ignore red-backgrounds, which are "losing conflicts" and being dropped from the result).
• Orange/olive-text on red-backgrounds are 'Identical To Master'(ITM) "conflict winners" and won't be merged.

Example Stage-1 Step-8: Clean Masters

Step 8. Clean Masters.

• Right-click on ModA and select "clean masters" from the context menu.
• Repeat on any ModB 'dependent' plugins (ones which have ModB as a 'master') as well. Once the ModB master is deactivated, their dependents should be using the new ModA as their master. This may require adding ModA as a new master to the dependent plugin.

Generally this means working down through all the plugins loaded after "ModA" because you added "prior loading plugins" as masters to them in Step 2.

Never manually delete a parent from a plugin unless you are absolutely sure it is not referenced. Always use "clean masters" instead, as it won't remove a "master" if there are any references to it.

In some instances "clean masters" will remove plugins (like with TTW) when it should not; re-add them afterwards and "sort masters" again after saving and reloading.

Example Stage-1 Step-9: Check All Plugins for Errors

Step 9. Check All Plugins for Errors.

Note that some plugins will not be in Bold Italics (indicating they were changed) prior to this step. The xEdit "check for errors" process will flag them as changed, so you may want to take a screenshot of this window first or otherwise note which files have changed by this point. You will need to know these file names in Step 11, the "Verify and Cleanup" step for copying to their own project folders.

1. Check for errors by right-clicking on each plugin, and selecting "check for errors" from the context menu that then appears.
2. Check in the 'File Header' for unexpected 'master files'.
3. The other loaded but unmerged plugins may have some of the ModB files we merged into ModA as 'masters'. As those records have now been injected into ModA, we have to make sure each unmerged plugin has ModA as a 'master' instead or it is added as needed, and then that we "clean masters" so the merged ModB plugins get removed. If they do not, it means we missed updating some record FormID, likely at step 6 - "copy as overrides" and have to start over.
4. If there are any remaining dependencies (evidenced by a master you expected to be dropped still being present in the plugin's "File Header" record) you can use the script "List records referencing specific plugin.pas" on that plugin to list them in the log window so you can fix them.
5. Once corrected, "sort" masters on that plugin.
6. "Clean masters" again on the ModA plugin, and re-check all plugins for errors.

If you are unable to remove an unexpected master dependency by "clean masters", then you will need to start over from scratch, by restoring all files modified by this procedure from your backups and beginning from Step 1 of this Stage again. Rethink the master files that you add to the plugin(s) having the problem.

Example Stage-1 Step-10: Save the Result

Step 10. Save the Result.

• Save the resulting ModA as the original ModA's filename (or the "<new file>" name selected in Step 6 as the target of the "Copy as Override" or as a "<new file>" replacement version of ModA). This is now our 'patched parent plugin'.
  

  MfMUP Fig. 1-10
• Save any other modified plugins as well. These will usually be those un-merged plugins that had one or more of the ModB plugins as masters that should now be gone and replaced with ModA. Some may have have some records updated with new FormIDs from the ModA plugin as well.

(See Fig. 1-10. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

• If you haven't already in Step 9, take a screenshot of this window or otherwise note which files have changed. You will need to know these file names in the next (Verify and Cleanup) step.

Example Stage-1 Step-11: Verify and Cleanup

Step 11. Verify and Cleanup.

The ModA file now includes the records from the other plugins we merged. Only our new version of ModA will be needed hereafter, so the ModB files that were merged into it can be left out. They will be deactivated/uninstalled from our "load order" once we check (once again) all the records have been successfully merged. However, do load the unmerged "ModB" plugins that were previously loaded.

1. When we have verified (as in Step 9) that the ModB merges into ModA are correct and complete, we should copy the new ModA 'parent plugin' file to it's new project folder where we have been tracking progress in our 'ReadMe' file.
2. In addition to ModA, various ModB plugins that were not merged have been changed (such as the replacement of the merged plugins as "masters" with the new ModA, or records updated with new ModA FormIDs). These should also be saved to the ModA project folder and added to the ReadMe file, as they are no longer the same as their original versions but specific this ModA version. They should be installed (overwriting the originals) when this package is installed.
3. There is still one further consideration: other 'asset files' (meshes, textures, sounds, etc.) that are part of the original plugins, both the 'parent' and any in the merged patches. Here you have a choice: either copy those asset files into the 'project folder' (starting with the parent's files, and then the patch files in the same sequence as they were in the "load order", overwriting any conflicts); or by noting that they exist in the original mod and have to be installed without that plugin. Whichever choice you make, record it in the "ReadMe" file so you don't forget it.

Example Stage-2 (Parent Plugin 2: 'EVE FNV - ALL DLC.esp')

• Stage-2: Lets take the plugin 'EVE FNV - ALL DLC.esp' next.

Example Stage-3 (Review candidate 'IMPACT.esp' and related plugins

• Stage-3: The plugin 'IMPACT.esp'.

So, now we are ready to move on to the goal stage, where we merge the three final 'parent' plugins into a single one.

Example Stage-4 (Merge of Parent Plugins 1-3 into the new 'EVE-WMX-Impact.esp')

Note that by patching each 'merged parent plugin' and saving it separately (where needed), we have made it relatively simpler to incorporate other, later patches into that parent. Of course, if you drop the use of a plugin for which you have patched the parent, it will prove necessary to re-patch from the beginning (which is why you want to keep the original plugin separate from your merged version) OR edit your 'merged parent plugin' to remove all references to the master file being dropped until the "Clean Masters" feature is able to remove the master from the 'merged parent plugin' file header. However, once the patched 'merged parent plugin' in question has been rebuilt, you can skip directly to this stage (as we did with the EVE and IMPACT plugins).

Here we apply the same Multi-file Merge Up Procedure as in Stage-1. The only significant change is that we will be renaming our saved ModA file to a new filename (e.g. 'EVE-WMX-IMPACT') once we have saved it under the current name in the added "Step-6a". Once that has been done it will become our new "ModA".

Example Stage-4 Step-1: Load related plugins

Step 1. Load ModA related plugins.

• Load the target ModA 'parent plugin', and all the ModB plugins related to it (even those you do not intend to merge), into xEdit.
• Go up to and <Right-Click> on the "FormID" column header, select the right pointing arrow after "Files", and make sure "always by load order" is selected. (If this capability is not available, it means you are not using the latest version of xEdit.)

• <Right-Click> in any open, unused space in the left-hand pane and select "Remove Filter" from the displayed "Context Menu". This ensures nothing is being filtered out of our view.

Each and every plugin that will be merged directly into the parent will all be done at the same time and not in steps.

• Note that xEdit assigns it's own relative two-character hexadecimal "mod index" to the plugins it loads. All records shown will begin with one of these relative mod indexes (which appear to the left of each plugin name in [square brackets]). When referring to unique records in a plugin, we mean one which has the same "mod index" as that plugin (regardless of background color), and not the index of any other mod.

Example Stage-4 Step-2: Add 'Masters'

Step 2. Add 'Masters'.

Add any masters before ModA to ModA if missing.

• Add all the masters that are loading before each ModB plugin to each ModB plugin, EXCEPT any other ModB plugins themselves (as they will be dropped later once they have been merged). Especially add the ModA plugin as master to all the ModB plugins. This includes adding to related ModB plugins that are NOT going to be merged, so any references will be updated when FormIDs are changed. (If they aren't actually needed such added masters will get removed later when we "clean masters".)
• Sort the masters in each plugin after adding.

MfMUP Fig. 1-2n3

• Save all the plugins that had 'masters' added to them (by enabling/selecting the checkbox for each in the 'target' window that pops-up when you attempt to close xEdit).

(See Fig. 1-2n3. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

• Reload all plugins from Step 1, and check the added 'masters' are in each plugin's "File Header" before proceeding to Step 3.

The 'Add Masters' selection window should come up empty if all is correct, allowing you to 'cancel' it by clicking on the "x" icon in the upper right-corner of the pop-up window. Otherwise, add the 'masters' indicated, and repeat this step when all have been checked this pass.

Failure to perform this step can result in the loss of hours of work in the last step.

Example Stage-4 Step-3: Select ModB

Step 3. Select ModB.

Select the first loading unmerged plugin (other than the 'parent') to be the first/next to be merged, and expand it so you can see the record types.

Example Stage-4 Step-4: Basic Record Injection

MfMUP Fig. 1-4

(Record types vary by plugin.)

• This is the order used to inject unique records for each of the "ModB" plugins (one at a time) to be merged, broken down into 11 sub-steps by record type:

1. All forms which are not record type: CELL, Worldspace, Dialogue, Script or Quest.
   • All record types to be selected in one plugin can be expanded and done at once, but if there are too many to fit on the screen, you may find it easier to break the step up into batches of record types for selection. Just remember to process them all in the record type sequence given, and inject them all at one time for each plugin to ensure they each receive a unique form number. Refer to the FNVEdit Training Manual section on "Merging a Plugin into another Plugin or Master" or "Gribbleshnibit8's Merge Up Guide (MUG)" if you have any questions.
   • You want to select all of these unique records (use <Shift+Click> and <Ctrl+Click>) before you:

   • review your selections to make sure you didn't accidentally skip/miss some and verify only unique records are selected,
   • renumber by right clicking on one of the selected records and selecting "Change FormID" from the "Context Menu", then
   • selecting the main 'parent plugin' (ModA) as the target file when the list of plugins appears.

   This will "inject" all the selected records into the "ModA" plugin. The consequence is the parent index number of the FormIDs for those unique records will be changed to that of ModA's index. (Any resulting duplicate FormIDs will automatically be adjusted.)

   • If selecting only one record to be renumbered, you will need to note the last "Changing FormID [<number>] in file <filename> to [<new number>]" message in the "Messages" tab of xEdit, add one to the "<new number>" in hexadecimal, and place that value in the "New FormID" prompt manually. ("<Ctrl+I>" Saves the FormID of the highlighted record to the clipboard.) The "starting value" given is not correct otherwise. This is only required when renumbering single records.

   xEdit may now prompt you with a message "There are overrides in later plugins, do you want to update them?" You should choose Yes to this and it will automatically fix them for your merged plugin. This function was added to xEdit for this very purpose. (Thank you Zilav).

   (You may find it necessary to scroll up and down the left-hand pane before all the updated FormIDs are displayed correctly in Bold Italics.)

   • Examine the "Messages" tab in the right-hand pane of xEDit for any errors.
   • Now process the remaining unique (white-background) form record types (following as sub-steps 2-11) in the same manner. It's important to process each record type separately so the FormIDs are updated properly.
2. CELL Persistent records (Expand "Cell" | < Block # > | < Sub-Block # > | < record # > | "Persistent")
3. CELL Temporary records (Expand "Cell" | < Block # > | < Sub-Block # > | < record # > | "Temporary")
4. CELL Parent Records (if unique) (Expand "Cell" | < Block # > | < Sub-Block # > | < record # > on "white-background")
5. Worldspace Persistent records
6. Worldspace Temporary records
7. Worldspace Parent Records (if unique)
8. Scripts
9. Quests
10. Dialogue Responses
11. Dialogue Top Level topics (if unique)
    • Examine the "Messages" tab in the right-hand pane of xEdit for any errors.
12. You want to collapse all record types for the plugin by "<Left+Click>" on the "-" sign to the left of the plugin name, and then "<Alt+Left+Click>" on the "+" sign that replaces it to expand them ALL again. (Recall that collapsed record types don't get copied.) When we are finished injecting all unique records, there should not be any records that do not begin with a mod index other than 00-05 or that of our "ModA" plugin. Anything else in an earlier loading "ModB" plugin should have already been injected and updated in this plugin. (If there are any, they will cause Step 6 to fail and you have to cancel the session: uncheck all plugins and "<Left+Click>" the "X" in the upper right corner of the "save changes" window to exit without saving, and restart Step 4 over. Take the time to check now.)

Example Stage-4 Step-5: Inject All Remaining ModB Records

Step 5. Inject All ModB Records.

• Repeat steps 3 and 4 for all 11 sub-step record types of Step-4 for ALL the other loaded ModB plugins you intend to merge, working your way down from lowest numbered (earliest loading) to highest numbered (latest loading) in load order.

Examine the "Messages" tab in the right-hand pane of xEdit for any errors.

Example Stage-4 Step-6: Copy as Override

MfMUP Fig. 1-6

• Expand any record types in any of the ModB plugins that haven't been (i.e. collapse each plugin file and then <Alt+click> the "+" to the left to expand everything if not sure), and select all sub-records from the first ModB to the bottom of the other merged plugins loading after it (this will ignore/de-select the "File Header" records). This time records of all background colors should be included (white, green, yellow, and red). Place the cursor over any 'unique' sub-record, right-click and select "copy as override" into ModA; or to "<new file>" if you intend this to be a new merged plugin file with ModA as it's master. If you don't merge into ModA, then ModA's records are not included in the result.
  

  MfMUP Fig. 1-6a

(See Figs. 1-6 & 1-6a. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

• Note you have to select "sub-records", under the first "record type" level. This will cause the Cell "Block #" sub-record types to be selected but not their sub-records, but all other sub-records should be selected.
• (If you only have "deep copy as override" as an option, the problem is you didn't right-click on a 'unique' sub-record to bring up the context menu.)
• You may be prompted that this will change the FormID of other plugin records loading after. You want this to happen. It is why you loaded those plugins even though they are not being merged.

(The previous records you just injected in Step 5 will now have a green background color once the "copy as override" is done.)

Example Stage-4 Step-7: Apply 'Merge Overrides' Script

Step 7. Apply 'Merge Overrides' Script.

Be sure to have used the "Copy as Override" command on the selected records in Step 6, before proceeding. It's easy to confuse these two steps as they are similar but have significant differences.

Now that all records in all the loaded, merged ModB plugins are overrides, you can now select them all (white-, green-, yellow-, and red- backgrounds), right-click on one and use the "Apply Script" command with the script "Merge overrides into master.psc" (bundled in TESEdit 5 v3.1.3+) to merge overrides into the parent (ModA) only.

MfMUP Fig. 1-7

MfMUP Fig. 1-7a

(See Figs. 1-7 & 1-7a. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

• xEdit will not merge overridden records by default; this script was created for this very purpose. (Thank you Zilav).
• You need to select the sub-records, not just the "record type" when using the script.
• The script will not copy 'injected' records even if selected. Don't worry about it.
• Try not to use "Deep Copy" as it doesn't always work as expected. Try with right-clicking on a different sub-record if that is your only option.

• Always check to make sure all records are merged (now either green- or yellow-backgrounds) when the script is done.

• Ignore red-backgrounds, which are "losing conflicts" and being dropped from the result).
• Orange/olive-text on red-backgrounds are 'Identical To Master'(ITM) "conflict winners" and won't be merged.

Example Stage-4 Step-8: Clean Masters

Step 8. Clean Masters.

• Right-click on ModA and select "clean masters" from the context menu.
• Repeat on any ModB 'dependent' plugins (ones which have ModB as a 'master') as well. Once the ModB master is deactivated, their dependents should be using the new ModA as their master. This may require adding ModA as a new master to the dependent plugin.

Generally this means working down through all the plugins loaded after "ModA" because you added "prior loading plugins" as masters to them in Step 2.

Never manually delete a parent from a plugin unless you are absolutely sure it is not referenced. Always use "clean masters" instead, as it won't remove a "master" if there are any references to it.

In some instances "clean masters" will remove plugins (like with TTW) when it should not; re-add them afterwards and "sort masters" again after saving and reloading.

Example Stage-4 Step-9: Check All Plugins for Errors

Step 9. Check All Plugins for Errors.

Note that some plugins will not be in Bold Italics (indicating they were changed) prior to this step. The xEdit "check for errors" process will flag them as changed, so you may want to take a screenshot of this window first or otherwise note which files have changed by this point. You will need to know these file names in Step 11, the "Verify and Cleanup" step for copying to their own project folders.

1. Check for errors by right-clicking on each plugin, and selecting "check for errors" from the context menu that then appears.
2. Check in the 'File Header' for unexpected 'master files'.
3. The other loaded but unmerged plugins may have some of the ModB files we merged into ModA as 'masters'. As those records have now been injected into ModA, we have to make sure each unmerged plugin has ModA as a 'master' instead or it is added as needed, and then that we "clean masters" so the merged ModB plugins get removed. If they do not, it means we missed updating some record FormID, likely at step 6 - "copy as overrides" and have to start over.
4. If there are any remaining dependencies (evidenced by a master you expected to be dropped still being present in the plugin's "File Header" record) you can use the script "List records referencing specific plugin.pas" on that plugin to list them in the log window so you can fix them.
5. Once corrected, "sort" masters on that plugin.
6. "Clean masters" again on the ModA plugin, and re-check all plugins for errors.

If you are unable to remove an unexpected master dependency by "clean masters", then you will need to start over from scratch, by restoring all files modified by this procedure from your backups and beginning from Step 1 of this Stage again. Rethink the master files that you add to the plugin(s) having the problem.

Example Stage-4 Step-10: Save the Result

Step 10. Save the Result.

• Save the resulting ModA as the original ModA's filename (or the "<new file>" name selected in Step 6 as the target of the "Copy as Override" or as a "<new file>" replacement version of ModA). This is now our 'patched parent plugin'.
  

  MfMUP Fig. 1-10
• Save any other modified plugins as well. These will usually be those un-merged plugins that had one or more of the ModB plugins as masters that should now be gone and replaced with ModA. Some may have have some records updated with new FormIDs from the ModA plugin as well.

(See Fig. 1-10. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

• If you haven't already in Step 9, take a screenshot of this window or otherwise note which files have changed. You will need to know these file names in the next (Verify and Cleanup) step.

Example Stage-4 Step-11: Verify and Cleanup

Step 11. Verify and Cleanup.

The ModA file now includes the records from the other plugins we merged. Only our new version of ModA will be needed hereafter, so the ModB files that were merged into it can be left out. They will be deactivated/uninstalled from our "load order" once we check (once again) all the records have been successfully merged. However, do load the unmerged "ModB" plugins that were previously loaded.

1. When we have verified (as in Step 9) that the ModB merges into ModA are correct and complete, we should copy the new ModA 'parent plugin' file to it's new project folder where we have been tracking progress in our 'ReadMe' file.
2. In addition to ModA, various ModB plugins that were not merged have been changed (such as the replacement of the merged plugins as "masters" with the new ModA, or records updated with new ModA FormIDs). These should also be saved to the ModA project folder and added to the ReadMe file, as they are no longer the same as their original versions but specific this ModA version. They should be installed (overwriting the originals) when this package is installed.
3. There is still one further consideration: other 'asset files' (meshes, textures, sounds, etc.) that are part of the original plugins, both the 'parent' and any in the merged patches. Here you have a choice: either copy those asset files into the 'project folder' (starting with the parent's files, and then the patch files in the same sequence as they were in the "load order", overwriting any conflicts); or by noting that they exist in the original mod and have to be installed without that plugin. Whichever choice you make, record it in the "ReadMe" file so you don't forget it.

References

• TESEdit5 v3.1.3+ (rename downloaded EXE to FNVEdit.exe)
• FNVEdit Training Manual
• Gribbleshnibit8's Merge Up Guide (MUG) (Currently NA. Investigating.)
• "Keep It Simple Stupid" (K-I-S-S) principle
• Hexadecimal article
• Mator's Standalone Merge Plugins (MPS)

Nexus wiki articles referred to by this article:

• Merged Plugin Guidelines for Personal Use
• Missing Masters

Nexus wiki articles that refer to this article:

• Merged Plugin Guidelines for Personal Use