Difference between revisions of "TES5Edit Documentation"

The following information is presented as a way to properly use the FO3/FNV/TES4/TES5Edit tools (collectively known as XEdit) created by ElminsterEU.  This manual contains a tour of XEdit, a lengthy FAQ/Navigator, and several Chapters of detailed instructions on how to utilize the varied functions of XEdit successfully to improve the modding experience.  This includes a guided tour of the many functions that XEdit provides, showing how to resolve conflicts between groups of mods, which improves the stability of the game and ensures a minimum of game-impacting conflicts.

The questions answered and processes described herein are intended to help both mod users and mod authors to improve the quality, standardization, and conformity of Bethesda mods. If you utilize more than the Bethesda-provided content, or if you write mods, then using XEdit will help resolve conflicts, clean mods, and improve your load order.  There are thousands of mods for all the games that XEdit supports.  Hopefully through public contribution, this documentation can become a resource to standardize mod delivery and reduce conflicts wherever possible.

This document presumes a basic understanding of what "mods" are, and how to install them on your system. This manual is not a guide on how to build mods, and the use of XEdit for extensive mod changes is discouraged for most users, as that is what the GECK and Creation Kit were built for.

== Introducing XEdit ==

XEdit is an advanced graphical module viewer, editor, and conflict detector, with many additional functions that make it akin to a Swiss-army knife for mod users and mod authors alike. The primary function of XEdit is to help you spot conflicts between mods and resolve them, as well as to prepare your mod-list for a smooth run-time with Master Update Mode (MUM). MUM resolves some bugs with Fallout: New Vegas and improves mod compatibility during run-time by turning all mod files into Masters (ESM) and creating the special ONAM records that allow the mod files to work together smoothly.

For the mod author XEdit provides the capability of viewing mod files at great depth, cleaning mod files of extraneous and duplicated records, merging mods together, changing ESPs to ESMs and scanning references in mod files for reach ability, form errors and specific references. These functions are vital to mod authors, as it will clean the mod of unintended changes, erroneous records, and potential conflicts with other mainstream mods that players run.

Thus whether you use mods to enhance your game experience or create mods for others to enjoy, using XEdit is both a wise investment in time and a beneficial act for the modding community. Authors who clean and prepare their mods with XEdit will experience fewer conflict and compatibility problems once published, and Players who de-conflict and MUMify their load-orders will be much less likely to experience crashes and headaches. In general the use of XEdit can only improve the interoperability of all mods, and this can only be a good thing.

If you are not convinced by now to invest an evening to learn how to use XEdit, then you should be sacked and have a live Nuka-grenade stuffed down your trousers. If, however, you wish to do the right thing for the modding community, grab a coffee and let's get to work! XEdit is not a difficult tool to use, but it does require that your CPU (brain) be involved in the process, and that is what this documentation is designed to teach.

=== Downloading XEdit from Nexus ===

XEdit works on Windows XP, Vista and Windows 7. Other platforms or Windows simulators may or may not work and are not officially supported. XEdit is available for download from Nexus, one of the most outstanding sources for Fallout3, Fallout: New Vegas, Oblivion and Skyrim content.

A page simular to this one will appear.  You will need to first click on "Files" to display the list of XEdit versions. Once loaded, check the Version number (B) to ensure you download the most current revision (it may/will be different from the screenshot below, which is just an example). Then click on that revision of XEdit in the main Files section (C).

