Merge multiple mods in a category, easier management then just throwing them together. I never reach stage 3 for skyrim but with new vegas having half the plugin limit i often get to stage 4. If your getting to stage 5, evaluate your damn mod list because unless you have 1001 weapon plugins you probably don't need everything you have. The console is a debugging tool in the PC version of Fallout: New Vegas. It is useful for altering content while in-game and working around bugs, but may be used to cheat as well. Use the backquote key while in-game (Unpaused). The backquote key shifts to tilde on U.S. Keyboards, and the not symbol (') on UK keyboards. Other keyboards with different layouts will differ, but the key is. Creating 'merged plugins' is a great way to reduce the number of plugins in your 'load order' to keep under the 'Plugin cap' for a particular game. See the wiki article Merged Plugin Guidelines for Personal Use for advice on choosing the appropriate plugins and procedures for this purpose. If new plugins are added, be sure to run LOOT to sort your load order 6. Refer to the Load Order General Guide if you are unsure of load order. There are a few places to look for TTW compatible mods 1. Refer to the recommended mod list for ideas 2. Check the TTW mod releases forums 3. Most mods on the Fallout New Vegas Nexus should be.
|
For TES and Fallout Bethesda games, primarily Skyrim
Introduction
Bethesda role playing games using the Gamebryo engine, including The Elder Scrolls games (TES4 and TES5) and Fallout games (Fallout 3, Fallout NV, and Fallout 4), have a limit of 255 plugins (roughly 140 for Fallout New Vegas). While this may seem like a lot, most heavily modded games need more plugins than allowed with this limit. Teoria de los colores goethe libro pdf gratuito. This small guide outlines the primary methods for merging existing plugins and for creating plugins that merge conflict resolutions and content for multiple mods.
There are multiple methods that can be used to merge all or portions of esp plugin files to allow large collections of plugins to fit inside the plugin limit of Bethesda games. Some of these methods create or merge compatibility patches for multiple mods using a single esp plugin, thus reducing the need for multiple esp plugins to provide compatibility patches for various pairs of mods.
The techniques below are listed in order of increasing complexity. With the exception of the Wrye Bash methods below, all the techniques described here require a good understanding of TES5Edit (or equivalents for other games including TES3Edit for Morrowind, TES4Edit for Oblivion, FO3Edit for Fallout 3, FNVEdit for Fallout New Vegas, FO4Edit for Fallout 4), and the record structures of plugins.
Until recently the only tools that could provided automatic merging of mods for Bethesda games were TES4Gecko which automatically merges Oblivion plugins, and FNVPlugin which merges Fallout New Vegas plugins.Mator'sMerge Plugins provides very capable mod merging tools that can be used across all the Bethesda games that are much more capable than any older merging tools. The x in xEdit stands for the first three letters of each of the separate editors for each of the Bethesda games. Merge Plugins requires the most recent version of xEdit which is available at the Fallout 4 reference above.
This guide does not cover the use of patches created by SkyProc or other similar tools. In Skyrim, SkyProc is used by several active Skyrim mods (e.g., ASIS, Dual Sheath Redux) to create mod-specific patches.
The rest of this guide discusses several tools used for mod merging and conflict resolution.
Merging Mods Without Conflicts
Automatic Merging of Multiple plugins with Merge Plugins
Mator's Merge Plugins utility has evolved to where it provides a simple way to do even complex merges. It is now possible to merge Fallout and Oblivion plugins, a particularly useful feature since Fallout NV cannot handle nearly as many plugins as other Bethesda games. The FAQ in the Nexus description for the Merge Plugins is also quite valuable since it covers the major issues associated with merging plugins including problems caused by changing FormIDs (as discussed later in this guide). Support for this utility is available as part of Mator Utilities Support on the STEP site.
Merge Plugins
Mator's Merge Plugins utility can be used to merge theoretically any installed mod with any other installed mod following 'The Rule of One', which requires that the behaviour of the assets after the merge are identical to their behaviour before. This includes mods containing Papyrus scripts (.pex files), NAVM/NAVI (navmesh) records and FormIDs (new objects created by the plugin). Adobe flash professional cs6 mac.
A very thorough tutorial on installing, configuring and using Mator Merge Plugins Standalone by Gamer Poets can be found here Merge Plugins: Start to Finish.
For mods that don't create objects used by other mods that aren't being merged, the resulting merged mod should be free of any problems. Examples of mods like this are (note the examples are old and will be replaced shortly with some newer examples)
- Atlas Map Markers plugins in Skyrim) with multiple plugins to support different DLCs, and
- Immersive Patrols with multiple plugins for different NPC categories that can be encountered.
The current version of the Merge Plugins utility can also merge mods without changing the FormIDs, thus preserving the capability to use items in these mods without the need to revise all the mods that use these items. This also preserves items that already exist in saved games.
The Merge Plugins utility also works well with mods that provide items like armor and clothing. The only issue with these mods is that if the mods being merged change sufficiently when updated then a new merge of the underlying mods might not preserve all of the objects in a players inventory, as discussed in the Q: My hair's gone?! My armor's gone?! My weapons are gone?! My face is gone?!?!WHAAATTTT?!!!?! question in the FAQ for the older script version of the mod. This won't be an issue if FormIds were not renumbered.
Merges of mods with conflicts uses the standard Rule of One approach that is also used in the Bethesda engine itself. The latest loading plugin that affects each object will be included in the merged plugin. A check for conflicts can be done manually by looking at the records and subrecords in xEdit or by using the Conflict Filters capability in xEdit described in section 4.3 of the FNVEdit Training Manual.
If the plugins being merged are compatibility patches, particular care must be taken since these patches typically need to load later in the mod load order and because there might be conflicts across different compatibility patches that need to be resolved. If this automated technique is used, it is a good idea to create one plugin that combines the optional patches for an individual mod vs. creating one plugin across many different mods since the automated method uses the simple Rule of One to handle conflicts. If the plugins being combined are from the same mod, always start with the plugin for the main portion of the mod if it is being merged. For large mods with multiple compatibility patches it's usually best to merge only the patches. The advantage of including the main mod is that there may be intentional overwrites in the DLC or optional capability plugins, and if the main mod is included then by adding the main plugin first the combined plugin will have the correct records.
The merged mods created by the Merge Plugins mod can merge plugins with navmesh records, but if more than one of the plugins includes navmesh overides some additional steps are needed before using the newly merged plugin. These steps are described in this post and this post in the A Real Explorer's Guide to Skyrim topic. These require deleting navmesh records in the plugin and then opening the merged plugin in the Creation Kit. An excellent detailed example of how to do this is available in one of the documentation forums for the Skyrim Expanded Towns and Villages mod.
Using LOOT (Load Order Optimization) to maintain proper load order
The patches created by this method will not be in the normal 'LOOT' list, so it is recommended that the load order assigned by LOOT should be checked, and if necessary the LOOT GUI can be used to cause the mod to load later. The STEP guide includes a set of LOOT rules for sorting Skyrim plugins.
Automatic Merging of Plugins that can have Conflicts
Automatic Merging by the Skyrim Executable
This STEP forum topic, which includes a pointer to this Afkmods post by Arthmoor, discusses the record types that are automatically merged by Skyrim itself. Dao tucked hair mod. For these there is no need for any additional merging. There are not many such record types, but it is important to know which ones are included.
Wrye Bash for TES games and Wrye Flash for Fallout games
Wrye Bash can create a bashed patch containing resolutions for some of the conflicts between plugins. Key capabilities of the bashed patch are:
- some plugins can fully merged into the bashed patch, and these plugins can then be disabled,
- some tweaks can be added to the bashed patch, avoiding the need for a plugin to set these (e.g., crime radius and maximum number of companions in Skyrim), and
- a few data record types, such as leveled lists, can be merged automatically in the bashed patch avoiding the need to manually create a compatibility patch for these.
Documentation on creating a bashed patch with Wrye Bash is available in the Bashed Patch section of the General Readme for Wrye Bash (use the '?' icon on the bottom of Wrye Bash to display this file) and in the Wrye Bash Pictorial Guide. There is also a video on this and additional discussion on Wrye Bash in the STEP Wrye Bash guide. The bashed patch can automatically resolve and merge several types of conflicts between mods.
The data record merging used in the bashed patch handles several types of conflicts. Like the xEdit Merge Patch discussed below, for records that are part of 'leveled lists' it can properly handle situations when one mod changes a subrecord and another mod changes a different subrecord and also when when two or mods change the same subrecord. In addition to resolving conflicts in leveled lists, Wrye Bash can also automatically resolve some non-leveled list record types when two mods change the same subrecord. For example, if one mod changes an NPC skill level to 50 and another mod changes the same skill to 60, the bashed patch will choose one of these changes or use a compromise value based on both (e.g., 55). In performing this task it uses Bash tags (for more details on the tags see here) to help determine which mod's records should have precedence when there is a conflict. These tags can be assigned manually in Wrye Bash, by using the BASH tags sutodetection script for xEdit, and (when implemented) automatically assigned to a mod when LOOT is used.
The Skyrim version of Wrye Bash does not merge nearly as many record types as the versions for TES4 (Oblivion) or Fallout (Fallout 3 and Fallout New Vegas). Wrye Bash for Skyrim handles record types for leveled items, leveled NPC, Names, Item Stats for armor and weapons, and a very small set of game settings (GMST). The only game settings it handles are ones explicitly included in the bashed patch menu; it does not include any GMST records from mods. It remains, however, the best way to merge leveled lists and leveled NPCs, but with the WB limitations in Skyrim other utilities are often needed to supplement its capabilities. An experimental version of Wrye Bash for Skyrim is available that handles a much larger set of hash tag types; once this has been tested Wrye Bash will be able to handle some of the merging that is especially tedious to do manually.
Mator Smash
Mator Smash currently in development, as discussed in the Mator Smash subforum on the STEP site, is being developed to provide a much more complete capability for merging mods managed with tags. Supreme commander forged alliance 1.6.6 patch.
xEdit Merge Patch
TES5Edit (and the equivalent xEdit programs for the other Bethesda games) can automatically create a Merge Patch that merges some potentially conflicting records across multiple mods. In Skyrim it can only work with a few types of records and is primarily useful as a starting point for creating manual patches. With the emergence of the Merge Plugins tool discussed previously there does not seem to be any need to use the xEdit Merge Patch.
Using this capability of TES5Edit is quite different than using the Merge Plugins mod described above since here TES5Edit is being using to create a set of merged records that only include records for which the mods being merged have conflicting entries while above it was merging entire mods when the mods had no conflicts. It can handle plugins that include scripts. This is described in section 4.8 of the FNVEdit Training Manual (the most recent available documentation for TES5Edit) and in Sharlikran's 'Merge Patch' video. As the video points out, when using this TES5Edit (and the equivalent programs for the other Bethesda games) feature make sure to remove the Leveled List records and the leveled NPCs from the Merge Patch (note that unlike the edit programs for other Bethesda games the TES5Edit Merge Patch does not currently include leveled NPCs). It is recommended that Wrye Bash be used to take care of leveled list merging, as described above. Like the Wrye Bash bashed patch, the Merge Patch needs to be recreated whenever there is a plugins are added or updated that would change the patches automatically produced in the Merge Patch. The documentation on the Merge Patch suggest manual review of the patch to fix conflicts that the automated Merge Patch process was unable to fix.
In TES4 and the Fallout games the Wrye Bash bashed patch is sufficiently comprehensive , more configurable, and intelligent that the Merge Patch isn't typically needed. In Skyrim, however, the TES5Edit Merge Patch is quite useful, especially since it takes care of portions of compatibility patching that Skyrim Wrye Bash doesn't. In addition to Leveled Item, the TES5Edit Merge Patch includes the following record types: Ammunition, Armor, Container, Faction, Magic Effect, Misc. Item, Scroll, Weapon, and Non-Player Character (Actor).
Creating a Merge Patch is straightforward. Load TES5Edit (or the equivalent programs for the other Bethesda games), and select 'OK' after removing the checkmark for the bashed patch if there is one. Right click in the left window and select 'Other' and then 'Create Merged Patch'. When prompted for a new module name enter a new name for the merged patch. After the patch is created disable and/or delete any previous Merged Patches. In addition, the Leveled Item object class should be removed and the patches reviewed to make sure they are reasonable changes; most of the time they are.
Manual Merging of Mods with Conflicts
Manually merging plugins with TES5Edit
TES5Edit can be used to manually create a single compatibility patch merge plugin that provides compatibility fixes and parameter changes across a large set of mods, that merge complete mods, or combinations of these. Manual editing is the most complicated and flexible of the methods being discussed here. It is briefly described in section 4.7 of the FNVEdit Training Manual. Since this is a manual process it can be used with plugins that have conflicts and those that have scripts; script records can be copied to the patch merge plugin like any other record. Manual Editing is easiest with plugins that do not have new FormIDs; if there are FormIDs they need to be renumbered. Manual editing is especially simple with small plugins that change a few parameters originally set by the main game esm file; of course, these are also the plugins that are easiest to combine with the automated methods discussed in the previous subsection. For example, in Skyrim the 26 Moon Size Tweak mod has two plugins each containing a single record. Merging these two plugins into a single plugin or even into an overall plugin containing Patches is particularly easy. Of course, the Merge Plugins TES5Edit Script mod described above can be used to further simplify this merge process as long as there are no conflicts. Generally speaking, actual manual editing (vs. using tools like the Merge Plugins TES5Edit Script) is needed when there are conflicts that can't be resolved automatically. This occurs frequently, but not always, when merging compatibility patches, and when creating compatibility records for mods that have compatibility problems but don't have existing compatibility patches.
In some ways the most difficult problem with manual merging is to decide which plugins to merge; it can be difficult to correctly merge complex plugins when there are conflicts on multiple subrecords. There is limited documentation on the types of errors that are typically encountered when doing this. In general the easiest mods to manually merge are ones that are small or don't have complex record structures.
Manual merging involves four types of actions:
- 'Copy as Overide', as described on page 33-34 in the FNVEdit Training Manual, is used to copy a single record from a mod into a patch plugin. When there are conflicts this is used to get all the subrecords from a mod into a patch plugin, typically followed by manual editing of selected individual subrecords in the patch as described below. The FNVEdit Training Manual suggests that this is done after using a conflict filter; this is useful when a lot of mods are being edited at the same time but isn't needed when a patch is being created or edited for a few specific mods.
- 'Copy as Deep Overide' is used to simultaneously copy multiple records from a mod into a patch plugin. When there are conflicts this is used to get all the subrecords from multiple records of a mod into a patch plugin, typically followed by manual editing of selected individual subrecords in the patch as described below.
- 'Edit' an individual subrecord, as described briefly on the bottom of page 36 in the FNVEdit Training Manual, is used to change the value, text, or reference in a single subrecord in a plugin.
- 'Drag and Drop' editing of individual subrecords, as described on page 35-36 in the FNVEdit Training Manual, is used to copy the contents of a single subrecord from a mod into a patch plugin. When creating a patch this is often the most commonly used action type.
When manually merging care must be taken with GMST (game setting) records as discussed in this post by EssArrBee. The procedure for merging these records is:
- Right click Game Settings->Add->GMST - Game Setting.
- Put in any FormID that start with the load order number (e.g., if the mod has 4D in the load order add 4DXXXXXX).
- Go to the mod whose Game Setting is being merged, get the Editor ID (a text name) of the Game Setting, then add it to the Editor ID line for the new FormID just added to the merged plugin.
- This should make the other records with that game setting show up in columns in TES5Edit, and the setting values can then be dragged and dropped from the mod with the desired Game Setting value.
An Example of Using Copy as Override and Drag and Drop to Change a Subrecord for a Patch Plugin
Drag and Drop editing is commonly used in creating patches. Motorola gp2000 programming software. An example for using this in creating a patch is a patch for to resolve a conflict between Acquisitive Soul Gems (ASG) and Animated Weapon Enchants (AWE). AWE changes the shader subrecord for the Soul Trap spell, while ASG changes many other subrecords. The steps used to create the patch are described below.
- Open TES5Edit
- Select 'Acquisitive Soul Gems.esp' and Animated Weapon Enhants.esp then click [OK].
- Expand 'Magic Effect' under Acquisitive Soul Gems.esp and select the '0005B452' node.
- Right-click on Acquisitive Soul Gems.esp column and select 'Copy as Override into.'.
- Select '<new file>' and click [OK]. In the resulting text box type 'ASG-AWE Patch'.
When you do this a new column appears on the right titled 'ASG-AWE Patch'. Scroll way down until you see the row heading 'Enchant Shader' under 'Magic Effect Data'. If you look on that line you will see that three of the columns have 'EnchPurpleFXShader' entries and one (AWE) has 'wpnSoultrapFXS'. You want to drag 'wpnSoultrapFXS' entry from the AWE column to the entry on the same line in the column to the right ('ASG-AWE Patch'). When you do this it will replace the 'EnchPurpleFXShader' entry with 'wpnSoultrapFXS'.
Guide to make a patch for solving conflicts
A small guide is available with screenshots and recommendations on patch creation. It has not been reviewed in detail yet, but it does ave some useful suggestions.
Using ModGroups to Simplify Manual Conflict Resolution
See this thread in the STEP forums and this post in the AFKmods xEdit thread. This capability is available in xEdit 3.1.0. More examples need to be added to this section about using ModGroups.
Patch Load Order
Fallout New Vegas Wiki
While potentially the patches created by these four methods could be merged, it is suggested that the plugins be kept separate to simplify maintenance (there will always be need to add new records and edit/remove old ones). Any merged plugins created should be loaded near where the original mod was loaded, as discussed in 1.3. The Merge Patch from 1.2 should be loaded prior to the bashed patch. Typically any manually created Patch Merge plugins from 1.4 are loaded either after the mods they reference or after the Merge Patch and before the bashed patch.
Issues in Changing FormIDs
Every different type of object in the game has an 8 digit hexadecimal number called a FormID, a unique identifier for that particular object type. As mentioned above, when merging some plugins the FormIDs for objects created by a mod (vs. the vanilla objects in the Skyrim.esm or Update.esm plugin or one of the DLC esm plugins) need to be changed. If the resulting merged mod includes all uses of these FormIDs, then there aren't any problems since the merging process changes all references to these FormIDs to use the new values. However, if there are other mods that reference one of these FormIDs that are not included in the merged plugin, there is a problem since those mods reference the old FormID value which is no longer exists. This is why the suggestion was made above to merge plugins from the same mod; this usually insures that all references to FormIDs created by the mod are included in the merged plugin. A merged plugin does not actually need to contain only plugins from the same nod, but for all the mods included in the new merged plugin all uses of any FormIDs created by these mods must be included in the merged plugin.
As mentioned above, this issue is also discussed in the 'Q: My hair's gone?! My armor's gone?! My weapons are gone?! My face is gone?!?!WHAAATTTT?!!!?!' question in the FAQ for the Merge Plugins TES5Edit Script mod .
Many mods do not introduce new FormIDs in their plugins, and as long as there are no conflicts among these mods merging their plugins can be fairly straightforward (unless there are issues with merging scripts; this does not typically happen with mods that use small scripts).
Retrieved from 'https://wiki.step-project.com/index.php?title=Guide:Merging_Plugins&oldid=81428'
- 1Overview
Overview
Terminology
A 'mod' is a package (archive) of related files that make some change to the 'vanilla' (unmodded; as delivered by the publisher) game. Within a 'mod' package can be a number of 'asset files' which add to or replace the existing vanilla assets (meshes, textures, sounds, animations, XML files, etc.), and one or more 'plugin files' that tell the game about the existence and use of the new assets and where they are placed in the game. The 'plugin' files are the only ones that appear in the 'load order', which determines the sequence in which the game engine loads them into the game from the 'top' (lowest numbered) to the 'bottom' (highest numbered) position in the sequence. 'Plugin' files have one of two possible file extensions: ESM and ESP. There is generally only one ESM file, but there may be any number of ESP files (including none). The ESM files are loaded first, and are considered 'masters' to the ESP files that depend upon them.
Official game expansions ('downloadable content', known as 'DLC') typically are provided as ESM files along with other 'assets'. They may or may not include ESPs. DLC are usually sequenced in the order they were released but this is not mandatory unless they depend upon an earlier DLC. All DLC depend upon the game's original ESM file (i.e. 'FalloutNV.ESM') so it should always be first.
(For the technical distinctions between an ESM and an ESP, see this ESP vs ESM wiki article. Remember that the capabilities of 'Construction Set' tools vary by game but the concepts related to the same game engine endure.)
The Issue
A 'master file' is one which must be present for another plugin to be able to utilize it's resources. The files which require some 'master file' are known as 'dependencies', because they 'depend' upon the assets of the 'master'. Typically these 'masters' have an ESM file extension, but this is just a general guideline. A file is technically considered an 'ESM' because it has that flag enabled in the file header, which is normally not visible to the player. Thus an ESP file can have the flag enabled and be treated as if an ESM file to include loading with other ESM files at the top of your 'load order'. In addition, an ESP file from one mod may be required by another ESP, in which case it is also considered a 'master' even though in all other respects it is 'just an ESP' and may appear lower in the 'load order' . but still should be above any dependent plugins.
The game engine requires that a 'master' be loaded before a 'dependency' or it generates an error. Usually this results in a 'Crash To Desktop' (CTD). If a 'master' file is missing when the game starts, this CTD can occur during or even before the 'loading screens' are displayed. If you get as far as the game's main menu once it has finished 'loading DLC content', you are not dealing with an actual missing file problem, but rather one that is out of proper sequence in your 'load order'. This will also cause the game engine to display that same error message.
In general, make sure all your ESM files are loaded first, with the game ESM (FalloutNV.ESM) as the very first file and those of the DLC next in the order they were released:
- FalloutNV.ESM
- DeadMoney
- HonestHearts
- OldWorldBlues
- LonesomeRoad
- GunRunnersArsenal
- and then the 'pre-order packs':
- ClassicPack
- MercenaryPack
- TribalPack
- CaravanPack
- Mod EMS files should follow.
'Dependency' files are supposed to include a list of their 'master' files in the file header. This list can then be read in turn by tools for sorting the 'load order', such as LOOT. Some plugins are 'patch files' which modify other plugins. They depend upon the presence of the other plugins to effect their changes, yet may not have them as 'direct masters' or otherwise included in their list of 'masters'. These 'indirect masters' may need to be manually identified and either added to the plugin's list or that information provided to the sorting tool. (LOOT uses the 'required' metadata field for this purpose only. It can find all listed masters by following the chain in the header of the file. See it's included documentation on the use of metadata.) If they are not included, the sorting tool cannot determine the proper file relationships, which leads to CTDs and plugin conflicts.
Programs and Tools
- FNVEdit or the 'xEdit' equivalent tool for another Bethesda game using the Gamebryo engine (i.e. TES3Edit, TES4Edit, TES5Edit, etc.).
- Tome of xEdit Current online manual for all games
- FNVEdit Training Manual (PDF)
- list of 'xEdit' repositories and related scripts
- LOOT (optional but recommended)
Procedure
Finding which masters that a plugin depends upon are missing is fairly simple. However, first you must disable your 'bashed' or 'merged' patch file and enable any plugins they deactivated. (See the S.T.E.P. Guide to Merging Plugins which covers both the 'bashed' and 'merged' approaches to 'patch files'.) Otherwise you may get much of your 'load order' considered as 'masters' simply because part of the plugin you are concerned with is in that patch file, and indirectly requiring all the other plugins included in it.
- Open your 'xEdit' tool (i.e. FNVEdit). A 'Master/Plugin Selection' window will be displayed.
- Right-click in any blank space of that window and a 'context menu' will be displayed, overlaying the list of plugins.
- Choose the 'Select none' option. This will 'uncheck' all of the displayed plugins in your 'load order'. The context menu window will close, and the 'Master/Plugin Selection' window will refresh with all the check-boxes 'empty'.
- Now scroll down the list of plugins and enable (Left-click in) the checkbox of the plugin you wish to check.
- Note that ONLY one plugin should be checked.
- Left-click on the 'OK' button at the bottom right of the window.
- 'xEdit' will automatically load all the required masters of that selected plugin, and will report an error if one is missing from your 'load order'.
When the 'background loader' is finished (message in the right-hand pane at the bottom of the 'Messages' tab), in the left-hand pane you should see all the masters referenced by the plugin, along with the plugin name itself (which will be listed last).
- You can also see the listed masters in the 'View' tab of the right-hand pane when you select the 'File Header' record of the plugin file in question in the left-hand pane.
Notice that an ESM file can have other ESM files as masters as well. An ESP plugin may require other ESP files in addition to ESM files as masters. This is especially true where a 'patch file' is concerned.
When a 'missing master' error is reported, it can mean one of two things. Either the file is not active/installed, or the name is not what is expected by the plugin. In the first instance, you must install or activate the missing plugin. In the latter instance, you may need to add or change the new name of the 'missing' master.
Changing the name of a 'missing master' most often occurs when a 'merged' version of the master plugin has been created to reduce the number of active plugins required. The content is now in one instead of several files. A typical example of this is an 'All DLC' version using one merged file instead of one for each of the individual DLCs. The plugin is still looking for the individual DLC files as masters.
- Select the plugin file. A 'context menu' will be displayed.
- Right-click on 'Add Masters', and check the boxes of all the plugins listed. If a merged plugin is replacing a number of individual plugin files, then uncheck those it replaces instead.
- Left-click on the 'OK' button.
- Select the plugin again. A 'context menu' will be displayed.
- Right-click on 'Sort Masters'. This will sort them to match their current sequence in your 'load order'. Generally experienced mod authors have their 'patches' for other plugins with the correct/expected load order in them already, so consider their sequence carefully before you override their expectations. Record their load order and carefully test the result of resorting.
- Exit the tool and save. When you exit the tool if there were any changes made to the plugin it will automatically display a 'Save Files' window and list those plugins that changed. Select (highlight) the ones you wish to save and Left-click on the 'OK' button.
- Reload the plugin following steps 1-6 above, and check it for errors.
If there are unresolved references then the plugin was made badly and cannot be fixed automatically. Perhaps you can get this kind of missing information added. GECK/CKIT will do this exact same error checking if you load and save the plugin in it (though possibly only with the tool's 'Powerup' addon).
Fallout New Vegas Nexus Mods
References
- FNVEdit or the 'xEdit' equivalent tool for another Bethesda game using the Gamebryo engine (i.e. TES3Edit, TES4Edit, TES5Edit, etc.).
- Tome of xEdit Current online manual for all games
- FNVEdit Training Manual (PDF) generally applies to all 'xEdit' versions for other games.
Nexus Wiki articles referred to by this article:
Fallout New Vegas Just Mods Merged
- <none>
Nexus Wiki articles that refer to this article:
Retrieved from 'https://wiki.nexusmods.com/index.php?title=Missing_Masters&oldid=40266'