FNV General Mod Use Advice

From Nexus Mods Wiki
Revision as of 23:33, 26 April 2017 by Dubiousintent (talk | contribs) (Essentials for Getting Started: update)
Jump to: navigation, search

Overview

If you aren't aware as yet, it's pretty much universally recognized that the default install location used by Steam (to the "C:\Program Files" folder tree) is a problem area due to the anti-malware security measures taken with it since the release of Windows Vista. Many unexplained problems are directly related to this location. Save yourself a lot of potential frustration and grief in the future by taking the time to move your Steam game (and really all games that did not come already installed) to a different location. The wiki article Installing Games on Windows Vista+ covers the reasons and procedure for moving Steam games.

If you are new to using "mods" with games on the PC, or just want some tips on how to quickly get using mods with "Fallout New Vegas" (or FNV as it is known) with the least amount of hassle, this is the place to start. This article broadly covers things you should know, and points you to more in-depth articles on particular subjects.

Just to clarify: "Fallout New Vegas" (2010) still uses the same "Gamebryo Engine" as "The Elder Scrolls III: Morrowind" (2002), "The Elder Scrolls IV: Oblivion" (2006), and "Fallout 3" (2008).

- Wikipedia.

It is important to keep the distinctions between engines in mind when attempting to transfer "lessons learned" or tools from one game to another. The games based upon the Gamebryo engine tended to build upon prior knowledge from the older games, while games built upon the "Creation" engine tended to "go their own way" in important aspects.

Terminology