Once the archive is open, you will need to extract the XEdit files into the main game directory (where the game's exe application is located) in order for it to function properly. Do not install into the Data directory or the program will not function correctly.

Note: The XEdit package also contains a special file called "[Game].Hardcoded.keep.this.with.the.exe .and.otherwise.ignore.it.I.really.mean.it.dat" where "[Game]" is the name of the game (possibly abbreviated). This file needs to be in the same folder as the XEdit.exe application. It contains hardcoded game engine records which will show up as false errors in XEdit if said file is absent.

What makes these special is that the records are referenced in the game's main master file (e.g., FalloutNV.esm for Fallout: New Vegas and Skyrim.esm for Skyrim) but are NOT contained in the game's main master file (they are in the binary). XEdit automatically loads these hardcoded records at the same load order index [00] as the game's main master file so that these hardcoded values can be used in conflict detection and resolution. These records will display as coming from the game executable (e.g., FalloutNV.esm for Fallout: New Vegas and Skyrim.esm for Skyrim). You should not touch this file unless you are uninstalling XEdit.

With XEdit installed let's review some system parameters and drivers that you will need in order to successfully operate the tool. XEdit requires current DirectX drivers from Microsoft. You can tell if your system is up-to-spec by simply launching the tool. If XEdit loads and presents you with a Master/Plugin Selector view, your good to go but you can skip this next step. If you get an error about d3dx9_*.dll not being installed, you need to update your DirectX to at least the March 2008 Version.

Once DirectX is installed, you should be able launch the XEdit application successfully. If you still get errors, please report them to Miaximus or ElminsterEU.

The UAC Security feature of Vista protects the Program Files directory from un-authorized access. Unfortunately this also causes problems for XEdit and Fallout: New Vegas, and requires some manual intervention on your part to resolve. You have 3 options for dealing with UAC Security:

# Install Fallout: New Vegas and XEdit in the C:\Games\Fallout New Vegas folder, which is not controlled by UAC and will prevent conflicts. (recommended)

Any of the above options will work, though it is probably a better option to install Fallout: New Vegas and XEdit into C:\Games\Fallout: New Vegas directory and avoid the Program Files directory all-together. That leaves your system secure and averts the UAC problem for Fallout: New Vegas.

If you are unable to get past the UAC restrictions, post the details of the problem to the Fallout New Vegas GECK forum for additional assistance. If all went well with the install, you should be able to successfully run XEdit.

=== Starting XEdit ===

When started it will automatically find your Fallout New Vegas Data directory via the system registry (not by where it was installed). If you immediately get errors indicating that XEdit can‟t find the Fallout: New Vegas files, it means you moved the files to another directory after installing XEdit. You need to re-install the Fallout: New Vegas Game again and place it into whatever directory you want as part of the install process.

If XEdit starts, you get a dialog to select which modules you want to load with the current selection from your Plugins.txt as default value. This order will have been set by FOMM, and cannot be changed in XEdit.

If you need to change your load order, close XEdit and change the load-order in FOMM, then re-launch XEdit.

Select the mods that you want to load into XEdit, which can be all (for conflict detection) or just one if you‟re working on a specific mod-file. Once you have confirmed that dialog the selected modules will start loading in the background. Depending on your system it should take 30 seconds to a few minutes (!) for all modules to load. You can follow the progress in the message window. (Don't panic if it seems to freeze, it just takes time).

The tree view on the left side now shows all active modules in their correct load order. By navigating that tree view you can look at every single record in any of your modules. An example of a successful launch of XEdit is shown below, though you may also see additional error information if errors were found during start-up.

This section of the manual will take you on a brief tour of XEdit to introduce you to the different views and screens that you will be working with. This tour is designed for beginner-level users, and does not discuss the functionality of the views at any depth just yet. The tour is recommended for all levels of user, especially if you have not used XEdit within the last several months as there have been many updates.

The Master/Plugin Selection view is presented to you when XEdit is first launched, and allows you to select/un-select the mods that you want XEdit to load. You can also Right-Click in open space to access more options, such as “Select All” or “Select None”.

To change the load-order of mods, close XEdit and open FOMM. Change the load-order as desired, close FOMM and re-open XEdit. There is an additional option you can use to quickly load a single mod – simply Double-Click on a mod file in the list. Double-clicking a mod will automatically un-select all other mod files, and will load the selected mod file. It‟s a short-cut to loading single mods.

The Left-Hand side of the main XEdit view is the most heavily used in XEdit, containing both a hierarchical data-tree structure for all references as well as the main context menu. It also contains a status bar and search boxes for hunting-down specific FormIDs or EditorIDs as shown below:

The main context menu (B) contains all of the major XEdit functions, including Filters, Reference hunts, Error checking, Removing Extraneous content and many more. There are also several functions that do not apply to Fallout: New Vegas, such as Generate Object LOD. We will discuss each of the important options for Fallout New Vegas in the tutorials below.

The main context menu is accessed by Right-clicking in the Left-Side Panel, and acts as the main navigation and function selection point for XEdit. As such, much time and explanation is provided on how to utilize this menu, as well as a Reference Chart (shown below) to help illustrate what each function does.

* Apply Filter – This function will present you with the Filter Menu, where you can select options on how you want to filter (restrict) the data shown in XEdit.

* Checking for Errors – This function is used to check for reports any case where the information in the module file does not match the XEdit record definitions. This is not a check for missing references, physical or data errors – that is done during the loading process with results available in the Messages Tab.

* Mark Modified – It will mark the currently selected node and all child nodes as modified. To minimize the chance that XEdit breaks something that it doesn't fully understand when saving, only records that are marked as modified are assembled field by field, sub record by sub record. Any record or even complete group that is not marked as modified is simply copied unchanged as a blob of bytes from the old module file into the newly saved one.

* Hidden – This function hides the selected mod file(s) or references from further view/processing by XEdit.

The Information Tab holds a textural version of the XEdit help guide, including basic information on mod conflict resolution, instructions on using Master Update Mode and a legend on how to interpret the color-scheme of text and background. You can reference this tab at any time as a cheat-sheet of sorts on how to use XEdit.

The Messages Tab acts like a running log-file of what XEdit is doing in response to your actions. When you first load XEdit, the Messages Tab is displayed by default so that you can watch the loading process in real-time. This is important as any Errors in the mod files such as missing references, missing files or dirty-edits to a mod file done in a hex-editor can all result in errors. Most of these will be harmless to Fallout: New Vegas, but some are lethal and you can see them all in the Messages Tab while they are loaded into XEdit. The view below shows an example:

Any actions that you take which result in changes to the files such as saving, will also print their output into the Messages Tab. Thus it is important to check this tab often while working in XEdit, as there are cases in which a mod file won‟t save due to errors – and you want to know about that as soon as a problem occurs.

We discuss this view at depth in the chapter on Conflict Detection and Resolution, but for now it‟s only important to understand its high-level function and how to navigate to it. As in the Referenced-By Tab, within the View Tab you can Right-click on any reference to receive an additional context menu. You can edit and remove any entry, as well as tell XEdit what kind of view you're looking for; with or without de-conflicted rows (rows without a conflict of any kind).

The Filter view is used for several purposes in XEdit; from conflict resolution to mod cleaning to reference viewing and reach ability data – all are achieved by activating a XEdit Filter. The Filters essentially work to restrict what data you see in XEdit to just what you want to see or are working on, and in some cases data is parsed (such as in conflict detection). When trying to resolve conflicts among mods, the Filter is used to show you only the records that show a conflict – leaving the un-conflicted rows invisible.

As you can see there are dozens of different options you can select in the filter view. Not to worry though, we will give you the correct filter options to select for each of the functions you perform with XEdit. For now it is only important to recognize this as the Filter View, which gives you unprecedented viewing access to mods files. You can Apply and Remove Filters from the main context menu as shown below:

You can save your changes at any time by pressing, “Alt” and “S”, and when you exit XEdit (if there are changes to save). If you have not saved for a while, XEdit may also remind you that it‟s a good time to save. When the, “Save changed files” window is presented, click on the mods you want to save. The screenshot below illustrates this process:

There are several important keyboard short-cuts that can make your usage of XEdit more efficient with less key-strokes for some common functions.

XEdit also provides the native ability to reverse the Master Update process, returning all MUM'ified plugins back to their original ESP state. This process is called Master Restore Mode (MRM), and will all you to edit your plug-in with the GECK. As the GECK will not allow you to set a Master (ESM) as the Active file, the MRM(er) process is required in order for you to modify your plug-ins again after running Master Update Mode.

Master Update Mode is activated by creating another copy of the program, and renaming it to, “FNVMasterUpdate.exe”. When XEdit runs, it will recognize its filename and run in Master Update Mode accordingly.

The process of creating the 2nd copy of XEdit for Master Update Mode is illustrated below:

It is recommended that you create icons for both MUM and MRM (alongside of the XEdit Icon) so that you can conveniently run either depending on whether you‟re playing or modding in the GECK. This is considered the best practice.

There is also a MasterRestore mode which reverses the MUM process by removing the ESM flag again from all .esp files. Similar to Master Update Mode, you need to copy/paste the XEdit.exe. Program, and rename the new copy to, “FNVMasterRestore.exe”.

This will give you 3 icons; XEdit.exe, FNVMasterUpdate.exe and FNVMasterRestore.exe. Once you launch the Master Restore Mode (MRM), the rest of the action is automatic. The screenshot below illustrates the output of Master Restore Mode:

One of the primary roles of XEdit is for conflict detection and resolution, so that multiple mods that modify the same records can work together successfully. Conflicts and Overrides are not always bad, and in fact the entire idea of “modding” is to make changes to the game that replace (and thus create a conflict or override for) the original records that came with Fallout: New Vegas. That is why our goal is to detect conflicts, determine their nature and resolve the bad conflicts while leaving good changes in place.

There is a huge difference between a "conflict" and an "override". There are mods which override changes from a Master file, such as changing the level cap. If for example, ModA changes the level cap to 40 from the default, this over-rides the level 20 cap in the Fallout: New Vegas Master files and is a normal. Overrides are not conflicting in any way. Overrides show up in XEdit with a Yellow background color and Green text color. In most cases you don‟t need to do anything with Overrides.

To get a conflict you need to have the same FormID defined in at least 3 modules, a Master, and 2 overrides. The conflict arises when the two overrides change different aspects of the same record, so that when the mods are loaded by Fallout: New Vegas, the last-mod loaded overrides the changes of the first-mod. Thus the last loaded mod is the, “Conflict Winner” while the first mod, whose changes were overridden, is the, “Conflict Loser”. Conflict Losers will show up with a red background, red text. The screenshot below illustrates the differences as seen in XEdit:

The application of Filters is the primary means of conflict detection for XEdit. When you apply a filter, the loaded mod data in XEdit is parsed and analyzed via a complex algorithm (described below) to detect all conflicts and overrides. The list of mods in the Left-Side Panel changes color (text and background) based on conflict status of each, and the results are shown in the View Tab which also changes color (text and background). The color-schema matches throughout XEdit, so you won‟t have to memorize more than one (described in detail below).

Once you click on Filter (F), XEdit will filter and analyze all of the loaded mods against the conflict-detection algorithm. This may take some time depending on how many mods you have loaded and how robust your computer is. The progress is shown in the upper-right corner of XEdit as the screenshot below illustrates:

XEdit also keeps track of how long the filter takes to apply. If you run 100+ mods, it can take several minutes to process all of the data. Conflict detection is not simply based on the existence of multiple records for the same FormID in different modules but instead performs a comparison of the parsed sub-record data via an algorithm.

The screenshot below illustrates how XEdit will look once the conflict detection process is complete. Note the [Filtering done] block in the Messages Tab below (A), indicating both the success of the conflict filtering process as well as record and time statistics about the filtration result. The screenshot below shows a typical outcome:

With that you now understand how to detect for conflicts with XEdit and where to look at the data. You‟re now ready to learn about colors and display order. Understanding the color schemes behind the text and backgrounds is critical to understanding the conflicts, and how to resolve them.

Understanding the color schema is a key to understanding XEdit. The color coding schema is designed to make the process as simple and efficient as possible. The legend below will introduce you to the basic color schema:

The sample below shows both the color schema and the display-order together to better illustrate how conflict detection works. XEdit displays each conflict in the order that the files are loaded (FOMM‟s load order), with the first mod loaded listed on the Left (Purple) and the last mod loaded listed on the Right (Orange).

The Load Order Workflow chart below is designed to help you understand the different color-combinations that you will encounter when de-conflicting mods. The XEdit display order as shown above was transposed into the vertical diagram below to help better illustrate how XEdit determines conflict winners and losers:

In this case we do need to take action to resolve the conflicts, or Veronica will never see benefits of the Cuter Veronica nod. The question is, “Can we resolve this conflict by simply changing the mod load-order in FOMM?” Let‟s find out, start by closing XEdit and opening FOMM.

Closing FOMM (to save the load order), re-opening XEdit with the new load order and applying a conflict Filter yields the following results:

There are two methods by which you can create a patch plug-in to resolve conflicts; by hand or using the automatic merged patch tool. The recommend best-practice with patch Plugins is that you use the automatic merged patch creation tool, after which you review the merged patch and add/remove/correct anything that the automatic tool did not change to your satisfaction. This is necessary because there is often not one “correct” answer to which mod should win a conflict over the same record, and sometimes what is normally deemed correct will not be to your personal liking. We describe the manual patch Plugin creation process first, and then show you how XEdit creates one automatically.

Once confirmed, XEdit will add NV-Phalanx as the Master-file of your new patch plug-in. This happens because we chose the Veronica reference from NV-Phalanx when we did the, “Copy as override into…”. If we had chosen Cuter Veronica instead, it would set that as the Master file for our patch plug-in instead. This ensures that when you copy a reference into your patch plug-in, any data needed for it from the original mod file can be accessed by Fallout: New Vegas at run time. Once complete, you will see:

We can now literally drag/drop each of these items into our new patch plug-in. We do this operation more than any other in XEdit when making a plug-in, as once the initial creation step is complete, it‟s simply a matter of dragging all of the overrides that we want into the patch plug-in as shown below:

Note that for the key we dragged it from the top-level, “Item” entry for that record, and not from the key item row itself. The Item row is the root-level for this particular object (including its Count variable, etc.). As such XEdit will only let you “drag” from the correct row-level, so you don‟t have to worry about getting it wrong! The screenshot below shows the result, with the key now replicated into our patch plug-in.

XEdit provides an automatic method of generated a merged patch, which is the same as a patch Plugin but contains resolved conflicts from All of the loaded mods. This will greatly speed the conflict resolution process, as most of the common types of conflicts are automatically merged into the patch Plugin. It's very unlikely that the generated patch is going to be any worse than using the originally conflicting mods without the patch would be, and as such this method is recommended for everyone that runs mods.

Once the conflict filter has completed its operation, we are ready to build our Automatic Patch Plug-in! This process will examine all of the loaded mods for certain form types that can be automatically merged into a patch plug-in. XEdit will create the new patch plug-in with all of the form types that it can safely merge for you, which you can then use as the base for your custom patch plug-in.

This does not include all form types, and not even all cases of some form types. This is because XEdit cannot read your mind (future release) and thus does not know how to resolve many kinds of conflicts. Without the ability to read your mind, interpret the data and determine what you would want in all possible conflicts, this means that XEdit cannot fully automate the conflict resolution process. The automatic merged-patch then should be thought of as a foundation from which you resolve conflicts in your mod load order. The screenshot below illustrates the challenge:

Notice how the Merged Patch automatically creates our Patch Plugin, and assigns all of the mods in our load-order as Masters to it. This is important, as it allows you to drag n‟ drop any record into it, and ensures maximum compatibility across your mod list. The screenshot above shows you how XEdit creates the entire record tree (1), and where the log file output is shown in the Messages Tab (2).

As described above, the process of creating an automatic merged patch has only resolved one of the conflicts in the example by successfully giving Veronica new inventory items from several mods. However all of the other conflicts remain, which can now be resolved by dragging-dropping records into our new patch plug-in, fleshing it out with both the automatic data XEdit could find and your personal conflict resolution decisions.

To round-out our discussion on conflict detection and resolution, we have included the main algorithm (in textural, descriptive form) for your reference. You do not have to read this unless you have an interest in the internal mechanism of how XEdit determines a conflict/override from un-conflicted records.

XEdit uses a complex algorithm that parses the mod sub-record data at depth, and performs a number of operations on the data to detect conflicts and overrides. While you do not have to memorize this, the main conflict-detection algorithm is described below for reference (and those brave enough to noodle it out):

Step 1. XEdit makes a list with all entries from the Master record, and designates this as the, “TargetList”.

Step 2. XEdit Loops and repeats the following for each existing override record:

Sub-Step A. XEdit determines the file containing this override record, and designates it as, “CurrentFile”.

Sub-Step B. XEdit makes a list with all entries from that override record, and designates it as, “CurrentList”.

Sub-Step C. XEdit goes through the list of Master files for CurrentFile, from last to first, and stops when the first is found containing an override for this record, designated as, “CurrentMaster”.

Sub-Step D. XEdit makes a list with all entries from CurrentMaster, and designates it as “CurrentMasterList”.

Sub-Step E. XEdit goes over CurrentList and CurrentMasterList, for each entry that:

Step 3. XEdit then makes a list with all entries from the winning override record, and designates it as, “WinningList”.

Step 4. XEdit then compares TargetList and WinningList, and if different:

Sub-Step A. XEdit copies the currently winning record as override into the new file, designated as, “TargetRecord”.

Sub-Step B. XEdit then removes all list entries from “TargetRecord”.

Sub-Step C. XEdit goes over TargetList and for each entry add a new entry to the “TargetRecord.”

Step 5. XEdit then makes the Master List (as it applies to leveled list entries) which is also important to understand what's going on:

Sub-Step A. For each entry, XEdit generates a string representation including: Level, Reference, Count, Item Condition, Owner, and Owner Rank.

Sub-Step B. XEdit sorts the generated list of strings.

Sub-Step C. XEdit walks over the sorted list, add numbers to duplicated entries, and so suppose you have a list: A, B, B, C, D, D after this step it will be A#0, B#0, B#1, C#0, D#0, D#1.

== Using XEdit and Wrye Flash For Maximum Compatibility and Stability ==

Instead of using XEdit by itself to create a compatibility patch for all of your mods, it can be used alongside Wrye Flash to create a more stable game that allows more changes from your mods to work.

Wrye Flash creates its patches using Bash tags, which are set by the mod author. These tags allow the program to more accurately merge the files than XEdit, because only the tagged items are patched. XEdit on the other hand, pulls the entire record from the master and attempts to make sense of it all. In other words, Wyre Bash is more precise.

XEdit is still needed, because sometimes mods have missing tags or there are 2 mods attempting to edit the same thing and you must decide which one you want to win. To fix these issues, it is recommended that you make an Manual Patch.  

# Open XEdit. Select all of your files, including the Bash patch and apply these filter settings: [http://imgur.com/o7f2J2v]  

Instructions for creating a Manual patch in XEdit can found in the "[[#Creating_a_Patch_Plugin_.28Manual_Method.29|Creating a Patch Plugin (Manual Method)]]" section.

XEdit provides several tools that help mod authors to clean their mods of extraneous / duplicated references, fix deleted references and to merge plug-ins together. These utilities can help a mod author avoid many conflicts with other mods and is considered a best practice. It is highly recommended that mod authors clean their mods before they are released to the general public, which can avert silly and embarrassing compatibility problems after release and make for a more professional showing in the community.

# Identifying any records in the Master files which have been marked as deleted, which XEdit un-deletes and marks as, “disabled” instead. This ensures that any change made to that object by other mods won‟t cause crashes or conflicts, which can happen if a modder accidentally deletes a base object, which is modified by another mod and you get a null pointer – poof!

Modder A could avoid both of these issues with the mod cleaning process, which un-deletes references that were deleted on accident and un-does inadvertent changes to things in the game that were not intended. The screenshot below illustrates the start of the process, in which you must load-up XEdit and follow the steps herein:

Once, “OK” is clicked (D), XEdit will load the selected plug-in for cleaning.

Note that you can also, “Select All” or “Invert Selection”, which gives you additional controls over which mod-files are selected for loading into XEdit. For the mod cleaning process, we only want to load the plug-in being cleaned. You can do this using the, “Select None” menu option, and then clicking on the mod file to be cleaned.

Once loaded into XEdit, we need to apply a Filter to detect all of the Identical to Master references in the mod being cleaned as shown below:

Clicking on, “Filter” (D) will launch the XEdit analysis for Identical to Master records, which should complete in a short period of time (perhaps 1-20 seconds). If your system is very slow or bogged down or the mod is really huge, it is possible for the process to take longer. The status of XEdit can be viewed in the upper-right corner of the screen, as shown in the screenshot below:

Both the elapsed time and processed records are shown in the upper-right window. When XEdit completes the analysis, the Messages Tab will reveal the result as shown on the next page. You should also not expect to see in anything yet in the View Tab.

that mop into action by clicking on, „Remove “Identical to Master” records‟ (C) – and watch as XEdit puts the shine on that puppy!

As XEdit completes the mod-cleaning process, you can see the output in the Messages Tab, which shows you every record that is being removed along with its hex ID number. Once complete, you get a line of text reading, [Removing “Identical to Master” records done] – along with statistics on the number of records processed and removed as well as the elapsed time (A).

Master File References are links or references from your Plugin to any Master files (ESMs) that it depends on to run, and stores the list in a record called, “MAST”. Most mods have FalloutNV.ESM in their Master List, but you can have many such links in a plug-in. In fact when XEdit creates a Merged Patch, it puts links to many or nearly-all of the Master files in your mod list. It is possible in some cases for a Plugin to contain a link to a Master file that it does not need.

For example, suppose the Plugin we are cleaning had MasterB.ESM in its Master List but it doesn't contain any overrides for, or makes any other references to, records from MasterB.ESM. In that case we would not need nor want MasterB.ESM listed in the Master record for our Plugin! This function detects any un-used Master references in the Plugin we are cleaning, and removes them from the Master List. XEdit also renumbers any file specific FormIDs in the Plugin to ensure that it is cleaned properly.

Note: You should not clean other people‟s mods! It is the responsibility of each mod owner to clean their own mods, and with the creation of this tutorial there is no longer any excuse why people can do this. If you find a dirty mod, send the mod author a PM on Nexus and tell them they have a dirty mod and reference them to XEdit (please?)

Note: Make sure that you run Master Update again before testing your mod in-game, as the cleaning process will undoubtedly change references and you want to make sure XEdit synchs everything up. This has shown to prevent crashes.

The “Check for Reference Errors” function reports any case in which the information contained in a module file does not match the XEdit record definitions. There is a very minimal chance that something that's reported as an error is actually an oversight in the XEdit record definitions and not in the module, but all cases should be reported to be safe). Note that there are errors in the FalloutNV.ESM and the DLCs. Both Elminster and Quarn have gone through them all to ensure they are genuine errors. Running the check is a recommended practice as part of the mod-cleaning process as shown below:

In this example we found both kinds of errors (Ouch!), which was ideal for our tutorial. In the first case XEdit found reference errors where data is missing such as Flags and Idle Timer Settings (A). These errors should be corrected by the mod author and not by you! The error we see in (B) is the result of an unknown Flags type, (Unknown: 15), which XEdit did not understand. These kinds of errors should be sent to Elminster for to ensure XEdit has the right information, or if the mod has some strange error.

I have not yet found an example in any mod of such a circular leveled list, but I do know that they exist and that XEdit can spot them. If you don‟t get any output from running this function, then the checked mod is clean of such loops.

This chapter is dedicated to mod authors and describes a number of XEdit functions which make mod authors' lives easier and lend a degree of uniformity to their work. Much like the material covered in the Mod Cleaning and Error Checking chapter, these functions help mod authors refine their plugins in order to make them less conflict prone when used with other mods. Actions like merging mods, splitting them into Plugin/Master pairs, adding Master file references and more are documented in this chapter, all functions which can open doors to new possibilities which mod authors may have not known existed.

In order to allow a Slave.esp to add new, merge ready, forms (by injection) to Master.ESM or to allow Slave.esp to reference and/or change (by override) Master.ESM native forms, Master.ESM must be included within Slave.esp‟s Master List (MAST) found within the Slave.esp‟s File Header. Master.ESM‟s inclusion in Slave.esp‟s Master List is as Slave.esp‟s key to draw from an otherwise inaccessible resource. XEdit is able to readily add new Master(s) to modules‟ MASTs and, when using the “Add Masters” feature, will correctly renumber the FormIDs in the module to ensure no two forms have the same FormID(s) post-reload. This can be very handy tool for mod authors as it whittles the process down to a few mouse clicks that the author can focus on other, more important things.

Once XEdit adds the Master file as a reference in the Plugin, you see results similar to the screenshot below showing the Messages Tab log-entry: Note that “SS Weapon Effects.ESM” has now been added to RealFragGrenade3.esp, making it possible to attach one of Saiden Storm‟s Weapon Effects explosions to the grenade effect in Better Frag Grenade Physics. The View Tab shows the specific entry:

With FormIDs it's important to realize that the FormIDs that XEdit shows you are NOT the ones that are actually written into the module file. The FormIDs that XEdit shows you are load order corrected ones, while the FormIDs in the file itself are file specific ones. FormIDs are made up of 2 parts, the first byte (2 characters) is the module index, the last 3 bytes (6 characters) are the module specific ID. Mapping from file specific to load order corrected FormIDs and back only affects the "module index" and leaves the module specific ID untouched. An example: Suppose you got a bunch of modules loaded: [00] FalloutNV.ESM ... [04] MasterA.ESM ... [10] MasterB.ESM ... [15] MasterC.ESM ... [20] Plugin.esp And let’s suppose the MAST sub record in the File Header of Plugin.esp lists: FalloutNV.ESM MasterB.ESM MasterA.ESM If you now see a record in Plugin.esp that overrides a record from FalloutNV.ESM, then you would see a FormID like 00123456 for it. In this particular case that record would also have the same (00123456) FormID inside the Plugin.esp module file. But if you have a record that overrides a record from MasterA.ESM, e.g. with a FormID like 04ABCDEF (you can see the 04 as module index matches the load order of MasterA.ESM) then it would be saved as 02ABCDEF in the Plugin.esp module file, because 02 is the index of MasterA.ESM in the list of Master files in the File Header of Plugin.esp. And an override for a record in MasterB.ESM (e.g. 10654321) would be saved as 01654321 in the Plugin.esp module file because 01 is the index of MasterB.ESM in the list of Master files in the File Header. Last but not least, a NEW record in Plugin.esp which belongs to Plugin.esp and which XEdit would show you e.g. as 20FEDCBA gets stored as 03FEDCBA in the file (because 03 is equal to the number of entries in the Master List, as indices into that list start at 00, 03 is one higher than the highest valid index into that list). You will also notice that it's not possible to have an override record for a record from Master3.ESM in Plugin.esp or in any other form reference such a record, because there is no way to map a load order corrected FormID of 15A1B2C3 to a file specific one that's valid in Plugin.esp. To reference a record from Master3.ESM in Plugin.esp you need to add Master3.ESM to the Master List in the File Header of Plugin.esp. But if you just go there and do that manually, then you've just added Master3.ESM with the index 03 to the file. This means that all the records that used to belong to Plugin.esp are suddenly

considered override records for records from Master3.ESM and will show up with 15xxxxxx FormIDs instead of 20xxxxxx FormIDs, a real mess! If you instead use the Add Masters function, then XEdit will not only add then new entry into the Master List, it will also renumber all (file specific) 03xxxxxx FormIDs into 04xxxxxx FormIDs first to preserve their meaning (which is "this record belongs to this file"). There are rare cases when editing the master list directly is what you actually want. e.g. when splitting an .esp into an .ESM/.esp pair. In that case you would make a copy of the .esp, rename it to .ESM, load it alone into XEdit to set the ESM flag in its header, then restart XEdit to load both the .ESM and the .esp and modify the MAST sub record in the File Header of the .esp by adding the .ESM as last entry. After restarting XEdit and loading both files you will see that all records in the .esp are now considered overrides for the same records from the .ESM”

Once the new module specific start FormID (in hex) has been input (A) and the OK button selected (B), XEdit will begin changing the FormIDs and present the output in the Messages Tab as shown in the screenshot below:

When changing the FormIDs of a huge mod like Reykjavik by Alexander Sigurðsson, the process took 3-4 minutes on a high-end computer. The results shown in the Messages Tab reveal just a few examples of XEdit renumbering a FormID, discovering all references to it in all mod files, and correcting the numbering to prevent conflicts.

Note: Changing the FormIDs of an existing module will make it SaveGame incompatible and will break any other module that uses this module as Master! If you have any dependent modules, you need to have them all loaded into XEdit at the time you change to FormIDs so that they will all be updated accordingly.

Many mod authors and users alike encounter the need or desire to merge modules. Many like to merge their favorite plug-ins into a single master file or multiple consolidated plugins. One anonymous modder affectionately calls their conglomerate module “[BORG].ESM (Best Of Really Great Enigmatic Super Mods)”. XEdit can be used to merge any number of plugins and, if used properly, will ensure that the resulting plug-in is synchronized correctly against its combined references and that the merged content will function properly.

In this example, we‟re going to merge Enterprise.esp and KlingonVessel.esp into [BORG].ESM. Note that any number of mods can be merged in one XEdit session as one desires, but it is best to merge them a few at a time. Firstly, we load up FOMM and order the files to ensure [BORG].ESM is loading before the plugins it is to assimilated.

Load order is very important when merging mods together, primarily because XEdit, the GECK, and the game engine are very particular regarding the numbering of Forms‟ IDs and the references to them amongst modules. It is easy to end up with multiple forms bearing the same FormID(s) when merging downward, that is, by copying records into a file loaded after the plug-in(s) to be assimilated. By merging upward, as will be demonstrated in this lab, all forms to be merged into [BORG].ESM will first be assigned new, [BORG].ESM FormIDs such that each form will invariably have a unique ID. After closing FOMM and load things up in XEdit, you will find the plugins are listed in the same order as you have set them up in FOMM.

While changing FormIDs, it is best to change as many at a time as possible via multi-selection of records. When doing so, all references to the records being changed will be automatically updated by XEdit, ensuring the inter-referential structures remain intact and that all of the puzzle pieces line up, so to speak. In the left panel, select Enterprise.esp and press „*‟ to expand all of its branches (A below).

Any plug-in with NavMeshes will have a GECK added record, NAVI, which is the single record in the Navigational Mesh Info Map group. This record keeps track of door connections and should not be manually edited with XEdit, but rebuilt by the GECK instead. Note that it has been updated since we‟ve changed the FormIDs of the NavMeshes it references. For the moment, don‟t worry about merging NAVI as we‟ll get to rebuilding that record with the GECK later on.

Once you‟ve gotten everything in order, you are ready to close XEdit and save your work. Since [BORG].ESM has new NavMeshes merged into it, its NAVI record will need updating by the GECK as previously mentioned. To facilitate doing so with [BORG].ESM, select its file header and hit F2 after clicking “ESM”. The ESM flag will be ticked as [BORG].ESM is, for the moment, a bona fide ESM. Untick the ESM flag.

If you had „orphans‟, open all three lab plugins in XEdit and “Deep copy as override into…” [BORG].ESM again any groups which hadn‟t copied properly the first time and verify that the fresh copies are „fostered‟ or „parented‟. Sometimes reloading several times might be required in the event some copies end up „orphaned‟ again.

Open up [BORG].ESM with XEdit and have a look at the new NAVI which should contain all of the door connections and such from the constituent plugins as well as any connections already within [BORG].ESM.

Converting a Plugin (esp) into a Master (ESM) file is a simple process that can be accomplished using XEdit in less than five minutes. The file extension of a Plugin as well as the ESM flag within its file header must be changed in order to make the transition to a bona fide Master file. The screenshot below starts the action by launching XEdit:

First you need to de-select all of the mods using Right-click in the Master/Plugin Selection window (A). Then click/check just the mod your converting (B), in this example we‟re converting Antistar‟s Weapon Mod Kits plug-in into a Master file. Click “OK” (C) to load XEdit with just the mod being changed as shown:

Note that Weapon Mod Kits is successfully loaded into XEdit (B), and that it is the only file listed aside from the Fallout: New Vegas Master files (A). You are now ready to convert the Plugin into a Master file.

This window is a default/standard in XEdit, and exists to make sure that anytime you are about to change a mod file for the first time, you know about it. It may seem annoying to some, but often the worst conflicts between mods come from changes that a mod author did not intend to make. Simply select, “Yes” (A) to move along.

Once done with XEdit, you will want to change the file extension from Weapon Mod Kits.esp to Weapon Mod Kits.ESM so that the extension matches the File Header flagging. The GECK and Fallout: New Vegas don‟t really care about the file extension (ESP/ESM), what matters is that File Header flag. The Extension is for

humans to keep them sorted correctly! Now all you need to do is exit XEdit or press, “Alt-S” and Save your new Master file as shown below:

It is also possible to change a Plugin to a Master using just FOMM or other tools, but there is always the potential of problems with ONAM records. ONAM records are special records created that allow Master files to communicate with one-another when references need to be passed. XEdit ensures that as part of the conversion process, these ONAM records are built and correctly ordered. This is why it is better to make the Plugin to Master conversion using XEdit.

Here you must also ensure that the Master (ESM) version loads Before the Plugin (ESP) version as this is a Fallout: New Vegas requirement. The recommendation is to move the Master (ESM) higher-up in the load order before all other Plugins, and load the Plugin (ESP) version of Weapon Mod Kits somewhere below the Masters. With that done, close FOMM and load XEdit. Your new load order with the Weapon Mod Kits.ESM loading before the Weapon Mod Kits.esp should be visible in XEdits as shown below:

To load just the Master and Plugin, first Right-click in open space (A) and select, “None” from the context menu as shown above, and then check-off just the Weapon Mod Kits.esp and Weapon Mod Kits.ESM files (C), and click, “OK” to load them into XEdit. This will load just the two Weapon Mod Kits files and the Fallout: New Vegas Masters into XEdit as shown below:

With the File Header block of Weapon Mod Kits.esp selected (A), Right –click in the open space next to the, “Record Flags” section (C) which will render a small context Menu. Select, “Edit” (D) from this small menu to add the ESM Master flag, which effectively converts the Plugin into a Master. Before you can proceed however, you will get a warning message from XEdit about changing the mod‟s contents. This is normal and provided for your protection. Simply select, “Yes” (A) to continue.

And for the final step, you need to save the changes. Use, “Alt-S” or close XEdit to present the Save Files window as shown below:

With this, you now have a Master/Plugin version of Weapon Mod Kits, and the process works exactly the same for any mod that you want to split. You can change the esp file extension to ESM, then open and save it with the GECK and it will tick the ESM flag on, but won't produce ONAM's like XEdit will which are needed for any overrides to FalloutNV.ESM's references. Unless your Plugin has no CELL and/or WRLD group, you're better off using XEdit.

One of the common tasks that mod authors face is to compare two versions of their own mods, either during construction or in subsequent updates. There are also times when mod authors encounter difficult to solve problems with a new version of a mod, and need to revert back to a previous backup. The XEdit compare function can provide a valuable and convenient way of copying data from one version of a mod to another, without having to sort through records that don‟t belong to their mods. Whatever the case may be, this section is devoted to teaching you how to compare two versions of a mod file, and how to copy records over if the need arises.

For this section we feature Quarn‟s Unofficial Fallout: New Vegas Patch, which has helped to resolve countless bugs in Fallout: New Vegas and has improved the gaming experience for thousands of modders. To start the action, launch XEdit and select One of the two mod files that you wish to compare as shown below:

You won‟t see any outward-change in the in the XEdit view afterwards, but you can confirm that they are marked as hidden by Right-clicking on them again – you will see a Check-mark next to, “Hidden” menu option indicating that they are hidden (from filters).

Selecting “Compare To” will present the, “Open” window as shown below, where you can select the current version of Unofficial Fallout: New Vegas Patch (A), and then, “Open” (B) to load it into XEdit as shown below:

The “Compare To” version of the mod is loaded as read-only into XEdit, so you will not be able to make any changes to it, but you can copy from it into the version of Unofficial Fallout: New Vegas Patch that we loaded into XEdit at boot time. You can change the order and load either/any version of the mod first, so that you can edit/copy records into whatever version you loaded.

Once the Compare To function loads the other version of the mod as read-only into XEdit, you will see a view similar to the one below. Note the two versions that appear together in the Left-hand panel (A), and no errors noted in the Messages Tab (B):

At this point we are done with the comparison. You can browse through the Unofficial Fallout: New Vegas Patch records between the new and old versions, and compare the differences at will. If you don‟t need to make changes, you can simply close XEdit when done.

Here we Left-click-and-hold the record we want to copy with the mouse (A), and drag it horizontally to the mod we loaded when XEdit booted-up (B). Dropping the record into the row will copy that record (and all of its attributers) into the other mod. The screenshot below shows the results, with both sides now identical (A) and the background of both now Green (B) indicating they are indeed duplicates:

The screenshot below illustrates how XEdit will prevent you from drag-n-dropping records from the loaded version of Unofficial Fallout: New Vegas Patch into the “Compare To” version (which is loaded read-only). Note how when trying the drag-n-drop, you get a blocked-circle (B), indicating that you can‟t drop records into the read-only version:

When you‟re done making changes, you‟ll need to save them. You can either close XEdit or press, “Alt-S” to render the Save Changed Files window:

In Step 3 we need to launch FO3Edit (the Fallout 3 version of XEdit), and load our mod-to-be-transferred. When FO3Edit loads, make sure that Fallout3.esm and your plug-in are the only two checked, then click “OK”.

# Replace the missing references using XEdit and placeholders to preserve the location/orientation of these references, and then and Fallout: New Vegas objects in the NV-GECK.

To illustrate the missing references, you can expand the Cell tree in XEdit by Left-Clicking on “Cell” and typing “*” (asterisk). This will expand all levels of the Cell tree and allow you to examine each “Placed Object” as shown in the example screenshot below:

XEdit will pre-populate the field with the next available FormID in your mod, which we will want to change to the FormID we copied from Step 13/14 (from your list of missing FormIDs). Using the missing FormIDs from the Error messages in Step 13 has the advantage of replacing all instances of those references at one stroke without you having to hunt through each cell to find them. The example FormID below is for our missing doors:

Step 19: The last step for each placeholder is to assign a model to that placeholder so that you can see it in the NV-GECK, select it with your mouse and thus replace them with New Vegas objects. To do this we first need to tell XEdit that this object has a model. To do this, Right-Clicking on the “Model” row of the View Tab (A) to spawn the editing window and select, “Add” (B) to create the model reference:

Note: Remember, if you have multiple copies of the same missing FormID (like in our example where we had two copies of the ForgeDoorExterior), you only need to create the placeholder for it once. XEdit will update all other instances for you.

Step 21: Save your work and exit XEdit! You can do this simply by closing XEdit, after which you will be prompted with the Save changed files window as shown below. Make sure your mod is Checked as shown and click “OK”.

Step 22: Great Job! With that done, you have completed the hard part of the complete transfer process and are ready to conduct a final error check to make sure you didn‟t miss anything, and it will be time to fire up the NV-GECK. To run a final test on checking for errors, simply re-launch XEdit and re-load your NV mod:

Step 23: Once XEdit is done loading your mod, run the error check again by Right-Clicking on your mod (A) and selecting “Check for Errors” (B) from the context menu:

Some mods have some many errors in them that the NV-GECK crashes when trying to load them up. This happened to my own big mod (Skyhaven Airport), which had 2,228 missing references and other errors when checking for errors in XEdit! The NV-GECK crashed violently when trying to load a mod with that many errors. Like so many of us, there is a limit to how much garbage that the GECK can swallow without vomiting.

If your mod is suffering this fate, there is hope! You can mass-delete the offending references from your mod with XEdit, or delete enough of them to so that the NV-GECK can take it without vomiting all over your computer (it‟s gross!). I don‟t know what that limit or number is, you may need to experiment if you want to delete some but not all of the offending errors. Below are some examples of the kinds of errors you may encounter, from background loader errors to errors you get when Checking for Errors:

The samples below are all of different types of errors that you might encounter when Checking for Errors in XEdit:

This will strip the entire wasteland out of your mod, and solve that critical issue. If you had this problem then I recommend saving and exiting XEdit at this point, and trying your mod in the NV-GECK again. Trust me, the NV-GECK will be a lot happier with you this time, as it wants nothing to do with the DC Wasteland worldspace.

If you‟ve reached this point and your mod still causes the NV-GECK to crash, then you may have no other choice but to mass-delete all of the missing references from your mod file. You can do this in XEdit by simply expanding each record type by Left-Clicking on them, pressing “*” (asterisk) to expand the tree and finally clicking the “Name” column (B) to sort the records. As shown below, you will then see the errored references grouped together (C):

Close XEdit when done and Save your work. Then re-launch the NV-GECK and try loading your mod file again. This time you should have more success assuming you removed enough (or all) of the errored references. In my testing I have found that the NV-GECK is “wasteland-hardy”, and will ingest a ton of shit before racing for the toilet. This is good for us, as you have an excellent chance of the NV-GECK loading your mod if you remove enough of the offending references.

The mod utilities are a collection of functions that have been added to XEdit over the years for both Oblivion and Fallout: New Vegas that can aid mod authors in several areas. The next sections review these functions and describe how to utilize them.

XEdit will automatically place the SEQ file into the SEQ folder for you.

Building reference information is a common task that is often performed behind the scenes by XEdit, and essentially finds all instances of a “Thing” in the game. Be it a script, NPC or a toilet, the build reference info function will show you all of them across the mod files loaded into XEdit. In this section we feature Xodarap‟s Fallout Overhaul (XFO) mod, which is known as one of the bigger, stable mods that changes that make your gaming experience much more challenging and immersive (I use this myself, so I had to feature Xodaraps fine work!)

For our example of building reference information, there are a couple of choices to consider; If you are trying to find All instances of that Thing, then load all of the mod files when loading XEdit. If however you are looking for instances of a Thing in a single mod-file, then you‟ll only want to load that mod-file as shown in the screenshot below:

Here we start the action by Right-clicking in the open white-space of the Master/Plugin Selection window (A) which presents a small context menu. From this menu choose, “Select None” (B) to clear all check marks. Then you can select just the XFO mod we want to load (C) and click, “OK” to bring it up into XEdit.

Once XEdit is loaded, you will be presented with a screenshot similar to that below. There you can see the three mods loaded, the XFO stand-alone version and its two Masters. To build reference information, Right-

The final step is to save our hard work! Either pressing, “Alt-S” or closing the XEdit program with present you with the Save changed files window as shown below. Simply ensure that the mod you worked on is checked (A), and press, “OK” to Save. (Don‟t try this at home kids!):

There are three options in the main context menu that were built for Oblivion and were carried-forward into the Fallout: New Vegas version of XEdit. These functions may still work for Oblivion, but they do not work for Fallout: New Vegas and are considered Deprecated functions which should not be used for any reason. You may even crash XEdit by trying to run them. These functions that are deprecated for Fallout: New Vegas are: