View source for Merged Plugin Guidelines for Personal Use

==Overview==
The active plugin cap for "Fallout: New Vegas" (FNV) is between 130-140 of both ESM and ESP file types, varying by system.  There is a mod that pops a warning when you hit 139, but people can have problems before that.  The solution is to create "merged plugin" files.

The focus here is getting under the plugin cap in the easiest possible manner consistent with a stable game by creating merge plugins for strictly personal use.  This means we take a very conservative approach and generally try to avoid any surgery on mods.  The resulting merge is highly specific to your personal "Load Order" (LO).  Do not attempt to redistribute the result as it will almost certainly not work for anyone else.

There are a number of very similar and confusing terms used in this article.  Fear not, they are explained in the [[#Terminology|Terminology]] section.  But we start with an "overview" of what is involved to give you an idea of what you are getting into.  It is worth while to learn how to do this, but it is also a learning experience that requires you to understand what is behind the differences in your choices.

"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 it's new file, 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" (neither "fixes" nor "compatibility"), as it uses the "merge down" technique.

Note that a "merge plugin" reduces the number of plugins that remain active in the "load order".  It does '''not resolve any record conflicts''' within plugins merged up into the 'parent master' plugin, making it now the sole "winning" plugin according to the "rule of one".  Record conflicts between the plugins to be merged need to resolve separately before merging, by way of a "merged patch" file.  Any 'dependent' plugins (that require a 'master' plugin you are merging) need to be included in the 'merge' process so they are adjusted to any new record "FormIDs".  When 'dependent' plugins are involved, you are better off using the 'merge up' technique.

A "merged patch", like a "bashed patch", resolves record level conflicts (i.e. "compatibility patches", other plugins affecting the same record, etc.) 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 "bashed patch", does it reduce the number of plugins that must remain active ''but only if'' you include the "Mark Mergeable" step when building the "bashed patch".  (See below under the "Finishing the Process" section.)

There is generally only one "merged/bashed 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 placed after the automated "bashed patch" in order to override the latters winning records with your preferences.  (The same basic process applies.)  However, "Mator Smash" can now be used to create a "merged patch" of record conflicts for just the plugins you intend to merge together into a "merged plugin".  This can be done for each "merged plugin" you create.  It has the advantage of reducing the number of record conflicts that the final "merged/bashed patch" has to resolve.

==Programs and Tools==
* [http://www.nexusmods.com/skyrim/mods/69905/? Mator's Merge Plugins Standalone] (MPS)
* [http://drive.google.com/open?id=0ByyDLPnmgtNVOUhNOWxlYWlQNWM Gribbleshnibit8's Merge Up Guide] (MUG)
* [http://www.youtube.com/watch?v=yq-fqpL5LqE Making a Merge Patch] video by '''Roy Batty'''
* [http://wiki.step-project.com/Guide:Merging_Plugins S.T.E.P. Guide to Merging Plugins]
* [http://github.com/TES5Edit/TES5Edit xEdit] (aka '''TES5Edit''' and various renamed specific game version names) on GitHub.
* [http://www.nexusmods.com/skyrim/mods/25859/? TES5Edit] on Nexus.
:* [http://tes5edit.github.io/docs/index.html Tome of xEdit] On-line Documentation.
:* [http://www.nexusmods.com/newvegas/mods/38413/? FNVEdit Training Manual] PDF document (applicable to all games).
* [http://loot.github.io/ LOOT]
* [http://github.com/matortheeternal/smash/releases Mator Smash]
:* [[Mator_Smash_Quick_Start|Mator Smash Quick Start]]
* [http://www.nexusmods.com/newvegas/mods/35003/? Wrye Flash]
:* [http://www.nexusmods.com/oblivion/mods/35230/? Wrye Bash Pictorial Guide]
* [https://www.afkmods.com/index.php?/topic/3337-skyrim-fixing-navmesh-deletion-using-tes5edit/ Fixing Navmesh deletion using TES5Edit by '''Arthmoor'''.] Thread.
* [http://www.youtube.com/watch?v=Q-ZQtgveKaM Fixing Deleted Navmesh with TES5edit by '''soupdragon'''] Video.
* [http://www.youtube.com/watch?v=babuNn5pzsw Filter for (find) Deleted Navmeshes with TES5edit by '''soupddragon'''] Video.
* [http://www.nexusmods.com/skyrim/mods/70285/? Guide for fixing deleted NavMeshes by '''AndrealphusVIII'''] Image guide.  (For Skyrim but works for deleted NavMeshes in general)
* [http://www.nexusmods.com/newvegas/mods/58562/? FNVLODGen]

==Details==
===Terminology===
First some terminology clarification.  Forgive me if this is covering old ground but it's better to ensure we are on the same page.

Mods have (among other file types) "plugin files" with ESM and ESP extensions.  In very broad terms, ESMs contain new "assets" and ESPs place those "assets" in the game world.  These files contain records which are alterations to the vanilla game records or add new records to the game.  In the normal course of events only the last such plugin to load that touches on a particular vanilla record "wins" when there are conflicting changes by different plugins.  The winning plugin wins completely: all the other plugins that "lost" are simply ignored in their entirety, even the non-conflicting records.  This is because the default conflict resolution behavior is "file" rather than "record" oriented.  This "only one can win" behavior is called "the rule of one".

A "merged [[plugin]]" combines more than one plugin into a single file.  This is typically done to reduce the number of active ESPs (and occasionally ESMs), but it also has the benefit of allowing non-conflicting records from other plugins included in the merge to be added to the game as well.  However, it is important to realize that "merge plugin" files DO NOT AUTOMATICALLY RESOLVE RECORD LEVEL CONFLICTS.  The "rule of one" still applies.

A "merged [[patch]]" combines more than one plugin's conflicting records to "resolve record level conflicts" and get a particular "winner" record as a result. The "Bashed Patch" (BP) created by Wrye Flash is such a "merged patch" file.  (We refer to the WF file as the "bashed patch" and the manually created one as the "merged patch" to distinguish between their origins.)  As a result it needs to be last (or near enough that no other plugin affects the same records) in the Load Order (LO) in order to ensure it's "winner" records remain the winners.  For this reason the usual advice has been to use only one such "merged patch".  If more than one patch file touches on the same record as the other, "the rule of one" comes into play and only one file will be used anyway.

So in the past you had to choose between using either the BP (which uses algorithms and "bash tags" to determine the winner) and a "roll your own" merged patch file.  But no longer.  Now you can combine the use of both a "merged patch" and a "bashed patch".  '''gromulos''' has provided a [https://forums.nexusmods.com/index.php?/topic/5479357-beginners-guide-to-xedit-merged-patch-wrye-bashed-patch-used-together/ "Beginners guide to Xedit merged patch / WRYE bashed patch used together"] which provides a "step by step" manual so the two work together due to some improvements to '''xEdit'''.

If you name your '''xEdit''' manually created merge patch file: "TES5Merged.esp", then '''LOOT''' will automatically sort it correctly (even when you include it in a load order with a Wrye "bashed patch" file.)

There is another mitigating factor though.  We use "merged plugins" to both reduce the plugin count and to ''manually'' determine the winners of some conflicts within a subset of conflicts.  Say we merge several plugins that affect "Perks".  There may be a few conflicting records.  We can manually determine which record wins in that "merged plugin" and then we have one file with only one "winner" record in each instance.  "Mator Smash" can be used to automate the conflict resolution among just these plugins as well, by producing a "Merged <purpose> - Smash.esp" file which is then "merged" in with the remainder of the plugins.  No internal conflicts, and unless there are other similar plugins not in our merge (which defeats one of the purposes, but perhaps not enough to forgo it), no other conflicting plugins.  It's a way of breaking down the problem into more manageable, smaller chunks.

A "[[Smashed]] Patch" produced by '''Mator Smash''' can used to provide "record level conflict resolution" for "merged plugin" files, and later as an alternative to the Wrye "bashed patch" if desired.

The arguments over which to use come down to how much control you want to exert over the result and how much time you are willing to spend to get that result.  The BP uses "bash tags" to enable an earlier loading plugin to win conflicts.  Otherwise the later loading wins.  A manually create "merged patch" is strictly controlled by the creator, who determines the conflict winner.  However, my BP affects over 10,000 records.  I prefer to spend the time playing instead of working out "winners" to that many record conflicts.  The '''xEdit''' "TES5Merged.esp" patch file as laid out by '''gromulos''' automates that pre-BP process to reduce those conflicts, and then you can edit the result to get exactly the winning record you desire, which gets passed on to the BP as the only record without conflicts.  "Mator Smash" also recognizes and uses "bash tags", but not in the exact same manner as the "Bashed Patch" process.  Please see the wiki [http://wiki.nexusmods.com/index.php/Bash_Tags_and_the_Wrye_Bash_Patch Bash Tags and the Wrye Bash Patch] article for details on determining which tags apply.

A "[[compatibility]] patch" is designed to enable two (or more) different mods to work together.  The "patch" file loads after the other plugins so it's records (with the reconciled differences between the other plugins) override those records in the prior loading plugins.  Note that the "rule of one" still applies, so you still need to use some form of "record level conflict resolution" such as a "bashed patch" or "merged patch" file, or the patch file plugin will negate the prior plugins it is supposed to patch.

A "[[Feature]]" or "[[Override]]" patch is similar to a "compatibility" patch in that it makes more than one mod work together, but it does so by adding "features" as "overrides" to one, giving it different results than originally.  It makes more fundamental changes to some aspects of the "master" plugin than a pure "compatibility" patch does.  But they are constructed in a similar manner.

:Tutorials on Compatibility Patches:
:* [http://www.youtube.com/watch?v=z61u0bQUmgM Making a Feature (Override) patch] video by '''Roy Batty'''
:* [http://wiki.nexusmods.com/index.php/Compatibility_Patching Compatibility Patching] (written description of the video "Making a Feature (Override) patch")
:* [http://www.youtube.com/watch?v=oKW3p3lUlNo FNVEdit BIS Compatibility Patch Tutorial 1]
:* [http://www.youtube.com/watch?v=PNQ-3PIIbfU FNVEdit BIS Compatibility Patch Tutorial 2-1]
:* [http://www.youtube.com/watch?v=3AcPsImi3E4 FNVEdit BIS Compatibility Patch Tutorial 2-2]
:* [http://www.youtube.com/watch?v=DEc1MB2BGUI FNVEdit BIS Compatibility Patch Tutorial 2-3]

As "compatibility patches" are working across multiple normally incompatible plugins, they are not candidates for "merge plugins".   Remember that "merging plugins" does not handle "record level conflict resolution".  For that you need either a '''Wrye''' "Bashed Patch", or a '''Mator Smash''' or '''xEdit''' "merged patch".

=== Merging ===
The latest tool for automated creation of merge files is [http://www.nexusmods.com/skyrim/mods/69905/? "Merge Plugins Standalone"] (MPS), which was released in December 2015.  '''Gamer Poets''' has an excellent video tutorial [http://www.youtube.com/watch?v=0S6cpCwTezE&feature=youtu.be Merge Plugins: Start to Finish] on installing MPS that includes instructions for both NMM and MO.  MPS is supported [http://forum.step-project.com/forum/99-mators-utilities-support/ here].  It uses the API for [http://www.nexusmods.com/newvegas/mods/34703/? xEdit (aka TES5Edit, FNVEdit, etc.)].  It makes the process very easy, but you do have to exercise some judgement and understand the problem areas it identifies for you as it uses a "merging down" approach.  Be sure to carefully read the included documentation.  Various setup choices may need to be revisited for each merge plugin such as record copying, FormID renumbering, and inclusion of "art assets".
{{xEdit Exclusivity}}

There are two potential problems with this automated "merging down" method.  One is that it has the ability to renumber "FormIDs" when they conflict between plugins.  This is often necessary but can cause "duplicate" entities with the same "name" but different IDs.  In the case of "Actors" if the "bash tag" "names" is used this can result in NPCs (such as "companions") sometimes appearing with "(dupe)" appended to their name, and sometimes not, which means there are two such actors with the same name and they will start to differ in particulars like their experience or carried items.  This is not a situation you want to have in your "saved games".  Such "merged down" results are effectively a completely new file.

The second potential problem is that this approach can also break any patches for the original plugin before it was merged.  "Patches" are designed for the original plugin's Form-IDs and will not work on these "merge down" result files, as their Form-IDs are now different.  However, if you "patch" before "merging", this then only becomes an issue when later patches are released, forcing you to re-patch the original files and re-build your merged plugin.

The original solution in both potential problem cases is to "merge up" using '''xEdit''' and following the PDF [https://drive.google.com/open?id=0ByyDLPnmgtNVOUhNOWxlYWlQNWM Gribbleshnibit8's Merge Up Guide] (MUG) instead of using Mator's "Merge Plugins Standalone" (MPS) as described in the remainder of this article.  The video [https://www.youtube.com/watch?v=yq-fqpL5LqE Making a Merge Patch] by Roy Batty and the [http://www.nexusmods.com/newvegas/mods/38413/? FNVEdit Training Manual] both use this "merge up" approach.  It is more complex and time consuming, but safer as well as more certain to produce your desired results.  There is now a section here devoted to that procedure with some supplemental information not covered in either those other guides.

Now that [https://github.com/matortheeternal/smash/releases Mator Smash] is available in an official release version, it provides a "one click" functional alternative way to '''''resolve record level conflicts''''' other than "merge up" or '''Wrye Bash''' and it's variants.  It works with "bash tags" and you can edit the results in '''xEdit''' to fine tune the results if desired.  It can also produce a "final patch" alternative to the Wrye "Bashed Patch".

But regardless of which approach is used, the basic concepts of what to include in different "merged plugins" still apply.  Once the "problem cases" have been "merged up" or "Smash Patched" you can use MPS to merge them with other non-conflicting plugins.

== Merge Up Procedure ==
This procedure conforms to the naming convention used in '''Gribbleshnibit8's Merge Up Guide''', and is best used with "patches" as the ModB files that only apply to the parent or ModA file.  ("Compatibility patches" to enable more than one plugin to work together should be in a "merged/bashed patch" file, which is a different process.)
{{Multi-file_Merge_Up_Procedure-1}}
{{Multi-file_Merge_Up_Procedure-2}}
{{Multi-file_Merge_Up_Procedure-2a}}
{{Multi-file_Merge_Up_Procedure-3}}
{{Multi-file_Merge_Up_Procedure-4}}
{{Multi-file_Merge_Up_Procedure-5}}
{{Multi-file_Merge_Up_Procedure-6}}
{{Multi-file_Merge_Up_Procedure-7}}
{{Multi-file_Merge_Up_Procedure-8}}
{{Multi-file_Merge_Up_Procedure-9}}
{{Multi-file_Merge_Up_Procedure-10}}
{{Multi-file_Merge_Up_Procedure-11}}

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.

== Merge Down Procedure ==
* First of all don't try to put everything into a single merge plugin.
* If you haven't already, ensure you don't have any "missing masters" required by any of your plugins.  See the Nexus FNV Wiki article [http://wiki.nexusmods.com/index.php/Missing_Masters Missing Masters] which describes how.
* Disable your "Bashed Patch" (BP) or manually created "merged patch" before working on merges, and activate any mods deactivated by it.
** You should be using a [http://www.nexusmods.com/newvegas/mods/35003/? Wrye Flash] Bashed Patch or a manually created "merge patch" file if you have many plugins.  (Resolves record level conflicts.)  See this [http://wiki.step-project.com/Guide:Merging_Plugins S.T.E.P. Guide to Merging Plugins] which covers both approaches.  (Use of "Mod Organizer" is not required.)
** You can manually create a "merge patch" file instead of using Wrye Flash, but if you play a heavily modded game WF is simply easier and "good enough" when thousands records are involved.  You can always use [http://www.nexusmods.com/newvegas/mods/34703/? FNVEdit] to tweak the resulting BP if desired.
** Use the [http://www.nexusmods.com/oblivion/mods/35230/? Wrye Bash Pictorial Guide] to quickly get functional with "Wrye Flash" and the "Mods" tab to build a "Bashed Patch", which I think is the easier approach for a novice modder.  Please see the wiki [http://wiki.nexusmods.com/index.php/Bashed_Patch_file_with_Marked_Mergeables Bashed Patch file with Marked Mergeables] article for supplemental "step-by-step" instructions to that guide if all you want to do is create a BP.

* Sort with [http://loot.github.io/ LOOT].  While it's results may not be 100% (primarily due to indirect masters that are not listed in a given plugin), the sort result can be adjusted and those changes incorporated into LOOT's "metadata" for future use.
* Follow the [https://forums.nexusmods.com/index.php?/topic/2247404-fallout-new-vegas-beginners-guide-to-modding/ "Fallout New Vegas Beginners guide to modding"] article by '''gromulos''' to get your  "Wrye Flash] (WF) "load order" check-boxes "green".  The article covers why this is a "good idea".

The mods that can go into a merge need to be "contiguously" adjacent in your load order (LO) (i.e. no other "active" mods not included in the merge between files being merged).  This provides your first clue as to how many separate merges you are going to need.

Note that once LOOT has sorted your LO, you can "move" mods up and down in the Wrye Flash "Mods" tab with <Ctrl+Cursor> keys to make them contiguous.  You can "group select" (<Shift+Click> or <Ctrl+Click>) files as well before moving them.  Likely other mod managers also provide this capability.  I always then run LOOT again to see if it doesn't like the result of my manual manipulations.  Sometimes it really wants to put a mod elsewhere that doesn't fit adjacently into a "merge group".  Personally I play it safe and leave such mods alone unless I feel really confident I know why it's safe to override LOOT's insistence.

As a general "placement" rule, the group needs to be positioned where the "highest numbered" (lowest in the LO list) is positioned.  This is where you should place the resulting merge plugin.  This is the primary reason you need all the mods you use active, even those that the BP may deactivate.

The S.T.E.P. guide [http://wiki.step-project.com/Guide:Merging_Plugins Merging Plugins] covers the basic "merge down" process very well in my opinion.  The following are some key points I learned to supplement it.

==Types of Merge==
The simplest merge to create is "non-conflicting" mods.  These are usually things that add new items, such as weapons or armor.  Let Wrye Flash deal with conflicting mods (i.e. "compatibility patches"), unless you don't like the results and want to create a "merged patch" file instead of using the Bashed Patch.  "Mator Smash" has now developed to the point where can also be used for this "patch of conflicting plugin records" purpose, but please bear in mind that it is still in development.  Use the "Smash Patch" or "Bashed Patch" for the final, overall record conflict resolution, but not both; or a manual "merged patch" file of the Bashed Patched file in order to get a different preferred "winner" in the case of particular records.  Note that if you "renumber FormIDs" you will lose any such items you already have in your save game's inventory, so this is best done before you start playing in earnest.  If "renumbering FormIDs" seems to be necessary, strongly consider using the "merge up" approach instead.

An example of this type of simple merge are the "Pre-Order Packs" (POPs; referred to by some as the "crap packs").  They just give you free starting equipment and nothing else.  You can remove them as long as you don't have any mods that use them because the POPs inject their records into "FalloutNV.esm" so that they can be overwritten without a master dependency. That's how patches like "Yukichigai Unofficial Patch (YUP)" are able to patch them without requiring them.

You can also merge all four of them together to save room, although that requires you to extract the contents of their BSAs and either repackage them to a BSA named for your "merge plugin" file or leave the contents as loose assets in your data folder. They will still work just fine with YUP and the like if you do this.  While most plugins shouldn't modify them, note that many that add or modify unique weapons, "weapon mods", or armor in them do require the individual ESM files to be present.  Know what mods you are going to install require before merging the POPs.

Be careful with plugins that add their own "configuration menu" by way of entries in the Pipboy tab menus such as "Apparel" or "Misc".  Usually these plugins need to be able to see their own ESP file in order to work correctly.  They do not make good candidates for a "merged plugin" for this reason.  Test in-game carefully if you do.  This does not seem to be an issue with plugins that use "Mod Configuration Manager" (MCM) instead, as long as they are not in the same "merge plugin" file.  You can merge them into separate "merge plugin" files, which results in them loading separately.

The next simplest merge is "fixes" that are unrelated to each other (because they aren't conflicting).  This might be considered a subset of the first group, but I find they are less likely to be updated over time, and therefor worth having in their own merge.  (Actually I have several such "fix" merges because they need to reside in different areas of my large load order.)

Third simplest are mods that all relate to a single topic mod (such as "Perks" or "Advanced Recon Armor").  Optional files for mods fall into this group UNLESS they are "patches" for other mods to work with the subject mod.  Those fall into the next group.  Here the LO is going to determine which of these merged mods wins any conflicts.

Less simple are files all related to an "overhaul package" such as Project Nevada, WMX, "Weapons of the New Millenia", etc. The primary issue here is dependencies (other files looking for a specific file name in the package as a "master", or that have a BSA file).

Merging quest mods are the most complex to do and not even expert mod creators would try and merge some mods like the SomeguySeries "New Vegas Bounties I-III, The Inheritance, Russell, etc." because renaming all the voice files without an automated solution would take eons of time.  Breaking dialogue is extremely easy to do. You'll run into issues where the worldspace and cell records need to be added first, then scripts and quests and there can be complications with references through out.  These kinds of things are best merged using GECK in version control mode. However that requires a server/client setup and has it's own set of complications. You can do it in FNVEdit, but only after gaining experience and knowing how to deal with the problems.  Compatibility patches are something else to keep in mind and you'll have to have to those loaded along with the mods they are patches for in order to not break them.  They are dependencies that won't work with your merged plugin otherwise.

Merges of patch files into their master plugin can be simple (only one master) or complex (multiple masters).  In either case, these should use the "merge up" approach identified above; not MPS.  "Mator Smash" can be used, but remember that: 1) it is still in development so the results need to carefully be examined and tested, and 2) it creates a completely new file with new Form-IDs.

MPS won't let you merge mods with "errors", but it does have an "ignore errors" option.  Be very skeptical about using this.  The only time I use it is for "Unknown flags" which have a value.  That just suggests FNVEdit doesn't know how to interpret the flag being used, which is not fatal (as far as I know).  I do not ignore "NULL references".  Those should be examined in FNVEdit or GECK and resolved or the plugin excluded.

==Complications==
* The things to always watch out for are:
# Unresolved errors; (fix them or exclude from merging)
# BSA files; (see the MPS "Advanced Options" tab) 
# Sound Files; (see the MPS "Advanced Options" tab) 
# Self-referencing scripts; (exclude them)
# Plugins that provide their own "in-game" configuration menus; (exclude them)
#* Plugins that use MCM (which is script based) seem to work fine if they are not merged together, but instead into separate "merge plugin" files with other (non-MCM) files.  That way they still are loaded separately from other MCM files, avoiding direct conflicts.  It is possible to merge MCM files from different plugins into a single merged MCM script, but requires some '''GECK''' script editing.  See the [[#How to merge MCM enabled mods|How to merge MCM enabled mods]] section.
# Deleted NavMeshes.  If these cannot be fixed, do not include the plugin in the merge.  For a guide on how to fix these, download the [http://www.nexusmods.com/skyrim/mods/70285/? Guide for fixing deleted NavMeshes] by AndrealphusVIII. (Written for Skyrim but works for deleted NavMeshes in general).  See also:
#* [https://www.afkmods.com/index.php?/topic/3337-skyrim-fixing-navmesh-deletion-using-tes5edit/ Fixing Navmesh deletion using TES5Edit by '''Arthmoor'''.] Thread.
#* [https://www.youtube.com/watch?v=Q-ZQtgveKaM Fixing Deleted Navmesh with TES5edit by '''soupdragon'''] Video.
#* [https://www.youtube.com/watch?v=babuNn5pzsw Filter for (find) Deleted Navmeshes with TES5edit by '''soupddragon'''] Video.
# NavMesh conflicts.  These need to be manually resolved in the game Editor, so are best left to the authors.  However, for "NAVI" errors, see the [[#NAVI NavMesh Conflicts|NAVI NavMesh Conflicts]] section. If this doesn't resolve the problem, leave out of a personal merge.
# Dependencies, all of which MPS will spot and tell you about with icons.  
# Patches.  The "merge down" process of MPS cannot handle patches correctly as they require preserving the FormIDs of the 'parent' plugin.  Use "Mator Smash" or the "merge up" process to deal with them.

* ESMs can be merged, but generally they are masters for dependencies and I leave them out (block from merging) just to avoid the complications.  While it is possible to deal with these issues, unless you want to become an advanced merge maker, it's easier to skip including files (i.e. "Block" them from merging) that have any of these issues.  There are usually plenty of other, simpler merges to get you under the plugin cap.

* Note that when you create a merge you may need to still have some elements of the original mod installed separately (ESMs, menus, etc) while others such as ESPs and meshes & textures can be included in the merge.  For this reason I recommend creating a "ReadMe" file for each merge plugin you create that lists which files are included and which still need to be installed separately.  I also find it useful to make note of mods I initially thought to include but later rejected and the reason why.  I also note any Bash Tags from the original mod, and which mod the merge needs to follow in the LO.  You can add the Bash Tags in the "Comments" section of the "Installer" tab of WF (aka BAIN) as "{{BASH:<tag>, <tag>, <etc>}}" (which then get picked up by LOOT), or individually in the "Mods" tab in the "Bash Tags" field in the bottom right part of the screen for the selected merge plugin.  Please see the wiki [http://wiki.nexusmods.com/index.php/Bash_Tags_and_the_Wrye_Bash_Patch Bash Tags and the Wrye Bash Patch] article for details on determining which tags apply.


==== How to merge MCM enabled mods ====
: Thanks to use '''helpful_visitor''' from the [http://taleoftwowastelands.com/viewtopic.php?t=6027 Tale of Two Wastelands] site and "The MCM Guide" by '''Pelinor''' (part of the MCM mod documentation) for the basis of the following.

<div name="Note Box" class="boilerplate metadata" id="Notice Box" 
style="margin:0px 10px 10px 10px;border:1px dashed #DAA520;color: lightgray;
background-color:#333333;padding:3px;
word-wrap: break-word;       /* Internet Explorer 5.5+ */
">There are three main issues that cause problems with multiple MCM scripts when merged into a single plugin:
# MCM "menu name items" with non-unique values (MCM "menu name items" are used to identify the plugin sub-menu in the left column of the Mod Configuration Menu, (i.e. where you click to pick which plugin you want to change settings for).
# Scripts that refer to the plugin file directly by name.
# Scripts that don't include logic for picking which MCM "menu name item" plugin the script refers to.

* To fix the first issue, all you have to do is give each MCM "menu name item" for every plugin you are going to merge a unique "Value" ("value" as in: "this selection's name").  You do this by defining each plugin "menu name item" (e.g. most mod creator's use a "Misc. Item" name) to have a unique "Value" that distinguishes it from all other plugin's "Misc. Item" names.

* The second issue requires fixing the scripts.  While that sounds ominous, in most cases it simply requires changing the same (or very similar) 1 or 2 lines of code and saving the result in the '''GECK'''.  The most common issue is that most MCM scripts reference the name of the plugin file and don't reference which MCM "menu name item" the script is for.  That's acceptable when there's only 1 "menu name item", but as soon as you add another "menu name item" (as when you merge plugins and scripts), the engine gets confused and you end up with MCM menus that don't display any options or they display the wrong options.

: Here is an example of how most MCM scripts look (the ";" comments are added to help explain the logic):
<div name="Note Box" class="boilerplate metadata" id="Notice Box" 
style="margin:0px 10px 10px 30px; border:1px dashed #DAA520; color: lightgray; background-color:#424242; padding:3px;"
word-wrap: break-word;       /* Internet Explorer 5.5+ */
">begin MenuMode 1013
: if IsModLoaded "The Mod Configuration Menu.esp"
: ; drop through to the "endif" for the remainder of the related script
: else
: ; If the MCM plugin isn't loaded, nothing to do ... so exit this script immediately.
:: Return
: endif
: ; The following one line is where we make our change:
: if (GetUIFloat "StartMenu/MCM/_ActiveMod" == GetModIndex "JIP Companions Command & Control.esp")
: ; lots of great menu definitions, etc. script for this plugin
: ...
: endif
end
</div>

: Changing the plugin name "JIP Companions Command & Control.esp" is obvious, as your merged plugin isn't ('''really should not''') be called the same name as one of the plugins you are merging.  You want to change this to some code that will work regardless of your merged plugin's name.  The following replacement line is suggested:

<div name="Note Box" class="boilerplate metadata" id="Notice Box" 
style="margin:0px 10px 10px 30px; border:1px dashed #DAA520; color: lightgray; background-color:#424242; padding:3px;"
word-wrap: break-word;       /* Internet Explorer 5.5+ */
">if (GetUIFloat "StartMenu/MCM/_ActiveMod" == GetSelfModIndex)
</div>
: This returns the index of the plugin according to the order in which it is loaded as detected by MCM.

* But the most important fix is for the third issue, which is adding logic that says which MCM "menu name item" this script is setup for (issue 3).  Most scripts don't have this logic, so we'll add it to our example from above:

<div name="Note Box" class="boilerplate metadata" id="Notice Box" 
style="margin:0px 10px 10px 30px; border:1px dashed #DAA520; color: lightgray; background-color:#424242; padding:3px;"
word-wrap: break-word;       /* Internet Explorer 5.5+ */
">if (GetUIFloat "StartMenu/MCM/_ActiveMod" == GetSelfModIndex  && GetUIFloat "StartMenu/MCM/_ActiveMenu" == 1)
</div>
: where "1" means this script will only work for the "menu name item" given the value of "1", which would be the MCM modindex of plugin "JIP Companions Command & Control.esp" from the example script above.

* To add another "menu name item" and it's related script to this "merged MCM script", just add another conditional logic block.  In this case we will restructure and break up our compound condition test to be more efficient:

<div name="Note Box" class="boilerplate metadata" id="Notice Box" 
style="margin:0px 10px 10px 30px; border:1px dashed #DAA520; color: lightgray; background-color:#424242; padding:3px;"
word-wrap: break-word;       /* Internet Explorer 5.5+ */
">if (GetUIFloat "StartMenu/MCM/_ActiveMod" == GetSelfModIndex
: if GetUIFloat "StartMenu/MCM/_ActiveMenu" == 1)
: ;   lots of great menu definitions, etc. script for this plugin
:    ...
: elseif GetUIFloat "StartMenu/MCM/_ActiveMenu" == 2)
: ;   lots of great menu definitions, etc. script for this plugin
: ...
: ; repeat 'elseif '_ActiveMenu' tests as often as needed for each merged MCM plugin
: endif ; of '_ActiveMenu' test blocks
endif  ; of '_ActiveMod' test block
</div>
: before the corresponding "endif" line, where "##" is the MCM mod index of the desired plugin.  Recall that the modindex is just another way to refer to plugin without using it's ESP filename.  See the "MCM Guide" doument Multiple Menus" section for more on this.

: If the MCM menu doesn't work as intended after you merge, you have to look through some of the other scripts to see if the original mod developer added a reference to the plugin file name somewhere else.  JIP CC & C actually embeds a couple of file name checks in quest scripts (I think only 1 checking for JIP CC&C.esp).

: You could always change that code to use some custom globals or just remove it but both those options require a bit more coding.  For the most part, the simple solution outlined above will work for a large number of MCM enabled mods.

=== NAVI NavMesh Conflicts ===
Sometimes after merging plugins, you will see a Pop-up window:
<pre>
 "There were some NavMesh conflicts. You'll need to rebuild these navmeshes in the CK:
[< Merged Plugin Filename >.esp] (i.e. "[Merged - More Perks.esp]")
 [NAVI:<Form-ID>] (i.e. "[NAVI:00014B92]")
</pre>
This pop-up does not currently create an entry in the log files, so be sure to note the "NAVI:<Form-ID>" given.

In '''xEdit''': search on the NAVI < Form-ID > (i.e. "00014B92"), which should return:
 "< Filename > \ Navigation Mesh Info Map \ < Form-ID >", as in:
 "FalloutNV.esm \ Navigation Mesh Info Map \ 00014B92" in the "View" tab.

According to Mator:
<div name="Simulated code box" class="boilerplate metadata" id="Warning Notice" 
style="margin:0px 10px 10px 10px; border:1px dashed #DAA520; color: lightgray; background-color:#424242; padding:3px; 
/* Remove the next four 'white-space' lines to restore default white-space processing. */
white-space: pre-wrap;       /* css-3 */
white-space: -moz-pre-wrap;  /* Mozilla, since 1999 */
white-space: -pre-wrap;      /* Opera 4-6 */
white-space: -o-pre-wrap;    /* Opera 7+ */
word-wrap: break-word;       /* Internet Explorer 5.5+ */
">NAVI records are used to effectively "connect" a bunch of navmesh and door records into a single "network". When you merge multiple plugins that affect the same NAVI record, merge plugins follows the rule of one and takes the winning NAVI. The issue is that conflicting NAVI edits really need to be merged. If your smashed patch handled NAVI records then this shouldn't be a problem. If it didn't then you will need to load the ESP in the CK and save it (the CK will automatically build correct NAVI information). Loading in the CK requires you to ''ESMify'' the plugin's masters for things to not get clobbered.</div>

In other words, you may need to ''ESMify'' some of the master plugins of the "Merged Plugin" file (if necessary), load those ESM masters and the "Merged Plugin.esp" (set as the "active file") into the Construction Kit, and save the result immediately as the "Merged Plugin" file again or as a new filename.

"ESMify" refers to temporarily changing the "File Header" record of an ESP file to indicate it is actually an ESM file.  (You can ''ESMify'' an ESP file by loading it into '''xEdit''', selecting the plugin in question in the left-hand pane and expanding it (< Left-Click > on the "+" to the left of the plugin name), and select "File Header".  In the "View" tab in the right-hand pane, toggle the "ESM" flag on.  Upon exiting this will create a new "duplicate" of the ESP file, but with an ESM extension.)  When you do save that changed result, you may get a warning that there are now two files with the same filename (which is true: but the newest one will now have an ESM extension).  Read the warning carefully.  If it is saying there already exists an ESM file with the same name, then you need to be loading that file instead of "ESMifying" the ESP.  The one with the ESM extension is the one you need to load into GECK (along with any other ESM masters to your "merged plugin") and the "Merged Plugin" itself set as the "active file".  Then simply save immediately without actually doing anything.  That should rebuild the NAVI record and resolve the conflicts with the other master files' NAVI records in your "Merged Plugin" file.

You don't need to keep the ESM versions of those files afterwards, though. They should be removed when done.  (This is primarily to avoid breaking anything that depends upon those being ESP files, such as sound files, etc.  Also because the game really doesn't expect ESP files to act as if ESMs.)  Leaving both around will cause the game to use the ESM files even though the ESPs still exist.  Avoid confusing the game engine.  An ESM is not inherently superior to an ESP file.

=== Errors preventing merges ===
Most errors in a plugin that MPS cannot resolve are not going to work in the game anyway.  The general approach is then to remove them from the plugin using '''xEdit''', so you can merge the result.  Some you can attempt to "read the mind of the author" and correct yourself if you can figure out how things were supposed to be.  But most can simply be done without.

Mator has a video covering the basics of this removal process intended for users of MPS: [https://www.youtube.com/watch?v=Zr7pz4JGSEM TES5Edit - Fixing Errors].  For those who prefer written instructions, or clarification of points raised in the video, see the TES5Edit documentation [https://www.creationkit.com/index.php?title=TES5Edit_Documentation#Mod_Cleaning_and_Error_Checking Mod Cleaning and Error Checking].  To help with understanding the record types, see the next section.

'''xEdit/TES5Edit''' TIP: Once you have identified an error ("Message" tab in the right-hand pane), locate the Form-ID within "[square brackets]" in the error message and < Ctrl+LeftClick > on it to be taken to that record in the left-hand pane.  Then you can either attempt to fix it or < Right-Click > on the record to delete it.  (You usually can't delete just a sub-record without deleting the whole thing.)

Not everything can be fixed with '''xEdit'''.  Sometimes, all you need is to load the original or merged plugin file into the '''Construction Kit''', and immediately re-save it without changing anything.  That alone will sometimes resolve the issues, as some "unresolved references" like QSTI or NAVI sub-records that '''xEdit''' won't touch or applies the "rule of one" to will automatically be removed or fixed.  If that isn't sufficient, reconsider including that plugin in your merge unless you really want to get involved in editing it.  Not everything should be merged.

If the plugin requires a "Script Extender" like NVSE, be sure to have your '''Construction Kit''' load with it.  (This is generally a good idea even if not required.)  Use the [http://www.nexusmods.com/newvegas/mods/ GECK Power-Up v1.4] version (which is NVSE aware) or see [[#Issue:_How_to_get_GECK_to_load_with_NVSE?|Issue: How to get GECK to load with NVSE?]].
{{Fallout Record Types}}

==Finishing the Process==
* Examine the resulting merge in '''xEdit''' for any errors or undesired conflict results.  IF there are any, resolve them or remove the plugin from the merge.

* The MPS places the resulting merge file in it's own folder.  You will need to copy and create a "package" (7zip or RAR file) to keep your ReadMe with the plugin and any assets.  (I recommend you create a naming convention to make it easier to identify your merges: i.e. "Merge - <purpose>".)

* Install the merged plugin you just made.

* Run LOOT and adjust in the LO as needed to get it placed just after where the highest numbered plugin that was merged is located.

* Disable all the mod plugins that have been merged.  (I uninstall them, and then re-install only the necessary files not included in the merger according to my ReadMe information because I use WF as my mod manager and then I can "Anneal All" to resolve "Install Order" issues.)

* Use the "metadata" capability of LOOT to identify the plugin that your merge needs to "Load After" to ensure it is placed correctly in your LO.  Use the metadata's: "required" field to identify plugins that are "indirect masters" but not in your "merged plugin" list of "master files".  (This "required" field is ONLY for master files not included in a mod's list of masters.  Consider adding the missing master to that plugin's list by means of FNVEdit instead.)  Note this "metadata" may need updating if you add other mods later or rebuild the merge.

* Run LOOT again to ensure no issues have been created when you disabled or uninstalled mods that were merged (such as "missing masters"), and that your LOOT metadata information is working as intended.

* Run [http://www.nexusmods.com/newvegas/mods/58562/? FNVLODGen] to rebuild your LOD files (because you have greatly changed your LO and the LOD "quads" are LO dependent.)  Please see the [http://www.darkcreations.org/testg/wiki/Category:VWD-OB LOD/VWD Overview] page on "The Elder Scrolls Texture Guide (TESTG)" site if this tool or the reasons behind using it are not familiar to you.

* There is a '''xEdit''' "Generate Bash Tags" script (available in the supplemental package [http://github.com/fireundubh/xedit-scripts xedit-scripts] from '''fireundubh''') which can determine more Bash Tags for a mod than the default "BASH tags autodetection.pas" script, including your newly created "merged plugins" and Smash "merged patch" files for those plugins.
:* Note that '''fireundubh's xedit-scripts''' require two library files (not included in that package).  These are available on the same site as individual text files.  Copy the "raw" versions and paste into a "plain text" (e.g. '''Notepad'''; not '''Write''') editor and save with that '''exact name'''.  Then place both saved files in the '''xEdit''' sub-folder "Edit Scripts".  The libraries and their links are:
::* [http://github.com/matortheeternal/TES5EditScripts/blob/master/Edit%20Scripts/mteFunctions.pas mteFunctions.pas]
::* [http://github.com/fireundubh/xedit-scripts/blob/master/lib/dubhFunctions.pas dubhFunctions.pas]
:* Note that "Mator Smash" uses "tags" differently: as a set of named logical groups that point to the specific data in records to process by the patcher.  "Smash" (at least at the moment) applies tags to all records.
::* Run the script against your newly created Smash "merge patch" for plugins that will go into a "merged plugin" file.
::* Then run the script again against the "merged plugin" file.
:* However, when you use the "Bashed Patch" you still have to exercise some judgement as the "tag generator" script can't tell if you really want Wrye Bash to apply those tags to that mod.  Only use a Tag for Bash when it is IMPORTANT that mod's tagged records win.  Just because a tag can be applied is not a reason to do so.  Remember that when more than one mod has the same Bash Tag applied to it's record, the LAST tagged wins.
:* Please see the wiki [http://wiki.nexusmods.com/index.php/Bash_Tags_and_the_Wrye_Bash_Patch Bash Tags and the Wrye Bash Patch] article for more particulars.

* Rebuild your Bashed Patch (or "merged patch" file).  As you are reading this article in order to reduce your plugin count, you want to be sure to include the "Mark Mergeable" step.  Please see the wiki [http://wiki.nexusmods.com/index.php/Bashed_Patch_file_with_Marked_Mergeables Bashed Patch file with Marked Mergeables] article on how to accomplish this.

* Test each merge plugin just like the original mods before moving on to the next merge.  The time to find problems is now, before they get into your save game.

* While you can add a new plugin to an existing merge, you have to completely redo it to remove one.  This is another reason to have several rather than one massive merge.

=== Combining '''Smashed Patches''' and '''Merged Plugins''' ===
According to '''Mator''', the author of both:
<div name="Simulated code box" class="boilerplate metadata" id="Code box sim" 
style="margin:0px 10px 10px 10px; border:1px dashed #DAA520; color: lightgray; background-color:#424242; padding:3px;"
background-color:#fff5f5;padding:3px; 
/* Remove the next four 'white-space' lines to restore default white-space processing. */
white-space: pre-wrap;       /* css-3 */
white-space: -moz-pre-wrap;  /* Mozilla, since 1999 */
white-space: -pre-wrap;      /* Opera 4-6 */
white-space: -o-pre-wrap;    /* Opera 7+ */
word-wrap: break-word;       /* Internet Explorer 5.5+ */
">
* '''Merge Plugins''' does not do ''conflict resolution''; rather it combines records in plugin files following the "rule of one".<br>
* '''Mator Smash''' is a "one-click" operation that generates a ''compatibility patch'' which selectively combines edits on conflicting records based on user settings.  They are entirely different programs, and should be used together, not separately.  E.g. make a '''Smashed Patch''' for some plugins you plan on merging, and include it in the '''Merged Plugin'''.  Make a '''Smashed Patch''' over your entire load order, including any '''Merged Plugins'''.<br>
...<br>
* '''xEdit''' Merged Patch: Generates a ''compatibility patch'' for specific plugins, processing all conflicts in a fixed set of records/subrecords.  Always generates the same patch given the same records.  Generally unreliable, unable to handle a large number of conflicts.
</div>

* Make a "Smashed Patch" for the plugins you intent to merge.
: (It should not be named the same as your final "Smashed Patch" file.  You can have multiple "Smash Patches" for sub-sets of plugins with any names, so use one related to the plugins for which it is resolving conflicts.)
* Include that "Smashed Patch" in the "Merged Plugin" file.
* Smash ''everything'' after all merges have been completed.
: This will be your "final" '''Smashed Patch''' file.  Please keep in mind that the current "intended" use case is to generate a patch and then tweak it in '''xEdit''' manually after generation.
* Place the final '''Smashed Patch.esp''' at the end of your "load order", similarly to with a "Bashed Patch".
: Note that LOOT will recognize the file name '''Smashed Patch.esp''' in it's masterlist, tagged with "NoMerge",  global priority the same as '''Bashed Patch''', and additionally set to load after '''TES5Merged.esp'''.

See the [http://wiki.nexusmods.com/index.php/Mator_Smash_Quick_Start Mator Smash Quick Start] guide for help getting "Smash" initially configured for games other than Skyrim, along with additional information and resource links.

==Merged Patch, a Bashed Patch, or both?==

===Which to use===

A manually created Merged Patch and Bashed Patch both at the same time would be redundant.

If you have an easy or straightforward "load order" and you want to keep it simple, use the "TES5Merged Patch" from FNVEdit (xEdit).  A guide to this is the '''gromulos''' article linked above and the wiki article [http://wiki.nexusmods.com/index.php/Load_order_and_you Load order and you].

If you want more control over what will exactly be merged (take the time to study the Bashed Tags and comprehend what they do), then go for the "Bashed Patch" from Wrye Bash/Flash.  See the [http://www.nexusmods.com/oblivion/mods/35230/? Wrye Bash Pictorial Guide].

With a complicated load order with many merged files, either tailor a "TES5Merged Patch" file to eliminate the conflicts, or create one manual "Override.esp" to correct or add things the Bashed Patch didn't take into account or "get right" for your purposes.  This uses the same FNVEdit technique as creating a "Merged Patch".

For example let's say you have three mods that alter weapons (i.e. two ESM's and one ESP), the merged patch strictly follows your load order and the modifications made by the ESP will win as it is loaded after your ESMs.  In case of the Bashed Patch you can bypass that load order limitation by assigning Bash Tags to the loaded mods you wish to win and it will import the things you selected, so it is more configurable than the Merged Patch.

But let's say you want the weapons stats from the first ESM, the "on dead" effects from the second (like the beautiful energy weapons criticals from EVE) and the weapon mods from the third, and "bash tags" aren't giving you the result you want.  Perhaps a "TES5Merged Patch" file is enough to give the BP an easy solution.  But if not, then you have to create a manual "Override patch" placed after the "Bashed Patch" to do just that. (By copying the weapons into a blank ("new") ESP file that is loaded after the "Bashed Patch" and copying the things needed from the three mods in this example.)  Same thing for character appearances: Lings Coiffure and Project Mikoto's mods can be made to work together this way for example, by selecting the NPC records you want from both.  The possibilities are virtually endless, provided you are willing to put the time and effort into it.

===TL;DR Summary===
* want it simple with no headaches (except the time it takes to make)?  Go for a '''xEdit''' "Merged Patch".
<div name="Simulated code box" class="boilerplate metadata" id="Warning Notice" 
style="margin:0px 10px 10px 10px; border:1px dashed #DAA520; color: lightgray; background-color:#424242; padding:3px;
/* Remove the next four 'white-space' lines to restore default white-space processing. */
white-space: pre-wrap;       /* css-3 */
white-space: -moz-pre-wrap;  /* Mozilla, since 1999 */
white-space: -pre-wrap;      /* Opera 4-6 */
white-space: -o-pre-wrap;    /* Opera 7+ */
word-wrap: break-word;       /* Internet Explorer 5.5+ */
">(See <span style="color: red; text-decoration: line-through;">[https://forums.nexusmods.com/index.php?/topic/5479357-beginners-guide-to-xedit-merged-patch-wrye-bashed-patch-used-together/ "Beginners guide to Xedit merged patch / WRYE bashed patch used together"]</span> by  '''gromulos''', and [http://wiki.nexusmods.com/index.php/Load_order_and_you Load order and you].

WARNING - As of 8-11-2017: The "Beginners guide to Xedit merged patch / WRYE bashed patch used together" link is deliberately broken.  The author says it is obsolete guidance in the (updated) first post of his "[https://forums.nexusmods.com/index.php?/topic/2247404-fallout-new-vegas-beginners-guide-to-modding/ Fallout New Vegas Beginners guide to modding]" guide.)</div>
* need less control or have a massive number of records to deal with?  Go for a '''Wrye''' "Bashed Patch" (see [http://www.nexusmods.com/oblivion/mods/35230/? Wrye Bash Pictorial Guide]) or a final '''Mator''' "Smash Patch".
* Want headaches and other pains but have a great game afterwards?  Combine the two approaches for a '''Wrye''' "Bashed Patch" + custom '''xEdit''' "Override.esp" loaded after it.

<span name="Note Box" class="boilerplate metadata" id="Notice Box" 
style="margin:0px 10px 10px 10px;border:1px solid #00C600;color: green;
background-color:#fff5f5;padding:3px;
word-wrap: break-word;       /* Internet Explorer 5.5+ */
">
A custom "override" file is not dependent upon the "Bashed Patch" (the BP is not in it's masterlist), but it is rather complementary to the BP.</span>  Even the "Bashed Patch" with "bash tags" can only do "so much".

For more in depth on "bash tags" (their role and how to determine which to use), see the wiki article [[Bash_Tags_and_the_Wrye_Bash_Patch|Bash Tags and the Wrye Bash Patch]].

Another example that will hopefully help to make it clearer:  Suppose you have many mods active that alter NPC appearances.  Unfortunately if you "bash tag" all these files with "npcfaces" the last loaded will win and all NPCs it alters will have the appearance they have in that last mod.  However, if you prefer the appearance for particular NPCs only that are in a mod that's higher in your load order, do "copy as deep override" with 'xEdit' on all NPCs you want to have a different appearance into your custom override file and load it after the BP to override the BP's changes you don't want.  So the custom override file has many masters, but the BP is not one of them.

So theoretically you could end up with three final "patch" files at the end of your load order:
* 1. "TES5Merged.esp" (manually created with xEdit): Global: 80, Priority: 1
* 2a. "Smashed Patch.esp" (automatically created with Mator Smash and manually tweaked with '''xEdit'''): Global: 80, Priority: 2
: OR
* 2b. "Bashed Patch, 0.esp" (automatically created with Wrye Bash/Flash): Global: 80, Priority: 2
* 3. "Override.esp" (manually created with xEdit): Global: 80, Priority: 3
'''LOOT''' can recognize these specific filenames and automatically place them in this sequence if you give them the "Global" and "Priority" values indicated in their respective "metadata" cards.  (By default both values are "0".)


== References ==

*[http://www.nexusmods.com/skyrim/mods/69905/? Mator's Merge Plugins Standalone] (MPS) 
*[http://www.youtube.com/watch?v=0S6cpCwTezE&feature=youtu.be Merge Plugins: Start to Finish] Video tutorial by '''Gamer Poets''' 
*[http://drive.google.com/open?id=0ByyDLPnmgtNVOUhNOWxlYWlQNWM Gribbleshnibit8's Merge Up Guide] (MUG) 
*[http://www.youtube.com/watch?v=yq-fqpL5LqE Making a Merge Patch] Video by '''Roy Batty''' 
*[http://wiki.step-project.com/Guide:Merging_Plugins S.T.E.P. Guide to Merging Plugins] 
*[http://www.nexusmods.com/newvegas/mods/34703/? xEdit (aka TES5Edit, FNVEdit, etc.)] 

:
:*[http://tes5edit.github.io/docs/index.html Tome of xEdit] Current online manual for all games 
:*[http://www.nexusmods.com/newvegas/mods/38413/? FNVEdit Training Manual] (PDF)   

*[http://loot.github.io/ LOOT] 
*[http://github.com/matortheeternal/smash/releases Mator Smash] 
*[http://www.nexusmods.com/newvegas/mods/35003/? Wrye Flash] 

:
:*[http://www.nexusmods.com/oblivion/mods/35230/? Wrye Bash Pictorial Guide]   

*[https://www.afkmods.com/index.php?/topic/3337-skyrim-fixing-navmesh-deletion-using-tes5edit/ Fixing Navmesh deletion using TES5Edit by '''Arthmoor'''.] Thread. 
*[http://www.youtube.com/watch?v=Q-ZQtgveKaM Fixing Deleted Navmesh with TES5edit by '''soupdragon'''] Video. 
*[http://www.youtube.com/watch?v=babuNn5pzsw Filter for (find) Deleted Navmeshes with TES5edit by '''soupddragon'''] Video. 
*[http://www.nexusmods.com/skyrim/mods/70285/? Guide for fixing deleted NavMeshes by '''AndrealphusVIII'''] Image guide. 
*[http://www.nexusmods.com/newvegas/mods/58562/? FNVLODGen] 
*[http://www.youtube.com/watch?v=z61u0bQUmgM Making a Feature (Override) patch] Video by '''Roy Batty''' 
*[http://www.youtube.com/watch?v=oKW3p3lUlNo FNVEdit BIS Compatibility Patch Tutorial 1] 
*[http://www.youtube.com/watch?v=PNQ-3PIIbfU FNVEdit BIS Compatibility Patch Tutorial 2-1] 
*[http://www.youtube.com/watch?v=3AcPsImi3E4 FNVEdit BIS Compatibility Patch Tutorial 2-2] 
*[http://www.youtube.com/watch?v=DEc1MB2BGUI FNVEdit BIS Patch Tutorial 2-3] 
*[http://forums.nexusmods.com/index.php?/topic/5479357-beginners-guide-to-xedit-merged-patch-wrye-bashed-patch-used-together/ "Beginners guide to Xedit merged patch / WRYE bashed patch used together"] 
*[http://forum.step-project.com/forum/99-mators-utilities-support/ Mator's Utilities Support] 
*[http://www.nexusmods.com/newvegas/mods/34703/? xEdit (aka TES5Edit, FNVEdit, etc.)] 
*[http://wiki.nexusmods.com/index.php/Missing_Masters Missing Masters] 
*[http://forums.nexusmods.com/index.php?/topic/2247404-fallout-new-vegas-beginners-guide-to-modding/ "Fallout New Vegas Beginners guide to modding"] by '''gromulos''' 
*[http://www.youtube.com/watch?v=Zr7pz4JGSEM TES5Edit - Fixing Errors] 
*[http://www.nexusmods.com/newvegas/mods/ GECK Power-Up v1.4] 
*[http://www.creationkit.com/index.php?title=TES5Edit_Documentation#Mod_Cleaning_and_Error_Checking Mod Cleaning and Error Checking] 
*[http://en.uesp.net/wiki/Tes5Mod_talk:Mod_File_Format Tes5Mod talk:Mod File Format] 
*[http://libraries.io/github/TES5Edit/fopdoc TES5Edit/fopdoc] as of 2 Jun 2014 
*[http://guides.github.com/features/mastering-markdown/ GitHub Flavored Markdown] 
*[http://forums.nexusmods.com/index.php?/topic/5479357-beginners-guide-to-xedit-merged-patch-wrye-bashed-patch-used-together/ "Beginners guide to Xedit merged patch / WRYE bashed patch used together"] by '''gromulos''' 
*[http://wiki.nexusmods.com/index.php/Load_order_and_you Load order and you] 
*[http://www.darkcreations.org/testg/wiki/Category:VWD-OB TESTG: LOD/VWD Overview] 
*[http://github.com/fireundubh/xedit-scripts xedit-scripts] by '''fireundubh''' 
*[http://github.com/matortheeternal/TES5EditScripts/blob/master/Edit%20Scripts/mteFunctions.pas mteFunctions.pas] by '''fireundubh''' 
*[http://github.com/fireundubh/xedit-scripts/blob/master/lib/dubhFunctions.pas dubhFunctions.pas] by '''fireundubh''' 

Nexus wiki articles referred to by this article:

*[[Mator_Smash_Quick_Start|Mator Smash Quick Start]] 
*[[Missing_Masters|Missing Masters]] 
*[[Fallout_NV_Mod_Conflict_Troubleshooting#Issue:_How_to_get_GECK_to_load_with_NVSE?|Issue: How to get GECK to load with NVSE?]] 
*[[Load_order_and_you|Load order and you]] 
*[[Bash_Tags_and_the_Wrye_Bash_Patch|Bash Tags and the Wrye Bash Patch]] 
*[[Bashed_Patch_file_with_Marked_Mergeables|Bashed Patch file with Marked Mergeables]] 

<br/> <br/> Nexus wiki articles that refer to this article:

*[[FNV_General_Mod_Use_Advice|FNV General Mod Use Advice]] 
*[[Fallout_NV_Mod_Conflict_Troubleshooting|Fallout NV Mod Conflict Troubleshooting]] 
*[[Bash_Tags_and_the_Wrye_Bash_Patch|Bash Tags and the Wrye Bash Patch]] 
*[[Mator_Smash_Quick_Start|Mator Smash Quick Start]] 

<br/> &nbsp;

[[Category:Tutorials]] [[Category:Tools]] [[Category:New Vegas]] [[Category:Modding_Guides]]