A "mod" is a package (archive) of related files that make some change to the vanilla game (including official "Down Loadable Content" (DLC) expansions as delivered by the publisher). The "file extension", the characters after the last period (".") reading left to right in the filename, indicate which program was used to create the archive package. (You can use the site File-Extensions.org to look up those you are not familiar with.) The ones most commonly used for mods on the "Nexus Mods" site are ".7z" (created by the 7Zip program), and ".rar" (created by the WinRAR program. There are a number of alternative tools which can unpack those types of archive files, but each archive tool has mutiple "formats" in which it can compress a file. Some of these may be "proprietary" and exclusive to a particular program, while most are common among many programs. 7Zip is the most commonly used program as it can unpack the most common, non-proprietary ".rar" formats as well as ".zip" files (a predecessor format, now natively supported by Windows).

Within a "mod" package are a number of "asset files" which add to or replace the existing vanilla assets (meshes, textures, sounds, animations, XML files, etc.), and one or more "plugin files" that tell the game about the existence and use of the new assets and where they are placed in the game. The "plugin" files are the only ones that appear in the "load order" (see below). "Plugin" files have one of two possible file extensions: ESM and ESP. There is generally only one ESM file, but there may be any number of ESP files (including none). The ESM files are loaded first, and are considered "masters" to the ESP files that depend upon them. You should find all of your ESM files (vanilla, DLC, and mod) at the top of your "load order".

"Modding" refers to both the process of playing the game with mods installed, and to creating such mods. More properly we should distinguish between "mod users" and "mod creators", but most people rely upon the context in which the term is used rather than explicitly stating which is meant.

There are two important "orders" to which you must learn and understand the distinction because they are going to come up over and over again: "install order" and "load order".

  • "Install Order" refers to the sequence in which mods are "installed" into the game "Data" folder. Later installed mods that have a file with the same folder path and filename will need to overwrite previously installed files in the same location. So the last installed "wins", as there can only be one file with a given name in a given folder. With mod managers, this can become less obvious than it would appear at first glance. Some mod managers allow you to "move" around the sequence of installed mods, and then resolve the new "winners". This is possible only if they have a copy of the "vanilla" files to restore from when needed. Read the documentation of your chosen mod manager carefully to see how (if at all) this is implemented. The "vanilla" files are typically all stored in ".BSA" extension archive files, but some "loose" files (not in a ".BSA" file but visible as individual files) may exist in folders under the "Data" folder. Therefor, best practice is to make a backup copy of the entire "Data" folder somewhere outside of the game folder. Then you will always have the original files and can compare the contents to see what has changed.
  • "Load Order" refers to the sequence in which the game loads ".ESM" and ".ESP" (collectively called "plugin" files) when the game is launched. These two files in turn take care of loading the "assets" (sound, meshes, textures, etc.) from the mod into the game. Most of your problems with running mods will come down to problems with your "load order" because two (or more) mods are trying to modify the same "data record" in the vanilla files (both the original game and the DLC expansions. Similarly to the situation with "install order", the last loaded plugin "wins" out over all previous plugins that conflict by default, in an all or nothing manner. IF the other plugins make changes to other records that the "winner" doesn't touch, they still lose out and those changes do not take effect. This is known as "the rule of one", and is why "proper sorting" of your "load order" is so important. Those files that are "lower" (relative to the "Fallout.ESM" files; higher numbered) in your "load order" will be the "winners" of conflicts.
    • Fortunately there is a way to get around this "all or nothing" winner in "load order" by using a "merged patch" file that resolves conflicts on a "last modified record field" winner basis. This enables multiple mods to change a record as long as they are the only one changing a particular field within that record. In the case of record field conflicts, the same "rule of one" applies. More on this topic later in a linked article.

For the user, a mod package essentially has three "states": "downloaded", "installed", and "activated".

  • Downloaded: the mod package has been copied from a server on the Internet (i.e. The Nexus Mods website) to a location on your computer.
  • Installed: the "downloaded" mod archive package has been "unpacked" and the package/archive contents "installed" into the same or a different folder (i.e. a "Mods" or the game "Data" folder) on your computer.
  • Activated (aka "Enabled"): The game has been instructed to load the plugin as part of it's "load order". For FNV, this means it has had the "checkbox" enabled in the "Data" option of the first game menu. Mod Managers take care of this for you when the plugin is enabled/activated in their interface.
For some mod managers (i.e. "WB/WF" and "FOMM"; see under Mod Managers below), "installation" means the mod files have been copied into the game "Data" folder or sub-folders. This "install order" is independent of the "load order", and is considered the "traditional" form of installation. For others (i.e. "MO" and "NMM"), the "mod" or "install info" folder is separate from the game folders, and only "links" to the actual files are placed in the game "Data" folders, and that only when the mod plugins are "activated". In these mod managers, the "install order" initially equals the "load order", and changes when the "load order" of the plugins is re-sorted.
However, mods often include the previously mentioned "asset files" that are placed in sub-folders under "Data", which are used instead of vanilla versions of those files. Merely "deactivating" a mod plugin does not remove such added or restore replaced files, so the mod must be either uninstalled or it's unused/unwanted "asset" files manually removed from the "Data" folder path so the vanilla versions will be used. The game engine still loads every file it finds in the "Data" folder into memory and checks it's references for "master files", regardless of it's "active" state. This is why they count against your "plugin cap" (described later). If it fails to find any of such referenced masters, it causes a "missing master" CTD without warning. This is the primary reason you can't use a patch file designed for mods you do not have installed, as they will always be missing the "master" plugin of the absent mod and "mysteriously" crash.

Most mod packages are "simple" in structure and can be installed with any mod manager. They just need to have all their contents installed into the correct folders under the game "Data" folder, which is what all mod managers assume. They normally have any sub-folders already included in the archive. You should always "overwrite" any existing files they encounter with the same name. (This is why "install order" is significant. Last installed is the last to overwrite, and the only version of that filename to exist.) Note that some mods, such as Script Extender plugins and tools like FNVEdit, need to be placed elsewhere than under the "Data" folder, which is why they should not be installed with a mod manager.

Some mod packages are more complex, with optional files that need to be copied when other specific mod files are also found to already have been installed. The mod may have specific instructions in the provided documentation (aka "ReadMe.txt" files), or on the download page, or under "optional files" on the mod's "Files" page. But some have "scripts" or "wizards" which the manager will automatically execute (if it recognizes them) that will detect the files of the other mods they are designed to work with, and automatically install the correct components or offer you options to choose among. (This is especially true of FOMM mods.) However, these "scripts" are not "universal" in that they do not work will all mod managers. Such scripted mods will normally specify on the download page which mod manager they require to process their "wizard" (i.e. "install with FOMM").

It is not absolutely required that you use the mod manager a script is designed for, if you don't care about actually executing the script and know how to interpret it. The script itself is a text file with basic "if ... then ... else" style instructions you can follow manually or rewrite into a different scripting language if you have the skill set. But most will find it easier to simply use the manager the script is written for. However, mod managers generally only can "manage" mods they themselves install. They won't "know" about mods installed by other managers unless they happen to place them where expected. ("Management" in this case typically refers to "installing", "uninstalling", and "restoring" the previously existing mod components cleanly, as opposed to "activation". Depending upon how your manager works, it may be relatively easy to get it to "activate/deactivate" plugins from sources it did not manage.) So it normally is beneficial to plan ahead and use the mod manager suited to the majority of mods you plan to install.

There is an important consideration with "complex" structured mod packages (i.e. "Fallout Character Overhaul (FCO)" being a popular example of this). YOU need to know which "optional" components or "compatibility patches" are needed. (Often others than the original mod author will produce "compatibility patches" for additional mods. Be sure to seek them out by searching on both the "full name" and "nickname" of the primary mod, such as "Fallout Character Overhaul" and "FCO", as well as under the "optional files" of the secondary mod, like one for "Hair styles".) Installing package component files that are not needed can prevent the game from starting. (See the entry on Missing Masters below.) Do not install every optional file without a reason: pick and choose only those you know are needed. It is much easier to add a missing optional file later than it is to figure out which are not needed and are preventing the game from loading. Seek assistance on the Forums when in doubt.


"Post Processing" is used in the video and film industry to improve the quality of images once they have been processed. In real-time 3D games, they are applied to the rendered effects to supplement the game engine.

According to Wikipedia:

Instead of rendering 3D objects directly to the display, the scene is first rendered to a buffer in the memory of the video card. Pixel shaders and optionally Vertex shaders are then used to apply post-processing filters to the image buffer before displaying it to the screen. Some post-processing effects also require multiple-passes, gamma inputs, vertex manipulation and depth buffer access. Post-processing allows effects to be used that require awareness of the entire image (since normally each 3D object is rendered in isolation).

There is a whole host of effects that can be produced. See the sub-topic Post processing shaders if this interests you.

First Timer Advice

Bandwidth Considerations

Bandwidth refers to how much data (measured in bits) you can move between point A and point B in a given period of time. All Internet communications consume bandwidth. In the most general terms, the faster your connection speed ("bits per second" or "Mega bps" or "Giga bps"), the more bandwidth you have at any given moment. However, the amount of data you have to move has to be divided into "packets" that do not exceed your bandwidth. So, the more data you have to move over a given bandwidth, the longer it will take. This is called your "throughput data rate". For this reason you generally want to minimize the amount of data that has to use bandwidth to increase your "throughput data rate". Your "Internet Service Provider" (ISP) typically has a maximum amount of data transfer each month or given period called a "monthly data transfer cap", after which it charges you extra or "throttles down" your available bandwidth to a slower throughput rate.

The Steam Client has to be running in order to play a "Steam" game. As this (in "online mode") consumes bandwidth, if you have a slower connection speed or "low transfer cap" you will want to take steps to minimize how much throughput the Client requires. If this is a concern for you, please read one of the articles:

However, if you previously setup the "Steam Client" (under "Steam | Settings") by disabling (unchecking) the "Don't save account credentials on this computer" option at the bottom of the page so it will save your account data locally, then you can start the Client in "offline mode" and play the game even without an Internet connection after your very first session. You simply won't have any of the Client functionality like "Community" or tracking of the number of hours you have played or achievements reached until the next time you play in "online mode", whereupon it will update that information.

In either "offline" or "online" modes, you can close the Client interface window but must leave the Steam icon in the "system tray" on the end of the Windows taskbar (the one on the edge of your monitor with the "Start" button).

Do NOT accept the default install location

If you have already installed Steam to "C:\Program Files", read the Installing Games on Windows Vista+ article which has a link to the official Steam guide to moving already installed Steam games. (Yes, you will need to "re-install" them so the Windows registry entries are correct, but you can still use your "saved game files".) As painful as this may sound, this one step will solve most "strange" problems not related to a mod conflict, and you will no longer need to run your games as an administrator. It is never easier to do than now, and you don't need to move all your Steam games at once.

Maximizing use of memory

You need to be aware that FNV is a 32-bit game. As such, it can only address up to 2GB of RAM by default, even on a 64-bit system. A detailed explanation of the reasons behind this and some solutions around it if you have more than 3GB of system RAM can be found in the wiki article 2-4GB game memory limits and solutions. But for FNV Steam users there is a tool called 4GB Fallout New Vegas Updated (FNV4GB) that easily solves the problem.

Note that in order for FNV4GB to properly work with NVSE (see the Script Extenders sub-topic below), it must be installed in the game root folder (".\steam\steamapps\common\Fallout New Vegas\"), even though technically it can be installed anywhere. Generally this means it should be installed "manually", as mod managers install to the "Data" folder instead.

Recently there has been a updated replacement for FNV4GB called FNV 4GB Patcher, which is simpler to install. (Run the patcher once as "Administrator" and thereafter just use the default game or Steam Launcher as a normal user. It automatically detects and launches NVSE.) It is co-authored and recommended by part of the "4GB Fallout New Vegas Updated" team.

Those anticipating or encountering problems with textures consuming too much video memory should read the S.T.E.P. ENBoost page. This a separate component of the ENB "post-processor" which increases available video memory by up to 4GB without the graphic effects of the main ENB tool.

Adding 'third-party tools' to mod managers

Most mod managers have a method of adding "third-party" tools like NVSE, FNVEdit, and FNV4GB to their launch options. This is not required for FNV4GB, which normally is run from the desktop shortcut instead of inside a manager. However, as some NMM users have had trouble discovering about it, here are specific instructions on how to do so. Supposedly the equivalent will be added to the "launch list" in the top left corner where the FNV and NVSE launchers are currently located in the "next release" after April 2015. The instructions are presented here in a generalized form as a guide to adding other "third-party" tools to the NMM launcher:

  1. Install the tool according to instructions, paying particular note as to the correct location.
  2. In NMM open "Settings" (looks like a pair of gears):
    • Open the "Fallout: New Vegas" tab.
    • Locate "Custom Launch Command".
    • Enter the explicit path to your tool "exe" file in the "Command:" field
    (Ex.: "C:\Games\SteamLibrary\steamapps\common\Fallout New Vegas\fnv4gb.exe" without the quotes.)
    • Click the "OK" button.
  3. Open the "drop list" window for the "Launch" button in NMM.
  4. Choose "Launch Custom Fallout: New Vegas".

First Rule: Install one mod at a time

First rule of playing with mods is: install and TEST one mod at a time. This is the only way you are going to know if you have made a mistake in installation or if the mod is going to conflict with others before getting many hours into the game before a fatal problem shows itself and you have to start over.

In turn that means you need to prioritize what is most important to you. You don't want something that is "nice to have" dictating that you can't use something you consider essential. This takes time, but if you don't force this discipline upon yourself, you are going to spend a lot of frustration and even more time ripping your game apart trying to figure out why it crashes or won't work right. There are no shortcuts. A guide by somebody else is not guaranteed to work on your system because they don't have the exact same setup as you; nor do they necessarily consider the same things as "important".

Second Rule: Make it playable first

Second rule is: "pretty" does not beat out "playable". Improved graphics come at a cost, usually in terms of "frames per second" (FPS). Add your graphics overhauls after you have a stable game built that runs fast enough to keep you happy. Nobody has a system new enough or fast enough to play with every mod they might want. The game engine is too old to accommodate that. It was written for single processor 32-bit systems. All your multi-core processors are going to be ignored. So there WILL be limits.

Third Rule: The Rule of One

Third rule is called "The Rule of One". What this means is that when two plugins attempt to modify the same record in the vanilla game, only the last plugin loaded (determined by the "load order") "wins"; totally and completely. (This is described in the Terminology section, under "Load Order". This rule also applies to "Install Order".) The way around this is to use a "bashed" or "merged" patch file, which enables "record level" conflict resolution among all the plugins instead of the default "one plugin winner takes all" approach. The subject of how to create either a "bashed" or "merged" patch file is covered in the S.T.E.P. Project "Fear and Loathing" guide linked under the sub-topic Merge Patch File below. You don't really need either one until you have settled on your basic mod lineup, which should be before approaching the plugin limit described elsewhere in this document.

Fourth Rule: Reloading "save game" files

The rule is simple: ALWAYS "quit to the desktop" before reloading a "save game" file of any nature during a game session: quick, auto, checkpoint, manual, triggered, whatever. (This rule applies to all Bethesda games thru the latest. It is the only guaranteed way to avoid corrupting save games.)

While this practice is annoying, it is necessary because there is now a difference in the state of the game "in memory" and "as saved". Unless you quit to the desktop, the "in memory" state of the game persists with only portions getting overwritten from the save file. As an example, say you've been blown up by a mine, reload from a quick/auto save ten yards away from where you were blown up, and then go in search of that mine ... only to find it is no longer there. That's because "in memory" that mine has already blown up and no longer exists. It was not something that was included in the save. (Saves are primarily about your character and it's status, inventory, and certain "state" variables such as quests; not the entire rendered world. Things that are different than the default state.) Quitting to the desktop will put the world state back in time to the way it was before you triggered the mine. Now imagine things like scripts and their flags being triggered, then "oops: not triggered", depending on states in memory. Complex corruption of the game thereafter if you don't quit to the desktop so the world "in memory" gets synced/reset to the state at the time of the save.

Essentials for Getting Started

There is an excellent set of advice for those new to modding "Fallout: New Vegas" (FNV) Fallout New Vegas Beginners Guide to modding thread ("sticky" at the top) which covers the essential tools you will need, such as LOOT for sorting your "load order". Like most automated tools, LOOT is not 100% accurate; yet it is infinitely better at determining a correct load order for a large number of mods than anything other than manually examining each mod in an editor like FNVEdit (a generic tool called 'xEdit' which is renamed for working with specific games) and building such an order by hand (each time you add or remove a mod). (There is a FNVEdit Training Manual specific to both FO3 and FNV.) LOOT works by examining the file header of each plugin and working out all the records each modifies, and determines the relationships between those mods. For the beginning mod user, it is essential to resolve most fatal mod conflict problems. LOOT does provide the "metadata" mechanism that allows you to customize it's sorting to preserve such adjustments as you determine necessary. Read it's documentation to exploit all of it's capabilities.

NOTE: Do not use xEdit with any "mod organizer" or other "load order aware" tool open at the same time. While some might be compatible with sharing the plugin or "load order" information with xEdit, others are not. Play it safe and give xEdit exclusive access.

For those who wish to use a manual sorting process, see the wiki article Load order and you for one such approach to FNV.

Also recommended is the S.T.E.P. Project "Fear and Loathing" guide for FNV (linked below under the Mod Managers sub-topic). While oriented around using "Mod Organizer" (MO), it can be used with other mod managers as well, with appropriate changes for their peculiarities.

"Auto-saves" are dangerous because they are seldom able to tell when the game is in the middle of doing something else critical. Most importantly, completely disable all manner of autosaves in the game options. The CASM and CASM with MCM mods attempt to provide more control over such situations. Simple Saves provides timed interval "full saves" without all the features of CASM, but only keeps 5 versions before it starts overwriting older files after the 5th save. They are all better than the built-in mechanism, but don't rely upon any auto-save exclusively. Manual "full saves" after waiting about five seconds with nothing happening are still safest. Also, you can use Clean Quick Saves to create a new "quick save" file every time, which is safer than overwriting an existing file. You will need to periodically clean old ones out (they count against the total number of save files you are allowed), but the purpose of a quick save is as a "temp" for safety's sake rather than a place to resume the game session from. They do not save as much data as a "full save". QSaves are best reloaded when you are still in the same cell (preferably in the same position) as when you saved.

Vanilla "Load Order"

In general, make sure all your ESM files are loaded first, with the game ESM (FalloutNV.ESM) as the very first file and those of the DLC next in the order they were released for the PC.

  • FalloutNV.ESM - (Oct 2010)
  • DeadMoney - (Feb 2011)
  • HonestHearts - (May 2011)
  • OldWorldBlues - (Jul 2011)
  • LonesomeRoad - (Sep 2011)
  • GunRunnersArsenal - (Sep 2011)

and then the "pre-order packs" of exclusive equipment to make the earlier stages of the game easier; later combined and released as the "Courier's Stash" pack (Sep 2011). As these "inject" records into the vanilla game, their load order is not important other than being up top with the other ESM files:

  • ClassicPack
  • MercenaryPack
  • TribalPack
  • CaravanPack

These are all included in the "Ultimate Edition" of FNV.

Mod EMS files should follow.

Note in particular the "First Rule" to install one mod at a time and test it thoroughly before the next mod. This, and that you install your Steam games to some folder OTHER than the default of "C:\Program Files", are pretty much universal for a solid, stable game.

Game INI files

The game has three INI files: the general "Fallout_default.ini" in the game root folder ("<steam install path>\steamapps\common\Fallout New Vegas") which only gets used to recreate the other two when they are not found; and the two specific to you in "C:\Users\<YourAccountName>\Documents\My Games\FalloutNV" folder ("FALLOUT.ini" and "FalloutPrefs.ini"). The two in the "Users" folder get created when you first run through the vanilla "FalloutNVLauncher.exe", which is necessary the first time in order for the engine to determine your hardware configuration. This information gets preserved in the "FalloutPrefs.ini" once you exit from the "Main Menu".

First make a backup of the original 'Fallout_default.ini' and 'FalloutPrefs.ini' files as a precaution. With these in a safe place as an appropriate backup, it is better to edit the default file as well the others with tweaks you know you intend to keep, so it will rebuild the "User" files as you expect when necessary. When experimenting with INI changes, only the "Users" files should be changed as they are what the game actually uses. Once happy with the chosen tweak, remember to change it in all three files: otherwise you tend to lose track of which you actually changed if you have to "verify files" or re-install later.

Restoring to "Vanilla"

It is often useful to have a copy of the original, unmodified game for testing purposes with a saved game just after you have created a basic character, or if a mod conflict forces you to "start over".

Sometimes, if you didn't plan ahead for this, you want to restore the game to the original "vanilla" state, for instance to restore an original file. The following "verify files" procedure will NOT remove any mod plugins or asset files it finds in the game "Data" folder, nor any files in the "Users" folder, but will restore any files in the game root folder with the same name as vanilla ones that do not match the originals on the Steam server. This can break a mod that intentionally replaced a vanilla file, so it is best to re-install mods after you "verify".

If you made any changes to any of the game INI files, remember to change it in all three files. (See the Game INI files section.) Otherwise you tend to lose track of which you actually changed if you have to "verify files" or re-install.

For a visual "image guide" to this same "verify files" process, click here.

  • Start the "Steam Client",
  • Navigate to the "Library" tab,
  • Right-click on "Fallout: New Vegas" in your list of purchased games,
  • Select "Properties",
  • Then in the "Properties" window, Select the "Local Files" tab.
  • Click on "Verify Integrity of Game Cache". "Verifying" files will not affect your "saved game files".
  • Rename both the INI files in the "C:\Users\<YourAccountName>\Documents\My Games\FalloutNV" folder, and let the game rebuild them by launching the "vanilla" launcher "FalloutNVLauncher.exe", configuring the hardware options and exiting when you get to the Main Menu of the game. Rename the INI files to anything you choose. I usually just add to the extension: from "<filename>.ini" to "<filename>.ini.old". The purpose is to be able to examine the old files for things you want to be able to replicate in the new versions of the same file.
  • If you used the FNV 4GB Patcher to enable the use of more than 2GB of RAM, you will need to re-run it after verifying files.

To completely uninstall the game in order to get a "clean start" without any mods installed, you should click on "Delete Local Game Content" in the game "Properties" | "Local Files" tab. This should remove all game related files, including mods, and you can skip to the "reinstall" step.

If that doesn't seem to be working for you, you can manually delete the game with the following steps:
  • Exit the Steam Client.
  • Navigate to "C:\Users\<YourAccountName>\Documents\My Games\FalloutNV" folder.
  • Backup any save games you wish to keep to another location. You might want to rename any INI files to something different (i.e. "<filename>.ini" to "<filename>.ini.old") before backing them up. It's better to make manual changes to new versions of the INI files instead of trying to use old ones that may have become corrupted.
  • Delete the "C:\Users\<YourAccountName>\Documents\My Games\FalloutNV" folder.
  • Use Windows "Control Panel | Programs | Uninstall a program" control to uninstall the game.
  • Navigate to the "<Steam install path>\steamapps\common" folder and check that the "Fallout New Vegas" folder is empty or deleted. If it isn't, manually delete the "Fallout New Vegas" folder and any contents remaining there.

To reinstall the game once you have deleted the previous version:

  • Start the Steam Client.
  • Navigate to the "Library" tab,
  • Right-click on "Fallout: New Vegas" in your list of purchased games,
  • Select "Play Game". Steam should now recognize the game does not exist on your computer and start downloading it again.
  • Once the game has been reinstalled, run the "vanilla" launcher "FalloutNV.exe", configuring the hardware options and exiting when you get to the Main Menu of the game.
  • If you used the FNV 4GB Patcher to enable the use of more than 2GB of RAM, you will need to re-run it after re-installing files.
  • Now you can restore your backed up "save game" files to the "C:\Users\<YourAccountName>\Documents\My Games\FalloutNV" folder.

Mod Managers

While a "mod manager" is not required it does make organizing your modded game much more manageable if you have more than a dozen files. This is especially true when trying to keep the "install order" (which deals with overwriting files of the same name) separate from the "load order" (which relates to the order in which the game reads in mod plugins). You should only need to learn and use one manager, but some mod archives are formatted for use with a particular manager. You can learn how to "repackage" them to work with your preferred choice, but sometimes it is easier to simply use the manager the mod is formatted to work with. Just remember that mods installed through a different mod manager will not be "known" by your preferred manager. The impact of this varies by the manager. But the "exceptions" are generally easier to keep track of.

There are several choices of mod managers such as:

  • NMM is still technically in "beta" status but is fully functional. Moreover the primary author of "Mod Organizer" (below) has now been hired full-time by the Nexus site management to rewrite "NMM" from scratch. So the current "beta" will not be further improved, and the future fate of MO is uncertain at the moment though support continues.
  • NMM Manual.
  • NMM Video tutorial by Gopher.
  • NMM Video tutorial by GamerPoets.
  • Neither version of FOMM seems to be updated any more but both are usable, stable, and functional, and the other managers are still actively supported. The "Forked" version is recommended between the two, and was created to fix problems in the original.
  • Installing a Mod with FOMM
  • FOMM and FOMODS for Dummies, Part 1
  • Wrye Flash (WF) is the FNV version of "Wrye Bash" (WB) and creates the "Bashed Patch" mentioned.
  • WF/WB is a "swiss army knife" sort of tool, but if you follow the Wrye Bash Pictorial Guide you can get functional with it quite quickly. The most essential parts are the "Mods" tab for your "load order" and "bash patch", and if you intend to use it as your mod manager: the "Installers" tab (known as BAIN) for managing your installed mod packages. Complete documentation is included as HTML files.

The subject of "ArchiveInvalidation" in mod managers always comes up when discussing "texture replacements". The topic is described in the TESTG Troubleshooting section. (When you have questions about "meshes" and "textures" and their replacements, this site is a good starting point to understanding the subject.) The basics of turning "ArchiveInvalidation" on and off are described in the the wiki article Fallout NV Mod Conflict Troubleshooting "Checklist" section.

Smaller Plugin Cap

Be aware that there is a limit to the number of mod plugins (ESM and ESP files) you can have active at the same time. ("Active" meaning the file is present in the game "Data" folder with an ESM/ESP file extension, and "activated" in the game for loading.) Merely being present in the "Data" folder, even if not "activated", plugins count against the effective limit the game can cope with. The game loads all that it sees in that folder before determining if they are part of the "load order". As a result, even "Inactive" plugins can cause a hidden "Missing Master" error. This is common for Gamebryo engine games, but the cap is much smaller for FNV than players of other Bethesda games are used to. The patched game has a cap anywhere between approximately 130-140 "active plugins" depending upon your system. "Strange things" happen when you exceed this cap, such as textures suddenly looking weird (missing, or solid or "wrong" surface colors) and the game crashes where previously things were fine.

Remove any unused plugins (ESM or ESP extensions) from the "Data" folder, especially "optional files" which shouldn't have been installed in the first place. Again, installing and testing one mod at a time, especially as you near or exceed 130 active mods, is the best way to tell where this limit is for your situation.

There are ways to get around this limitation: by "merging" plugins, and by placing only the "activated" plugin in the "Data" folder (which some Mod Managers do) for instance. See the wiki article Merged Plugin Guidelines for Personal Use for a description of the "merging" process.

DLC expansions

There are two types of "downloadable content" (DLC) available for FNV: four expansion addons to the game world, and "item packs". There are four "pre-order item packs" originally only available through certain retailers for pre-ordering the game, which contain custom items available to the starting character. Later the "pre-order packs" were made available combined in the "Courier's Stash" package. The fifth expansion "Gun Runners Arsenal" (GRA) is also an "item pack" with primarily additional unique weapons, weapon mods, and new powerful ammunition types and ammo recipes; along with some additional Steam "Achievements and trophies". All five expansions and the "Courier's Stash" packs are bundled in the "Ultimate Edition" of the game.

The "pre-order packs" and GRA have no impact upon the main plot line. The other four expansions provide additional background motivational material on some of the characters in the main plot, as well as additional world spaces, unique weapons and chems, and new challenges to explore. You can safely ignore them without harming the main plot progression if you wish.

The community has generally recommended that you play the four world expansion DLCs in this order. Note that it is not strictly in release date order. Some feel strict release order sequence is the development team's design:

  • Honest Hearts (Happy Trails Expedition - accessed via the Northern Passage). Target: level unspecified. (Suggested before Level 10, and after the "Volare!" quest from the Nellis Airbase "Boomers" faction, which is unrelated but does get you a "rebreather" and is a way of judging how ready you are).
  • Old WorldBlues (Midnight Sci-Fi Feature! - accessed via the Mojave Drive-In). Target: level 15+. Recommended before level 20 and Dead Money. (Suggested before the "Brotherhood of Steel" (BoS) quests as well.)
  • Dead Money (Sierra Madre Grand Opening! - accessed via the Abandoned BoS Bunker). Target: level 20+. (Suggested before level 20, just after BoS quests.)
  • Lonesome Road (The Reunion - accessed via the Canyon Wreckage). Target: level 25+. (Suggested last, before the 2nd Battle of Hoover Dam climax of the main plot. Be prepared for lots of Deathclaws and SentryBots).

All the DLC worldspaces (except for Dead Money) can be returned to upon completion of their quest. In addition, only Lonesome Road can be left at any time before you complete it's main questline. Companions are not allowed to enter any of the DLC expansions. They must be dismissed ("part ways") or will be dismissed for you prior to the actual activation of the specific add-on quest. Some companions can be acquired during the DLC quests, but will not be able to leave that worldspace at the end of the questline.

If you don't want to play with some of the DLC, you may find that simply not activating them is not enough; they still load anyway. This is due to the presence of a "<DLCName>.nam" file for each. These force the game (and the Construction Set "G.E.C.K.") to load them automatically. You will need to move those ".nam" files out of the "Data" folder, or rename them with a different extension before you can successfully deactivate the DLC.

Script Extenders

Mod creators are always wanting additional script capabilities the native game "construction set"/editor doesn't provide. These are generally provided by mods/tools called "Script Extenders" and are created by talented programming members of the community. In general, there is only one such tool that the community settles around and possibly additional supplemental extenders that "hook" into that primary one.

FNV, at the time of this writing in 2016, has New Vegas Script Extender (NVSE) as it's primary extender, and the supplemental "script" extenders JIP NVSE Plugin and "Lutana NVSE Plugin". In addition to other functions, JIP is known for providing "companion" oriented functionality, and Lutana for "game controller" input emulation. However, both go well beyond those features. Mod creators should check their download pages and the GECK website on "NVSE", "JIP", and "Lutana" for documentation of their added functions. Various mods require one or the other or even both, in addition to NVSE. This is always documented in the requirements section of the mod's description. NVSE plugins other than supplemental "script extenders" also exist.



It is first necessary to get the vanilla game correctly installed and INI files created before installing NVSE. Be sure you go through the hardware setup screen, and then exit when you get to the "Main Menu" which has the options to create a new game or load a save game file. This is necessary to create the "FalloutPrefs.INI" and "Fallout.INI" files in your "C:\Users\<YourAccountName>\Documents\My Games\FalloutNV" folder.

The FNV game itself does not automatically create a log file. However, NVSE can be made to turn one on. See Checklist item #4 in the "Fallout NV Mod Conflict Troubleshooting" guide for instructions on how to enable this.

You must have NVSE installed correctly before it or any of the supplemental extenders will work correctly. All the script extenders create "log" files in the game "root" folder, automatically. If there isn't an NVSE log, then you either didn't set it up properly or failed to start it correctly. It always creates one with game initialization entries automatically. Once installed, always check the log files for errors after initially running the game with any mod that requires them. It's also a good practice after installing any mod.

NVSE will always create a log when the game starts. The others only do so when a mod calls for their services. Otherwise there is no visual indication that they are working or not.

Be sure to launch the game either with FNV4GB (if you use it) or "nvse_loader.exe" instead of by the vanilla launcher or from the Steam Library, so NVSE gets loaded. If that still doesn't get you a log file, then you need to reinstall NVSE.

  1. This time, don't use a mod manager to install NVSE. They always assume everything goes under "Data" which is not the case with NVSE.
  2. Manually unpack the NVSE archive file somewhere outside of the game folders. The internal structure of the archive usually has a top level "version" folder like "nvse_5_0_beta3", which the game won't process correctly.
  3. Copy the contents under the "version" folder (excluding the "src" folder which is not needed) into the game "root" folder (i.e. "<Steam Install Path>\Fallout New Vegas").

When installed correctly you should see "<Steam Install Path>\Fallout New Vegas\Data\NVSE" folders. The game "root" folder should have four "nvse_*.dll" files, and "nvse_loader.exe", along with two "nvse_*.txt" files. You can compare the contents of the unpacked archive to the files you copied over to the game to check you have everything.

Other NVSE plugins like JIP and Lutana will go into the "Data\NVSE\Plugins" folder. You may initially create this "Plugins" folder yourself or let either JIP or Lutana plugins installation do so for you. Again, best to install them manually unless you know your mod manager can properly handle such plugins. You always have to watch out for "version" folders. When present they always require you either restructure the archive without them or install manually.

NVSE installation does not automatically create the "nvse_config.ini" file in the "Data\NVSE" folder. When you need one for the "Sheson" memory patch mentioned below under "game fixer mods", simply create a text file of that name and rename it with the ".ini" extension instead of a ".txt" one.

Towards Game Stability

  • The foundation of game performance is to first optimize your system for gaming.
  • If you want a stable game, don't make any changes to your setup once you start playing and making "save game" files. Even updates to current mods run the risk of making things unstable after the point they are added. If you do update, ensure you know which save to revert to prior to that update if it goes wrong.
  • Do not use the game's "auto-save" feature. See the sub-topic 'Issue: CTD on interior/exterior/"fast travel" cell change' in the wiki article Fallout NV Mod Conflict Troubleshooting for the explanation and alternatives.
  • Removing a mod that has stored some elements in a "save file" will leave residue (even with a "clean save") that can cause problems down the road. In particular you have to watch out for mods that use scripts to permanently change form and leveled lists (such as, purely as an example, Millenia's Weapon mods). This is not, in and of itself, a bad thing as there are compatibility advantages to using this "script" technique. Such mods usually point this out in their description. But it is something to pay attention to when experimenting. It's better to find out what causes problems before you start to play in earnest.
  • Use the Community "game fixer" mods. The following are commonly recommended, though their effectiveness varies by system. Install and test individually in the following order:
(Note that NVSE is not listed as a "bug fix", though it may be required. Instead it extends the game functions that may be needed to produce a fix. See the Script Extenders section for details.)
Essentials:
  • New Vegas Stutter Remover (NVSR) (requires NVSE. The 5.0 beta versions are stable. Check version requirements of other mods when choosing.)
  • New Vegas AntiCrash (NVAC) (solves most common CTDs).
  • "Sheson memory patch" for NVSE. (Increases "heap size". Use either the "heap replacement" feature of NVSR or this. Both together do not appear to conflict, but seem to be "overkill" at the cost of almost 1GB of game memory.) See the 'Issue: CTD without warning, "out of memory error", or stops responding' sub-topic in wiki article Fallout NV Mod Conflict Troubleshooting for simple but detailed instructions for enabling this patch or alternatives.
  • Yukichigai Unofficial Patch (YUP) (and the various optional patches for it and other mods, There are other YUP patch files than on that page you may have to search out for other mods). Provides the most current and complete "bug fixes" for the vanilla game without requiring anything else.
Optionals:
  • Unofficial Patch Plus (complementary to YUP; bug fixes that require NVSE, plus some "fixes" that are not technically "bugs", but believed by the author to be "as intended").
  • Mission Mojave Ultimate Edition - FNV Community Patch (MMUE) (alternative to YUP, along with it's various optional mod compatibility patches). Note some who have looked at the internals of both YUP and MMUE feel they should not be used together. MMUE is only partially a bug fix patch: it's mostly arbitrary edits that are not bug fixes. Some of the bug fixes are also incompatible with each other and are difficult to resolve.
  • New Vegas Enhanced Content (NVEC) (notice it has "bugfix" modules if you don't want the "complete version" with enhancement mod inclusions. These "bugfixes" are likely to conflict with YUP, so only implement if you need them and manually resolve any conflicts. Note that it includes older versions of Someguy's "New Vegas Bounties I-II, which are incompatible with the latest release if you intend to play that excellent mod series.)
  • Better Game Performance (NOT generally recommended by knowledgeable modders, test extensively first: some reports of minor slowdowns or worse, to include CTDs and corrupted saves. Best used with a "merge patch" or left out).

These "game fixer" mods often alter the same records, which means you should only use one (because the "Rule Of One" still applies, in which case YUP is the favorite recommendation) unless you also use a merge patch file to resolve the record level conflicts. As with other record level conflicts, the "load order" determines which mod's "fix" wins.

One of the problems with mods that are "collections of" or "include" other mods, is that they rather quickly get "out of date" when the other mods they include are updated. The other major problem is that it is difficult and time-consuming to properly merge all the various individual plugins to work together. Not all "collection" uploaders are equally skilled, but inevitably the problems are laid to the door of the included mod creators. For these reasons, many experienced mod users and most mod authors dislike "collections" despite their touted advantage of reducing the number of active plugins. Carefully check the "latest version" upload date and comments on the Nexus before choosing to implement one.

Body Replacement Basics

Body replacement is generally considered a "beautification" process. As such, it has to be done before you start "playing" the game in earnest, but should be added after you have a basic stable game setup. Remember: 'Pretty' doesn't beat 'playable'!

Replacing the vanilla body of either the Player Character or an NPC involves two different sets of files: meshes and textures, which usually come as separate mods. Mods labelled "body type" are actually meshes that have a different shape in some regards to those used for the vanilla body. Both are generally going to be found in the Nexus site New Vegas Models and Textures category.

First of all you have to understand the difference between mesh and texture. Simplified, the mesh forms the 3D framework or shape of every item in the game. Texture covers the surface (provides a 2D "skin" if you will) to those frameworks. A UVmap (aka "texture coordinates") is part of the texture file and tells the rendering engine how to project the 2D texture onto the 3D mesh. While the mesh and texture are separate files, each mesh includes the path to it's respective texture. Changing the texture of a mesh requires either a direct replacement of the existing texture file by name, or changing the path to (and possibly the filename of) that replacement texture within the mesh file. So the two files are intimately linked.

The vanilla body "texture" has underwear included, so it is not removable. Custom body replacement textures may have both a "nude" option and an "underwear" option texture as separate files. These tend to be "all-or-nothing" choices: everyone is nude underneath their armor and clothing, or everyone wears underwear; as long as that body replacement is used. Select a custom body texture mod that is designed to be compatible with your custom body type (i.e. the mesh) mod. Otherwise you may have apparent "black bands" around the groin area or huge scars on the breasts because the vanilla texture (used by default) doesn't fit correctly to the adjusted body mesh. Toggling "ArchiveInvalidation" off-and-then-on again as with other texture replacements may be necessary.

Body replacements are designed for two different purposes: to change the basic human body shape; and to play a "custom race": something other than a "vanilla human" (i.e. to role play what is normally only an NPC such as a ghoul, or an "anthro pony", or "anime-style" character, or "creature" like a "Death Claw"). As a consequence of these custom meshes, vanilla clothing and armor will have "clipping" issues where body parts show through or don't seem to "fit" correctly leaving gaps or seams. Some "clipping" is minor, but often it is major enough that you have to also install mods for clothing and armor that are made specifically for that body type.

Both replacement purposes may involve using the "ShowRaceMenu", which has some peculiarities of which you need to be aware. (See the Issue: "ShowRaceMenu" / Changing Character / Uninstalling a "custom race" problems entry in the "Fallout NV Mod Conflict Troubleshooting" guide.)

Often these replacements will include female mesh pathing to items for which the vanilla game did not provide a female version. (By default the game engine uses "male" versions instead in that circumstance.) However, these can cause conflicts with patches or an overhaul to the vanilla game, resulting in the loss of some fixes or changes. Such conflicts can usually be resolved with the use of a custom "Merge/Bash Patch" file or a distributed patch file for the specific mods involved.

"B-n-B" or "Bouncing Breasts and/or Butts" mods are meshes based upon a different "armature" or "skeleton" rigged with added "bones" (i.e. "breast bones") and weights to support the "bouncing" parts. They will either provide or tell you to use a specific "skeleton" in order to work correctly. Without that customized skeleton, the "bouncing" parts will not bounce and may appear "deformed" (i.e. stretching out to the horizon). There is only one skeleton used by each race in the game, so it will not adversely affect any "non-bouncing" meshes which will just ignore the added bones they don't know about. As a consequence, in order to see the "bouncing" effect in clothing and armors, you may need to install mods with those "bouncing" features enabled. Sometimes special animations for certain actions (i.e. walking, sneaking, jumping, swimming, dancing) are also available. Not all mods can use the same specialized skeleton, so check the description/documentation for each carefully. This "skeleton" choice can easily limit your options.

Cosmetic appearance mods (tattoos, piercings, hair styles, beards, etc.) are often included in this grouping, but really should be considered separately if they only involve the "head". Some features, such as scars and tattoos, are part of the texture and not a separate addition. Others have to use specific body part slots, which are broken down into "Body Data", "Face Data", and "FaceGen Race". Only one mesh can be assigned to each body part. For instance, "Face Data" has only "Eye colors" and "Hair styles". Which in turn means you can have "hair" or a "hat/helmet" but not both. If there is hair showing under a hat or helmet, it is part of that "hat" mesh. FNV does not have a separate slot for "facial hair" (i.e. beards, mustaches, "mutton chops", etc.). Mod authors have to cannibalize the use of a different slot for the purpose, or make the facial hair part of the texture itself.

Because they use a slot on the head, custom "Hair" and "Eye" mods can get complex to install. Sometimes they require using the GECK to add their mesh and textures to the "head" mod. Read their installation instructions carefully before choosing.

As the head is separate from the body, that means it too can have custom versions of it's mesh and textures (i.e. "head06" is a replacement head shape). In all other regards it is similar to but independent of the body. As the head (hair and face) is a separate component from the rest of the body, custom meshes often have a problem with a visible "seam" where the head mesh joins with the body mesh. It is just a fact of life you will have to live with; nothing the mod creators can completely eliminate. There are "seam concealer" mods that provide necklaces and similar to hide this seam. Not all such "head" mods are compatible with various other "body mods" or even "vanilla" heads. Read the documentation for each carefully.

The question of using body replacers from "Fallout 3" in "Fallout New Vegas" often comes up. As usual the answer is not simple.` IF the "replacement" is purely "meshes" and "texures" (no ESM or ESP file required), then the answer is MAYBE. It is best to use "ported to FNV" versions of FO3 body replacements. However the texture files can usually be used without change so long as they share the same UV map. In fact the mod "Type 6 Modification Body NV by Izumiko" advises using the texture for the "DIMONIZED TYPE3 female body" from the FO3 section of the Nexus. However, this texture mod has since been uploaded to the "New Vegas" section of the site, apparently unchanged. As always, experiment with care.

In summary, you can expect to need "Body Type", "Body Texture", "Clothing and Armor", and possibly "Head", "Hair", and "Eyes" mods that are all compatible to work together. Hopefully by now you realize that using a "Body Replacement" mod is not something to take lightly. It is more complex than it appears on the surface. For a list of "Frequently Asked Questions" (FAQ), see the Issue: Custom "Body Type" Replacement section in the "Fallout NV Mod Conflict Troubleshooting" guide.

Merge Patch File

The "Rule of One" means only the last loaded plugin that touches on a record, "wins". This is not usually a satisfactory solution as only one plugin is the winner. Even if other plugins affect different records but are dealing with the same sort of "thing" (i.e. perks, weapons, armor, ammo, etc.) they lose out if they touch the same record as the "winning plugin". So you might have several dozen plugins loaded, but only a few "winners" if the losers are all dealing with the same common item (even if they don't actually change it). The way to get all the plugins to use their records that are not in conflict, and still resolve all the conflicting records to a single "winner", is the use of a "merge patch file" that performs "record level" (instead of a broader file or type level) resolution.

There are two primary methods of creating such a "merge patch file": through the use of a Wrye Flash "Bashed Patch", or a manually created file. (The "bashed patch" and "merged patch" are the same essential thing. One is created by algorithm; the other by the user making choices.) See the S.T.E.P. Merging Plugins Guide which covers both approaches. (Use of "Mod Organizer" is not required.) Use the Wrye Bash Pictorial Guide to quickly get functional with "Wrye Flash", which I think is the easier approach for a novice mod user, especially when thousands of records are involved. The FNVEdit Training Manual and the video Making a Merge Patch by Roy Batty both use the "merge up" method of manually creating a merge patch with xEdit/FNVEdit.

Some suggestions for what and how to merge to reduce the number of active plugins can be found in Merged Plugin Guidelines for Personal Use.

Those taking the "manual" approach to creating a "merge patch", as well as mod users in general, need to understand about "Bethesda Software Archive" (BSA) files, which are very similar to (but not the same as) other archive format files such ZIP, 7Zip, and RAR. An archive is a way to package and compress various individual files together to both group related files and save physical disk space. Bethesda games can read the contents of their respective BSA formats, to include folder paths, without actually extracting the file contents to disk but into RAM memory instead as needed. BSAs are not loaded unless they have the same beginning to their file name as the ESP plugin (i.e. "Project Something.ESP" and "Project Something - Assets.BSA".) It isn't exactly clear just how much of the filename has to match, so common practice is "all that is significant enough to distinguish from others" (like other "Project" mods) up to a blank space. The BSA filename has to match an ESP, not an ESM file. The ESP does not have to contain any actual content, but a file with the correct name must exist. Without this, the BSA is ignored, and you get the "missing textures" red triangles, etc..

Mods that have their own BSA files but get included in a "merge patch" file won't have the necessary matching ESP filename to cause their BSA to get loaded. The solution is to extract the contents of their BSA files into the same folder (keeping their sub-folder structures intact), and then create a new BSA from the contents of that folder with the name of your "merge patch" file using FOMM or an FNV format compatible tool like the command line BSASharp. (Other BSA tools may be able to extract files from a BSA, but may not be able to create a new, valid BSA due to subtle differences in format between games. Always check compatibility first.)

The Wrye Flash "Bashed Patch" approach avoids this issue by leaving the ESP file associated with a BSA "active" (green "check" in the box icon). This is why you always need to run the "Mark Mergable" process before building the BP.

"Mator Smash" is an alternative to the Wrye "Bashed Patch". While it is basically functional, it's still in "Alpha" stage development and the developer's focus is still on Skyrim. At the moment it is not recommended for beginners, but if you are determined to experiment with it and willing to contribute bug reports to aid in it's development, it can be used with FNV. The results will needed to be checked. Please see the wiki article Mator Smash Quick Start.

Testing

"Testing" is not about "playing". It's about pushing boundaries and isolating problems that tend to only show up in the "edge cases". There are so many possible permutations of mod combinations no one mod creator can test them all. You can't count on anyone else to have tested your particular combination of mods.

You want to keep your "test" save files and your "game" save files separate. The easy way is to simply rename the "C:\Users\<YourAccountName>\Documents\My Games\FalloutNV\Saves" folder to something like "Saves - Game"; and create a new, empty "Saves" folder to replace it.

In very general terms, you want to create a "test character" just for that purpose. Simply take the defaults, unless you are testing a "character overhaul" mod. But "quick and dirty" is all you need; don't waste time customizing it. Once you get past the character generation, make a "full save" using the Menu "Save Game" option (not a quick or auto- save). This will become your "baseline test" starting point; as close to "vanilla" as is practical. Make a backup copy of this save game somewhere else.

Now use the console (typically the "~" key) to toggle on "God Mode" ("tgm"). This is so you can go places a 1st level character normally can't with impunity.

Run around GoodSprings, into and out of buildings, interact with NPCs, etc. Then push outside of the GoodSprings cell into the wastelands. GoodSprings is a good initial test cell because many mods initialize scripts there and you will be able to notice game lag as a result of scripts running pretty quickly. One known culprit in this regard is the "Cheat chest" from the "Weapons of the New Millenia" mod. If you initially don't see a problem, this is good. But if you do while in GoodSprings after installing a new mod, then you have an idea as to why.

From this point you want to get to areas of the game that stress various aspects of it. Toggle on the console command "tmm 1" to show all map markers so you can "fast travel" to them. ("Fast travel" is one of the things you want to test anyway.) Places with lots of NPCs, such as battlefields ("Camp Forlorn Hope", "Cottonwood Cove"), rich textures (i.e. "Zion Canyon" of Honest Hearts and "Red Rock Canyon" where the Khans hang out), and cities which are their own cell "worldspaces" such as "Free Side" and "New Vegas". If you are testing a mod that adds new locations, be sure to test those locations. Whatever a mod is supposed to bring to the game is what you need to test as hard as possible to see if it "breaks". Don't forget to also work through changes to the HUD, UI, or Menus such as MCM if they are affected by a newly added mod.

Anywhere you see a "loading" screen is changing between exterior and interior cells, or loading a new "worldspace". Things operate differently between the two so be sure you include such cell changes in your tests. When running through the wastelands you will also trigger cell changes, but these will be less obvious. But they are where your character may seem to momentarily "pause" for no apparent reason. The longer pauses are called "stuttering", and mean you are pushing the limits of what your graphic system can handle. The pause is the result of it having to load graphics out of the video memory (VRAM) and then load in the graphics from disk. The more "high resolution" your graphics, the less room there is to "pre-load" adjacent cells into the same amount of VRAM, and the more likely you are to get stuttering. There are also INI file settings that affect this. (See the "TweakGuide's General Fallout Guide" link in the Towards Game Stability sub-topic.)

Once you feel you have tested a new mod addition sufficiently and haven't encountered any unresolved problems, make a new "full save" and leave the mod in your "load order". In future tests, you will probably want to start from this "cumulative modded test" save point, but may on occasion (depending upon the mod) want to start from the "baseline test" save. You should delete older test saves between those two just to keep the used disk space down.

Now repeat the same test cycle with the next mod you add to your "load order".

When you have tested all your mods and have eliminated conflicts, rename the "C:\Users\<YourAccountName>\Documents\My Games\FalloutNV\Saves" folder to something like "Saves - Test"; and rename your "Saves - Game" folder back to just "Saves" (or create a new, empty "Saves" folder). Whichever version of those two "Saves" folders ("Saves -Test" or "Saves - Game") is NOT present is the one which is the current "Saves" folder.

Now build your "game character", this time with the full mod "load order" installed and functional, and again save after the character generation. Be sure to disable the game "Auto-Save" feature, and now you can play in earnest. But remember, if you want to add any mods once you start playing, restore the "Saves - Test" folder as the current "Saves", and test fully before adding it to your existing game.

You do not want to ever remove a mod once you have included it in your saved game file.

Game won't launch

Or get past the "loading screens" to the game's Main Menu.

See the wiki article Fallout NV Troubleshooting Guide for tips on getting the basic vanilla game to launch. If you can't manage that, you have a major problem and most likely need to re-install the game outside of the "C:\Program Files" tree as suggested in the First Timer Advice sub-topic in this article.

If the vanilla game (no active mods) launched without problem, most likely you have a Missing Masters problem.

Missing Masters

The game engine still loads every file it finds in the "Data" folder into memory and checks it's references for "master files", regardless of it's "active" state while determining it's "load order". (The "master files" are listed in the "file header" of each plugin.) This is why they count against your "plugin cap". If it fails to find any of such referenced masters, it causes a "missing master" CTD without warning. Similarly, if you attempt to load a "dependency" plugin prior to loading a "master" file (which is usually, but not always, an ESM file) that it depends upon for certain assets (i.e. if you have not sorted your "load order" or have it wrong) it will also result in a "missing master" situation even though all the files are present. This is especially true of the vanilla game and official DLC plugins which are masters for many mods. The "pre-order packs" are dependencies of the vanilla game and expansion DLCs. (See the Vanilla "Load Order" section.)

Installing optional package component files that are not needed can prevent the game from starting. This is the primary reason you can't use a patch file designed for mods you do not have installed, as they will always be missing the "master" plugin of the absent mod and "mysteriously" crash.

Mods often include "asset files" that are placed in sub-folders under "Data", which are used instead of vanilla versions of those files. Merely "deactivating" a mod plugin does not remove such added (or restore replaced) files, so the mod must be either uninstalled or it's unused/unwanted "asset" files manually removed from the "Data" folder path so the vanilla versions will be used.

As the game engine fails to report WHY it crashed under these circumstances, we primarily determine it to be a "missing master" issue by the timing of the crash: when the game is loading files during the display of the "Main Title loading screens" (aka "Before the Main Menu") or upon loading a "save game file" (aka "After the Main Menu"). This is not to say it can't happen later, upon the first attempt to use an asset that relies upon a missing file, but at least 95% of the time it will show up as a hang or CTD either before or just after the "Main Menu".

See the Missing Masters wiki article for detailed instructions on identifying and resolving this issue.

Mod Conflict Troubleshooting

When you run into problems (which you will inevitably) there is the wiki article Fallout NV Mod Conflict Troubleshooting. It will help you narrow down the most commonly asked questions so you can get more directed help faster. It also contains links to all sorts of essential tools and stability mods, as well as some specific problems and solutions.

It's always useful to post your "Load Order" (LO) with your problem description. (Use the "Special BBCode" button in the Forum "Reply" menu bar as the third icon from the left in the top row, next to and left of the "Font" pick-list field to put the LO in "Spoiler" tags.) Screenshots are not the best way to convey your LO, because they usually can't include everything in one image. LOOT (mentioned above) can copy your LO into a list suitable for posting on forums. (It's under the ":" with three dots to the extreme right in it's menu bar.) Most "mod managers" have a similar "LO List" capability. But the total number of mods you have installed in the DATA folder is also important, because even inactive plugins are counted against the so-called "140 cap". LOOT provides both numbers: active and total installed.

For help interpreting an error log, please see the How to read most Bethesda game error logs wiki article.

Modding a game takes time if you want the mods to work well together and be stable. Rushing the process will invariably lead to problems. Take the time to read and learn about the many new things that are involved, and you will have a much more enjoyable game when you are finished with the preliminaries.

Post processing shaders

Within the Bethesda gaming community the primary two graphic enhancements other than texture replacements used are: the ENB Series and the SweetFX Suite of shaders (though others exist). They are "post processing" effects to enhance the graphic feel of the game as the cost of some processing power and "frames per second"(FPS). Their installation can make changes to the INI files in your "User" account folder.

I would suggest you skip them for the time being, until you get a stable game going. If your average FPS is below 30, any post process shader is going to be a massive hit according to this Steam Community thread. Only if you are then still interested, the following may be helpful.

They are two different approaches to the same issue and can be used together if your system can handle the load. (Though likely you will have to learn the meaning of the configuration settings to deal with potential conflicts between them, they are considered generally complementary. Those settings, however, are very specific for technical effects and will require educating yourself.)

The "ENB Series" is developed by Boris Vorontsov and consists of a version for a specific game, and is available in either a "wrapper" or "injector" format depending upon which your system and game needs to work. (Some people can get the preferred "wrapper" version to work with FNV, while others are forced to the "injector" version.) The site for downloading the driver series is ENBDEV.

The "SweetFX" is a "shader suite" that uses an "injector" called "ReShade". Reshade and SweetFX are described in the article How To: Anti-Aliasing/Shader Injection (SweetFX, GeDoSaTo, GEMFX, and ReShade) along with a couple of others. Download SweetFX Suite (including ReShade) here.

And then there are various "presets" for both available for download from the Nexus, which are specific configurations developed by the authors and users to produce specific graphic atmospheres. These are a matter of personal preference.

Refer to the wiki article Fallout NV Mod Conflict Troubleshooting sub-topic "Issue: ENB is not working" for general ENB installation instructions.

HUD-UI-Menu Issues

Most of us sooner or later end up installing a mod that makes some change to the "Heads Up Display" (HUD), "User Interface" (UI), or some of the game's Menus. See the HUD-UI-Menu Issues wiki article before you do so, and avoid potential problems.

How to ask for help in the forums

The How to ask for help wiki article applies to any game. Read it before posting any problem not found in the resources listed here in the forums to speed up getting to the correct solution. The time you are wasting otherwise is not just your own.

References

Nexus wiki articles referred to by this article:



Nexus wiki articles that refer to this article: