Difference between revisions of "TES5Edit Documentation"

=== Downloading xxx-Edit from Nexus ===

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

A page simular to this one will appear.  You will need to first click on, "Files" to display the list of xxx-Edit 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 xxx-Edit in the main Files section (C).

Once the archive is open, you will need to extract the FNVEdit files into the right place in order for it to function. That place is the Fallout: New Vegas\ directory, where the FalloutNV.exe program is installed. Do not install into the Fallout: New Vegas\Data directory or the program will not function correctly as shown below.

Note: the FNVEdit package also contains a special file called, “FalloutNV.Hardcoded.keep.this.with.the.exe .and.otherwise.ignore.it.I.really.mean.it.dat”. This file needs to be in the same folder as the FNVEdit.exe. It contains hardcoded, Fallout: New Vegas game engine records which will show up as false errors in FNVEdit if said file is absent.

What makes these special is that the records are referenced in FalloutNV.ESM but are NOT contained in FalloutNV.ESM (they are in the binary). FNVEdit automatically loads FalloutNV.hardcoded.esp… at the same load order index [00] as FalloutNV.ESM so that these hardcoded values can be used in conflict detection and resolution. You shouldn‟t touch this file until you're ready to un-install.

The FalloutNV.hardcoded.esp simply needs to be in the same folder as the FNVEdit.exe. FNVEdit automatically loads FalloutNV.hardcoded.esp at the same load order index [00] as FalloutNV.ESM so that these hardcoded values show up as coming from, “FalloutNV.exe” while working in FNVEdit.

With FNVEdit installed let‟s review some system parameters and drivers that you will need in order to successfully operate the tool. FNVEdit requires current DirectX drivers from Microsoft. You can tell if your system is up-to-spec by simply launching the tool. If FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit.

=== Starting FNVEdit ===

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 FNVEdit can‟t find the Fallout: New Vegas files, it means you moved the files to another directory after installing FNVEdit. 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 FNVEdit 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 FNVEdit.

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

Select the mods that you want to load into FNVEdit, 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 FNVEdit 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 FNVEdit 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 FNVEdit within the last several months as there have been many updates.

The Master/Plugin Selection view is presented to you when FNVEdit is first launched, and allows you to select/un-select the mods that you want FNVEdit 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 FNVEdit and open FOMM. Change the load-order as desired, close FOMM and re-open FNVEdit. 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 FNVEdit view is the most heavily used in FNVEdit, 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 FNVEdit 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 FNVEdit. 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 FNVEdit.

* Checking for Errors – This function is used to check for reports any case where the information in the module file does not match the FNVEdit 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 FNVEdit 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 FNVEdit.

The Information Tab holds a textural version of the FNVEdit 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 FNVEdit.

The Messages Tab acts like a running log-file of what FNVEdit is doing in response to your actions. When you first load FNVEdit, 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 FNVEdit. 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 FNVEdit, 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 FNVEdit 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 FNVEdit; from conflict resolution to mod cleaning to reference viewing and reach ability data – all are achieved by activating a FNVEdit Filter. The Filters essentially work to restrict what data you see in FNVEdit 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 FNVEdit. 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 FNVEdit (if there are changes to save). If you have not saved for a while, FNVEdit 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 FNVEdit more efficient with less key-strokes for some common functions.

FNVEdit 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 FNVEdit runs, it will recognize its filename and run in Master Update Mode accordingly.

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

It is recommended that you create icons for both MUM and MRM (alongside of the FNVEdit 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 FNVEdit.exe. Program, and rename the new copy to, “FNVMasterRestore.exe”.

This will give you 3 icons; FNVEdit.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 FNVEdit 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 FNVEdit 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 FNVEdit:

The application of Filters is the primary means of conflict detection for FNVEdit. When you apply a filter, the loaded mod data in FNVEdit 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 FNVEdit, so you won‟t have to memorize more than one (described in detail below).

Once you click on Filter (F), FNVEdit 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 FNVEdit as the screenshot below illustrates:

FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit. 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. FNVEdit 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 FNVEdit display order as shown above was transposed into the vertical diagram below to help better illustrate how FNVEdit 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 FNVEdit and opening FOMM.

Closing FOMM (to save the load order), re-opening FNVEdit 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 FNVEdit creates one automatically.

Once confirmed, FNVEdit 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 FNVEdit 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 FNVEdit 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.

FNVEdit 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. FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit determines a conflict/override from un-conflicted records.

FNVEdit 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. FNVEdit makes a list with all entries from the Master record, and designates this as the, “TargetList”.

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

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

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

Sub-Step C. FNVEdit 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. FNVEdit makes a list with all entries from CurrentMaster, and designates it as “CurrentMasterList”.

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

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

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

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

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

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

Step 5. FNVEdit 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, FNVEdit generates a string representation including: Level, Reference, Count, Item Condition, Owner, and Owner Rank.

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

Sub-Step C. FNVEdit 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 FNVEdit and Wrye Flash For Maximum Compatibility and Stability ==

Instead of using FNVEdit 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 FNVEdit, because only the tagged items are patched. FNVEdit 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.

FNVEdit 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 FNVEdit. 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 FNVEdit can found in the "[[#Creating_a_Patch_Plugin_.28Manual_Method.29|Creating a Patch Plugin (Manual Method)]]" section.

FNVEdit 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 FNVEdit 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 FNVEdit and follow the steps herein:

Once, “OK” is clicked (D), FNVEdit 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 FNVEdit. 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 FNVEdit, 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 FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit puts the shine on that puppy!

As FNVEdit 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 FNVEdit 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. FNVEdit 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 FNVEdit (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 FNVEdit 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 FNVEdit record definitions. There is a very minimal chance that something that's reported as an error is actually an oversight in the FNVEdit 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 FNVEdit 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 FNVEdit did not understand. These kinds of errors should be sent to Elminster for to ensure FNVEdit 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 FNVEdit 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 FNVEdit 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. FNVEdit 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 FNVEdit 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 FNVEdit shows you are NOT the ones that are actually written into the module file. The FormIDs that FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit to set the ESM flag in its header, then restart FNVEdit 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 FNVEdit 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), FNVEdit 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 FNVEdit 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 FNVEdit 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)”. FNVEdit 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 FNVEdit 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 FNVEdit, 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 FNVEdit, 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 FNVEdit, 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 FNVEdit, 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 FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit:

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 FNVEdit with just the mod being changed as shown:

Note that Weapon Mod Kits is successfully loaded into FNVEdit (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 FNVEdit, 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 FNVEdit, 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 FNVEdit 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. FNVEdit 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 FNVEdit.

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 FNVEdit. Your new load order with the Weapon Mod Kits.ESM loading before the Weapon Mod Kits.esp should be visible in FNVEdits 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 FNVEdit. This will load just the two Weapon Mod Kits files and the Fallout: New Vegas Masters into FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit.

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 FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit as shown below:

The “Compare To” version of the mod is loaded as read-only into FNVEdit, 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 FNVEdit 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 FNVEdit, 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 FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit or press, “Alt-S” to render the Save Changed Files window:

In Step 3 we need to launch Fo3Edit (the Fallout 3 version), 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”.

Step 6: Close Fo3Edit by clicking on the “X” in the upper-right corner, after which you will be prompted to Save your changes to the mod file. Make sure your mod is checked as shown below, and click “OK”.

Note: NOTE: Once you change the master file to FalloutNV.esm, the mod will no longer load correctly in the Fo3 GECK, Fo3Edit or the Fallout 3 game! This is why it is critical to make a backup first!

The complete transfer process will take you through the steps of checking your mod for missing references that are not in Fallout: New Vegas, and offer a method of preserving their location/orientation in your mod by using placeholders. It will also show you how to spot these missing references, and how to look them up in Fo3Edit so that you can see what they were and make decisions on how to move forward. There are two methods of dealing with missing references (or objects/things in your Fallout 3 mod that are Not in Fallout: New Vegas):

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

Step 10: starts the process with launching Fo3Edit, and selecting the copy of your mod and Fallout3.esm as shown:

We load Fo3Edit with the Fallout3-copy of your mod to use as a reference, so that we can lookup references that show as missing.

Step 11: Next launch FNVEdit and load you‟re new/modified New Vegas plug-in, which should show up if you copied the mod into the Fallout New Vegas\data\ directory. The screenshot below shows an example:

Step 12: With both Fo3Edit and FNVEdit loaded with copies of your mod, we start by checking the FNVEdit version for errors. As we have not yet loaded the mod into the NV-GECK, any missing references will be called-out when you do this, and allow you the option of how to handle it. To check for errors, Right-Click your mod in FNVEdit and select “Check for Errors” as shown below:

To illustrate the missing references, you can expand the Cell tree in FNVEdit 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:

Step 14: Now you can Paste each of the missing FormIDs into the copy of Fo3Edit that you launched earlier (Or you can launch Fo3Edit again if you don‟t have it up, and load the Copy/Backup (Fallout3 version) of your mod now). Paste one of the missing FormIDs into the “FormID” window as shown below. This will find that reference and show it to you in the View Tab in the Right Pane:

As we can see in the example above, the “ForgeDoorExterior” object reference was not carried forward from Fallout3 to Fallout: New Vegas, and is thus not present in FalloutNV.esm. You can do this with each missing FormID (copying from error message in FNVEdit, pasting into Fo3Edits FormID window) to see what they are.

FNVEdit 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 FNVEdit 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. FNVEdit will update all other instances for you.

Step 21: Save your work and exit FNVEdit! You can do this simply by closing FNVEdit, 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 FNVEdit and re-load your NV mod:

Step 23: Once FNVEdit 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 FNVEdit! 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 FNVEdit, 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 FNVEdit:

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 FNVEdit 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 FNVEdit 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 FNVEdit 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 FNVEdit 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.

Building reference information is a common task that is often performed behind the scenes by FNVEdit, 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 FNVEdit. 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 FNVEdit. 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 FNVEdit.

Once FNVEdit 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-

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 FNVEdit. 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 instead of the entire list. Some important notes about the "Build Reachable Info" function

Start the action by right clicking in the open white space of the Master/Plugin Selection window (A), which will present 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 FNVEdit as shown below:

Be aware that half-way through the process, the Elapsed Time clock on top will appear to stop, and FNVEdit will appear to be frozen or locked-up. In truth the Elapsed Clock only counts through half of the Build Reachable Info function, so be patient – the process will complete within a minute or two.

One of the less-used features of FNVEdit allows you to actually insert to records (items, scripts, NPCs, etc.) into a mod-file directly from FNVEdit. The GECK is of course the preferred method of adding new things to your mod, but in certain circumstances it is easier or simpler to add the thing directly to the file without the GECK. This function saw its most use just prior to the release of the GECK, when there was no tool to use for such purposes. Now with the GECK in play, there is less of a need for this capability, but it still exists in FNVEdit and is documented for cases in which you want to add references directly to the game.

In this section we feature Martigen‟s Marts Mutant Mod (MMM), which is one of the very best mods created for Fallout: New Vegas. The screenshot below starts the action, in which we Right-click in open space somewhere in the Master/Plugin Selection window (A), then choose, “Select None” to un-check all of the entries. Now check-off the mod you want to change (C), and click, “OK” to load it into FNVEdit (D) as shown below:

The last thing we need to do is save our changes! You can do this via either selecting, “Alt-S” and/or close FNVEdit to render the “Save changed files” window. Here you can select/check any mod you want to save (A), and click, “OK” to save the files (B) as shown in the screenshot below:

This function is used to mark records modified, meaning they will be saved when you press, “Alt-S” or exit FNVEdit. This is sometimes necessary when a mod author wants to force an update of a particular records or group of records to save even though FNVEdit registers no change. The process is one-step as shown in the screenshot below:

To start the action, launch FNVEdit and Right-click in open space somewhere in the window (A) to render a small context menu. Select, “Apply None” (B) from this menu to de-select everything. You can then Left-click the check box for just the mod you want to copy idle animations into (C), and then, “OK” to load it (D). As this function was written by Elminster for Martigen, we of course will feature MMM in this section as shown below:

Once loaded FNVEdit presents the typical output as shown below, in which MMM and its Master file references are the only record-trees shown in the Left-Side Panel (A):

You will be presented with the classic FNVEdit warning window, harkening doom upon the universe should you dare attempt to tamper with this mod file! Indeed, you should not change other people‟s mod files as a general rule. We are only changing MMM for the purposes of this tutorial; just don‟t save it when you‟re done eh?

The final step is to save our hard work! Either pressing, “Alt-S” or closing the FNVEdit 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 FNVEdit. 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 FNVEdit by trying to run them. These functions that are deprecated for Fallout: New Vegas are: