Getting started creating mods using GECK

From Nexus Mods Wiki
Revision as of 01:28, 10 February 2019 by Dubiousintent (talk | contribs) (→‎TIP Merchant Inventory: update)
Jump to: navigation, search


Contents

Overview

The following information is primarily taken from the Help starting out thread on the "Fallout New Vegas GECK and Modders" forum. The information is preserved here as an alternative to searching through back posts in that forum for commonly asked questions. Much of the information applies to "Fallout 3 (FO3)" as well, but the focus is on FNV.

This article provides a learning roadmap, a starting point and guide to progression; not a tutorial. Consider it a collection of suggestions and links to more detailed tutorials, articles, videos, and tools. Just from the "Table of Contents" you should get a reasonable idea of the learning curve ahead of you. Don't get discouraged. Tackle things one at a time. Just don't expect to learn everything quickly.

'Regional language' (i.e. "non-English") version mod creators and translators: PLEASE see the 'Issue: Regional (non English) version has different FormIDs' entry in the wiki "Fallout NV Mod Conflict Troubleshooting" guide first. It will save you a lot of grief and frustration.

There is a lot of unique vocabulary related to creating mods in the following material, such as the distinction between "meshes", the 3D framework of objects (saved as Nif files); and "textures", the surface "skin" over the "mesh framework" (saved as DDS files). The Elder Scrolls Texture Guide (TESTG) site has a glossary and several pages devoted to explaining these to new mod creators and users. Rather than explaining them here, please reference that site when you need clarification. (This article does a lot of that: referral to other existing resources. Why reinvent the wheel?)

Programs and Tools

Note: You are working with a 32-bit game. It requires 32-bit FAT system compliant files and data in specific formats. 64-bit tools may not output 32-bit FAT files; they output 64-bit files which are NTFS compliant (strictly speaking about Windows). You can't read 64-bit NTFS files with standard 32-bit tools, unless they both use the exact same data format, file format, and naming restrictions. Overlooking this simple fact will cause you a lot of frustration and wasted time. Use the right versions of tools for the job. "Newest" does not always equal "most appropriate".

GECK Tools

  • Garden of Eden Construction Kit (GECK) (freeware.) The official "game editor" for Fallout 3 and New Vegas. NOTE that when loading files, the one plugin you designate with the "Start as Active" button becomes the one that gets edited and saved when you exit the editor. ALL of the files loaded into the GECK at the same time will automatically become "master files" to the "active file" when it is saved. In particular to this regard, see the NAM files entry.
  • GECK Extender NVSE Plugin. Project to extend GECK functionality and bug fixes. Compatible with all NVSE script extender plugins. (Do not use together with GECK Powerup (nor the Forked version), which it replaces.) Note the optional "Patcher" to make GECK 4GB aware and auto load NVSE is a separate file.
  • GECK 1.4 Powerup NVSE Plugin. (Replaced by GECK Extender. Do not use both together.) Comes in a "standalone" version for the "vanilla" GECK functions, and one for GECK with NVSE functions. It fixes and improves some issues while providing the missing messages when the GECK compiler finds an error or warning, and lets you save a script without compiling it. Considered "essential" by experienced mod creators.
  • There are now two wikis devoted to the GECK: the official one by Bethesda, which is not very well supported and a major pain to update (Five CAPCHAs per post!), and a Modding Community GECKWiki site with everything from the official one but actively updated by the modding community. While most links to the GECK wiki are to the official wiki, be sure to check out the Community one to see the latest info on your topic. Anything related to "Script Extenders" like NVSE or JIP LN NVSE functions will be more current on the Community GECKWiki site.


Image Tools

  • Category:Tools on Nexus Mods wiki has articles on various aspects of the primary tools you will be using. Check it out as well.
  • 3DS Max (1 month free trial, $185/month or $1470/year subscriptions, 3 yr student/educator license.) Commercial product by AutoDesk but the version that works with Nif files isn't free. Versions after 2013 don't seem to work with at least Fallout 4 (according to this thread) using the included official NIF exporter, though there is an unofficial "Figment" exporter plugin fork on GitHub which does seem to work.
  • Blender v2.49b (freeware.) This download includes ALL related files and compatible versions. This is the "complete" package for creating meshes for Bethesda games; including:
Python 2.6.5
Blender NIF Scripts 2.5.5
NifSkope 1.0.22
PyFFI 1.1.5
"Noob to Pro" PDF tutorial.
Check out the "Optional" files section for some additional functionality. Recommended for FO3/FNV.
  • Blender v2.49b Portable by Room207 is also a "complete" package that is preferred by some for it's convenience. Includes:
Python 2.6.6
Pyffi 2.1.11
NIFscripts 2.5.9
True Normals by Anthony D'Agostino
Geom Plugin 0.5
Mesh Ascii Plugin
UDK Scripts
Blender Tools 1.01 by Kormgar
Blender TRI file scripts and Tutorial by Kapaer and Deedes
  • DXTBmp Texture Tool (freeware.) Images can be passed to any Paint program for editing in 24 bit and then re-imported and saved in any of the 16/24/32 bit formats. Transparency (Alpha) channel of textures can be viewed and edited separately from the main image.
  • GIMP: GNU Image Manipulation Program (freeware.) A cross-platform image (texture) editor available for GNU/Linux, OS X, Windows and more operating systems. Provides extensions through integration with many programming languages including Scheme, Python, Perl, and more. The result is a high level of customization as demonstrated by the large number of scripts and plug-ins created by the community.
  • Hairs - Eyes - Races Auto - Patcher (Mod.) Extracts all the hair / eyes / races records from every plugin loaded in your load order - then, it rewrites the list of eyes and hairs for every race found. So, if you untick / unflag a hair mod from your load order, these records won't be loaded by the game itself and consequently won't be found by this mod because they don't exist.
  • LOD/VWD Overview TESTG site wiki.
  • Maya (1 month free trial, $185/month or $1470/year subscriptions, 3 yr student/educator license.) Animation, modeling, simulation, and rendering software by AutoDesk.
  • MindTex2 ($20) by Frozen Flame. MindTex is a normal map generation utility for game developers and 3d professionals. Built to rival the competition in quality without the steep price, whether you want to generate a normal, height, specular, gloss, self-illumination, occlusion, or reflection map, you can easily do it in seconds flat from a single source texture with MindTex.
  • NIF tangents and binormals updater (freeware) by zilav. A command line tool to batch update tangents/binormals in Oblivion, Fallout 3, New Vegas, Skyrim, Skyrim Special Edition and Fallout 4 format NIF meshes. The one in NifSkope doesn't handle degenerate normals, such as if your NIF has a lot of texture tiling. It also gives all around better results especially for people who use Blender and cannot reset the normals and smooth them because it lacks the features to do so.
  • NifSkope (freeware.) A graphical program that allows you to open NIF files, view their contents, edit them, and write them back out again. You can use it to quickly make changes to specific properties of a NIF file such as changing the texture, adding translucency, and more. A 3D view of the contents of the NIF file allows you to preview your changes instantly. You can even create texture templates, and import & export OBJ files. (Note: This link is the latest release and may not be the best choice for FO3/FNV. A fully compatible version of this tool (v1.0.22) is already included in the Blender v2.49b package linked here.)
  • NifSkope v1.3.3 (revision36efdd) (freeware.) A later version than that bundled in the Blender v2.49b package (with EXE and features referred to in many tutorials that are missing in even newer (v2.0+) releases, such as "import/export .OBJ files"). Fully compatible with that Blender package, and more "shader flags" are identified. While both versions of NifSkope can be installed, only one can be used at a time. Recommended for FO3 and FNV (along with the NifTools XML Format version 0.7.0.0, which has the essential "differentiated color for Collision"). Recommended for FO3/FNV.
  • NifTools Wiki (freeware.) 3D package plugins for 3ds Max, Blender, and Maya modelling tools. Note: this link will have the latest release versions. The versions bundled in the Blender v2.49b package are all mutually compatible.
  • The NifTools XML Format (documentation.) Used to extend NifSkope to open files from new games, or better understand files from games which it can already open. Version 0.7.0.0 recommended for FO3/FNV.
  • Paint.NET (freeware.) Image and photo (texture) editing software for Windows, originally based upon the Paint program included as part of Windows, but with many enhanced features such as "layers", special effects, and unlimited history ("undo"). Require Microsoft's .NET Framework 4.6+.

Packaging Tools

  • BAIN Archive Tools - BAT by Surazal
  • BSArch (freeware) by zilav. A command line tool for packing and unpacking Bethesda archives. The most complete support setting the correct flags across the various games.
  • BSAOpt (freeware) Tool for extracting the contents of BSA files. Note this tool unpacks the entire BSA file. It does not easily allow for unpacking a single file.

(See the Skyrim thread BSAs and You for details about the pros and cons of "Bethesda Software Archives" (BSAs), but bear in mind such files in previous games, like Oblivion, FallOut3 and Fallout New Vegas, don't have "strict order" like in Skyrim. Games prior to Skyrim don't support overriding of assets in archives using other archives; only loose files can. If the same resource is contained in several BSA archives, those games won't use it from the last BSA on 100% of occasions. They may grab the resource from a random one of the BSAs containing the same file.)

WARNING! Do not unpack BSAs directly into your game "Data" folder; potentially overwriting any mod files. The tools don't ask you to confirm the overwriting, either. All the hair textures unpacked to "loose files" will go through the head models in that case; because that's what happens when hair is not packed in a BSA. "Best practice" is to unpack to a unique folder (they are large: 1-2GB) and manually drag the desired files to the appropriate "Data" folder as needed.

  • BSAExtractor (BSAE) (freeware) Tool for extracting just one or the entire contents of BSA files. See warning above about unpacking an entire BSA.
  • FNV BSA Decompressor Mod by zilav. Decompresses the Fallout New Vegas BSAs and repacks them into BSAs without zlib compression for performance. Also transcodes the ".OGG" sounds effects to ".WAV" format so they work. It also extracts any MP3 files to loose files because they will not play when in a BSA.
  • FOMM - Forked (freeware) Mod Manager with built-in BSA file extraction and repacking.
  • Note that FOMM has several tools bundled with it. The TESsnip tool in particular is obsolete and has been shown to cause "silent corruption" of save game files as a result. The use of xEdit/FNVEdit is recommended in it's place.
  • FOMM and FOMODS for Dummies article.
  • FOMOD Validator by Ganda

Scripting Tools

  • CIPSCIS Script Validator (freeware.) Allows you to quickly indent your script while simultaneously checking it for several basic errors, many of which are not picked up by the GECK's compiler. It works with Skyrim, Fallout 3, and Fallout New Vegas, but is not "script extender" aware. Includes it's own tutorials.
  • New Vegas Script Extender (NVSE) Site.

Sound and Voice Tools

Misc Other Tools

  • DarNified Forum Community site. Articles and questions on XML for the User Interface (UI) and Menus, primarily about the Oblivion version of DarNUI but there is a section for FO3.
  • Gamesettings profiler Mod. Adds intuitive, app-like, modding tool for debugging, testing, profiling, and dumping\printing to file any numeric GMST (gamesettings) records.
  • Tree LOD billboard creator for xLODGen by zilav
  • xEdit/FNVEdit (freeware.) A generic tool called xEdit which is renamed for working with specific games. The latest "stable" release is on the Nexus, generally under the game name version or as "TES5Edit".

Details

Basic advice is to start with the game Construction Set/Editor (this is usually a separate, free download, not included with the game installation). There is going to be a wiki page for it with tutorials to help get you started, but note that there are unspoken assumptions that you are familiar with concepts introduced on the "Construction Kit"/"game editor" wikis for earlier Bethesda games such as:

(TES5: Skyrim came after all of those (2011) and uses a different variation of the game and script engine.) So, don't neglect those older wikis as resources. Where there appears to be a conflict, assume the later wiki or the one specific to your game is correct.

In addition to the Construction Set/Editor, you'll probably want to get community created editor enhancement tools, like the GECK "Extender" or "PowerUp", "Oblivion Construction Set Extender", etc. These allow you to perform actions not included in the default editor, like edit ESM files without converting them to ESP first, and may also give you better debugging for scripts. These capabilities vary by the tool. On the negative side, such extensions may also annoy the heck out of you with error messages, many of which you don't need/understand and don't care about. But they are always worth looking into.

There are also conversion tools which are required to export the 3D models from your modeling tool into the "NIF" format that Bethesda games use. It is very important to note that the import and export tools only work with certain versions of modeling programs. For Blender, you need version 2.49, which is older than the current version of Blender. The Nexus Oblivion mod Blender linked here is a package that has Blender v2.49 plus all of the NIF tools and includes NifSkope, all of which are the correct versions to use together. You will save yourself a lot of trouble if you install everything from this one package. If you don't, you can run into version problems and things will never work right. Instructions on the correct way to install this combination of tools can be found the wiki article here. (Note where there seems to be a discrepancy in version numbers, stick with the version included in the package.)

"Script Extenders" (SEs) are plugins to the game editors that provide additional functionality features, and were created by the gaming community to overcome perceived shortcomings. Mods the use even one of those SE functions need to specify that the particular SE is now a requirement.

Item (armor, weapons, buildings, etc.) construction and customization requires learning 3D modelling, which is NOT a quick process. You are going to invest a lot of time and patience in learning your tool of choice. The three most common tools used are Blender, "3ds Max" (aka "Max"), and Maya. There is very little discussion about Maya in the forums related to Bethesda games because while it is considered the better choice for animation, "Max" is simpler to grasp and less daunting. Both "Max" and Maya are considered "industry standard" tools, and both will do the job. See these articles for more in depth comparisons if you are going to invest in learning either product:

The Nexus has the Software Programs - 3D Modelling - Blender forum, Software Programs - 3D Modelling - 3ds Max forum, Software Programs - 3D Modelling - Maya forum, and Software Programs - 3D Modelling - Miscellaneous / Other forum areas for discussion about those tools.

The "workflow" on Blender for Nif files is considered more complex than with the others because it often takes you into the Nifskope tool, but read about the Nif Exporter plugin for Max issues in that entry. It is necessary to use the correct version and tools that work with that version of any of these products.

Because it is "free" and the others are quite expensive for most people, Blender is usually at least their first choice. "Blender Noob to Pro" is a good resource for 3D modeling using Blender, and the compatible (not the latest) version is included in that package linked above under Programs and Tools. Consequently, there is a long history of tutorials on all aspects of modelling with Blender. It is well worth the time to refer often to the Blender - Read this first thread as you progress through the learning curve. It has an extensive list of tutorials from Oblivion thru Fallout 3 and more generalized topics which still apply to the basics of modelling in Blender.

For texturing your 3D models, you'll need something that can handle ".dds" files. GIMP and Paint.Net (which is not the Paint that comes with Windows) can both handle ".dds" files. Paint.Net comes with ".dds" support built-in these days. GIMP still needs a plugin. Which program you use is more a matter of personal preference than anything else. Some find GIMP a bit more difficult to use but it also can do some things that Paint.Net can't do. Paint.Net on the other hand is, in the opinion of many, more intuitive and easier to use. Although, now that Paint.Net has a proper normal map generator that actually works available as an add-on, GIMP use tends to be even less frequent now. A lot of it is personal preference, though. Some folks just like GIMP better. Both programs work fine. You can also use Photoshop, but that's not free.

Once you have the 3D model textured (UV mapped) and maybe have generated a normal map for it as well, then you need to export everything. First, read the Working with DDS/DXT Files article by Gary "Buckaroo" Neely to understand the choices in DXT codec to choose among. Blender and the NIF tools don't export a lot of things properly, so then you have to go into NifSkope (which comes with the NIF tools) and fix it. (The proper weight of "bones" in skeletons, along with "shader flags", is almost always wrong, for instance.) Be sure to check that the path given in the mesh to the texture file is in "relative" format. (See How to fix hard-coded texture paths in NIF files.) The default format of the mesh editor's paths may not be "relative".

Once that is done, then go into the game specific Construction Set/Editor and add your custom items to whatever mod you are working on.

Getting back to the GECK, there are a few things that are broken in it. It ships with a spell checker but doesn't include the dictionary, so that's just annoying. (But you can use the language resource files from Fallout 3 as the dictionary.) If you use the GECK "Extender" or "Powerup" you can uncheck the spell checker and disable all of that annoyance at least while you are editing your mod. Unfortunately it won't remember that setting and you'll have to uncheck it the next time you edit your mod as well.

Another thing that is broken is the "lip generator" for dialog. If you have Skyrim or Oblivion you can copy their lip generator from the "sound\processing" folder to GECK's. If you have all of your voice files in place and they work already, in the GECK all you need to do is bring up that dialog in the quest editor. Your WAV file should show up down near the bottom, where it says voice type: MP3, WAV, LIP, LTF, and "path". Click on that to select it, then click on the "from WAV" at the bottom. The "generate lip file" option should now become active and you can click on it. Note that the GECK will not update the information on the screen, so it will still have an N under LIP file even after you have generated it. Close that dialog option and re-open it and then you should see a Y under both the WAV and the LIP. If you record the voice files directly into the GECK (using the record button at the bottom of the dialog window) then when you press save it will automatically generate both the WAV and the LIP files.

Common Problems with GECK

Issue - Where to obtain the GECK

  • Cause: The Construction Kit is a separate download and not automatically installed by Steam. (It is with the GOG DRM-free version.)
  • Solution-1a: You can download the "GECK. - New Vegas Edition" through Steam. It's under the "Library | Tools" tab in the Steam launcher.
  • Solution-1b: Download from the following links:
  • Official GECK Wiki by Bethesda Softworks.
  • GECKWiki Community maintained (more up to date) version of GECK Wiki.
  • FNV 4GB Patcher by Roy Batty - LuthienAnarion. Sets LAA flag specifically to work with Steam versions of FNV and GECK.
  • Recommended: The community developed optional NVSE plugins supplement the GECK, and are considered essential due to the error fixes and additional diagnostic messages (especially for scripts that won't compile) it displays. They require you to launch GECK with NVSE in order to function.

Remember: you must run the GECK and NVSE Plugins with "Administrator" privileges. So you don't forget, see Issue: GECK crashes upon starting to have the executable itself prompt you, or create a "shortcut" link which prompts you for this.

Create a shortcut to the GECK executable.
< Right-click > on the shortcut and select "Properties | Shortcut".
  • If you just want to use the GECK without NVSE plugins, your target command line executable is "geck.exe".
  • If you wish to have NVSE loaded whenever you launch the GECK, please see the Issue: How to get GECK to load with NVSE? entry.
  • Script compiler warnings will now be displayed. Scripts will no longer silently fail to compile.
  • Many other warnings were restored: in cell loader, in NavMesh checker, and so on, more than in 1000 places. [back for testing in 0.1.7.1 beta 1]
  • Adds a special Marker hack which makes RoomMarkers and PortalMarkers visible and transparent in the render window [since 0.1.3].
Unfortunately, cannot make them completely invisible as they should be, but it's better than having to move them all away just to see the cell.
  • You can now save scripts without compiling them (useful if you want to save your script and finish it later).
  • The spell checker can now be enabled and disabled at runtime.
  • Fixed the bug which caused the GECK to crash when user double-clicks on empty space in Form List Editor.
  • The "Edit" menu item in Form List editor will now work.
  • All MessageBox'es will now be in English, regardless of your system's language. This also means that "Cancel" will be replaced by "Yes to all" where intended by GECK developers. [since 0.1.2]
  • ESM are now active and editable directly.
  • ESP used as masters will remain in the masters list.
  • ONAM records in ESM will be preserved. No guarantee new required ONAM will be added. When in doubts, use FNVEdit to update the ONAM records.
  • Enables level 2 LOD generation for large worldspaces
  • Fixes bUseMultibounds = 0 crashes in cells with multibounds
  • Extends GDI handle limit: This cleans up opened windows better when closing them so you can edit for long periods without fear that you won't be able to save your plugin because the GECK can't open any new dialog windows.
  • Help links point to new community maintained wiki: GECKWiki.

Issue - GeckCustom INI file

The "GeckCustom.ini" may not get created in the "C:\Users\<YourAccountName>\Documents\My Games\FalloutNV" folder until you save your first modified file; not merely close GECK as some have reported. NOTE that as you have to run GECK as an "Administrator", the "C:\Users\..." folder with the INI file will be for the "Administrator" account. This can cause confusion as to where to look.

See also the wiki GECK: Tips and Tricks article.

TIP - GECKCustom INI may be missing
The "GECKCustom.ini" may not get created in the "C:\Users\<YourAccountName>\Documents\My Games\FalloutNV" folder until you save your first modified file; not merely close GECK as some have reported. NOTE that as you have to run GECK as an "Administrator", the "C:\Users\..." folder with the INI file will be for the "Administrator" account. This can cause confusion as to where to look.

TIP - Disable Audio in GECK
Disable the editor interface from hearing sounds by changing the following to "0", but a re-edit back to "1" will restore the ability when you need it. While not completely eliminating all frustrations, it seems to increase the amount of trouble-free edits between CTDs to multiple hours at a time.
[Audio] bEnableAudio=0

TIP - Enable loading multiple master files at once
In order to load multiple master (i.e. ESM) files into GECK at once, you need to edit the "GeckCustom.ini" file to add:
bAllowMultipleMasterLoads=1

TIP - Enable more than one copy of the GECK
(or both the FO3 and FNV versions).
To enable more than one copy of the GECK (or both the FO3 and FNV versions) to be open at one time, edit the "GeckCustom.ini" file to add:
bAllowMultipleEditors=1

TIP - Enable MultiBounds
Thanks to pixelhate of the Nexus Fallout "Mod Talk" forum for the basis of the following:
You may find many things are invisible when viewing an interior cell in the New Vegas version of the GECK. This is especially true if you copied from another interior cell.
"Objects are often rendered in games when they don't necessarily need to be, wasting precious performance.

For instance, if the player is in a room with walls on all sides, the player cannot see anything outside of the walls. Objects behind these walls don't need to rendered. While this seems obvious to us, game engines sometimes have a hard time making these decisions.

In order to help the game know to not render anything outside the walls, we have special tools available to us to optimize the room. Thanks to these tools the game can make smarter decisions about what to render and what to cull without having to perform complex line-of-sight and occlusion calculations. The tools we have available are Portals, Room Markers, Multibounds, and Occlusion Planes." - GeckWiki: Optimization

When you duplicate a cell, you duplicate the Portals & Multibounds of that cell as well. But because these are not related to adjacent cells anymore, you end up with large invisible parts.

Open the "GECKCustom.ini", find the line "bUseMultibounds=1", and change the value to "0" to remove the invalid Portals & Multibounds in your copied cell when you save it. Obviously, the value of this setting depends upon circumstances, so it is not "set once and forget".

More about Multibounds & Occlusion culling:

TIP - Load ENB Series with GECK
To get GECK to work with ENBSeries loaded so you can see ENB's effects while in the editor as well, try the following.
  • In the "enblocal.ini" file located in the game root folder (i.e. <SteamInstallPath>\steamapps\common\Fallout New Vegas"), set:
[FIX]

FixGameBugs=true FixTransparencyBugs=true IgnoreGECK=false  ;<- set "false" from "true"

And get ready for GECK to take >20 seconds to load on startup. But it'll look pretty.

TIP - Master files
Thanks to madmongo of the Nexus Fallout "New Vegas Mod Troubleshooting" forum for the basis of the following:
A file becomes a "master" when a "dependent" plugin relies upon a record or asset from that master. If you aren't copying a record from some other plugin into your new plugin, then it doesn't require ("depend upon") that plugin as a master file to provide the original definition of that record. Editing a record's value or form list in your plugin does not create that dependency. You usually have to "copy as override" from the master into your plugin and then make the changes there. This is usually done after the "master" mod is created using xEdit/FNVEdit, but it can be done in the GECK as well (often accidentally).

The GECK will automatically add any "master" file that is loaded when you save your plugin. These are usually ESM files, but there are exceptions. ESP files are not "master" files, but you can fake out the GECK by setting the "master" flag in the ESP file header using xEdit (then turn it back off when you are done). The game engine (and GECK) will consider any file with the ESM flag set in the file header as a "master" regardless of the file extension.

If you try to reference assets defined in an ESP and you haven't faked out the GECK to make it think the ESP is a "master", it won't handle the reference properly. Best case: that part of your mod just doesn't work. Worst case: it crashes the game. Once a "master" file has become listed as part of a plugin's "file header" record, you have to use xEdit to "Clean Masters" to remove it safely or you will corrupt your plugin. This procedure is described in the Tome of xEdit manual.

Issue - GECKPrefs INI file

In the "Users" game folder, along with the three INI files generated for your game is the GECKPrefs.INI file. This file gets created when you first start using the GECK, and saves any customizations you make to it's interface (e.g. such as if you change any values for the "map editor" color masking).

The problem that can arise is when your changes don't work out as you intended and you wish to revert to the default values. There is no built-in mechanism to restore the defaults in that file, nor is there a file for the GECK to refer to similar to the "Fallout_default.INI" file. (There may be a "reset" button in the GECK window, but it only affects the current edit session: resetting to the values in effect when the window opened.)

Therefor: it is your responsibility to make a backup of either the initial or your stable customized version of GECKPrefs.INI so you have the default values to refer to. Otherwise, all you can do is delete (or rename) the file and let GECK rebuild it the next time it starts.

Issue - How to get GECK to load with NVSE

  • Cause: "New Vegas Script Extender" is an addon library of functions developed after GECK was "finished", so it doesn't know about the extensions. Without including NVSE, use of commands from that or the older FOSE (which is incorporated) extension will produce script errors of "unrecognized command" preventing compiling and saving them.
The GECK Extender NVSE Plugin with the Optional "Patcher" to make GECK 4GB aware and auto load NVSE is recommended. (Do not use together with GECK Powerup (nor the Forked version), which it replaces.)
While the GECK 1.4 PowerUp for Fallout New Vegas addon comes in both "standalone" and NVSE plugin versions, that does not mean that NVSE is automatically loaded as part of the GECK itself, so it doesn't otherwise recognize those extensions. The suggested method is to use the NVSE Plugin version of PowerUp when also loading NVSE. Then it will automatically be included when your shortcut points to the "nvse_loader.exe". (Replaced by GECK Extender. Do not use both together.)
Note you must launch GECK as an "Administrator" account: no matter if you are also loading "Extender", "NVSE", or the "GECK Power-Up StandAlone"; or only GECK.
  • Solution (for Powerup only):
  • Create a Windows shortcut to the GECK. Name it something to reflect this is for the GECK + (PU or/with NVSE) (e.g. "GECKPU+NVSE").
  • < Right-click > on the shortcut and select "Properties | Shortcut".
  • To load "NVSE" (with or without plugins such as PowerUp or GECK Extender), in the link shortcut "Target:" field put the complete path to the nvse_loader, and include the "target command line":
"<path to Steam>\steamapps\common\Fallout New Vegas\nvse_loader.exe" -editor
in double-quotes (because of the embedded spaces in the path.) The "-editor" must be placed outside of the double-quotes of the path so it will be recognized as a "parameter" of the executable.
  • If you use the "Power-Up Standalone" version 0.1.6 or later, in the "Target:" field put the complete path up to and including the target command line:
"<path to Steam>\steamapps\common\Fallout New Vegas\geckpu-nv-14.exe"
(This is a change from previous instructions for "Power-Up", as documented in the PU "ReadMe" file.)
  • Select the "Advanced" button on the same "Shortcut" tab, and enable (check) the box "Run as administrator" on the window displayed.
  • Click the "OK" button until the shortcut window closes.
Note that if you add this shortcut to "Steam", it will initially strip off the "-editor" parameter. Be sure to double-check the "Target" within "Steam" for the presence of this parameter.
  • Select the "Advanced" button on the same "Shortcut" tab, and enable (check) the box "Run as administrator" on the window displayed.
  • Click the "OK" button until the shortcut window closes.

Issue - GECK Power-Up or NVSE cannot find GECK

  • Cause: You must launch anything to do with GECK from an "Administrator" account.
  • Create a shortcut, and on the "Properties | Advanced" tab enable (check) the "Run as administrator" box. This will cause you to automatically be prompted to enter a valid Administrator account and password each time you try to run the command so you won't forget.
NOTE: The GECK Extender, which should be used instead of the "GECK Power-Up", includes an optional patch as a separate file to make GECK "4GB aware" and auto load NVSE.

Issue - Where to start in creating mods

  • Cause: The GECK is only part of what you need to create mods, and it doesn't have a training manual.

Issue - Where are the Warnings and EditorWarnings text files

They are supposed to be in the game root folder (where the FalloutNV.exe is found).

  • Cause: It appears that Bethesda dropped these output files after FO3.
  • Solution: Instead, the "GECK Power Up" and "GECK Extender" plugins have now provided that functionality. Try setting NVSE to report them.
  • In Data\NVSE\nvse_config.ini, set:
[Memory]

DefaultHeapInitialAllocMB=448 [Logging] EnableGameErrorLog=1 [RELEASE] LogLevel=2

  • In Data\NVSE\nvse_plugin_geckpu_ew.ini there is a "[WARNINGS SELECTION]" followed by a list of hex offsets. Each offset is set to a reporting level, as described at the top of that file. The default (=1) is to both display the warning in a "MessageBox" in the GECK and write it to file. When the nvse_config.ini LogLevel is set between "2" and "5", the warnings are written to the nvse_plugin_geckpu_ew.log file in the game root folder (where the FalloutNV.exe is found).

Issue - GECK crashes upon editing a weapon

"Every time I attempt to use the GECK to edit a weapon it crashes, even when only the main NV master file is selected." This also occurs when "Fallout Character Overhaul" (FCO) is installed.

  • Cause-1: GECK needs to have the LAA flag enabled in order to take advantage of more than 2GB of memory.
  • Solution 1-b: The GECK should also be patched to use up to 4GB of memory (i.e. FNV 4GB Patcher, the NTCore 4GB Patch or their more general CCF Explorer, or the like).
  • Cause-2: This has been traced to the presence of a specific file that is overwritten by "Fallout Character Overhaul" (FCO): eyebrowm.nif in: Data\meshes\characters\hair.
  • Solution-2: Remove the troublesome file when using GECK, and restore it when playing. If you put it into a batch (.cmd) file such as the following to launch GECK you won't forget.
@echo off
cls
::REM As GECK has to be run from an 'Administrator' account, you should launch it from a
::REM   shortcut (.lnk file) that has that "run as" setting in the 'Properties'.  This will
::REM   be run in a separate sub-process window.  Otherwise the 'start' command won't WAIT
::REM   until GECK is done before continuing with this script.
::REM Change the 'set runpgm=' line to point to your GECK shortcut.
set runpgm=C:\Users\Public\Rec\FalloutNV\GeckPU.lnk
::REM Change the 'set gamedir=' line to point to your game install folder.
set gamedir=E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
::REM Nothing else below this point should need to be changed.
set tgtdir=%gamedir%\Data\meshes\characters\hair
 
pushd "%gamedir%"
if exist "%tgtdir%\eyebrowm.nif"  ren "%tgtdir%\eyebrowm.nif" eyebrowm.nif.hld && @echo SCRIPT: Removed file [eyebrowm.nif]
 
@echo SCRIPT: Manually close the separate window GECK is launched in.  When you do, DO NOT
@echo SCRIPT:   select to 'Terminate batch job' (answer "N") or you won't restore files properly.
start "GECK" /D "%gamedir%" /WAIT cmd /k "%runpgm%"
if exist "%tgtdir%\eyebrowm.nif.hld"  ren "%tgtdir%\eyebrowm.nif.hld" eyebrowm.nif && @echo SCRIPT: Restored file [eyebrowm.nif]
 
:DONE
pause
popd
  • Cause-3: If the GECK seems to "hang" while loading your plugin, this may be due to failing to select other plugins your target plugin requires as "masters", but which are not ESM files and/or not automatically included by GECK.
  • Solution-3: You can use the xEdit/FNVEdit "File Header" to identify all the files that are masters to your plugin, and then be sure to select all of them when loading it into the GECK. Please see the wiki Missing Masters article for details.

Issue - GECK crashes upon starting

  • Cause-1: You don't have the correct permissions for running GECK.
  • Solution-1: GECK must be "run as administrator".
  1. Navigate to the program folder of the program you want to run (i.e. FalloutNV game root folder).
  2. Right-click the program icon (i.e. the "Geck.exe" file).
  3. Choose Properties.
  4. On the Compatibility tab, select the "Run This Program As An Administrator" option.
  5. Click OK.
  6. If you see a "User Account Control" prompt, accept it.
Now each time you run GECK you will be prompted to enter an "Administrator" account password. If you enter it wrong, GECK won't start.
  • Cause-2: There is not enough available memory in the default 2GB allocated for 32-bit programs. GECK needs to have the LAA flag enabled in order to take advantage of more than 2GB of memory.
  • Cause-3: GECK seems to be overly sensitive to the correct "system compatibility" mode when run on versions of Windows after Vista SP2.
  • Solution-3: Set the "Properties | Compatibility tab" to "Run this program in compatibility mode for: Windows Vista (Service Pack 2)" for both the GECK.EXE and the (PowerUp) GECKPU-NV-14.EXE files.
  • Cause-4: You installed an ENB or the pre-ENB "enhanced shader" mod containing a custom D3D9.DLL file placed in the game folder. The GECK tries to load all of the DLL files it finds when it starts, and it doesn't know what to do with that one: so it crashes.
  • Solution-4: Put the D3D9.DLL file somewhere outside of the Fallout game root folder whenever you want to run the GECK. Make sure to put it back before you start your game; otherwise it will not load. (A "batch file" to handle this that is run when you click on the link to start the GECK is the best way to avoid forgetting this. See Issue: GECK crashes upon editing a weapon for a similar example.)

Issue - GECK does not automatically select FalloutNV or some DLC ESM file

Normally, when starting GECK and opening the "File" menu it has automatically "checked" (enabled) the DLC ESM files for loading, but not the "FalloutNV.ESM".

  • Cause: This is controlled by the presence of the "*.nam" files, which by default are present for all the DLC (but not for "FalloutNV.ESM"). If any are not found, that DLC is not automatically selected (enabled) either. These files cause the game to load those DLC even if they are not "active" in the "load order". (It is recommended you rename rather than delete them if you don't want a particular DLC to be loaded.)
  • Solution: The "nam" file contains nothing more than the common name (i.e. "Dead Money") of the respective DLC. When a plaintext "FalloutNV.nam" file (which does not exist by default) with "Fallout New Vegas" as content is created, "FalloutNV.ESM" will be automatically checked (enabled) in GECK's "File" menu just like the DLC.

Issue - GECK does not show Landscape

  • Cause: There is a barely mentioned "shortcut key" combination that toggles the display of Landscape in the "Render Window" when you have an "exterior worldspace" loaded. It does not appear in any menus so it is usually an accidental toggling.
  • Solution: <Shift+L> will toggle the display of the Landscape. (Thanks to VenonXNL for reporting the solution to this "mystery".)

Issue - GECK hates me in general or how to get started working with it

  • Cause: The GECK is frustratingly buggy. It is not intuitive to use. The GECK website makes assumptions that you understand concepts introduced in earlier game Construction Kits (CKs).

Issue - GECK will not tell me what is wrong with my script

  • Cause: The GECK does not report problems with scripts, and won't allow a script with errors to be saved.
  • Solution-1: the GECK Extender Plugin re-enables 1220+ Warning, Error, and General messages, in addition to providing more verbose messages and fixing many bugs. (Do not use together with GECK Power-Up (nor the Forked version), which it replaces.)
  • Solution-2: the GECK 1.4 Powerup Plugin comes in a "standalone" version for the "vanilla" GECK functions, and one for GECK with NVSE functions. It fixes and improves some issues while providing the missing messages when the GECK compiler finds an error or warning, and lets you save a script without compiling it. Considered "essential" by mod creators. (Replaced by GECK Extender. Do not use both together.)
  • Solution-3: The CIPSCIS Script Validator allows you to quickly indent your script while simultaneously checking it for several errors, many of which are not picked up by the GECK's compiler. It works with Skyrim, Fallout 3, and Fallout New Vegas. Includes it's own tutorials.

Issue - GECK is missing text in some fields

GECK seems to be missing the text associated with certain columns of AI Package, Dialogue, Effects, and Perks (possibly others) information (Editor ID, Topics, etc.). Typically this is a "list box" type field on the form.

  • Cause: This occurs in the GECK for both "Fallout 3" and "New Vegas". The problem originally appeared following the installation of Microsoft Knowledge Base article 3000850 (a Win8.1 "rollup update"), was fixed by rolling back that update, but then the problem got "baked in" to Win10. The issue causes the column's right border to be shifted to the far left of the field so the column text is not visible. (See the GECK: Collapsed Text Field.
    GECK: Collapsed Text Field Figure
    Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)
  • Solution (Partial): This "fix" seems to stick only so long as you do not open an AI Package. Switching between Perks, Effects, and Dialogue condition columns work perfectly if you don't open an AI Package's conditions; but then ALL condition columns become squished for any form you open. The next time you start a GECK session, all will be fine again; but once you open AI Package's conditions the bug remains for the session until you implement the "temporary" or "workaround" solutions in each form.
Set "compatibility mode" for the GECK to "Vista SP2" or "Windows 7 SP 1". (Either seems to work as well.) For example: Right-click on your GECK-NVSE shortcut or the GECK executable directly, chose the Properties | Compatibility tab, Change settings for all users, and select Windows 7, and hit OK. Load up the editor and things should look normal for the first time since upgrading to Windows 10. (See the GECK: Expanded Text Field.
GECK: Expanded Text Field Figure
Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)
GECK: Expanding Collapsed Text Field Figure
  • Temporary Solution: Place the mouse cursor in the top left corner of the "blank" field that is missing text until it changes the cursor shape into a "split cross" (column resize) cursor. (See GECK: Expanding Collapsed Text Field. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.) Left-click and hold while dragging to the right, and the missing text should be displayed. Continue dragging to the right until everything is shown or the mouse cursor is no longer the "split cross" shape. When you release the mouse button the display field should be corrected. However, this "fix" may not be persistent from one GECK session to another.
  • Workaround: there is a Windows "hotkey" for expanding all columns in the currently active window of Windows Explorer and some programs (including GECK).
  • First you have to select a field with the problem (i.e. the "Conditions" field in the GECK: Collapsed Text Field) in the displayed GECK window,
  • Then press "Ctrl" and the "+" key on the cursor/number-keypad. (The "+" key on the regular keyboard won't have this effect. See GECK: Expanding Collapsed Text Field. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)
Now all columns should be expanded fully by themselves. (See the GECK: Expanded Text Field. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

Issue - GECK Render Window shows a large gray square in new world space

Created a new world space and set WastelandNV as parent, using land and map data from the parent. Everything seems to be working fine except for a huge gray square covering most of the render window when trying to view the new world space.

  • Cause: The gray square is the water table.
  • Solution: Go to your 0,-0 point, zoom past the gray till you can see your land, and then add a static. Close, save, and then open your world space in GECK again and your land surface should now be visible.

Issue - How do I configure the GECK to do something


GECK and the Active File

Ever since Windows version 3 on a 386, programs have standardized on "File | New" or "File | Open". But not the GECK. This is your first introduction in how un-intuitive the GECK is. It truly is a miserable toolset.

The "active file" is just the file that you are currently editing. Unfortunately, this gets confusing in the GECK.

The way you create a new plugin (ESP) file is you:

  • Open up the GECK,
  • Click "Data",
  • Select any "master files" you want for your new ESP file.

At this point you don't have an active file for editing. But if you are creating a new file, that's what you want to do (yes, it makes no sense). At a minimum you need to have Fallout.ESM selected as a master. The GECK will load the master files (which are usually but not always with an ESM extension), and then you can make your changes, and when you select SAVE, then the GECK will finally prompt you for the name of your new file (which will usually have an ESP extension). Now that you've created a new file, this is your "active file" for this session. Any more changes that you make will all be saved to the same file.

TIP GECK can isolate records in a particular plugin

Thanks to madmongo of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
Suppose you want to only view content added by one particular plugin.

With the GECK open, click on "File" | "Data" to bring up the list of mods. Instead of selecting a mod to open, just "<Left+Click>" on the mod you are interested in to select (highlight) it. Now click "Details", and you'll see a list of records in the mod. By default, it will be sorted by type on the left, which is what you want, but for other types of searches you can sort by other columns. Armors will be a type of ARMO and since that starts with A they will be somewhere near the top of the list.

You can do this before loading a mod. You can also do it while you have a mod loaded and are working on it: but be warned! Be very careful to hit "Cancel" when done and not "OK". If you accidentally hit "OK", the GECK will try to load the configuration you have selected which will probably screw up whatever you were working on. You'll probably lose whatever changes you had that weren't saved.

TIP Limit to Mod Size

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Note that there is a 16 MB limit (that no one ever tells you about) for references (i.e. "objects") in mods. If your mod gets larger than 16 MB and you add an object or an NPC, your mod will be permanently broken. It will crash the game and will crash the GECK if you try to load it.

Here's why: Ever notice that all objects in the game have a ref ID that is two digits to refer to the mod number (called the "mod index"), followed by six digits for the actual ref ID? In other words, the ref ID for water is "000151a3", where "00" is the mod index indicating it is from Fallout.ESM and "0151a3" is apparently the offset into the file. The largest six digit hex number you can have is FFFFFF, which is 16 MB (minus 1). That's where the 16 MB limit comes from.

The two digit "mod index" at the front means that you can theoretically have 256 mods, though this game breaks once you get to about 130-140 or so. The "FF" mod index is reserved for "dynamically placed" objects in the game and these are preserved in the "save game" files. You (as a "mod creator") cannot directly address these "FF" references as they only exist in game memory at run time.

Anything with a base/ref ID has to be under that 16 MB reference limit or it breaks. Things that don't have a ref ID (navmeshes, landscape textures, etc.) can be placed without regard to the 16 MB limit. Since your ambitious "overhaul" is likely going to be a fairly large mod, you might want to make all of your object/NPC changes first, then add dialog, navmesh, and similar non-reference changes last.

TIP Save often

This brings up a major point: save early and often. Where "often" is defined as after every change you make; and then make a copy of your ESP every few days or so, just in case. Configure "compatibility mode" for "Vista SP2". This seems to reduce how often it crashes.

Still the GECK seems to crash if you breathe heavily on it. It really sucks to open your plugin one day and find an entire town you spent a month on, gone: not a brick left and no aliens with probes in sight.

Once you have a file saved, if you want to edit that file later, you just select the files you want to load and make that your "active file" and start the GECK. When you save, all changes will go into the "active file" that you selected. Let's say you want to add resources from another master file to your plugin, like say, from Honest Hearts. If you are creating a new file, you'd check Fallout.ESM and HonestHearts.ESM, but you wouldn't select any active file. Later, when you save, you will be prompted for a new plugin filename that will become your new active file.

Let's say you already created a plugin, but you didn't include Honest Hearts initially, and now you do want to include it. Open the GECK, select "Data", make your plugin the "active file", and also check the HonestHearts.ESM. Once the GECK is up and running, as soon as you save any changes, your plugin will now include HonestHearts.ESM as a "master file", which it will require to be loaded thereafter.

Once you've added a "master file" to your plugin, you can't easily delete it. Well, you can, all you need to do is right click and press "Delete" when you start up your plugin in the GECK, but if you aren't very careful about exactly how you do that, you will completely destroy your plugin and render it unusable. There are ways to remove "master file" requirements in your plugin, but since you are just beginning with the GECK, assume for now that any "master files" you add are needed there forever.

The GECK will let you load multiple ESP files, but where any ESM "master files" that become requirements for your plugin are loaded automatically, the same isn't true for ESP files your plugin becomes dependent upon. Don't add resources from a different esp to your plugin, because that doesn't work. You can only add things to your plugin that come from master files, or things that your plugin adds on its own. There are ways around this, but again, that gets pretty advanced.

GECK Form-ID Base-ID Ref-ID and Editor-ID

An Editor-ID (sometimes called a GECK ID) is a text identifier used to reference persistent objects. It functions similarly to a Form ID, although it is not limited to 8 characters and a hexadecimal character set. It exists for the human user of GECK. The game engine itself is only concerned with Form-IDs. There is a direct "one-to-one" correspondence between an EditorID and a Ref-ID, but for the human only. (Editor-IDs are primarily used to identify objects in the Object window [the left pane of the GECK].) The game engine needs and only recognizes the Form-ID in commands, but they can also be used in scripts along with Editor-IDs. See the GECK Reference page.

Whether you create your own new object or copy and rename an existing one, you want to give it an "Editor-ID" (the human consumption one) that will enable you to quickly locate yours in the Object window.Refrain from beginning the Editor-ID with numbers. While this will tend to sort the name high in the list of objects, GECK will confuse such names with Form-IDs, which it won't find. Most experienced mod creators use a short common prefix, such as their initials or those of the mod, as the way to group their objects. Whatever naming convention you use, it must be unique and not too closely matching that of other mods to avoid confusion.

A Form-ID is anything specific to an object: whether it be Base or Ref. It is a more general term for both.

"A BaseID (or Base ID) is a FormID assigned automatically to an object by the GECK when a new object is created in the Object window. The Form IDs listed in the Object window are Base IDs. A Base ID is only associated with an object template in the editor, never with an instanced object in-game" - GECK glossary.

"Base ID is the number assigned to a template for an object that is used to create many instances of that object. For example all bottle caps in the game have exactly the same Base ID. This ID is used in scripts or the console with commands that create new instances of an object, like additem or placeatme." - Form-ID on The Vault wiki. You could think of it as the "parent" of each "child reference". Any change made to a Base-ID affects every reference back to that Base-ID. Which is why you need to make a "copy" of a Base-ID and change it's Editor-ID (which forces a change to the Form-ID) when you need to make a variation of an object. Otherwise you are changing ALL instances of that object in the game. (Don't try to change a Form-ID directly yourself. Let the GECK handle it.)

"A Reference ID is a FormID assigned automatically to a Reference [instance] by the GECK when an object is placed in the Render Window [in the right pane of the GECK]. Reference IDs are required to uniquely identify each instance of an object in-game. The Form ID column of the Cell View window lists Reference IDs" - GECK Glossary.

"The Reference ID is the unique ID of an individual object (unlike the Base ID, which is an ID for an object template). For example, all the bottle caps created from same Base ID will have different Reference IDs. This ID is used to manipulate existing objects with commands like kill, move to, or prid, for example.

"Any item that is not created by pre-defined game scripts (either original or from mods) will have [a] Reference ID starting with FF to indicate that this item belongs to this particular save game. It is for dynamically generated items, like loot from containers, random encounters or trader's wares." - Form-ID on The Vault wiki

RefID's that mod creators input, are only of assistance in letting the humans know to what the reference applies. You can actually use the FormID hex code value shown to the side in parentheses of the ref-ID field.

Note it is the persistent flag on the Reference that is mandatory in order for a RefID to become included in the search list for scripts/targets/whatever. (See GECK: Creating New Persistent Reference.) Otherwise the list of refs to search through would be way too huge and cause engine lag.

TIP Reference Variables explained

Thanks to vforvic of the Nexus "Fallout 3 Mod Talk" forum for the basis of the following:
Sometimes confusion arises from the terms: a Reference compared to a Reference Variable.

A Reference (Reference Editor ID, aka "Ref-ID") is a unique name you give a GECK object (Base Object). This is done so that when you put (for example) a vanilla 10mm pistol (Base Object name "Weap10mmPistol") instance in the game, you can subsequently identify in a script that one specific 10mm pistol if needed. For example: Actor Colonel Autumn, which has a Base Object name of "ColonelAutumn" is in the game world twice with two different Reference names. This way the game can manipulate each instance of these References of the same Object separately.

Think of a Reference Variable as a dynamic placeholder in a script. It is used in scripts to make reference to something that is not named specifically. One thing to keep in mind is that they can be set to almost anything; including set to nothing at all (which is 0). The name used for a Reference Variable can be almost anything as long as you declare it (give it a name) at the start of the script. So you can name (declare) a Reference Variable "MyLightRef" or can name it "yadayadayada" and it does not matter. The only thing is: you should normally not start a Ref Name with a number, some special characters or some names which are reserved.

As an example: I make a new Raider Actor in the GECK called "EscapingRaider" (Base-ID). I put 50 of these Raiders at the end of a long large room with the Player at the other end by a door. The Player has to kill one specific instance of "EscapingRaider" before it reaches the door, but the Player does not know which one and there is no time to kill them all. In this case I give one of the Raiders I have put in the room a Reference (Ref-ID) name of "EscapingRaiderREF". I then give them all an AI Travel Package to run to the door. Right before the door I put a Trigger Box with the following Script attached. If this specific Raider ("EscapingRaiderREF") reaches the door then the mission fails. 

scn EscapingRaiderTrigger

;This script is attached to a Trigger Box (Primitive) in the game world
;Anything that move into the box activates the script.

ref actionRef  ;Here is where I tell the script that actionRef is a Reference Variable (ref)
               ;I could have said "ref action" or "ref stuff" and it would be ok.
               ;You can name this almost anything as long as it makes sense to you.

Begin onTriggerEnter   ;When something enters the Trigger Box this part of the script runs
    set actionRef to getActionRef   ;Get the Reference Name of whatever entered the box
                                    ;Whenever the script sees actionRef in the script it
                                    ;will substitute this Reference Name in its place.
    if actionRef == EscapingRaiderREF   ;If the Reference Name of the Object that walked
                                        ;into the Trigger is EscapingRaiderREF then the next
                                        ;line will also run.
	showmessage MissionFailed   ;Pops up a message saying the mission has been failed
    endif
End

Granted this might not normally be how I would do this specific event, but it could be done this way.

I could also use a Reference Variable in conjunction with a FormList I have populated with NPC's which placed a Nuclear Explosion at the Players location if an NPC in the FormList reached a particular location. 

scn NukeTrigger

ref obj  ;Once again I could have named this almost anything. 

Begin onTriggerEnter   ;Runs when something enters the Trigger Box.
     set obj to GetActionRef   ;Sets the Ref Variable "obj" to what ever entered the Trigger
     if obj.isInList NukeList == 1   ;If whatever entered the Trigger is in the FormList NukeList then run below.
        showmessage NukeSuccess
        Player.placeatme smallnukeexplosion   ;Player has a bad day.
     endif
End

The following example code would be used somewhere you wanted to find out in what container (and remember an NPC or the Player can be considered a container), an object is located. (This has mostly been used for custom weapons where a script would be attached to the weapon for a custom reload animation.) The following script would be attached to that specific weapon. 

Scn FancyRifleReloadAnimationScript
ref rContainer

begin gamemode
;The following line says to set the Variable "rContainer" to whatever Container has the weapon.
;Let’s assume a Talon NPC "Talon1GunAM" has the weapon and is firing it.
	set rContainer to GetContainer  ;essentially says to set rContainer to Talon1GunAM
;From this point anytime the script reads rContainer it will really use Talon1GunAM.
;Which means the following line really says “if TalonGunAM is reloading do the following”
	if rContainer.GetAnimAction == 9
;The following 3 lines show the custom reload stuff.
		if rContainer.GetEquipped FancyRifle == 1
			PlaySound FancyReload
			rContainer.CastImmediateOnSelf FancyRifleReloadActorEffect
		endif
	endif
end

The Base Object ID (aka Base-ID) is what you name an Object when you make it in the GECK. Whether your making a NPC, a Weapon, a Door, a Rock or anything, it has a Base-ID name.

For example:

In the GECK you make a new "Bandit" Actor. In the first line you see ID which is the Base Object ID and you put "MissionEssential". ("MissionEssential" is now the Base-ID of this "form".) The second line you see Name which is the name you see in the game (e.g. "Lucas Simms", "Allistair Tenpenny", "Amata", etc.), and you put "BANDIT". ("BANDIT" is now the Editor-ID of this form.) Now every NPC of "Bandit" Actor that you just made and you drag or spawn into the world will be named "BANDIT". In the GECK you drag two of those "Bandit" Actors into the middle of the "Megaton" cell. You double-click on each of those two Bandits and you see identical boxes with the Reference Editor ID field empty on each. Here is where you would put (for example) BanditGoodEndingREF and BanditBadEndingREF. Now you could use those two Ref ID's in scripts to make your good or bad ending occur. There is actually more than one way to do this type of thing. You could have a Quest Script that monitored when one of those Refs died or you could use a Trigger Box or all kinds of Functions depending on exactly what type of thing you were scripting.

Keep in mind that spawning objects in a cell using the Console is not the same as placing them in the GECK because you can't "spawn in" things with Ref-ID's. Ref-IDs are always assigned automatically by the GECK when form records are placed in "the world".

But not everything within the "object tree" can then be put into the "Render window" and become a Ref-ID. Hence the difference between Base, Ref & Form ID: a Ref-ID always has a Base-ID, and conversely a Base-ID means it can create "references" that rely on it. "Message" objects are something outside of that relationship. A "message" is its own kind of object; like a "sort of" note, with it's own Form-ID. (The GECK distinguishes between "notes" and "messages", and so should you. In the same way, GECK does some things one way, and addons such as the "New Vegas Script Extender" (NVSE) can do them differently.) The GECK command "ShowMessage" needs a Form-id to point to. You can't just use the message text directly as a parameter. There are 2 kinds of messages though. Read up on Message in the GECK wiki. The New Vegas Script Extender (NVSE) and JIP LN NVSE Plugin mods add several additional "message" functions that facilitate passing message text directly as a parameter. (See TIP: Passing a 'Note' to the player.)

"Load order of modules (ESMs and ESPs) will affect the ID number of modules. The first two digits of a ID number [i.e. "Form-ID"] corresponds to its load order (in hexadecimal, like the rest of the number). One must use a utility like FO3Edit [or FNVEdit, aka xEdit] to ascertain the load order of a module. [The Fallout ESM file's] ID number is 00, as it will always be the very first module to load. The ID number series in the FF (decimal equivalent: 255) range is reserved by the game engine for objects created and saved in the gamesave file (such as PlaceAtMe'd objects, projectiles, dropped inventory, or list-spawned actors).

"According to the layout of this system, the maximum number of additional modules that can be loaded by the game is 254 (256 load order ranges, - 1 for the Savegame FF range, - 1 for the always-mandatory Fallout3.esm/FalloutNV.esm)." - Form-ID on The Vault wiki

TIP Global ref variables Player and PlayerREF

Thanks to DoctaSax of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
According to the Community GECK site, "Player is used to describe several things, sometimes simultaneously." Among them is: "A scripting keyword that is effectively a global reference variable that resolves to the Actor reference described above."

The Ref Variable page only uses "PlayerREF" for checking that a locally defined ref variable is that specific Actor "formid" reference. It cautions regarding using a base form reference: "Beware that this is still a base form and may not be used as the calling reference to functions that allows this syntax, although it may be passed as the target if the function permits this.

The combination of those statements suggest that it is a poor practice to assume the variable "Player" refers to the PC Actor formid at any given moment without checking first. And "[PlayerRef].< function >" syntax implies that "[PlayerRef]" is an abstraction of a locally initialized (e.g. "set myPlayerRef = PlayerREF") variable. The following hopefully clears this up.

On the surface, the relation between the Global Ref Variables "Player" and "PlayerREF" is the same as that between any "base form" and a reference of it. An instance of the NPC base form with EditorID "Player" (formID 00000007) was placed in the world (albeit in a NULL cell if you can believe it - literally in the world but not in any part of it), becoming a reference and receiving formid 00000014, and given the EditorID string "PlayerREF". Everything that happens to the PC happens to the "PlayerREF". The base form is really just a container of some information, a "template", most of which is still subject to change during gameplay and "character generation" (chargen).

PlayerREF's formid cannot be found using xEdit, but can be found by using any console/script function on it that returns the formid. A script example would be: 
GetFormIDString playerref
printc "%i" playerref
If you open the GECK, load up FalloutNV.esm, and open the "Find Text" window in the "Edit" menu, type in "playerref" and check the results in the "Objects" tab, you'll find this: 
"REFR Form 'PlayerRef' (00000014) to NPC_form 'Player' (00000007) in Cell (null)"
Because there can be only one, "Player" is indeed a shortcut to mean "PlayerREF" in many vanilla scripts and scriptlets where a reference function is used on it, which in any other case would cause a script to fail. In addition, "Player" is still the EditorID of the base form; so it is used to refer to the base form when functions demand a base form, such as "GetIsID" condition checks. It's not quite clear why that is done. Using "PlayerREF" instead of "Player" is just as easy, and keeps things clear. People make enough mistakes confusing forms and refs as it is, and ref vars being called that but still being able to hold base forms, and "Player" being sometimes the base form and sometimes the reference variable doesn't help.

On the whole, in practice, it's simply best to use "PlayerREF" for the reference variable, and only use "Player" for the base form. Because all vanilla "GetAV" variants are reference functions, "PlayerREF" is preferable, and definitely doesn't cause "GetBaseAV" to not work. "GetBaseAV" cannot be called on a base form variable at all, including "Player" (00000007). The only reason "Player.GetBaseAV" will work is because it's interpreted as the shortcut to "PlayerREF" there. If you were to pass the "Player" base form to a ref var ("rSomeRef") and then call "rSomeRef.GetBaseAV", your script wouldn't work.

Custom items

On the other hand, loading in multiple ESP files can be a quick and easy way to copy resources from another plugin into your plugin. Just go into the GECK with the other plugin loaded (as well as yours as the "active file"), make a change to whatever resource you want (you can literally change something and then change it back to what it was, just so you make sure that entry gets flagged as changed), and save your plugin. The changed resource will now be saved to your plugin. You have to be careful with this, as it won't work if the entry you are trying to copy depends on other things in the plugin that you didn't copy. Generally, as someone new to the GECK, you should probably try to avoid doing this, but if you are trying to copy items from another plugin, this is the fastest and easiest way to do it.

The GECK only includes a file as a resource if it's a "master file". If you load an ESP, the GECK won't treat it as a "master file". The GECK will automatically add any "master files" that the other ESP loaded since those will all be loaded into your new editing session when you load both ESP files.

One word of warning. If you want to copy a piece of armor or some other resource from another plugin, load that ESP without making it active, then make a change to the item you want, then save it, and DON'T DO ANYTHING ELSE. Exit out of the GECK, load it with the resource only in your plugin and WITHOUT the other (original) esp loaded, and then use the modified resource in your plugin. If you try to use the resource while the original plugin is still loaded, that can get the GECK confused and it may end up scrambling your plugin as a result.

This copy from one ESP to another will end up including "master files" from the original ESP in your new plugin; so if you don't want them, DON'T just delete them from the GECK data screen when you select your plugin. If you accidentally left something in your plugin from one of those masters in your copied cell, deleting the master will screw up your plugin, so first ensure you have a saved copy and then clean up the "master files" list early. Instead of using GECK for this, load your plugin into xEdit and use the "Clean Masters" function by right-clicking on your plugin and selecting that option from the resulting "context menu". If all your references to those other masters have been removed, it will safely remove those masters. If not, you can use the xEdit script "List records referencing specific plugin.pas" on that plugin to list them in the log window so you can fix them.

Make sure that the item you want is in a loose file (both mesh and texture) and isn't packed into a BSA file. If it is, you'll need to unpack it to properly reference it in your plugin.

(See the Skyrim thread BSAs and You for details about the pros and cons of "Bethesda Software Archives" (BSAs), but bear in mind such files in previous games, like Oblivion, FallOut3 and Fallout New Vegas, don't have "strict order" like in Skyrim. Games prior to Skyrim don't support overriding of assets in archives using other archives; only loose files can. If the same resource is contained in several BSA archives, those games won't use it from the last BSA on 100% of occasions. They may grab the resource from a random one of the BSAs containing the same file.)

WARNING! Do not unpack BSAs directly into your game "Data" folder; potentially overwriting any mod files. The tools don't ask you to confirm the overwriting, either. All the hair textures unpacked to "loose files" will go through the head models in that case; because that's what happens when hair is not packed in a BSA. "Best practice" is to unpack to a unique folder (they are large: 1-2GB) and manually drag the desired files to the appropriate "Data" folder as needed.

Sometimes these extracted textures appear to be almost transparent. This is because their color (aka "diffuse") maps are transparent instead of opaque. You may need to adjust the opaqueness to make things visible.

Plan to start by making simple mods: like maybe adding a house somewhere. Then make simple re-textures of existing objects. If you get that far, then you are ready to start making your own "mesh" models.

If you are making armor or a weapon, the most commonly suggested advice is to start with an existing version that is similar to what you want. That way you'll have an existing model to base your 3D model on that is close to the right size so you can scale your new model appropriately. Depending on what is desired, for armor it is suggested to often start with just a body model instead. Once you've created your model, you will have to "parent it" to the appropriate armature (aka "skeleton") in order for it to work. If words like "parent" and "armature" in this context don't mean much to you, then you need to do more reading about 3D modeling (again, "Noob to Pro" is a good resource for Blender).

Things like buildings and clutter items are also created with Blender (or 3dsMax), but they don't have armatures. They do have collision though. You'll have to make a collision mesh in Blender when you create your model.

When creating custom meshes for things with different materials, just create individual collision meshes ("bhkcollisionobjects") for each material and let Blender and the NifTools figure it out. When creating something like a log cabin with a stone base, for example, create one collision mesh for the stone base and another collision mesh for the wooden parts. The stone part would have a string property of HAV_MAT_STONE and the wood part would have a collision of HAV_MAT_WOOD under the "hkPackedNitriStripsData".

Primitive collisions (box, sphere, capsule) can be created in NifSkope as well as convex shapes. The nature of your object will sometimes require you to create them in Blender, though.

It is interesting to know that a collider will relate to an object part when it encompasses it, not by the child/parent relation inside a Nif.

  • Getting NIF and DDS textures out of BSAs. (See BSA Extraction Warning above.)
  • Importing, editing and exporting into/from Blender (2.49 and latest)
  • Creating new texture files as DDS in Photoshop.
  • Adjusting new object in NifTools for correct projection.
  • Making various emission colors for signs, like green, red, yellow and non-glowing.
  • Importing new model mesh into GECK for use in game.

 

TIP Biped and Equipped Objects

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
The GECKWiki page GetEquippedObject lists the 20 "Equipment Slot IDs" (which are the equivalent of the "Biped Objects" in NifSkope) that return the "base object" of the item equipped in the specified slot, for the calling reference. The function returns "0" (nothing) if no object is equipped there.

According to the TES5EDIT fopdoc these "body slots" are stored as "Biped Flags" found in a hexmask (starting at a value of "1") in the "BMDT Subrecord" of FNVEdit, used in the ARMO and ARMA record types. There are 8 "General flags" which accompany that subrecord.) The function GetEquipmentSlotsMask returns the slots used by the biped form as a bitmask int, for the specified object or calling reference.

(Note how in FO3/FNV there are far fewer (20) than the 44 in the following list of Fallout 4 "Biped Slots" and the 32 (17 "named", and 15 "unnamed" but unofficially, community designated) "Biped Object" slots of Skyrim from the "Creation Kit" site.)

FO3/FNV mods usually use the "upper body" slot for armor and clothing (collectively "garments"). This includes both arms down to but excluding the hands (which have their own individual slots), and both legs to include the feet/footwear. There is no "lower body", "arms", or "legs" slot, and there does not appear to be any community agreed "standard" assignment for the three "body addon" slots. (The general "head area" actually has more related slots (11) than the body.) Consequently these "addon" and nominally "head related" slots might be used by other mods in a conflicting manner (e.g. for implants, holsters, or other accessories).

The article Mixing and Matching Items from Diffrent Mods to get the Look You Want (sic) describes how these slots can be repurposed to create a "unique" look, but without regard for compatibility with other mods. This "merging" of various parts of other mods into a new "garment" is called by some "mashing up meshes & textures" or simply "mashing" for short. What it doesn't mention is that if you don't "mash" the garment onto a body mesh and texture that is compatible with your "body replacer" mod (if any), it will have the shape and texture of the original source body instead of your preferred "replacement". Any exposed skin is part of the "garment" and not from the "body replacer". If you attempt to remove the "exposed skin" mesh, you end up with "invisible" or "missing" parts of the limb.

Mustaches, beards, eye patches, cyborg eyes, etc. can be added to the GECK by selecting Character (at the top of the GECK Objects list) and selecting Head Parts. This will bring up a form where you can add new head parts, similar to how you add new hair and eye parts. Make sure you select the playable check box if you want the player to be able to use the part.

The new head parts can then be added to NPCs on the NPC's form. Select the Head Parts tab, then add the new part by selecting New in the Head Add Ons at the bottom of the tab (the same way you select existing facial hairs).

TIP Flickering on added item Radius Setting

Sometimes when adding an item to another (such as a hat on a Mr Gutsy) it seems to flicker out of sight depending on the player's camera angle or distance. This is a classic symptom of a problem with the model's "Radius setting". The following is courtesy of Prensa in a specific reply to a question about this issue with general application.

The "Radius setting" in the "NiTriStrips' NiTriStripsData" tells the game how big the model is. If this Data is incorrect than the game can end up thinking the model is a different size than it really is. If it's told the model is smaller than it really is, it will cull it when it thinks it's out of view at the edge of the screen.

Normally this happens when a "NiTriStrip" is enlarged in Nifskope without going to "Radius" & right clicking it, and then "Mesh | Update Center/Radius".

In this case the "Radius" is being messed up because the NiTriStrip's of the hat top & bottom are "Scaled" 17x larger but their "Radius" is still set tiny. You probably enlarged them to size in Blender & did not update the objects before export.

Normally you could fix it in Nifskope with right clicking the affected "NiTriStrip" & "Transform | Apply". Then updating the "Radius" as mentioned above but because these have "BSDismemberSkinInstance" that would be messed up so you must use Blender.

Easy fix still. Import the hat parts into Blender, right click the hat part to select & press <Ctrl+A>, then from the menu select "Scale & Rotation to ObData".

Export the piece out & repeat for the other hat part.

You'll notice in Nifskope they are no longer "Scale" 17x & that their "Radius" is much larger (correct to their size).

Don't forget to select "Skinned" in the shaders again as this is lost on export from Blender.

 

TIP Floating objects

Thanks to Stonedturtle26 and baduk of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
You created a custom weapon but find that if you "drop" it, it floats and you cannot pick it up. To fix:
  • Open the weapon in question in NifSkope.
  • Locate bhkCollisionObject, and <LClick> the little arrow next to it.
  • <LClick> bhkRigidBody so the dialog at the bottom of NifSkope populates with information.
  • Now change the following values;
  • Set "Layer" to "OL_WEAPON".
  • Set "Layer Copy" to "OL_WEAPON".
  • Set "Motion System" to "MO_SYS_BOX".
  • Set "Deactivator Type" to "DEACTIVATOR_SPATIAL".
  • Set "Solver Deactivation" to "SOLVER_DEACTIVATION_LOW".
  • Set "Quality Type" to "MO_QUAL_DEBRIS".
  • Set "Max Linear Velocity" to "1068".
  • Set "Max Angular Velocity" to "31.5700".
Now the weapon should drop to the ground.
For other object types, look in NIF.XML located in the Blender foundation\blender\.blender\scripts\bpymodules\pyffi\formats\nif\ folder or the NifSkope documentation files in the "Doc" folder of it's installation folder. Search for bhkRigidBody. It has a good listing and some simple explanations of the options.

 

TIP Head Parts Rotated

It's not known why head parts changed between FO3 and FNV, considering that so much else in the game engine is identical, but they did. If you port a head part (hat, glasses, facemask, etc) from FO3 to FNV or from FNV to FO3, or make a new open helmet/hat/head accessory that uses a existing mesh, whether it's a simply a clone or a retexture, it tends to equip sideways (rotated by 90 degrees).

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following fix using NifSkope:
The easiest way to fix it is to edit the model with NifSkope and rotate it by 90 degrees to get it pointing the way it should be.
Summary from How To Rotate A Mesh In Nifskope 2 minute video by Zylice Liddell.
  • < Right-click > the object in the NifSkope "viewport", then "transform | edit | R (rotate in +/- 1-180 degrees)".
  • After you have it positioned correctly: < Right-click >, "transform | apply".
Thanks to masternetra of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following fix using FNVEdit (xEdit):
Make sure to save your ESP/ESM plugin in question and exit the GECK. Then open up FNVEdit.
  • Load up your plugin in FNVEdit and locate the item(s) in question.
  • Go down to "Male Biped Model", and at the empty section next to "MODD - FaceGen Model Flags" - <right-click> and select "Add".
  • Select "Head" or, if you using a older version of FNVEdit (for some reason), replace the default zeros with a "1".
  • Repeat for the "Female biped model" section if applicable.
  • Exit FNVEdit (with it saving the plugin of course).

 

TIP Item Substitution

Thanks to madmongo and Jokerine of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Suppose you have created a unique Service Rifle with a custom mesh that you want to use to replace the vanilla Service Rifle that Private Halford can reward the Player with for completing the unmarked quest "Help for Halford." How do you find where the quest/dialogue reward is given in the GECK so you can replace the vanilla weapon with your unique custom version?

You can just select "Weapons" on the left side of the GECK "Objects" window and enter "service" in the filter box, and the Service Rifle will show up. Most of the time this is faster than searching out the item's "base ID" (FormID) code. However, sometimes the item's EditorID (human reference name) in the GECK is a lot different than the item name (as seen in the game), so filtering different parts of the name won't find it. For example, "This Machine's" EditorID is "WeapNVBattleRifleUnique", which doesn't contain the words "this" or "machine" in it anywhere. How do you find it if you have no idea as to it's actual EditorID?

Jokerine provides a step-by-step more generalized alternative approach of looking for the item you need based on using a wiki or clicking on the object in the game console to get the "base ID" (hex FormID).

  • In this case the item is listed in a wiki as Service Rifle, and its "base ID" is "000e9c3b".

Jokerine Fig-01

  • Paste that "base ID" number in the GECK's Object window filter with "ALL" selected and the weapon will show up...

Jokerine Fig-02

This gives us an idea already - "Count" field is the amount of these items that exist in the world (only 7), and "Users" field is the amount of objects in the game that reference it - in this case, 23.
  • Then, right-click the desired result and select "Use Info"...

Jokerine Fig-03

  • A window will show up showing everywhere this item is used. As you scroll thru it you'll see the quest/dialog topics among a bunch of other stuff.

Jokerine Fig-04

  • Then, you can just double-click on whatever you want to look at. Here's one of the dialogue topics, where you can see the reward being given in the end script.

Jokerine Fig-05

And now you know where to change the vanilla "Service Rifle" item reference to that of your custom unique item as the new reward.

 

TIP Mashing Meshes

Thanks to madmongo, M48A5, and 'RoyBatterianof the Nexus Fallout "New Vegas Mod Troubleshooters" forum for the basis of the following:
Suppose for example you want to place the model of a particular pistol into a holster for display purposes. (This "pistol" will not be usable. It's for aesthetic purposes only.) Some call this process "mashing" two meshes together (e.g. mashing the pistol into the holster). The process is similar for other sorts of "mashing".

The basic procedure is first go into NifSkope and remove all of the unneeded "animations" and "collision" and such so that you are left with just the (in this instance: "weapon") source mesh. Save that to some new nif (you can delete this temporary nif later).

(If instead you are intending to actually be able to use the "weapon" you exported with any existing animations it already contains: don't save it without copying the NiTriStripsData into the temporary mesh nif, as the transforms for the parent nodes are baked into the animation. If you have to fix it later you'll have to re-weld/re-smooth the mesh and move the vertices themselves rather than move the mesh as a whole so the transforms don't change.)

Now open up your handy-dandy 3-D modeling program (e.g. Blender or 3DSMax, etc. We'll assume Blender for this example). Import your target (e.g. "holster") mesh. Next, import your modified, stripped down source (e.g. "weapon") temporary nif.

I find it easiest to just join all of the weapon meshes together into one mesh at this point, since that makes moving it around and weight painting it much easier. Once it is joined into one piece, edit the "pistol" mesh and move it to where you want it to be in the "holster". (This is likely to be the most difficult step.) When you are satisfied with the positioning, join the "pistol" and "holster" meshes into one single mesh again.

Then you need to parent the source ("pistol") mesh to the human skeleton ("armature"), and weight paint it so that it matches the weighting on the target ("holster"), so that it moves with the "holster". Since something solid like a pistol doesn't deform when you move, unlike say a piece of clothing, chances are you will weight the entire mesh 100 percent to a single bone. Having the entire pistol & holster as a single mesh means that you can assign the same bone weight to every vertex in the mesh very quickly and easily in Blender.

Once that is done, export everything (armature, holster, and pistol) to your new "final, mashed" nif. It's a good idea to save everything in Blender before exiting that as well, in case there is a problem (such as with your export settings). After exporting, go into NifSkope and fix up all of the shader flags (because Blender never seems to set the shader flags properly when you export items) and correct any unweighted vertex.

If the target (e.g. "holster") is not part of an existing item, you will need to go into the GECK and create a new item with your "mashed" (armature, holster, and pistol) nif, and you're done. (See Spawning modded items.) If you want to get fancy, you can make a world model in Blender and use that for when someone drops the mashed "hostler with pistol" item. Or you can get really fancy and have a script swap out the different holsters depending on whether or not you have the pistol equipped.

(You can do the same basic thing to make a wearable rifle slung over your back. Just edit the rifle's mesh so that it is located on the back where you want it, and weight it 100 percent to the spine bone. If I recall correctly, the spine bone you want is just the one called spine, not spine1 or spine2.)

 

TIP Movable or Static custom objects in cell

Thanks to madmongo, davidlallen, and Tefnacht of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
You create a custom object and place it in a cell. But then you can no longer move it simply by clicking and dragging. Why not?

There are a couple of possible causes. Please see the first 7 posts in the thread "Can't pick up custom objects". But in summary check the following:

  • Try zooming or rotating the view so no other object is in the way (such as large cubic triggers or lightbeams). When you click on your object, check the cell objects list to see if something else is selected instead.
  • Make sure your object NIF file has a bhkCollisionObject. Without this, you cannot "Activate" to pick up the object in game.
  • Ensure that the root node of the NIF file has a BSFadeNode. Armor models and animated objects use a "normal" NiNode as their root node. The GECK will accept such a model when placed into the world but you will not be able to select it ("Activate"). The FO3 GECK was nice enough to give a warning about this, the one for New Vegas doesn't bother.
Should this be the case, you can use NifSkope to convert the root node. Right click on it, select "Block | Convert | Bethesda | BSFadeNode". Only the root node (the one at the very top with the index zero ("0")) needs to be a BSFadeNode.

To convert a "movable" object into an "immovable" one, what you really want to do is create a static out of a usable item.

  • If this is a standard Fallout item, it's model is going to be in one of the BSA files. The first thing you need to do is extract the model from the BSA file.


(See the Skyrim thread BSAs and You for details about the pros and cons of "Bethesda Software Archives" (BSAs), but bear in mind such files in previous games, like Oblivion, FallOut3 and Fallout New Vegas, don't have "strict order" like in Skyrim. Games prior to Skyrim don't support overriding of assets in archives using other archives; only loose files can. If the same resource is contained in several BSA archives, those games won't use it from the last BSA on 100% of occasions. They may grab the resource from a random one of the BSAs containing the same file.)

WARNING! Do not unpack BSAs directly into your game "Data" folder; potentially overwriting any mod files. The tools don't ask you to confirm the overwriting, either. All the hair textures unpacked to "loose files" will go through the head models in that case; because that's what happens when hair is not packed in a BSA. "Best practice" is to unpack to a unique folder (they are large: 1-2GB) and manually drag the desired files to the appropriate "Data" folder as needed.

You can do this with the any of the tools listed in the Packaging Tools section. If it's a standard vanilla fallout item, then it will be in Fallout - Meshes.bsa. If it's from one of the DLCs, then it will be in that DLC's bsa file (Old World Blues - Main.bsa, for example, if it's from that DLC). If the item is in another mod, then the NIF could be loose or it could be packed into a BSA file; however that mod author chose to do it. You may need to go into the GECK to see what the file name of the NIF is, but the file names usually match up fairly closely to the item names in the GECK.
  • Now that you've got your NIF extracted, you may want to put it somewhere where it is clear that this belongs to your mod, like in \meshes\MyModName\ (where obviously you create a folder with your actual mod name and not "MyModName").
  • The final step is just to go into the GECK and make a static item and make its model be the NIF that you just extracted.

If the NIF was a usable item then it should already have collision and textures and everything that you need. All you need to do is make a static out of it then place it somewhere. Since it's a static, you won't be able to move it or pick it up in-game.

TIP Plugins can not override injected records

Thanks to luthienanarion of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
You cannot modify a form record that has been injected into an ESM. The game engine will not load any record overrides from any plugins for injected records (e.g. those from the "Pre-Order Packs/Couriers Cache", aka "POP" ESMs). It loads the record data once and then fails to resolve the FormID each time that an overriding record is loaded from a subsequent plugin.

This means, for example, you cannot alter a POP unique weapon to enable it to utilize a "weapon mod" from either the vanilla game or a mod such as "Weapon Mods Expanded (WMX)". It's a design choice that cannot be overcome.

TIP Repairability

Thanks to slippyguy for his informative description in the mod Alternative Repairing listing a number of potential problems he identified/resolved.
A "repair kit" (either weapon or armor) is one of the most common methods of restoring/repairing the condition of an item. However, they have the limitation that the item must have a DT (for armor) or "condition" (for weapons) greater than zero, and be "equippable", as the kits only work on the currently equipped item(s) of that category. The only alternatives are to pay a "vendor" to repair the item, or have sufficient "repair skill" along with the correct mix and quantity of "ingredients" to do so by the player. (NOTE: A mod like "Workbench Repairs" may need to be recommended to enable the player to utilize that "repair skill" generally. Search the Nexus on keyword "repair".)

If you make a custom or unique item that is intended to be repairable by other than a "repair kit", you need to ensure it has a couple of things.

  • For the player to be able to repair using "found items" (as enabled by some mods), you have to create (or utilize an existing) "recipe" that specifies which items and quantities are "ingredients" (inputs) and "outputs". (See the Recipes entry in the Misc Topics section.) If you wish to limit the ability to repair that item to only those with particular skill levels or "catalyst" items, those need to be set as "conditions" in the "Requirements" tab of the recipe. (A "catalyst item" is one which appears in both the "inputs" and "outputs" tabs in the same quantity (i.e. "is not consumed"). Most commonly these are a "tool".) NOTE: Due to a limitation of the game engine, any "breakdown" recipe has to produce at least three different items as "outputs" to display correctly. "Catalysts" are a way to circumvent this.
  • The game does not support 'OR' item ingredients: it's all or nothing. 'Dummy' recipes (as "notes": see also TIP: Passing a 'Recipe' to the player) can be shown instead to bypass this game limitation and provide all the relevant information without cluttering the crafting interface. Once all the required material has been obtained, the real recipe for that set of ingredients can appear and be functional.
  • For a vendor to be able to repair a "new item" in exchange for cash, the item must be added to a "leveled list" used by that vendor. (See TIP: Adding Items to Actors (Leveled Lists) under the Scripting section.) The recommended method is to create your own list, and add that list to those the vendor(s) in question use by way of a script. (Vendors don't all use the same lists or even generic ones.) It is possible to add your items directly to an existing list, but that runs the risk creating problems if your mod is uninstalled or another mod rebuilds the list without considering the possibility it was modified by others.
  • In order for a "vendor" to be able to repair something for cash, the item must have a value greater than zero.

Custom Creatures

Thanks to madmongo of the Nexus Fallout "New Vegas Mod Troubleshooting" forum for the basis of the following.

Let's assume you want to add an "albino radscorpion" to the game.

An "albino" version of the radscorpion would just be a re-texture. What you are going to want to do is export all of the meshes related to the radscorpion (everything in \meshes\creatures\radscorpion) into your own custom directory, and do similar for the textures. Let's assume you are using \meshes\creatures\albinoscorpion (you can of course change the names to match your real directory names). Edit your custom texture using GIMP or Paint.Net or Photoshop or any other texture editor that can handle DDS files and save it with a new name. Then go into NifSkope and edit radscorpion.nif so that it will use your new texture, and save the modified mesh Nif as something unique like albinoscorpion.nif.

Since this is just a re-texture, the easiest thing to do is copy the existing radscorpion creature in the GECK and modify it. So open up one of the radsorpions under the "creatures" section of the GECK like CrRadscorpion2Large and select the "ModelList" tab. Change the skeleton to the skeleton in your new directory. Now your custom Nif should show up along with the standard radscorpion Nifs. Uncheck radscorpion.nif (if it's still checked) and check your new albinoradscorpion.nif, and change the ID for the creature from CrRadscorpion2Large to something like AlbinoRadscorpion or whatever you want to call it, and hit "OK" to save it. You can edit the stats or traits or anything else in there that you like if you want too, of course.

Remember: in the GECK, save early and often.

If you want to make a custom model in Blender that uses the same skeleton as an existing creature, the procedure is basically the same, except that you have to know how to create meshes in Blender and parent them to skeletons. You'll end up with a custom Nif that will already have a custom texture that you applied to it in Blender when you created the model, and the idea is basically the same. Export the meshes and textures of the creature whose skeleton you are using, then edit that creature to use your new Nif (and your Nif will tell it to use the new textures), and save it with a new ID.

To create a completely new creature (one not based upon any existing creature already in the game), you will have to build the mesh and texture files from scratch, and also provide it with animations. If it is based upon an existing skeleton, then you can use that as the "armature". Otherwise you will need to create a specialized one from scratch along with weighting the bones appropriately or by adapting an existing one with a new editor-ID. As you might guess, this is a much more involved process than merely re-texturing an existing creature. Save it for after you have mastered the basics.

Spawning modded items

The following overview is taken from a thread reply in the "Fallout New Vegas" Nexus forum by Hexrowe:

In GECK, there's a category titled Leveled Item (under Items). It contains a whole bunch of lists that tell the game what items should be spawned in randomly filled loot containers, vendor inventories and enemies. These are usually called "leveled lists" because much of their contents are affected by player level (which is why you tend to find more powerful items in better condition the higher your level is). Adding your items to these lists causes them to appear randomly in the game like any other non-unique items, and is what is meant when mod descriptions mention "leveled list integration" or some such.

The sheer number of these lists can look daunting at first, but if you use filters with some fairly obvious keywords and look around a bit you should get the hang of it. Lists starting with "Cond" are used for randomly determining the condition of spawned items, and are usually referenced by other lists; lists starting with "Vendor" are used to randomly fill vendor inventories; lists starting with "Loot" are used to spawn random loot on enemies and in containers; and so on.

In order to add an item to a list, you can double-click on the list to open it in its own window and EITHER go back to the Object Window, find the item you want to add and physically drag-and-drop it into the list, OR right-click on an empty spot on the list (to create a new default list entry) or on an existing entry (to create a copy of that entry) and select "New" from the context menu. Then you have to edit the new entry into what you actually wanted to add. (Drag-and-drop is required for adding items into Form Lists, but Leveled Item Lists can also use the right-click menu. GECK is kind of a mess like that.)

ALTERNATELY, if you want to place an item in a specific location in the game as is often done with unique weapons, creatures, and such, there's a list of world spaces in the Cell View window; find the one you want to place the object in (note that there are several lists; Interiors seems to be displayed by default, but if you want to place the object in an open air location go to WastelandNV instead), double-click it to open it in the Render Window, then find the object in the Object Window and drag-and-drop it into the Render Window. The item will now appear in the list of objects on the right side of the Cell View Window, and double-clicking it there allows you to edit it's exact location and rotation, ownership, whether it can be picked up by wandering AI, and so on. You can also use a "X Marker" and define a radius from the marker at which a script will place an item or creature when certain conditions are met. See Tip: Random NPC Comments for an example of this technique.

Common practice is to put the items in an owner-less container, just to be safe. For this you'll have to create the container in the Object Window (they're found in the Container category, under World Objects) and add it into the world space by drag-and-dropping it into the Render Window just like any other item. The easiest way to create a new container is to double-click on an existing one that uses whichever world model you want (fridge, gun cabinet, briefcase, etc.), change its Editor-ID and name, and click OK; at this point GECK will ask whether you want to create a new form instead of renaming the old, so click "Yes" and you'll have your new container. Now just edit its contents and attributes (remember to remove any owners, unless you specifically want the player to have to steal the goods) and add it to the world space of your liking. Done!

TIP Respawning Plant bug fix

Thanks to masternetra of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
If you add plants (usually ones that can be harvested) that start off as disabled and are later enabled via a script or whatever, pretty much every time you leave the cell and come back (e.g. enter and then exit a interior cell), the plant instantly respawns. (This also occurs if you simply hide the plant below the terrain initially to later move it back up to the surface via script.)

Fortunately it seems the plants produced by the placeatme command don't seem to suffer from this bug if you just place it (and at worse change it's angle and scale). (Don't know about the impact of enable/disabling placeatme items or changing their position.)

Here a bit of example code to help explain how this works: 

set PlacedRef to GFMaize1.placeatme MaizePickable
set RefAng to GFMaize1.getangle z
set RefScale to GFMaize1.getscale
PlacedRef.setangle z RefAng
PlacedRef.setscale RefScale

In that scenerio: placed a disabled version of the plant (GFMaize1) to work out placement, angles, and scaling. Then just give the placeatme plant PlacedRef (=MaizePickable) the disabled one's angle (RefAng) and scale (RefScale) information.

Worldspaces

If you want to create your own worldspace, then you must be a real glutton for punishment, because this gets you into the buggiest parts of the GECK. For example. you create a worldspace, then go and edit its heightmap, and when you save your heightmap and exit out of it, the GECK will crash. The only way to avoid this is to create your worldspace, save your mod, exit the GECK, reload your mod, and then edit the heightmap. This isn't explained anywhere in the GECK, but if you create a heightmap that is too low, the GECK will crash. One modder used to create heightmaps with a general offset of about 6000, but then found there's another bug that when you do that: trees don't generate LOD properly. So your heightmap really needs to be above something like 20-25,000 or so. If your landscape doesn't have trees (or objects that are defined as having tree LOD in the GECK) then you don't need to worry about it and 6000 offset works fine, BUT: the default LOD water height is 10500.

At some point you will try to navmesh your entire new worldspace. It's a really big worldspace with lots of cells, so it's a royal pain to navmesh each cell. Here you find out that the default settings for generating navmeshes will typically navmesh right across a fence, but will block on a piece of road. (Hey GECK, isn't it supposed to be the other way around? Arrgghh.) (As an aside, using heightmap generation mode works a LOT better). Oh, but wait, there's an automatic navmesh generator under the Regions section. Except that it is THE MOST BUGGY THING IN THE ENTIRE GECK. People have had it navmesh the entire area OUTSIDE of the area you want it to navmesh, completely leaving the area you wanted to navmesh untouched. Oh, and by the way, it completely rips out whatever navmeshing you had before in your mod, so hope you saved a backup somewhere because otherwise it's gone. Oh again, but don't worry. The auto navmesher doesn't always navmesh outside where you want it to. No, more often it just completely locks up with an infinite "Get Jean" popup error box that you can't get rid of because it just pops up again. Seriously, the error box just says "Get Jean". After some googling it was learned that "Jean" was the pathing coder and this was a debug message that was never removed from the GECK. The auto-navmesher also completely hangs up when it encounters an SCOL (static collection). The auto navmesher managed to navmesh a large (and very simple) landscape for a modder once. And only once. These days it's recommended you don't even bother to try and use it. Just navmesh cell by cell. It's quicker and less frustrating.

The list of bugs that you run into with worldspace generation goes on and on like this. Worldspace generation is MISERABLE. There's a reason you don't see many worldspace mods and many of the ones you do see use a flat worldspace with landscape objects like cliffs and rocks instead of a true heightmap to generate the landscape.

Many consider duplicating an existing worldspace and removing unwanted elements. This is fraught with it's own problems as well. Please see the Nexus forum thread Duplicating a world-space tutorial first, for an idea of the difficulties involved. Be aware that deleting objects from the world means you are removing references used by the game and possibly other mods. When you delete static objects like vehicles, the navmesh for that cell is typically done so that NPCs will avoid walking into the vehicle. If you don't fix the navmesh, you can walk right through where the vehicle used to be, but your companion NPC won't. It's a bit odd when you are walking down the road and your companion suddenly does a left turn and goes out of their way to avoid nothing, just because the navmesh says they can't walk there. Similarly, if you are being chased by a creature, it will also avoid the holes in the navmesh where the vehicles and other statics used to be.

Note that there is a 16 MB limit for objects in plugins. (Terrain painting and navmeshes can go above the 16 MB boundary.) If your plugin gets larger than 16 MB and you add an object or an Actor (NPC or Creature), your plugin will be permanently broken without any warning. It will crash the game and will crash the GECK if you try to load it. Since your overhaul is likely going to be a fairly large plugin, you might want to make all of your object/NPC changes first to determine if you need to split things up into multiple files, then add dialog and navmesh changes.

New worldspace creation is pretty much the same from FO3 to FNV, so tutorials for FO3 are okay for you to use. There don't seem to be any good tutorials. Most have pieced together bits and pieces from various tutorials and just plugged through it until they figured it out by trial and error.

Some tutorials make it sound a lot easier than it is. If you are making a very small worldspace, it can be done fairly quickly. But if you are making a larger worldspace, it becomes a very slow and tedious thing.

Also, the worldspace parts of the GECK are among the buggiest and most difficult to use parts of the toolset. Save often, and make backup files often just in case the GECK totally trashes your mod and you need to revert to an earlier version.

Here are some tips on getting past the first initial problems, which will give you an idea of how frustrating this can be. However, if all you need is the basic game worldspace but empty of content, you might consider The Community Wasteland Project which is an ESM file that has safely removed all NPCs, Creatures and scripted triggers from the game and its DLCs instead as an alternative to "rolling your own".

Assuming you want to make your own landscape from scratch, the first step is just creating the world space. Click on "World | World Spaces" in the GECK, and when that form comes up, just click "New" on the left hand side to give your new region a name, and fill in the blanks. Exit out of that, and save your mod, because the next step will usually crash the GECK.

TIP Center_On_Cell COC Markers

Thanks to pixelhate of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Keep in mind when navigating:
  • COC <InteriorCellName> (Center on Cell) is a Console command that will bring you ("Player") inside a Interior cell at the spot where the CocMarkerHeading (a GECK Markers reference) is placed.
  • COCMarkerHeading defines the placement and direction when the player COCs to the cell. You can only place one COCMarkerHeading per cell. If one is already in the cell, you won't be able to place another one.
  • COW <WorldspaceName> <X, Y coordinates> (Center On World) is a Console command that will place you in the named WorldSpace at the coordinates specified. It doesn't use any GECK Marker references.
  • COCMarkerHeading is a special Marker that (in GECK) when dragged into a cell defines the placement and direction of the Player when they use a "COC" command into the cell.
  • North Marker placed in a Worldspace defines that direction as cell North.

There's an auto navmesher, but that is buggy as all heck. Some have found that it works reasonably well on wilderness landscapes containing simple objects like trees and cactuses. It often completely fails when the cell contains SCOLs ("static collections") and doesn't work well at all if there are a lot of complex objects inside the cell. That means that you end up having to hand navmesh a lot of cells. If your new worldspace only has a few usable cells, this isn't a big deal, and you can navmesh all of them in a few hours easily. A worldspace has basically 64x64 cells, which is 4096 total cells. You can auto navmesh three or four cells per minute, and once you get experienced at navmeshing, you can probably finish a fairly complex cell in a few minutes. If you figure an average of one cell per minute (being a mix of hand navmeshed and auto navmeshed), that's 4096 minutes to navmesh the entire worldspace. That works out to a bit over 68 hours. If you navmesh for three hours per day (because you have a job or go to school or do something that takes up the rest of your day) then it will take you roughly 23 days to navmesh the entire worldspace.

The auto navmesher will often not navmesh across roads. If you set the auto navmesher to "Height Map Only" mode, it works a lot faster and a lot better, and will usually navmesh across roads just fine. However, it will usually navmesh through fences. So be prepared to hand navmesh any cell that contains a road or a fence.

Use the "b" key in your "render window" to show "cell boundaries". You'll want to arrange buildings and structures and other things so that you can easily do the navmeshing. You wouldn't want a building's door to be straddling a cell boundary, for example.

There's also an "auto generate navmesh" button under "regions". Don't use it. It is very very very very broken. Some have made it work under some circumstances but it is incredibly buggy.

LOD generation is similar. It's not too bad if you only have a few cells, but for a large worldspace it takes darn near forever.

This is why you need to decide ahead of time if you want to create a tiny worldspace that you can finish in a short amount of time, or if you want to create a major sized worldspace that will take you a huge chunk of time to complete.

There's a reason that you don't see too many mods with worldspaces on the nexus. It's difficult to figure out, and buggy as all heck. It also takes a huge amount of time, which is why the few worldspaces that you do see tend to be small and simple. It is not uncommon for a single mod creator to spend so long working on a mod with a new worldspace that the vast majority of that game community has moved on to another game.

One other thing. If you do try to make a huge worldspace, you can use the regions to add a lot of landscape items like cactuses and trees. This is a huge time saver, but be forwarned. If you have ever clicked on an object in debug mode, you'll notice that the object has an 8 character ID, something like 4100D236 (a completely made-up number). This is a hexidecimal number. The first two digits will be the number of your mod (41 in this case), aka its mod index. Fallout gets 00, and the different mods are assigned numbers as you add them into your mod list. On a system with the official DLC, "Dead Money" is 01, "Honest Hearts" is 02, "Old World Blues" is 03, etc. You can see the mod index in most mod managers. So if you add another mod and it ends up loading before this one, that 41 could get bumped up to 42, for example. Now here's the important part. That xx00D236 part means that you have a six digit hex "form" number for the ID. This corresponds to the file offset in your mod. The largest 6 digit hex number you can have is FFFFFF, which is 16,777,215. (The FF mod index is reserved for "save game" file changes to the environment, such as inventory and moved objects.) A worldspace will take 10 to 12 megs just for the heightmap and landscape, not including navmesh and texturing. If you go over the 16 meg limit and add an object, you brick your mod. The GECK will give you no errors at all when it saves your mod, but when you try to load it again, it will lock up the GECK. That means you can't use the GECK to fix it. Hope you have a backup of your mod from earlier somewhere, because that's the only way out of it.

This is important enough to put it another way: What this means to you is that you need to watch your file size. Once you get over 16 megs, you can't add any more objects or you will break your mod. If this happens, the game can't load your mod and the GECK can't load it either, so if you didn't save an earlier copy of your mod somewhere, it's forever broken. Fallout.esm is significantly larger than 16 megs, so Bethesda obviously has some way of packing the data in so that they don't get this problem. But the GECK that you and I get to use can't add objects to a mod that is more than 16 megs in size. You can paint landscapes and add navmeshes and such which can take your mod well beyond the 16 meg limit, but as soon as you add an object to a mod that is larger than 16 megs and save your mod, you just broke it. The GECK won't tell you that it is broken, either. You won't find out until you try to reload your mod in the GECK or if you try to use it in the game. Authors have had to split mods into multiple files to get around this.

(Repeat the mantra: save early, save often, keep backups.)

If you are making a small worldspace, then you probably don't have to worry about this at all. If you are making a large worldspace and are adding tons of landscape objects (cactuses, trees, etc) then you can run into this limit and it will break your mod. So if you are going to do a worldspace, do the landscape first, then add all of your objects, NPCs, creatures, etc. to it, and THEN do the navmeshing and texturing last as those don't care about the 16 meg boundary issue.

TIP Finding cell North in GECK

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
When you first open a cell in the GECK, the camera defaults to pointing North. You can place a North Marker in a Worldspace to set that direction as North instead.

If you have rotated your view of a cell around and you aren't sure which way you are facing, the "<Up cursor>" key will always move you North, the "<Down cursor>" South, the "<Left cursor>" West, and the "<Right cursor>" East. So just moving around a bit with the cursor arrow keys can help you re-orient yourself.

The next step is to create a "heightmap". A lot of people skip this and make small, completely flat world spaces, and use things like cliff objects to do the majority of their landscaping. That's okay for things like a small base surrounded by mountains or something like that, but if you are trying to create a town or something it looks amateurish.

Warning - If you basically default the heightmap settings, it will crash the GECK. Seriously, sometimes it seems like the GECK is a Vault-tec experiment designed to test modder frustrations. The reason for this is that the GECK doesn't like it if the landscape is too low. So the first thing some do is create a random landscape that doesn't have much randomness to it, so that what it ends up doing is creating a basically flat landscape. The settings successfully used under the random generator are a frequency of 100, an amplitude of 50, and a base offset of 6000 if there will be no "tree LODs" or 25,000 if there will be. (Though bear in mind the default LOD "water level" is 10500 if you are planning on any underground structures. It seems the "Default Water Height" and the "Default LOD Water Height" need to be the same. The "Default Land Height" is -2048.0 and that appears to be sensitive to changes, and is best left alone.) The base offset is extremely important since if you don't set it high enough, the GECK crashes.

TIP Generating Worldspace LOD

When either creating or editing a worldspace, you need to generate LOD ("Level of Detail") mesh and textures to reflect those changes. But first you need to be sure you understand the difference between VWD (View While Distant) and LOD (Level of Detail). See the LOD/VWD Overview page on "The Elder Scrolls Texture Guide (TESTG)" site. (The "FNV" version of "TES4LODGen" mentioned there is FNVLODGen, and along with Ultimate resolution landscape LODs and generator TES4LL can be used as an alternative to creating LODs in the GECK. The "LOD/VWD Overview" page provides a TES4LL process sequence.)

The following articles provide guidance on using the GECK to generate LOD files:

The folders used for LOD output files are laid out on the description page of "FNVLODGen". The key to finding those for yours would be looking for subfolders with the name of "yourworldspace".

If you add any VWD/LOD textures (such as NMC or Ojo Bueno or your own custom ones) to your game, please see the 'Checklist Item #15 & 16' entries in the wiki Fallout NV Mod Conflict Troubleshooting guide regarding the need to run both TES4LL and FNVLODGen. Also recommend you read the 'LOD/VWD Texture Packs' section of the wiki FNV General Mod Use Advice article first.

TIP Static Water goes into Interior cells only

Thanks to madmongo and SnakeSlippers of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
Don't ever place static water in exterior cells. Even after deleting, the water is still there. Use that in interior cells only.

You can change the water heightmap of individual exterior cells, but ALWAYS make a backup copy of your mod first as this can be buggy and can totally screw up the water heights for your entire mod. Name or store your backup copies so you know what you did in each one. Don't rely solely upon timestamps.

Some folks use things like "geological survey data" to generate their heightmaps. See the last couple of threads in the list of tutorials below or poke around on the net.

If all is well so far, save your heightmap and save your mod. If you didn't restart the GECK earlier, chances are that right here is where the GECK will crash. The second time through this it usually works.

Now re-open your heightmap, and use the editing tools to create your mountains, rivers, lakes, etc. You can play around with the default water settings in your worldspace to get the water to line up with where you want it on your landscape. If you used a base offset of 6000 when creating the heightmap, a water height of about 3500 tends to work fairly well. When you are editing the heightmap, make very small changes. If you make changes that are too drastic, you basically tear the landscape and the GECK can't figure out how to fix it and it ends up with a broken landscape that either crashes the GECK or crashes the game or both.

What you probably have at this point is a landscape that has mountains and plains and rivers and lakes and whatever. Save your heightmap and save your mod. If you were to go and look at it though, it will probably be very flat and unrealistic looking. You can add in some randomness to your heightmap to fix that. The settings that some tend to use are a frequency of 2000, an amplitude of 200, a base offset of zero, and this is very important, make sure you click "additive" and "subtractive". If you don't check the "additive" and "subtractive" boxes, it will create a new random heightmap instead of just adding a bit of randomness to your existing heightmap. Now you should have something that looks a lot more realistic. Again, save your mod. The GECK likes to crash for no good reason a lot when doing worldspace stuff.

Now you can go to your "cell view" form, and change "interiors" (where it says "world space") and select your new world space. It will put you right in the center of your new world space. And you'll run into yet another GECK bug. If there is nothing on the landscape, and the GECK hasn't ever focused on any kind of object, the GECK will usually display water instead of your landscape, so you end up looking at a big solid grayish-green blob on your render window instead of looking at your landscape. If this happens to you, select "interiors" in the "cell view", double click on some static object, let the render window display that cell, then go back to your new world space. Sometimes just moving around using the arrow keys will get the water blob to go away once you move far enough to change cells. Once you have objects in your new worldspace you won't have this problem any more, as long as you first go to an area that has objects when you select your new worldspace when you start up the GECK.

Now you can tweak and paint the landscape to your heart's desire, and add objects and do all of that fun stuff. Unfortunately, you have only two basic tools for editing landscape. You can use the "landscape editing" function in the "render window", which limits you to a maximum brush size of 15, or you can use the "heightmap editor". If you are trying to make something the size of a small pond, the "landscape editing" makes you feel like you are carving out Mount Rushmoor using a hand chisel, and using the "heightmap editor" makes you feel like you are trying to do brain surgery with a chainsaw. There's nothing in between. The "heightmap editor" is also a bit quirky. It tends to leave big black square splotches just outside of the view on your render window, and those don't go away when you close out the heightmap editing box. Even if you move away from that area using the arrow keys, the splotches stay there. You can only make them go away by selecting another area from the cell view and then going back to the area where you were.

Buggy buggy buggy. That's the GECK.

TIP Terrain Editor missing texture

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
When you have the GECK PowerUp tool installed, you may encounter the following error message upon selecting the terrain editing tool: 
Icon file "Textures\Landscape\Default.dds" not found.

You can safely ignore this message. There is no such file, and it does not appear to cause any problems.

Copying interior or exterior cells between plugins

Reusing cells from one plugin to another is a great time saver, but you have to bear some things in mind.

  • The Trick is to make your new ESP first, only dependent on the main master file. Save and close it.
Best way to make a new ESP file is to drop something in the "Render" window, then save and name the file. So loading a cell first is needed. Suggest "Wasteland cell / Good Springs" if you don't have any in particular in mind. You can of course delete that cell later from your ESP if it's not needed for your purposes.
  • Then open your preferred tool adding the other files from which you want to use assets, (with your new .ESP as the "active file" in GECK).

At the moment we don't know of any way to duplicate exterior world spaces in GECK. You can copy cell records between plugins in FNVEdit. In order to change the FormID of the duplicated Worldspace, you need to work from the bottom up: changing the FormIDs of the children cells before the parent.

You can use either FNVEdit or GECK to duplicate interior cells, but this is how to use the GECK. In the GECK, load up the ESP with the cell you want but don't make it "active", while loading the ESP that you want the cell to end up in (i.e. your new ESP) as the "active file". Then just right click on the desired cell in the "source" plugin and select "Duplicate Cell". It will give the duplicate a name of whatever the cell name is plus COPY (or something like that). If there are any objects in the source cell that are unique to the mod you are copying it from or come from one of its masters that you don't want to include, delete those out of the copied cell. Then save your "active file" ESP. Do not add items to the cell or do anything else other than duplicate it or the GECK can sometimes get confused and it will mess everything up. Just duplicate the cell, remove anything you don't want in your "active file" ESP, and save. That's it. Exit and reload, and maybe rename the cell so that it doesn't have the word COPY in it, and then edit it to your heart's desire.

The GECK only includes a file as a resource if it's a "master file". If you load an ESP, the GECK won't treat it as a master (unless you have configured the GECK PowerUp to allow ESPs to be "masters"). The GECK will automatically add any master files that the other ESP loaded since those will all be loaded into your new editing session when you load both ESP files.

This will end up including "master files" from the "original ESP" in your "new ESP", so if you don't want them: just delete them from the GECK data screen when you select your mod for loading. However, if you accidentally left in something dependent upon one of those masters in your copied cell, deleting the master will screw up your mod.

Here loading your new ESP with the copied cell(s) in FNVEdit first will enable you to safely see if there are any unexpected "master files" in the "File Header" record list of masters. It's "Clean Masters" command won't remove a "master file" as long as some record depends upon it, which is not true for the GECK.

  • Check for errors in FNVEdit by Right-clicking on your plugin, and selecting "check for errors" from the context menu that then appears.
If there are any remaining dependent records (evidenced by a master you expected to be dropped still being present in the plugin's "File Header" record) you can use the FNVEdit script "List records referencing specific plugin.pas" on that plugin to list them in the log window so you can remove them.
  • Once that is done, Right-click on your plugin and select "Clean Masters" from the context menu.
  • "Sort Masters", which will order them in the plugin according to your current "load order".
  • Check the plugin's "File Header" record for any remaining unexpected "master files".
If there are any, repeat the process. Otherwise, exit and save.

There are a lot of things that FNVEdit and the GECK can both do, they just do it differently. Which one you choose to use is a matter of personal preference, but sometimes one has capabilities the other lacks.

Additional Material

The following is not intended to be a complete list, but rather a starting point on articles and videos specific to FNV to assist new mod creators in getting started. Bear in mind that articles in older games may also be of assistance with basic concepts as long as you adjust to the peculiarities of the syntax in the GECK.

Rather than "reinventing the wheel", your life will be a lot simpler if you take advantage of resources made available for your use by the modding community. They also provide useful examples of correctly created elements which can supplement tutorials. These are generally listed on the Nexus in the Modders resources and tutorials category. Check back often. Please respect the various authors usage permissions, and give credit where due.

These articles are not necessarily intended as "tutorials", but do convey useful information to the mod creation process.

Game Time

Time in the game is tracked in "Global Variables" (type: GLOB). The use of "Global Variables" (e.g. GameHour) and GameTime functions such as GetGamesDaysPassed can get tricky. (Using this GetGamesDaysPassed function is preferable to using the GameDaysPassed global variable, which is highly unreliable.) It is necessary to carefully examine the descriptions and examples to understand how each works. They are not as "obvious" as one might think.

The game engine originally stored "time" values as type "float" (i.e. "single precision") values. But when returned in various functions they were often converted into type "short" (i.e. "integer") values. This caused problems, which made it necessary for "New Vegas Script Extender" (NVSE) to intercept and implement as "double precision" values and it's own functions to correct;y deal with returning the proper values. So you need to be aware of these differences when choosing how you deal with time.

(It's "Game Engine fixes" such as these that make NVSE essentially a requirement. As many of the plugins essential to a stable game (such as "New Vegas Anti-Crash", aka NVAC) require NVSE already, don't shy away from using it's functions instead of the vanilla ones. Virtually every mod user should already have it installed.)

"Global Variables" are considered base types in the GECK, and can be viewed by clicking "*ALL" in the "Object" window, clicking the "Form Type" column heading, then scrolling to view all items of type "GLOB".

As with all base types, you can create your own global variable just by renaming one of these to something that is unlikely to conflict with other mods (typically by prefixing it with the name of your mod), and clicking "yes" to create a new object.

In order to modify "Global Variables", you must open the "Global" window by clicking on "Globals..." under the Gameplay menu. The "GLOB" Form type doesn't have its own dialogue window, so double-clicking on a Global in the "Object" window will result in an error.

Alternatives

If the variable will only be used within one script, typical script variables are the best choice, as they have a scope of only that script: variable naming conflicts are not possible.

If the variable will be used within a single quest, using quest variables should suffice, as then the variable will not need storing before or after the quest.

In some cases, you could create a persistent reference which would store the value in a property.

However, where a variable will need to be used across multiple quests, cells and scripts, a well-named global variable is probably the correct choice.

Global variables for In Game Time

  • GameDay: Returns the current in-game day (day of the month: 0-31).
  • GameDaysPassed: Returns the amount of days passed since the beginning of the game: i.e. 10/13/81 (October 13, 2281).
  • GameHour: Returns the current in-game hour (0-23).
  • GameMonth: Returns the in-game month (0-11).
  • GameYear: Returns the in-game year.
  • Timescale: Number of in-game minutes that passes in 1 real minute. Default: 30, typically expressed as a ratio of "30:1". IMPORTANT: Please see Issue: Can Timescale adjustments break certain quests, etc.? before using other than the default Timescale value of "30".

Notes

  • While GameHour and GameDay are defined as short, they return float values. For instance, at 2:30 AM, GameHour has the value 2.5.
  • Remember that an hour is about 0.041667 (1/24) of a day. So using GameDaysPassed for anything other than day tracking may get awkward.
  • Care must be taken when mixing use of GameDaysPassed and GameHour in a script. When crossing midnight, GameDaysPassed may indicate the start of a new day, while GameHour is still in the previous day. For example, if GameDaysPassed is 6.04 (6th day at 00:01), then GameHour should be about 0.02 (00:01). But GameHour may indicate something like 23.90. This situation can exist for multiple frames.
If all you want to know is if it is a new day (strictly meaning that the 12:00am boundary has been crossed), save the current GameDaysPassed into a SHORT variable (e.g. lastDay) and then when you want to do your comparison, create a SHORT (currentDay) and set it to the current GameDaysPassed. If (currentDay - lastDay) >= 1, then a day has passed. By storing GameDaysPassed in SHORT variables you trim off the factional hours that live in the decimal places. If you use floats instead of SHORTs you will essentially be checking if "24 hours has passed" rather than, "is it the next day."
- See the GECK entries on List of Global Variables and Special Variables.

NAM files

By default there are "< DLC >.nam" files for all the DLC ".ESM" files. These files cause the game to load those DLC even if they are not "active" in the "load order". If any ".nam" files for specific DLCs are not found, that DLC is not automatically activated (enabled). (It is recommended you rename rather than delete them if you don't want a particular DLC to automatically be loaded.)

Normally, when starting GECK and opening the "File" menu it has automatically "checked" (enabled) the DLC ESM files with "< DLC >.nam" files for loading, but not the "FalloutNV.ESM". There isn't a ".nam" file by default for "FalloutNV.ESM".

The "nam" file contains nothing more than the common name (e.g. "Dead Money") of the respective DLC. When a plaintext "FalloutNV.nam" file with "Fallout New Vegas" as content is created, "FalloutNV.ESM" will be automatically checked (enabled) in GECK's "File" menu just like the DLC.

3D Model and Texture resources

Note that often the models on these sites tend to have very high polygon counts, which the NIFTools either completely choke on or if they do handle it, end up just killing your game performance. Use with caution.


Plugin File Header and Record information by game

Thanks to Sharlikran on the "Afkmods" site Wrye Bash - All Games thread for the following:

"While these pages still provide the best public documentation of the Oblivion file formats, all mod makers should also be using Tes4View, which currently provides the most complete and correct understanding of the mod file format in a readily accessible manner." - UESP Wiki (on the Oblivion page for the TES4 Mod File Format). [These days, instead of the Oblivion tool TES4View, use the game-specific version of xEdit instead (e.g. TES4Edit, FNVEdit, etc.).]

"One of the things about those Wiki pages is the format of the 24 bytes doesn't change much. In my opinion you really only need to compare Oblivion, with one of the other games. About the only thing that changes is the Flags because they are record specific. The TES4 header is defined in the following Data which is a group of subrecords. A GRUP or Top Group also has 24 bytes and indicates the beginning of what will follow. Bethesda's internal tool sometimes introduces duplicate Top Groups which are combined in xEdit. Each record starts with 24 bytes, and then the subrecords follow. After the 24 bytes is the size of the data that will follow from what I understand. From what I know Oblivion is 20 bytes, and that's about the only difference. Zilav [of the xEdit team] only mentioned the other day when I asked that Oblivion doesn't have a Form Version because it was the first use of the new format."

Fallout Record Types

Sources:

  1. Tes5Mod talk:Mod File Format contains comparative counts of use by type between FO3 and FNV, omitted below.
  2. TES5Edit/fopdoc as of 2 Jun 2014 documents the FO3, FNV, and FO4 plugin file formats known to the xEdit team. Only those pertaining to FO3 and FNV are listed here.
FOPDOC has each record on a separate GitHub Flavored Markdown page with sub-record type information. This should be referenced for further details like flag values. (Markdown format is quite readable by the average user with an ordinary plaintext editor.)
  • ACHR = Placed Character/NPC Reference
  • ACRE = Placed Creature Reference
  • ACTI = Activator (usually something like a light switch, plant, etc.)
  • ADDN = Addon Node (Particle Effect)
  • ALCH = Ingestible Potion/Medicine (Alchemy)
  • ALOC = Media Location Controller (FNV only)
  • AMEF = Ammo Effects (FNV only)
  • AMMO = Ammunition
  • ANIO = Animated Object
  • ARMA = Armor Components (Addon)
  • ARMO = Armor
  • ASPC = Acoustic Space (sound effects)
  • AVIF = Actor Value information
  • BOOK = Books (usually one that's actually usable.)
  • BPTD = Body Part Data
  • CAMS = Cameras
  • CCRD = Cards (Caravan) (FNV only)
  • CDCK = Deck of Cards (Caravan) (FNV only)
  • CELL = Cell (Areas that make up the game world. Each interior is in its own cell.)
  • CHAL = Challenges (FNV only)
  • CHIP = Gambling Chips (FNV only)
  • CLAS = Class
  • CLMT = Climate
  • CMNY = Caravan Money (FNV only)
  • CONT = Container
  • CPTH = Camera Path
  • CREA = Creature
  • CSNO = Casino (FNV only)
  • CSTY = Combat Style
  • DEBR = Debris
  • DEHY = Dehydration level (FNV Hardcore mode only)
  • DIAL = Dialog topic
  • DOBJ = Default Object Manager
  • DOOR = Door (Teleports or removes barrier, often used to teleport the player into cells.)
  • ECZN = Encounter Zone
  • EFSH = Effect Shader
  • ENCH = Enchantment (such as Stimpak's healing ability.)
  • EXPL = Explosion
  • EYES = Eyes
  • FACT = Faction (All NPCs and creatures are assigned to one.)
  • FLST = Form ID List
  • FURN = Furniture
  • GLOB = Global
  • GMST = Game Setting
  • GRAS = Grass
  • GRUP = Group
  • HAIR = Hair
  • HDPT = Headpart (Eyes, hair, beards, etc.)
  • HUNG = Hunger level (FNV Hardcore mode only)
  • IDLE = Idle Animations
  • IDLM = Idle Marker
  • IMAD = Image Space Adapter
  • IMGS = Image Space
  • IMOD = Item Mods
  • INFO = Dialog Response
  • INGR = Ingredient
  • IPCT = Impacts
  • IPDS = Impact Data Set
  • KEYM = Key
  • LAND = Land
  • LGTM = Lighting Template
  • LIGH = Light
  • LSCR = Load Screen
  • LSCT = Load Screen Type (FNV only)
  • LTEX = Land Texture
  • LVLC = Leveled Creature
  • LVLI = Leveled Item
  • LVLN = Leveled NPC
  • MAPM = Mapmarker (These are what tell you where a town, etc. is on the map.)
  • MESG = Message
  • MGEF = Base Magic Effect
  • MICN = Menu Icon
  • MISC = Miscellaneous item (such as random junk.)
  • MSET = Media Set (FNV only)
  • MSTT = Moveable Static
  • MUSC = Music
  • NAVI = Navigation Mesh Info Map
  • NAVM = Navigation Mesh (NavMesh)
  • NOTE = Note (which can be activated to show a text string, or the FormID of a Dialog record.)
  • NPC_ = NPC (Non Playable Characters)
  • PACK = Package (See the FOPDOC for the types of sub-records controlling when it gets triggered.)
  • PERK = Skill Perks
  • PGRE = Placed Grenade
  • PMIS = Placed Missile (FNV only)
  • PROJ = Projectile
  • PWAT = Placeable Water
  • QUST = Quest
  • RACE = Race
  • RADS = Radiation Stage
  • RCCT = Recipe Category (Collection)
  • RCPE = Recipe
  • REFR = Placed Object Reference
  • REGN = Region
  • REPU = Reputation
  • RGDL = Ragdoll
  • SCOL = Static Collection
  • SCPT = Script
  • SLPD = Sleep Deprivation Stage (FNV Hardcore mode only)
  • SOUN = Sound
  • SPEL = Actor Effect (Spell)
  • STAT = Static
  • TACT = Talking Activator
  • TERM = Terminal
  • TES4 = TES4 record format header. (Remnant of TES4:Oblivion.)
  • TREE = Tree
  • TXST = Texture Set
  • VTYP = Voice Type
  • WATR = Water
  • WEAP = Weapon
  • WRLD = Worldspace
  • WTHR = Weather


Factions Stealing and Ownership

Factions

This is a topic which gets complex in a hurry in application. Consider the following a broad overview.

Factions are "groups of members" with a relationship to other factions which affect the default behavior between members of those factions, and between members of the same faction. The actor's membership in a faction is processed by the game AI in determining another actor's reaction to them. The key thing is the relationship between factions, rather than between individuals. Actors will never attack "Friends" or "Allies". (See also Custom NPCs.)

You should not generally attempt to change anything about a faction's relationship with another faction. Instead create a new faction, decide which actors or other factions you want to be members of your new faction, and then establish their relationships with other factions. If you haven't fully mapped out those inter-faction relationships, things get "surprising".

Reputation is about how members of various factions (including your own "Player" faction) feel about your character. While related, they are separate issues. Note you can have both positive and negative reputation (fame/infamy) with a given faction at the same time. The "fame label" attached to your character is the result of a matrix of that positive/negative range, given in the referenced wiki article. "Reputation" changes only apply to the Player; not to other Actors.

Once you have "committed a crime" against one member of a faction, the entire faction is hostile to you (and your PlayerFaction). All NPCs react based upon the Actor's membership in a faction and that faction's relationships with their faction, including your "companions" who become part of the PlayerFaction when they are "hired".

The dialogue topics are a hierarchy of responses. The first response which tests ALL conditions as "true" is the response given. (If you are never seeming to get to your desired response, this is the first thing to check.) A Faction's "Hostile" reaction is right up there at the top, so they never get past it to say anything else. If you want them to say something before attacking, then you need to alter the response so that it causes them to bark (say something or make a noise to the player or another NPC) before attacking. If you want them to bark only in the first instance, then you need to add a "DoOnce" conditional test to that response, and have a standard "attack response" after it in the hierarchy. Speaking always takes a bit of time, and "sounds" process independently of other script actions (meaning once started they run until done while the rest of the script is processed), so you just put the bark line before the attack in the script.

It is worth noting that the game designers created separate "factions" for dialogue (e.g. "vSecuritronDialogueFaction", "vOuterVegasDialogueFaction", etc.) that could be tested for in dialogue conditionals in addition to the typical factions (e.g. "vStreetSecuritronFaction") for relationships with other factions.

Various types of armor have faction associations. Wearing any faction disguise armor will turn reputation with that faction to "Neutral". For example, if "Liked" by the NCR but wearing NCR "face wrap armor" (a "disguise armor"), that armor will return reputation with the NCR to "Neutral". It will go back to "Liked" once the armor is removed. Only certain types and sets (in combination with the correct helmet) of armor function as "disguises" in this manner. (See the table in this apparel page of "The Vault" wiki which identifies which vanilla armor counts as a disguise.) "Disguises" provide a temporary membership in their respective faction. Such "indirect" methods of changing faction membership and/or reputation are preferred to directly altering it for the Player.

TIP Companions and Followers
Thanks to miguick of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Assume you have some reason for determining who or how many Actors are accompanying the Player (or any Actor reference).

GetFollowers returns an array of any actors following the calling reference for whatever reason; not necessarily teammates if they are doing anything else besides following the reference.

If you want an array of the actors that are actual 'teammates of the player, you can use GetTeammates. If you only need the number of them, GetPlayerTeammateCount can suffice.

More broadly you can check every GetDetected Actor individually (JIP function GetDetectedActors returns an array of such), and determine if they are a member of the "PlayerFaction" using GetFactionRank. Other Faction Functions are available. Broadly there are seven major factions, and a host of additional lessor or specialized ones:

  • PlayerFaction
  • BrotherhoodSteelFaction
  • VCaesarsLegionFaction
  • GreatKhansFactionNV
  • NCRFactionNV
  • PowerGangerFactionNV
  • VWhiteGloveSocietyFaction

Use the GECK, with all the DLC (except the Pre-Order Packs) loaded, and you will find their Editor-IDs under "Actor Data | Faction". The "Users" column gives a good indication of how often that Faction ID is applied. The "User Info" property can reveal other factions that also belong to any given Faction or Actor.

TIP Faction Disguise system
"Faction Disguise" is treated as a "magic effect" spell: DisguiseFactionPulseActorEffect. It has "no duration", so it remains in effect until "dispelled". This is supposed to be done in the script when the disguise armor is unequipped. Sometimes this fails (bug). Try the console command: 
dispel DisguiseFactionPulseActorEffect

The 6 armor disguise factions are:

  • ArmorNCRFactionNV
  • ArmorVCaesarsLegionFaction
  • ArmorBrotherhoodSteelFaction
  • ArmorGreatKhansFactionNV
  • ArmorPowderGangerFactionNV
  • ArmorVWhiteGloveSocietyFaction

There are individual "FactionOutfitWarningScripts" to check if the Player is wearing faction armor and store the Player's actual reputation scores upon equipping; and restore them upon unequipping. These also check for companion reactions:

  • BrotherhoodFactionOutfitWarningScript
  • CaesarsLegionFactionOutfitWarningScript
  • KhanFactionOutfitWarningScript
  • PowderGangOutfitWarningScript
  • VMS18WhiteGloveSocietyFactionOutfitWarningScript

There are two scripts related to the DisguiseFactionPulseActorEffect spell:

Scn DisguiseFactionQuestScript

This code kicks in whenever players equip any faction disguises. We place an explosion with a custom enchantment on it [scripted spell effect: DisguiseFactionPulseActorEffect] that filters through all the references within its radius. When this pulse finds a Sniffer reference from the appropriate faction, it removes them from the disguise faction and thus potentially turns them hostile to players with whom they have less than stellar relations

Scn DisguiseFactionPulseScript

This script belongs to a spell effect [DisguiseFactionPulseActorEffect] that removes Faction Sniffers from the "magic" armor faction donned when players use faction disguises. The spell is set off intermittently, through a pulse, that filters the appropriate references within its radius. This radius is set to 25 (spell units), currently, and it's planned to reach at least 50 units. The pulse is placed on the player every two seconds, timed through a quest script that kicks off/on when players equip a faction disguise. - Jorge

Also, the script only addresses NCR relations. It'll eventually consider any faction that has faction disguises. [Editor - It now does, but only for those with "armor"; i.e. "not the WhiteGloveSociety".]

The following commands are present in those scripts. "Self" refers to a FactionSniffer Actor. Removing the Actor from the specific ArmorFaction means they are NOT fooled by the disguise, and will see the actual Player Reputation (Fame/Infamy). Example: 

Self.RemoveFromFaction ArmorNCRFactionNV
Self.AddToFaction ArmorNCRFactionNV 0

Stealing and Ownership

"Containers" and their contents have "ownership". This affects who can use items without it being regarded as "stealing". Cells have ownership as well.

  • First the ownership of the item is considered; if none is selected ...
  • Then the ownership of the container is considered; if none is selected ...
  • Then ownership of the Cell is considered.

If the ownership set on the cell is the only way any containers/items are being claimed, then you can just change that to none. But this will also effect any trespassing if it was something in use.

Opening "owned containers" and taking their contents or "owned" items found "lying around", and trespassing (to include opening specific doors with "owners"), have negative effects on the Courier's reputation with the owning NPC and the faction(s) in which they have membership.

You can set NPC container ownership to "Player" as long as it is not a container that another NPC will need to use. But you could use the faction ownership to let the player share the ability to use it, by making a new faction and adding the player to that faction. Anything with the faction ownership set will also count as stealing, unless the player is in the faction or has ally status with that faction.

Containers and "pickable plants" in exteriors can also have faction ownership set. The faction ownership is used so that all people in the faction will consider it a crime and react accordingly. Otherwise only the NPC set as owner would react.

Another way that will set ownership for a whole area is an encounter zone. It looks like the NV main file doesn't set any ownership with encounter zones anyway. But some of the DLC's and others mods may do that. Just mentioning as a place to check on ownership in the future.

Tutorials

Some tutorials are specific on making various kinds of Fallout NV mods with GECK. Others cover aspects of creating mods that are more applicable to mod creation in general. Always bear in mind that the game engine for Skyrim and Fallout 4 is different than that used for older Bethesda games like Morrowwind and Oblivion, and each game version of the engine is different in some way. However, each succeeding game built upon concepts implemented in earlier games, so they are still worth investigating. Your starting point should be the "Basic Tutorials" provided by Bethsoft as part of their "Construction Kits".

Bethsoft Basic Tutorials

Animation

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

TIP Animation Summary

Thanks to pluramon and RoyBatterian on the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following summary:

You'll find the animation options for weapons in the "Art and Sound" tab of the weapon in GECK; just double click on it.

As for the animations themselves, the Gamebryo engine uses the NetImmerse format, and there are two file types you should be familiar with:

  • ".nif" files store all mesh 3D data and shading properties, under control nodes.
  • ".kf" files store all animation data, manipulating the control nodes in nif files.

All ".kf" files associated with weapons share a naming convention that tells the game engine which specific action they animate. Generally the first three characters in the file name indicate the weapon type, followed by the action type, and lastly the variant tag. The exception are the "sneak" animations which begin with that prefix before following the same naming pattern as the rest. To throw in a few examples:

  • 2haattack3.kf = two-handed automatic weapon type, attack animation #3;
  • 2haattackloop.kf = two-handed automatic weapon type, fully-automatic fire attack animation;
  • sneak2hrattack5.kf = two-handed rifle weapon type, sneak attack animation #5;
  • 1hpreloadr.kf = one-handed pistol weapon type, reload animation 'r';
  • 2hhattackright.kf = two-hand handler weapon type, attack animation 'right'.

Each weapon animation has two versions - default (3rd-person) animation and 1st-person animation. Both share exactly the same name, only located in separate folders. From limited experience with weapon animations, it appears most 1st-person weapon animations have little to no noticeable effect in-game. The default animations are used most of the time, whether it be 1st-person or 3rd-person.

Some weapons (e.g. the "minigun" and "flamer") can utilize a "looping" sound file with the animation. The FO3 wiki article Minigun sounds describes the basic process. Getting the "loop points" to work correctly can be difficult. (The mod Automatic Weapons Fix is known to cause a problem with the ending "release" loop point.) The (free) sound editor Wavosaur is recommended as the only one which seems to work reliably with the GECK for this purpose. Also make sure the sample positions are correct in the sound form; GECK only sets them when making a new sound.

All vanilla ".nif" files and ".kf files" are packed in the archive Fallout - Meshes.bsa. After you have installed FOMM or by using BSAOpt, you will be able to extract them, and then edit them.

(See the Skyrim thread BSAs and You for details about the pros and cons of "Bethesda Software Archives" (BSAs), but bear in mind such files in previous games, like Oblivion, FallOut3 and Fallout New Vegas, don't have "strict order" like in Skyrim. Games prior to Skyrim don't support overriding of assets in archives using other archives; only loose files can. If the same resource is contained in several BSA archives, those games won't use it from the last BSA on 100% of occasions. They may grab the resource from a random one of the BSAs containing the same file.)

WARNING! Do not unpack BSAs directly into your game "Data" folder; potentially overwriting any mod files. The tools don't ask you to confirm the overwriting, either. All the hair textures unpacked to "loose files" will go through the head models in that case; because that's what happens when hair is not packed in a BSA. "Best practice" is to unpack to a unique folder (they are large: 1-2GB) and manually drag the desired files to the appropriate "Data" folder as needed.

Default animations are located in the folder "meshes\characters\_male", while their 1st-person counterparts are found in "meshes\characters\_1stperson". You will also want to extract a skeleton to work on. You will find humanoids use the one in "meshes\characters\_male\skeleton.nif". All ".nif" files that refer to a vanilla ".kif" animation look for them in the same location, so it is common for "animation replacements" to be placed in those same locations. "ArchiveInvaildation will then cause the "loose" files to be used instead of the ones in the BSA. If the replacement ".nif" files points to a different ".kf" file (which might be placed under it's own folder), every mod that uses that ".nif" will consequently use the same ".kf" file.

What's left is importing the skeleton.nif, along with the ".kf" animation file you wish to edit, to your choice 3D modelling software, then you can finally get to work.

When done, you will need to export the ".kf" file back to the folder from whence it came. Some post-editing with NifSkope may be necessary, since some properties are not always exported correctly (this applies to Blender; it may not be necessary if you're using 3DS Max/Maya). More details on importing/exporting/post-editing can be found (Blender specific) Creating a Character Animation, and (3DS Max specific) Animation Options. Both pages contain relevant info, regardless of which you use.

TIP Animation Exporting

Thanks to uhmattbravo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
You can't properly Import/Export Texture animation in Blender. Set up for such animations are best done in NifSkope. See the Material and Texture Animations in NifSkope - Tutorial by Pixelhate, which should pretty much be considered the authority on the subject.

First be sure to set the "bone priority" in Blender. To set your bone priorities open up a scripts window in Blender, select scripts | object | set bone priority. You'll need to have a bone (or all of them in a lot of cases) selected first. (For instance, you'll likely want all the bones in a special idle to be priority 25, but a lot of attack animations (as another example) use different priorities for different bones.)

The 90° rotation happens when you import a skeleton and/or animation into Blender. One of it's quirks. It's fixable. You can't rotate the rigging bones themselves to make the actor turn in game. The "armature" is all the bones together and is named the scene_root. The armature and collision together are called the "skeleton" and it won't actually rotate in game even though it appears rotated in Blender. Moving the Bip01 bone in any way except up and down, (including rotation) will move all other bones with it.

If you need to jump or move something up or down in an animation, use Bip01 Non Accum. It controls vertical movement like Bip01 controls the horizontal.

Carefully check the "start" and "stop" entries for the animation type (e.g. "1/Start" and "44/End" instead of "idle_start" and "idle_end") on the "Anim" text are correct before exporting because NifSkope translates it into "text keys".

To export the animation from Blender, basically click to use the Blender game defaults, click "animation" only, don't touch the "collision" or "shader" options, and while it may not actually make a difference, use the bsfadenode for animations. See also TIP: Exporting a mesh from Blender for import into GECK.

After exporting your animation from Blender as a ".kf" file, make sure your "animation text string" in NifSkope is set correctly (e.g. change the Cycle_Type default "Clamp" to "Loop" for repetitive movement (e.g. "mtforward") or combat animation (e.g. "2haaim"), and change the group name (the string at the top). The "group name" is usually exported from Blender as the filename (e.g. "mtforward" or "2haaim"), and needs to be changed to a name the game will recognize, such as "Forward" or "Aim". Apparently you can add on to the end of this "group name" for a special idle (e.g. SpecialIdle_Bark).

When saving the file in NifSkope, it defaults to ".nif", so for animations you need to be sure to choose ".kf" from the drop down menu list of choices.

TIP KF edit rotates Actors 90 degrees to right

The following is taken from the "First Aid for frequent problems" section of the Avoiding Blender animation pitfalls Nexus Wiki article.
Any kf that is edited usually results in the Actor facing 90 degrees to the right. It does this even when the kf is imported into Blender and then immediately exported without changing anything.

This is an issue that can be fixed in NifSkope. Apparently Bip01 will generally have a rotation applied to its "Rotation Quaternion" (Euler R) within its "interpolator".

To fix it:

  • click on the root NiControllerSequence in the "Block List",
  • then expand the submenu "Controlled Blocks" in the "Block Details",
  • then find and expand the "Controlled Blocks" Bip01,
  • click on Interpolator value,
  • then set Rotation Quaternion and change to "0, 0, 0".
  • DO THE SAME WITH 'BIP01 NonAccum' and change to 90.

Note the article has both an "easy way" and a ""hard way" if the easy version doesn't work.

TIP Play an Animation

Thanks to DoctaSax of the Nexus Fallout "New Vegas" forum for the basis of the following:
The basic command/function to force an Actor to play an animation is PlayIdle: taking a string argument with the name of the idle to play. JIP LN NVSE adds the alternate, extended function PlayIdleEx which takes the Editor-ID instead. It also can determine which of an "AnimGroup" to play based upon conditions the same as the PickIdle function. See the linked commands for details.

AnimGroups are groups of animations that can be played on actors and creatures as well as some objects. Only one animation can be active at a time.
Note that some combat animations can only be played while the actor is in an "alerted" state (has a weapon drawn; see SetAlert).

When you want an Actor (even the Player) to play a specific animation, make sure you pass the reference to a "ref" variable first. For example: 

ref rActor 

set rActor to PlayerRef
if rActor.IsActor
   rActor.playidle TheDesiredAnimationName
endif

Note that in the GECK, a ref variable may store either a reference or a base form. Base forms may not be used as the calling reference to functions that allow this syntax, although it may be passed as the target if the function permits this. Hence the "IsActor" check in the example, while not necessary for "PlayerRef" (which is always a reference), is a good practice.

If you want to use the console to force a particular "idle" (such as when "posing" the Actor), you must be in "3rd Person View", go into "Toggle Free Camera" (TFC) mode, select or reference the target Actor, and then issue the "PlayIdle" command. Note that the skeleton (armature) in use must be compatible with that required by the animation or it won't work correctly.

Armor and Clothes

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

Note the KGTools web site containing the downloads is no longer accessible. Use the links on this site (adults 18+ only) instead.

TIP Bone Weighting

Thanks to madmongo of the Nexus Fallout "Discussions" forum for the basis of the following:
The thing in the game that makes clothes follow body parts is called bone weighting, which is a part of the mesh/NIF file. Bone weighting is created and modified using a 3D modeling program like Blender or 3DSmax. (This can also be adjusted using NifSkope, but that works best with values that are already present.) Every vertex on the NIF is weighted to the skeleton (aka the "armature"), so as the various skeleton bones move, the clothing moves with them. If you want a piece of clothing to move with an Actor's forearm, you weight that section of clothing 100 percent to the forearm bone.

Suppose you want part of a dress to fall straight down between the legs. The parts of the dress that you want to hang are normally weighted to the thigh bones and move with the legs. If you want those parts to hang straight instead, you need to remove their weights from the thigh bones and weight them more heavily to the pelvis. If you weight them 100 percent to the pelvis then they'll just hang, regardless of the leg movement. By weighing them heavily to the pelvis, but adding in a little weight to the thigh bones then they'll move a bit with the legs, which will look more realistic.

TIP Exporting a mesh from Blender for import into GECK

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following.

Be sure you are following the correct "subject" tutorial: either for weapons or armor/clothing, etc.

For importing armor and clothing, mostly using the default in the Nif tools doesn't create a problem. When you export, make sure you "select all" before exporting to ensure that you get the armor/clothing mesh as well as the armature (aka "the skeleton"). Blender only exports whatever you have selected, so make sure you do a "select all" before exporting.

You want "Use BSFadeNodeRoot" unchecked for clothing and armor. Don't remember what all of the numbers should be all over that screen, but generally click on "Creature" and the "Skin" (not cloth) on the export options. Better record the export settings for reference in case of issues. Not sure that having cloth active instead of skin actually matters much. Anyway, no matter what's checked or unchecked on that export screen, Blender has never output all of the shader flags properly, and there does not seem to be any way to get it to do so. For regular armor/clothing parts, the type needs to be set to SHADER_DEFAULT and make sure SF_SHADOW_MAP and SF_REMAPABLE_TEXTURES are both checked. For the any visible human skin body parts (arms, legs, etc) the type needs to be set to SHADER_SKIN and make sure SF_SHADOW_MAP and SF_FACEGEN are both checked. When these flags aren't available in Blender, then you have to set them in NifSkope.

Blender usually sets the rest of the flags correctly. When the shader flags are set wrong, the typical symptoms are that everything looks fine in the GECK but is invisible in-game.

Blender Mesh Editor

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

TIP Blender Clear the display

Thanks to M48A5 of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
People complain: "When I open or import a mesh into Blender, often all that shows up is a cube. No mesh, no shape, no object ... just a cube." The solution is simple, but not obvious.

When you first open Blender, move your mouse to clear the logo. Then press the "<a>" key twice to highlight everything. When all the items in the display have a pink highlight around them, press the "move" (<m>) key. A small grid will open near where you have the cursor. Choose any of the boxes (such as the far right one on the top tier) and <Left- click> the "OK" button. This will clear the display.

You can now continue to import or create what you want with nothing else in the display.

TIP New to Blender

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following.
The Blender Noob to Pro tutorial included in the Blender v2.49b package under the Programs and Tools section is a good resource.

Some tips that maybe aren't obvious when you are starting:

  • Make sure you select all before exporting. Blender only exports what you have selected. Also, make sure you have the export options set properly for what you are doing. If you are making a static, click on the static button (at the top near the middle) and then below that click on the button for the closest material type (wood, metal, etc). If you are making armor, click on "creature", because armor and human skins and creature skins are all basically the same thing.
  • Statics and clutter items need a collision mesh. Armor, clothing, and human and creature skins don't need a collision mesh, but they do need to be parented to an armature (aka "a skeleton").
  • Blender tends to export statics and clutter objects fine, but the version recommended as most compatible for FNV (v2.49b) doesn't seem to export the shader flags correctly for skins (armor, clothing, etc.). If you don't go into NifSkope and fix the shader flags, your skin thing (armor, clothing, creature, etc) will end up invisible in-game.
  • There are two different approaches used for UV mapping. One is to start with the texture and fiddle with the mesh to fit it, and the other is to start with the mesh and let Blender give it a UV map (unwrap using "smart projection") and then fiddle with the texture instead. Either way works, and which is easier depends on what you are making.
  • Start by making simple modifications to things. Here's an easy one to start with. There's a coffee table mesh ("SubCoffeeTableDirty01" in the GECK) that has an upper part and a lower part to it. Edit the mesh to get rid of the upper part, and edit the collision mesh to match, then export it and put it in a mod somewhere.
There are plenty of good tutorials out there. Blender is a full-function 3-D editing tool that can be used to make everything from cartoon movies to games, so it's got a lot of stuff in there with lots of examples and tips scattered around the internet. The Nexus Mods site has a wiki "category" devoted to Blender articles. Admittedly, there's a bit of a learning curve involved. But as long as you keep plugging away at it, you'll figure it out. It will seem easy once you get used to it.

TIP Blender version NIF export

Thanks to EPDGaffney and madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
When attempting to export a model from Blender as a NIF file, you get the "traceback (most recent call last):" error message box (after reporting one or more file lines) saying: 
"io_scene_nif.utility.nif_utils.NiError: non-uniform scaling not supported.  Workaround: apply size and rotations (CTRL-A) on '<object>'".

Most probably the issue lies in using a newer version of Blender. These are only minimally compatible with modding the older "Gamebryo engine" games.

  • You want to save your model from the newer version of Blender using ("Save As | Legacy Mesh Format") which outputs a legacy ".blend" file, and then open it in a v2.49b version of the tool. (See Image Tools above under the "Programs and Tools" section.) However, some things don't seem to export properly when you do it this way. The next bullet point is a possible way around such problems, but more likely you will just have to edit it. For this reason, many people prefer to create new meshes using Blender v2.49b since everything there just works (except hairs).
  • If you try to import a mesh from a different format (example: fbx) Blender v2.49b won't import it properly. (See TIP: Blender Import other Model Formats.) Instead import it into a newer version of Blender and then export as an "OBJ" format file. At that point you can (in the same newer version of Blender) just "Save As | Legacy Mesh Format" which outputs a legacy ".blend" file, as the mesh probably doesn't contain anything fancy that wouldn't export back to a legacy blend.
Most have a lot of success in general when importing "OBJ" files so they tend to use that as an intermediary format. But it isn't required when modding images from Gambryo games such as FNV and earlier. Note that an "OBJ" file is a lot like a "text" or "CSV" file and does not include a UV Map. You will need to generate a new one after importing before you can apply a texture. (See 4th bullet point in TIP: New to Blender.)
You should generally <Ctrl+A> (apply size and rotations) to everything before moving from Blender's default to another format, or rigging, or any big changes. It doesn't always matter, but it's a good practice. This needs to be done BEFORE creating "collision" or the scaling and rotation will cause the collision to not export properly. You can avoid that type of scaling in the first place by scaling in edit mode rather than object mode.

TIP Blender Import other Model Formats

Thanks to madmongo and user826 of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
The import options for other formats (example: fbx) or even newer version ".blend" format files into the FNV recommended version of Blender (v2.49b) are more limited in terms of results than with later versions of Blender. It is solvable with an annoying two-step process, but by using a later version of Blender that has an import option for the model format in question you can export it from that version as an "OBJ" file, then read the "OBJ" into v2.49b, which can then export it as a "NIF" file. However, it is worth noting that the NIF tools will fail in all kinds of ways if the model is too complex, so that may be an issue no matter how you do it.

Some have found that with a three-step process of, after importing the "OBJ" file into v2.49b, they then export it as a .3DS format file, and then re-import the .3DS file into v2.49b before then exporting it as a "NIF" file, they get a better result.

Collision

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

TIP Collision Impact Sounds

Thanks to pixelhate and miguick of the Nexus Fallout "Mod Talk" forum for the basis of the following:
In FO3 or FNV the impact sound of one material upon another (e.g. a shell casing falling upon the ground, a footstep on a wooden stair, etc.) is referenced in the collision object as "HAV_MAT" (Havok Material). But it doesn't handle the sound only; it combines it with the particles emitted when hit or shot as well as the decals associated. "Havok Material" will decide: The impact sound, the decal, the particle effect on impact, the sound when walking over a surface, and the colliding sound upon dropping, kicking, or grabbing an object. These are hard coded in the game engine and cannot be changed as far as we know. What the actor is wearing does not affect this; only the action being taken.

However, there is an INI file setting under "[Audio]": 

fPlayerFootVolume=x

which has a "x" float type value of "0.65" by default. Setting "x" to "0" will make your footsteps totally silent. You can alter it in scripts using NVSE's SetNumericINISetting command, as in: 

SetNumericINISetting "fPlayerFootVolume:Audio" x

Modders have found 96 "Havok Materials" which are combinations of different things mentioned before. 32 of them are the most commonly used by the game. Bear in mind that the names in the drop down list don't reflect the effect at all and can be misleading; so some experimentation may be called for to achieve the desired sound.

There's a drop down list in NifSkope or your preferred texture editor from which you can choose the most fitting one.

In NifSkope: open the "Block" list window, select the BHKCollisionObject, expand and look into each of the Nodes in the "Block Details" window.

Depending on the type and structure of the Collision, you should find one or two places where HAV_MAT is noted: double click on it to access the drop down list.

The material you set in the bhkRigidBody(T) overides any setting on the lower blocks. To get multiple "Havok Materials" with a single NIF, you have to nest multiple NiNodes and create a new bhkColisionBlock for each material you use. Check to make sure that the Layer and Layer Copy entries in your bhkRigidBody(T) and the Layer setting inside Data Layers in your bhkNiTriStripShape all match. Collision sequences are one of the few places in a ".NIF" file where the exact order is essential.

Don't forget that the "armature/skeleton" can have it's own HAV_MAT as well.

If you alter the mesh NIFs for your mod, you will have to include them in your package. There are basically two ways of doing so:

  • If the items are replacements for vanilla items and should affect all those items in game: place the modified meshes, keeping the original naming, in the "Data" loose folder reproducing exactly the original folder structure. These will then override the ones in the vanilla BSA file when "ArchiveInvalidation" is toggled. In that case, you shouldn't need to make any changes to your ESP/ESM files to have the new meshes active.
  • If the items are specific to your mod and should coexist with vanilla items: place the modified meshes, with new names, in a folder structure specific to your mod. You will then be creating new unique instances of the items using those meshes under that unique path and have to include them in your ESP/ESM files.

TIP Custom Object Collision

Thanks to madmongo and pixelhate of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Sometimes (even though you added "collision" to an object) when you initially place it on a shelf or other surface with collision just fine, it seems to fall at least partially through the surface when the cell reloads. If precisely aligning your object with the surface results in it sinking, try placing the object's Z-axis just slightly above the surface collision boundary and let it drop into collision with the surface. However, this only works if the object is a "Movable Static" based upon "Havok Materials", whose weight gives them "gravity" physics. (See also TIP: Collision Impact Sounds and the GECK entry for Object Palette.)

Part of the issue can be in how you created the collision mesh. For simple objects, just copy the mesh for your custom object from the vanilla object mesh. However, that doesn't work so well for complex objects with a complex collision mesh. It's preferable to use a simple box collision (which can be created in Nifskope instead of your "mesh editor"). For "havoked" or "grabable" objects: primative collision (sphere, box, or capsule) are preferable to avoid engine problems.

Conversions

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

Tools behind a "gated" "Adult (18+) Only site" in their "modder resources" section.

TIP Converting meshes

Thanks to madmongo and MA48A5 of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
Other games has meshes you would like to use; either vanilla or from mods. Which game is better to get a mesh from? Quality wise, and which game is easiest to convert said mesh to FNV? Oblivion, Skyrim, or Skyrim Special Edition?

If this is for your own personal use, there's no issue. If this is for a mod that you plan on releasing on the Nexus (or anywhere else), then you can't use assets from other games (period). They are copyright protected against "distribution" without permission. Not even from other Bethesda games in the same series like Fallout. (The exception is if the resources are already included in the "destination" game's files even though not used.)

You can only use assets from other mods if the mod author gives you explicit permission to do so (e.g. "this is a modder's resource").

That said, the game engine for Oblivion is fairly close to the game engine for FO3/FNV. They changed quite a bit for Skyrim. In any event, the skeletons for the player and for NPCs is different for any of the TES games. If you are porting over armor or clothing, you'll need to unparent the mesh from its original armature and reparent the mesh to the FNV skeleton, and of course reassign all of the bone weights as you'd expect from doing that sort of thing.

Statics don't have a skeleton so those will port much more easily.

Some things just won't port. Skyrim Special Edition, being 64-bit, is about impossible to convert to a 32-bit game.(See also Footnote [1]) So that leaves Skyrim and Oblivion. Skyrim armor that uses wings for example won't ever animate properly in FNV no matter what you do, because the FNV skeleton doesn't include wings. To make them work, you'd have to not only create a new skeleton/armature, but you'd also have to create a whole bunch of animations to go with the new skeleton. Otherwise, the best you can do is have static wings, which will look a bit funny. (There is one armature with support for moving wings by Deedes (2014) on Nexus with versions for FO3: The Skeleton and FNV: The Skeleton. You would have to re-parent the mesh to that armature.)

The New Clothing Body Style Converter Tool, behind a "gated" "Adult (18+) Only site" in their "modder resources" section, is designed to facilitate converting "armor" and "clothing" between different body types. However, it is still in "Beta" status since 2014, but does work with upper/lower body meshes and CBBE bodies. Note you will need either an existing Clothing Converter Lattice Library or to make one yourself.

Skyrim, being a newer game, has more detailed meshes in general, and mod authors have generally followed suit and have created similarly more detailed custom meshes. While this does make for higher quality 3d models, you can run into difficulty if you use a lot of higher quality models and textures in FNV since it's an older 32-bit game and it will only use 2 GB of memory by default. You can double that to 4 GB if you install the 4 GB patch, but that's as far as you can take it. (32-bits can't address any more than 4GB.) Your PC may have gobs more memory than that, but FNV won't use it. So it's very easy to run the game out of memory if you use high resolution textures and high quality models.

The recommendation is almost never use any textures larger than 1024 x 1024 pixels for FNV unless it absolutely needs a higher resolution due to the nature of the 3D model, just because of the memory issue. Also try to keep the triangle count (vertices) as low as possible. If you use a lot of 4096 x 4096 textures, your game will look prettier, but it's also going to crash a lot more often. (A 4096 x 4096 pixel image with 16 bit color resolution is 32 MB of data. If your screen is displaying 100 different models with textures that size, that's 3.2 GB of data just for the textures. Since a 32 bit program can only handle 4 GB of data, you can see how trying to display a lot of high resolution models is going to run the game out of memory very quickly.) The texture caching system in FNV seems to leak memory. The more you stress it, the sooner it will run the game out of memory and crash.

Footnote [1]: This statement deserves some clarification.

A lot of people seem to think that anything made with a 64 bit program can't be compatible with stuff made by a 32 bit program. That's not true. What matters is the data format that the programs use. If the format is the same, then the data will work for both the 32 and 64 bit programs. There's nothing special about the data created by a 64 bit program. It's just data. The key is in the format.

32 bit programs can't access more than 4 GB of memory. This is because 2 to the 32nd power is 4 GB, so if all you have is 32 bits available to specify a memory location, it has to be in the lower 4 GB of memory. This is why FO3 and FNV will never use more than 4 GB of memory (2 GB without the "4 GB patch") no matter what. The programs just aren't capable of accessing any more memory than that.

Skyrim SE is basically a 64 bit port of Skyrim using the updated Creation Engine that they developed for Fallout 4 (FO4). For porting objects from one game to another, we don't really care about that. What we care about is whether the NIF file format changed between Skyrim and Skyrim SE. There are plenty of programs which come in 32 and 64 bit versions, and both use the same data format to store their data if you select it, so you can use either the 32 bit or the 64 bit version.

For Skyrim SE though, they were playing around with the Creation Engine for FO4 development, and they made changes to the NIF format for FO4. It's not known how many of those changes (if any) were made to the NIF format for Skyrim SE, but if you can't easily import meshes from Skyrim SE into Blender (for example), it's because the tool set hasn't been updated to handle the data format difference. It's a data format difference, not a 32 vs 64 bit difference.

TIP Copying between plugins

  • The Trick is to make an ESP first, only dependent on the main master file. Save and close it.
Best way to make a new ESP file is to drop something in the "Render" window, then save and name the file. So loading a cell first is needed. Suggest Wasteland cell / Good Springs. You can of course delete that cell later if it's not needed for your purposes.
  • Then open the GECK adding the other files from which you want to use assets, with your new .ESP as the "active file".

Creature Creation

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

The process of creating a "creature" is essentially the same as creating a "NPC Companion", but without the "companion wheel".

TIP Locate Embedded Creature Weapon

Thanks to uhmattbravo of the Nexus FalloutNV 'New Vegas GECK and Modders' sub-forum for the following:
  • If you're using an existing creature, the quickest way to locate an embedded weapon would be to look at one of it's existing weapons in GECK.
  • If it came from a resource, and doesn't have any existing weapons, open the skeleton in Nifskope and look at the end of bones where it would be logical to fire from. Typically it's named projectile node or something similar, but it's also one of the few (if not only) bones that doesn't start with bip01.

Custom NPCs

Other sections have relevant information to this subject. The following "Tips" in particular are applicable.

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

"All Companions are NPCs, but not all NPCs are Companions." Both are discussed in this section, but please note and bear in mind the distinction when used.

TIP Actor height in GECK

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
If you want to make an Actor taller or shorter in the GECK, just modify their Height on the Traits tab. It's a little confusing because most Actors have a value of "0.00" for height, which just means use the default: "0.00" is the same as setting the height to "1.00" (told you it's confusing). If you set it to something other than zero, then it's a percentage scale factor. In other words, if you set the height to "0.95" then they'll be "95 percent" as tall as the default, or about 5 percent shorter. Setting the height to "1.05" would make them 5 percent taller (105 percent of normal height).

Body meshes can just be copied from FO3 to FNV (and vice-versa, but that's illegal "porting": so, personal use only). The skeleton is the same. The only thing that is different between the two games as far as body parts are concerned is "hair" and "hats", which end up rotated by 90 degrees between the two games. You can fix that in NifSkope by just rotating the part by 90 degrees. (See TIP: Head Parts Rotated under the "Custom Items" section.) You don't need to re-parent meshes to armatures and that sort of thing.

If you want your Actor to be about a foot shorter, that's about 84 percent at the default height of about 6 feet, so set their height to "0.84".

TIP AI Packages and Distance

Thanks to EPDGaffney of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Supposing you want your character to meet up with an NPC at some X-Marker location, but they aren't there when you "fast travel" to that location? You need to "teleport" them ,but you don't want to just make them "vanish". Here is one way to handle it.

In the "Dialog Result Script" where you make the NPC start using your "AI Package" to send them to that location, also start a "quest script" (e.g. "ThisQuestName"). This quest should have a processing delay of perhaps one second, and then check for the player to be a certain distance away from the NPC, and for the NPC to not be in the player's view ("Line of Sight": LoS). Once it's found that both requirements are satisfied, the NPC is teleported to the marker and the quest was ended. The quest is set to be stopped on proper completion of the AI package as well, in case it's still running.

The example script below uses the JIP LN NVSE function GetDistance2D, but it will work fine with the vanilla GetDistance function as well. 

Begin GameMode
    ; separation of player and NPC check
    If player.GetDistance2D refNPC >= 2048
        If player.GetLOS refNPC == 0
            refNPC.moveto refMarker
            ; maybe remove their AI package or add another one or whatever here?  maybe EVP?
            StopQuest ThisQuestName
        EndIf
    EndIf
End

Begin GameMode
    ; NPC near X-Marker check
    if refNPC.GetDistance2D refMarker <= 64
        StopQuest ThisQuestName
    endif
End

GetLOS isn't always reliable, so in some situations it may be preferred just to increase the distance; maybe use GetDistance3D. GetLOS has returned "true" when the NPC or object was at the very edge of the player's camera, and has not realized the player couldn't see the NPC. These both require an extreme circumstance, and most of the time it works fine; but it's best to test each situation.

TIP Avoid CTD previewing NPCs

To avoid crashing the GECK when you desire to "preview" an NPC, try opening their face "advanced" tab first. Then go back to one of the other tabs to check the "Preview Full". And when editing, click "Ok" for closing the NPC window, and then save the file instead of switching to the other tabs. Don't leave "edits" hanging when switching among tabs.

TIP Changing only one race

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Since the GECK is really an evil Vault-Tek experiment designed to test modder's frustration levels, one of the annoying things that it does is any time you even click on a race to view it, it marks that race as changed. Your mod will therefore not only create your custom race, but it will also overwrite any other mod's changes to the (Caucasian, Asian, Asian Child, Ghoul, etc.) races. If you don't want your mod to change these other races, when you start up the GECK: select your mod and select Details. Then select the races other than your custom race one by one, and press the <Delete> key. That will flag those changes so that they don't get loaded when you next load up the GECK. Now load your mod up as usual and save it. That will get rid of the extra races in your mod that you probably didn't want to modify.

Alternately, you can use FNVEdit to remove the extra race records. It's a bit less clicking and fiddling to do it in the GECK, but either way works.

TIP Companion Wheel

Thanks to madmongo of the Nexus FalloutNV 'New Vegas GECK and Modders' sub-forum for the following basic summary:
To make the companion wheel work, you MUST use the specific dialog options and variables shown in the Advanced Companion creation guide with Companion Wheel tutorial, as those are the options that the command wheel is expecting. Hopefully when converting an existing one, the original companion has enough dialog options that you can just copy the voice files to the dialog topics that you need. The tutorial has two quests, one that runs the companion and one that is only to hire the companion. You don't really need a quest to hire the companion. You can just do it through dialog if you really want to keep it simple.

Only one companion conversation option should be active at a time. In other words, if you already have a dialog option for the companion to follow you, you need to disable that conversation option and use the existing FollowersLetsGo topic instead. Similarly, if you have a wait option, you need to disable that and use FollowersWait instead. Using SetPlayerTeammate 1 in the hiring script is enough make the command wheel appear whenever you talk to the NPC, but the command wheel options won't actually work unless you use the Followers topics: such as FollowersWait, FollowersLetsGo, FollowersTrade, and the various FollowersTactics' options.

If the topics aren't showing up, check to make sure you have Top Level checked (upper right on the quest form) and make sure that the conditions are valid. Also, trading (OpenTeammateContainer) won't work unless the NPC is set to be a teammate (you've done a SetPlayerTeammate 1 on the NPC, which is usually done when hiring the NPC).

Make sure you have a line with SetPlayerTeammate 0 when firing the companion so the command wheel will no longer show up when you talk to them. The tutorial has the details of exactly which topics you need to use.

span id="Tip-CustomRaceFaces"></span>

TIP Custom Race and Faces

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
A custom race doesn't give you a custom face. (The head mesh is separate from the body mesh and the race textures. See TIP: Custom Race & Skin Textures.) It gives you a custom face blueprint that is further modified by all of the FaceGen stuff (see FaceGen: Heads, Faces, Hairs, and Helmets section) when you actually apply it to your NPC or player preset. If the custom race version is pretty close to what you want, then you'll probably want to adjust all of the sliders in both the Geometry and the Texture section of the NPC pretty close to the middle (zero) for each slider. There are some shading and tinting effects that always get applied whether you want them or not, which is a royal pain in the backside sometimes. Unfortunately, there's no known way to disable them.

TIP Custom Race and Skin Textures

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Suppose you want to add tattoos (or scars or whatever decoration) to the skin of a particular NPC or race. The body texture is controlled by the race, not by the mesh "NIF" file. You need to change this in the GECK. NifSkope won't help you here.

You are probably going to want to create a custom race for your character, otherwise the tattoo will show up on every NPC who is a member of that race.

To create a custom race, open up the GECK with at least the Fallout New Vegas.ESM file selected, select the Actor Data | Race tab on the left (in the Object Window), double click on one of the races to bring up the Race form, and now select one of the races to duplicate. (Note there is a "TestQACaucasian" race that is not otherwise used if you want to try out the process.) If your tattooed character is Caucasian, for example, right-click on the Caucasian race and select Duplicate.

Important Note: Since the GECK is an evil Vault-Tec tool designed to test modder's frustration levels, it's important to note that, for no other reason than it's evil, it has now decided to mark your original vanilla Caucasian race as modified, even though you haven't made any modifications to it, thus guaranteeing that your tattoo mod will conflict with any other mods that modify the Caucasian race. Stupid GECK. (See also TIP: Changing only one race.) Fortunately, fixing this is fairly simple. You can use FNVEdit to remove the modified Caucasian race from your mod, OR you can just save your mod, start up the GECK again, select Data, and instead of just selecting your new mod, highlight your new mod and select the Details button (at the bottom next to the Set as Active File button). There should be a RACE entry under the Type Column, with the Caucasian Editor-ID. Highlight that and press the <Delete> key. This will mark the modified Caucasian race as not to be loaded by the GECK. Select the Close button, and now load up your mod in the GECK. With that your mod no longer includes the modified Caucasian race, so save your mod, and now the unintentionally modified vanilla Caucasian race is permanently gone from your mod.

Now that you have a modified race to work with, again select Race on the left side and double-click on your "new race" to bring up the Race form with your "new race" selected. Make sure you do not even click on any other race, or that race will be marked as modified by your mod (stupid GECK). Again, if you goof up and accidentally click on another race, you can mark it as deleted during load and get rid of it that way, or you can clear it out using FNVEdit.

Make sure the Playable box is checked. As long as you copied from another playable race, it should be checked already.

Select the Text Data tab at the top of the Race form, and change the name of your "new race". If you don't do this, when you go to select your race during character creation, you'll have two races that both say Caucasian (or whatever race you copied) and you won't be able to tell which race is which. So change it to something like Tattoo Race or Caucasian Tattoo or whatever you want to call it.

If you are only modifying the female body texture, check the Female box down at the bottom where it says editing. (There is a box for Male and Female, and Male is checked by default.)

There are four textures that define a human body: The body texture (includes torso, arms, legs, and feet), left hand, right hand, and head. All of these except the head are found on the Body Data tab. The default human bodies use the same texture for both the right and left hand. For my tattooed characters, I have given them custom tattoos on each hand and therefore have ended up with unique textures for both the left and right hands. Just click on Edit and select your new textures. If you are only replacing the body texture, then you only need to modify the Upper Body Texture and you can leave the hand textures alone.

Another important note: You only select the main texture file (i.e. upperbodyfemale.dds) in the GECK. The GECK, and the game, assume that the normal map and skin files are in the same folder, and have exactly the same name as the main texture, except with "_n" for the normal map and "_sk" for the skin appended to the base filename. In other words:
If your tattooed texture is called upperbodyfemale.dds:
  • the normal map has to be upperbodyfemale_n.dds, and
  • the skin needs to be upperbodyfemale_sk.dds.
If your tattooed texture is called tattoobody.dds, then
  • the normal map needs to be tattoobody_n.dds, and
  • the skin needs to be tattoobody_sk.dds.
Typically, if you are only adding tattoos to an existing texture, you can just copy the "_n" and "_sk" files from the original body to the folder with your new tattoo texture. Each modified texture (body, left hand, right hand, head) that you have needs a matching "_n" and "_sk" file.

It should go without saying that all of these textures have to be somewhere in your "Data\Textures" folder.

The head texture works the same, except it is under the Face Data tab instead of the Body Data tab with all of the other textures.

Once you have all of your modifications done and you have all of the files in the right place, you can click the preview boxes to look at your race's Head or Full view.

Something else to note: if you make changes to the head texture and preview it, further changes to the head texture don't always show up in the GECK. It caches a copy of your head texture and sometimes won't show any newer version in the preview window. You can shut down the GECK and reload your mod to properly preview your head texture changes if that happens. It will usually pick up modifications to the body texture if you preview again though. It's only the head texture that gets stuck (it has the same issue for textures for items and other non-NPC things). See also TIP: Switching Custom Facial Features.

If you are using a custom body for your player, you can select the NIF for that on the Body Data tab as well. There is an Upper Body model, and a Left and Right Hand model. For hand and body NIFs, all you need is the NIF in your Meshes folder. Head meshes need an "EGM" file as well, and the file name again needs to match. If your NIF is CustomHead.nif then the "EGM" needs to be CustomHead.egm, for example.

If all you are doing is adding a texture to whatever the default mesh is on your system for that race, then you probably don't need to worry about custom NIFs. This is true even if you are using a body replacer, since they tend to place themselves in the same location as the default vanilla body NIFs in the folder structure. In other words, if you are using say the "Type 3 body replacer" and your "tattoo texture" is for "Type 3", you already have custom NIFs in your Meshes\Characters... folder for the "Type 3", and those are already what gets loaded by the GECK for each race type. You don't need to have a custom "Type 3" NIF for your character.

On the other hand, if you want a custom NIF just for your character so that they use a different mesh than the default races, then you will need to specify a custom NIF in the race in the GECK. Whatever body texture is defined in the NIF ends up getting ignored by the game, though. The game will use the custom texture defined in the GECK instead.

TIP Hostility between NPCs

Hostilities will not immediately break out between two NPCs when they come into proximity simply because they are in "Enemy" Factions. Their actions are influenced by the NPCs personal "aggression" and "confidence" numbers (on the GECK "AI Data Tab" page and the resulting "Threat Ratio" at the time.

You can use the "setav" command in script to change the "Actor Value" for permanent changes or "DamageActorValue" and "RestoreActorValue" for temporary changes to the "Stats List". (See the GECK "Actor Value Code" list.) Be careful about the scope of effect of your changes. Read the warnings under "Actor Value" carefully.

There are ten "user defined/mod actor values". They have no defined game functions, but can be used by quests to establish permanent data on the actor. Keep in mind that setting one of the variables on an actor implicitly defines that variable for ALL actors, not just in your mod. Using these values to store extra information has the potential to cause conflicts with other mods. If you need to store information on an actor, use a token (an unplayable, therefore invisible, piece of armour) instead.

TIP Interrupt combat for dialog

Thanks to clanky4 of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Suppose you want an NPC (once engaged) to interrupt combat in order to switch to some dialog: such as to offer to surrender when their HP drops low enough. (An example of this is during the "Dog/God" fight in the kitchen of the Sierra Madre Casino, but that script is a mess to try to interpret.)

When the conditions for that interruption are correct, use the command:

This ends the fighting flag for all enemies targeting the specified actor (e.g. PlayerRef). All hostile actors that are in combat with that actor will return to their normal routines. Now they can enter into dialog (or other activities such as a "run away" travel package).

If you wish to only stop the fighting flag for a single actor, refer to StopCombat.

TIP Making NPCs move aka AI Packages

Thanks to madmongo, EPDGaffney, and FiftyTifty of the Nexus FalloutNV 'New Vegas GECK and Modders' and kingbeast88 of the 'New Vegas Mod Troubleshooting' sub-forums for the following basic summary of how to get NPCs to move:
An NPC that just stands there typically is doing so because they don't have an GECK: AI package to run.

A typical companion will have a companion script which will have defined a number of GECK: Packages: a Follow default package, a Follow Long package, an Idle/Wait package, and a Non-hired package (they may use the same package for Wait and Non-hired, like a sandbox type package, for example). Each of the packages must have a condition variable, which will typically be the equivalent of "if (IsFollowingDefault == 1)" for the follow default package, or IsFollowingLong for the follow long package, or HasBeenHired is set to zero for the Not-hired sandbox (or whatever) package, and "if (waiting == 1)" for the Wait package. If you don't have a condition, then the package will want to always run. Those variables (e.g. IsFollowingDefault, IsFollowingLong, etc.) all have to be defined in the NPC's script. You set the various variables to match what you want the character to do as the way you control which package is used, then do an EvaluatePackage (.EVP) function on the NPC to get them to switch.

Function ResetAI clears all current AI behaviors from an actor. Combat, pathing, and packages are re-evaluated. This is a severe command that affects all AI behavior. Usually, you just want to have an actor re-evaluate its current package. In that case, use EvaluatePackage instead. (When using the number of "tokens" present in an Actor's inventory to control AI packages, one author found it necessary to use ResetAI instead of EVP in order to get their script to function correctly more often than the first time. The cause behind this behavior is unknown.)

See also How Are Packages Evaluated.

So, if you want your NPC to Follow you, it's necessary to script the following in the NPC's conversation quest (replace "MyNPCREF" with the NPC's actual Ref-ID, obviously):

Set IsFollowingDefault to 1
Set IsFollowingLong to 0
Set waiting to 0
MyNPCREF.evp

If you want the NPC to Follow Long, you would do the following:

Set IsFollowingDefault to 0
Set IsFollowingLong to 1
Set waiting to 0
MyNPCREF.evp
(Also, on the NPC object: uncheck the no low-level processing box if they need to follow you through portals consistently.)

And if you want the NPC to Wait, you would do the following:

Set IsFollowingDefault to 0
Set IsFollowingLong to 0
Set waiting to 1
MyNPCREF.evp
(Don't forget to set the Guard Location on the Wait package to "Near Current Location" instead of the default "Near Editor Location", or the companion will run off to wait at their spawn site.)

Note that you want to set variables to enable your packages, and also clear variables to stop the other packages from trying to run. You want to set it up so that the only condition that evaluates to true is the one that's for the package you want the NPC to run. For example: if you want the NPC to follow the "default" package, you need to enable the IsFollowingDefault variable while disabling both the IsFollowingLong and the Wait package variables.

The HasBeenHired variable would be used to enable or disable various conversation options, and would also be set when the NPC is hired and cleared when the NPC is fired (and again, an .EVP would be done to get the character to sandbox when not hired so they don't just stand there like an idiot).

If you want a fully functional command wheel, you have to use the conversation topics that the command wheel expects.

The first tutorial listed ('Advanced Companion creation guide with Companion Wheel') is recommended for learning to use the "companion command wheel".

AIPackage-GoingHome_Fig-01

Some people prefer to follow the simpler instructions and example in the FNV Companion Tutorial Thread by trilioth (even though it does not include how to use the "companion wheel"), but get confused at "Step 3: Create AI Packages".

The way this was done in the vanilla game (and the AIPackage-GoingHome_Fig-01 image here) was using quest variables, whereas trilioth's tutorial uses script variables. Follow the tutorial, as based on the preceding steps you should have these variables in your object script, not your quest script. The way you create the package is the same otherwise. (See AIPackage-GoingHome_Fig-01. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

(WARNING: There is a bug in GECK on versions of Windows after Win7 that causes the columns under the "Conditions" tab to be collapsed to the left and appear to not be present. Accessing this field in the "AI Package" form consistently causes this bug to trigger, and it then affects other "list box" type fields in other forms. Please see the Issue: GECK is missing text in fields entry for suggestions on dealing with this.)

For Patrol packages your NPC needs to be linked to your first "X marker" in the navmeshed patrol path. (See the TIP: Navmeshing Exterior cells.) All "X markers" in the patrol path need a unique ID, need to be persistent, and linked to each other in the succession you wish it traversed. "Idle markers" can be used but need duration times set and need to be made persistent.

To make a new Patrol package with a unique ID: Just edit a base package to your liking; then change the Editor-ID name. GECK will create a new form. Make sure the package type is Patrol, the starting location is a linked reference (e.g. "X marker"), and flagged repeatable. Then give the NPC the new package and link your NPC to the first marker in the patrol path.

An NPC not waking up from sleep is an indication the time schedule conflicts with another package. All it should need is a package type of Sleep, a schedule time and duration (do not allow the times to overlap with other packages), flag enable fallout behavior & for location: the name of a cell or a linked reference (which needs to be selected) or a near reference (if you have multiple beds for instance and don't care which they use).

Exterior sandbox type packages need a package type of sandbox, and a wander location set with a radius. Set whatever flags you want in: allowed behavior, enabled fallout behavior in flags, and a non overlapping time scheduled.

When you send someone away (i.e. "no longer hired" or "go home"), set the "GoHome" package to be a "sandbox" type instead of "travel", and they will automatically run off to the "home" location to sandbox there. The game scripts often teleport actors to that location first when they want to avoid encountering "hostiles" enroute. Be sure you first set the conditions you are using as appropriate (i.e. "not hired", "available for hire", etc.) before an ".evp" command to take immediate effect.

Be very careful using "AddScriptPackage <packagename>". In practice, whenever an NPC teleports (fast travel, goes through a door, etc) they tend to stop running whatever AI package was added through AddScriptPackage, and then use a suitable sandbox package. It's a useful function for some things, but it won't work in cases like this (traversing cells).

If your NPCs take off for parts unknown when following a package, make sure you have a "North Marker" placed in the cell.

To make the NPC go back to Goodsprings (for example), you need a package that sends him there. The condition for the package will be similar to "<CompanionREF>.HasBeenHired == 0". You don't necessarily need to make an Xmarker the destination. You can have the package be a sandbox inside the "Goodsprings Saloon" cell if you want. Then he'll just sandbox around inside the Saloon whenever he isn't hired and he'll go back there if you fire him. See also TIP: Using AI Packages.

TIP Merchant Inventory

Thanks to EPDGaffney and madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
The GECK tutorial Adding items to vendors fails to point out that you can only have one merchant/vendor container in a different cell (such as "VendorChestsCell"). For example, if you open up the GECK and go to the NovacGiftShop cell and double click on Cliff Briscoe (which brings up his "reference editor"), and then click on the "Merchant" tab, you will see where his merchant chest gets linked in even though it's in a different cell. You can change that link to a different container, but you can't add a second container there.

If you want to add a second container, you can't place it in a different cell. It has to be in the cell where the merchant is located and the cell has to have its ownership set to the merchant. And of course the container has to be persistent and its ownership has to be set to the merchant.

You can place the container in the shop (hidden behind a wall or underground if you'd like), or you can place the items individually in the shop.

Another approach is to add the items directly to the merchant's original container. There are two ways to do this. First, you can just edit the original container. That works, but breaks compatibility with any mods that also edit that container. The second way to do it is to use a script to add the items to the container, like making a quest with a quest script that is set to run once to add the items. Since you aren't actually modifying the container permanently, this second approach won't break things if another mod also wants to modify the same container.

Let's suppose you want to have a merchant sell certain items only if you succeed in a "speech check". The solution to adding this inventory leads to some interesting bits of information pertaining to inventories in general.

Merchants will sell any items that are marked as owned by them as long as their container or the item is in the same cell when the ShowBarterMenu function is called. This includes items lying about the shop outside an obvious container (apparently the shop itself, i.e. the "interior cell", can count as one if solely owned by the NPC; as exemplified by buying Chet's silenced pistol from him removes the one in his display case and that doesn't appear to be specifically scripted anywhere). Of course, the merchant in question must be able to sell that type of item (e.g. the merchant must have the AID service ticked in their NPC form or the wine in their owned fridge won't be available to buy in the barter menu).

The tested conditions determining what can be sold are:

  1. Any item that is owned by the merchant, in the cell with them, enabled, and a type that they can sell will turn up in their barter menu.
  2. These items do not need to be in containers.
  3. Additionally, the merchant's own personal inventory is an "owned container", and anything reverse-pickpocketed onto their person (or presumably added via script, though this was not tested) becomes part of their barter menu.
  4. Likewise, placing the player's items into the merchant's owned containers makes these items part of the barter menu as well. ("Ownership" automatically changes as soon as the transfer completes; i.e. item is released.)
  5. If the cell (this usually refers to an "interior cell") is marked as owned by them, all items in that cell without explicit ownership will belong to them, as usual, and these items will be available for purchase as well.
  6. An item that is marked as belonging to the merchant will be available for purchase even if the entire cell is not marked as owned by them.
  7. If something is owned by the merchant and it was originally put in one cell, transferring it to their current cell makes it immediately part of their barter menu.
  8. Disabling and enabling owned items works to control whether these owned items are eligible to be in the barter menu (provided they meet the other criteria).
  9. Items that are owned by a faction of which the NPC is a member will NOT be available in that NPC's barter menu; ownership must be theirs alone (which is the case when the interior cell is owned only by the NPC).

Bottom line seems to be, if the merchant owns it and it's in the cell they're in when you open their barter menu, as long as they sell that form type, it should be there to buy. The editor location has no impact.

So, what you would do is set up your secret items container in advance and leave it out of reach in that cell. Then when the secret stash should become available to the player for purchase, run SetOwnership on the container or item (either of which needs a Reference ID and to be marked as a persistent reference).

This normally means the vendor must be in that cell, so it may be a good idea to give them dialogue about how the merchant needs to meet them at a location in that cell, should the player ever speak to them when they are in a different cell. Alternatively, you could script an owned container to be transferred to the current cell in that circumstance. You could use an invisible model for the container and place it near the merchant before opening the barter menu. It's not believed you need collision on the container but that has not been tested. If you do need collision, the container should just be scaled down to nothing to avoid weird collision experiences.

TIP Only Combat Teammates give XP to Player

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Followers don't give their kill XP to the Player unless they have been "hired" as "companions" or otherwise had the function SetPlayerTeammate 1 applied. The XP sharing is apparently a built-in engine function specific to "combat teammates" and not those with simply a "follow" AI package.

TIP Perks for Companions

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for providing the following quotation:
It is generally understood that you cannot add Perks to Companions in the same way as to the Player. However, according to a J.E. Sawyer (FNV project director) Q&A roundup:

Quote:

There is an undocumented feature in F:NV that some modders may find useful. It is the ability to give perks to companions. Or, more accurately, it is the ability to add perks to a special list on the player that will have an effect on any active followers. Here's how it works: 
player.addperk XXXXXXXXXXXXX 1

The "1" means "put this on the special list for companions". Companions will still not store/keep perks, but we give the player a second list of non-displayed perks that only apply to companions. If you want the effect to apply to all companions, you do not need to conditionalize the perk owner conditions for the perk's entry points. If you want the perk to be special for the companion, check the NPC's ID or ref in the perk owner conditions.

I recommend making special companion versions of perks even if you want to use existing effects. E.g. if you want to give Raul the equivalent of Shotgun Surgeon for some reason, make a special "RaulShotgunSurgeonPerk" that's filtered just to him, and add it to the player with player.addperk RaulShotgunSurgeonPerk 1 the first time Raul is hired. Even if Raul leaves the party, you shouldn't have to worry about the perk hanging out on the player as long as the perk owner conditions are filtered properly.

N.B.: The effects will ONLY work while a companion is in the party. So in the above scenario, Raul would no longer have the benefits of RaulShotgunSurgeon if he left the party.

This tip applies to "companions" only. Some test results of using this "feature" are found at the end of this Bethsoft 'Perks on Companions' thread.

TIP Switching Custom Facial Features

Thanks to rikkurikku of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
For example: Let us say you want to switch between the normal actor's face, and one that is "bloodied". Set up your "bloody" face version texture as a different race and use the SetRace function to switch, followed by "Update3D" to refresh the display in-game. This applies to both the Player and NPCs. See TIP: Custom Race & Skin Textures regarding creating a "custom race" and the appropriate folders.

When switching among custom facial features (such as eyes or hair), switch to a "vanilla" feature first, and then switch to a new "custom" look. The GECK gets confused if you try to switch straight from one custom feature to another.

TIP Trick with making NPCs

If you create the NPC in an ESP, you can run into the infamous "head/body mismatch" bug. There are some settings you can change that fix the bug on some computers, but if you want it to work on all systems, define the NPC in an ESM file.

TIP Using AI Packages

  • You can activate dialogue and travel packages by using the AddScriptPackage function, usually in a "dialogue result" or "base effect" script. This has the advantage that a package added in this fashion will take precedence over all other packages until it is done, and terminate as soon as it is able (check the Must Complete and/or Must Reach Location flags to prevent premature termination, but be sure you provide the means to determine it IS completed).
  • An actor can have only one script package active at a time. When calling the function twice on the same actor, the second package replaces the first one added. Unless the AddScriptPackage has some constraint on it (Must Complete and/or Must Reach Location), it will be removed the next time the actor reevaluates his package.
  • Actors evaluate their packages every 10 seconds. If no packages have true conditions then the actor will just stand there by default, unless they are in combat. So if you want a package to take effect right away, set the conditions for the package and call the EvaluatePackage (.EVP) function on the actor: ActorREF.evp.
  • Sometimes it can be difficult to get the AddScriptPackage to trigger, or you don't want it to take precedence over all other packages. The usual method to assign AI packages is to attach the package directly to the actor and give it conditions to trigger or disable activation. On the NPC/Creature object, the first package from the top of the list that has true conditions will be the one in effect when packages are evaluated.
  • Check that the order of your packages and their conditions do not prevent some from ever triggering. Treat each as if a part of a series of nested "IF ELSE" blocks. (IF < condition > is "true" then do "this package", ELSE do "that", where "that" can be another ("nested") "IF ELSE" block.) The last "ELSE" should trigger an "idle" or similar "default" package.
  • The RemoveScriptPackage function is only used for packages added by way of the AddScriptPackage function. Once you remove an added script, the actor will automatically re-evaluate and determine which package should take it's place.
  • AI Packages attached directly to the actor are activated or deactivated by setting the variables used in the conditional tests. If they are only in effect in very specific circumstances (such as being in a particular cell or location), then use another variable set in a quest script to determine if the circumstances exist to avoid making the full condition checks unnecessarily.
  • If an Actor won't use a particular weapon type, make sure they have a "combat style" appropriate for that weapon in the package; and that the weapon has a "health" greater than zero. They will always use the "best" weapon in their inventory for the combat situation.
  • If the AI Package has a "schedule" or timing (start time and duration) to it's events, make sure that schedule does not overlap or conflict with any other package assigned to the NPC. A scheduling conflict will prevent either package from running.

See also TIP: Making NPCs move (aka "AI Packages").

Dialogue and Lipsynch

Other sections have relevant information to this subject. The following "Tips" in particular are applicable.

  • See the Custom NPCs section regarding scripting "AI Packages".

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

TIP Adding Generic Dialog

Thanks to madmongo of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
So, you want your NPC/Vendor to have some generic dialog (meaning: re-use existing dialog already in the game that is not situation specific; like "Hello").

There are two ways you can do this.

  • One is to extract all of the voice sounds and corresponding LIP files from the game "Fallout - Sound.BSA file" to some other folder (NOT to "Data"); then go through and pick and choose which lines you want; and just create new dialog topics and responses for your NPCs that use those lines verbatim. Then just copy/paste and rename your voice files for the new dialog. For some things, this will be the faster way of doing it.
  • For Vendors though, it's probably faster to integrate them into the existing vendor system. This will probably require a bit more digging through the GECK to make sure you get your NPC correctly configured. You'll probably need the voice type to be set to the proper type of the existing vendor you are modeling yours after, the NPC's class to be set to what the vendor dialog expects, and you'll probably need to add the appropriate factions for vendors to your NPC. Just go through the configuration of an existing similar vendor NPC and you should be able to figure it all out.

See also TIP: Standard Dialog.

TIP Conversation or Quest system

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the following:
The conversation/quest system for Fallout New Vegas seems like nonsense until you realize it evolved out of the conversation/quest system for Morrowind. In Morrowind, different people could say the same topics, and most of it wasn't voiced; so it made a lot of sense to group things by quests and topics instead of by speaker.

What this means for FNV is that some dialog is spread out through a lot of different quests. If you want to edit Doc Mitchell's dialog during your initial character creation, for example, that's in the various VCGxx quests (VCG01, VCG02, etc). His healing options are in VDoctors, the same quest as for all of the other wasteland doctors. If you right click on Doc Mitchell's ID in the GECK and select "Use Info", you'll get a list of topics where his ID is used.

Tip Cutting Lip files to match dialog

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Assuming you are cutting up existing voice files to make new dialog. What I typically do is import the existing voice clip into Audacity (see Programs and Tools) and chop it down to the part I want, then export that as a WAV file and rename it to match the file name that the GECK expects in the dialog quest. Make sure you export it as a WAV and not an OGG. The Lip generator wants a WAV file.

Instead of trying to cut down the lip file to match, just regenerate the lip file from scratch. Click on the voice file in the box at the bottom of the dialog editing box to highlight it, then click on "From WAV" and click on "Generate Lip File", which should now no longer be grayed out. If you don't seem to be able to actually generate a LIP file, double-check that your voice file is in MONO (and not Stereo) mode.

This of course requires that you have copied the lip generator from Oblivion or Skyrim, or the alternative FonixData.cdf. In Oblivion the lip generator's in \Sound\Processing, which is where it belongs in FNV as well. (See the links above for options.) NOTE: The FonixData.cdf tool must be installed under the sound\voice\processing folder.

Helpful tip - I will often record a very short bit of blank audio in the dialog editing box just so it puts a blank WAV and LIP file in the right directory where it's expecting it. Then I just go to that folder and delete those "dummy files", which seems kinda stupid, but it gets the folders all created properly and named properly and stops me from doing stupid things like typing one of the folder names wrong. Then I copy and paste the file name from the GECK onto my newly edited WAV so that I can't make a stupid typo there as well.

TIP Get the current speaker reference

Thanks to FiftyTifty of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
Suppose you want to identify the current speaker of a line of dialog for use as a later reference. Dialog "inherits" it's implied speaker from it's topic, so you need to use the "GetActionRef" function, placed inside the dialog "Result Script (End)" block.

See also the GECKWiki "Calling reference" page.

TIP How to generate lip files

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
There are two parts to Voices in topics: the sound file, which is usually a .WAV or an .OGG format file, and the lip file (.LIP). The sound file has (obviously) the spoken sound, and the lip file has the synchronized lip movements. Without the lip file, the NPC's lips won't move as they speak, which is very weird.

The GECK as it ships is missing its lip file generator. Bethesda has updated the GECK a couple of times since its first release and still hasn't bothered to put the lip generator in it. (They seem to like making things difficult for us.) You can use the one provided with the Oblivion or Skyrim CK installed on your computer: the same lip generator is in the \sound\processing folder. Just copy that folder to your FNV directory and you're good to go. Or there is a "third-party" lip generator: FonixData.cdf ( Easier .Lip Files ) Mod by DingraThePishvaz. NOTE: The FonixData.cdf tool must be installed under the sound\voice\processing folder.

Now the question is: where is your sound coming from? If you are going to be speaking into a microphone, just bring up the topic and hit "record" near the bottom of the window. Don't forget to "save" it when you are done. If you don't like what you just said or you made a mistake, flubbed the line, whatever: then don't hit "save", and instead just hit "record" and try another "take". When you click "save" it only saves your last "take". If you have the lip generator installed, the GECK will automatically create both the .WAV and .LIP files.

If your sound is coming from an already existing .WAV file, it needs to be in the exact location that the GECK expects it to be in and it has to have the exact name that the GECK wants it to have. If you look down near the bottom of the topic, you'll see the file name that it wants, without the .WAV extension, which will have the topic name in it and will also have what looks like a bunch of random letters and numbers in it (they aren't random; they are hexadecimal). Sometimes the easiest way to make sure your file ends up in the right place is to record a quick 2 second dummy hello or something into the microphone and save it, then go under the \sound folder and find your mod and voice type (etc.) until you land on the files you just created. If you have to create all of the folders yourself it's very easy to make a mistake. This way (i.e. by recording dummy files) you make sure that the folder names are right and everything is in the right place. Then delete the .WAV and .LIP dummy files that you just generated, and put the actual .WAV file that you want to use in its place. You can copy the file name from the topic screen and paste that into the file name of the .WAV file. The file names are too long and contain too many letters and numbers, so changing the name manually isn't recommended; copy-and-paste is safer.

Now you have a .WAV but no .LIP file. You'll need to close the topic and re-open it, as the topic window doesn't refresh when you change the files. Now you should see a "Y" under your .WAV near the bottom, and you should see your .WAV file listed. Select your .WAV file, click on "from wav" and click on "generate lip file", and the GECK will create the .LIP file for you. You can also do this to create .LIP files from any dialog you may have recorded before realizing that you didn't have a working .LIP generator.

TIP No sound driver available error message

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
So, you keep getting an error message saying "Error: No sound driver available for use" every time you open the dialogue window. What gives and how do you make it go away?

It's not necessarily an audio driver problem. It doesn't matter where your GECK is installed.

The form in the GECK where you edit dialog is also where you record audio for that dialog. If you do not have a microphone or some sort of line input connected to your computer, the GECK can't find anything to record audio from and gives you that error.

Plug in a microphone and the error will go away. Depending upon your version of Windows, something other than a microphone (such as headphones) plugged into the line input will also make the error go away.

Some audio drivers will have a virtual audio source of some sort that will be enough for the GECK to think that it has something to record from. If nothing else, many audio drivers used to have a loopback so that they could record whatever was going out through the speakers. (Microsoft and the audio driver manufacturers have moved away from this since some folks were using it to illegally record the audio off of YouTube videos and the like.)

Look under the Windows "Control Panel | System | Sound | Input | Device Properties". There should be a drop-down box in the "Device Properties" window that lets you enable various devices (e.g. "Stereo Mix (Realtek Audio)") that (regardless of whether they actually function or not) will be sufficient to get rid of the error message in GECK.

If you have something configured or plugged into one of your sound card's inputs and you still have the error, then you have an audio driver problem.

TIP Obsidian Conversation Editor aka OCE

Thanks to EDPGaffney (the "I" in the following) of the Nexus "New Vegas GECK and Modders" forum for the details of this tip:
Obsidian wrote the Conversation Editor (OCE) to help them do dialogue in this game in a way that was workable for so many branching paths and such. It comes with the "New Vegas G.E.C.K." and can be accessed by clicking the last button on the right on the top toolbar, which looks like the symbol for a "right-justified" paragraph. Its interface looks very similar to the Dialogue Tree in the Quest window that most people seem to use even in this game. (I suspect because of all the Fallout 3 tutorials, and that OCE wasn't available in Fallout 3). Some of its advantages are:
  • loading things much faster,
  • never crashing (at least for me after weeks of editing hundreds of lines),
  • not having that Windows 10 bug unless you open certain other things in the G.E.C.K.,
  • being able to save your mod with it open,
  • inheriting the speaking NPC (and optionally other conditions if you tell it to, I think) so that you needn't enter it for every single line,
  • being able to edit conversations in a more visually comprehensible way (as a tree, with entries you can modify in the same window),
  • making new dialogue by simply adding a child to the last thing you wrote and typing it into the same window as the rest of the conversation,
  • being able to copy topics and then paste them as links or simply pasting the topic as a new topic with the same text and conditions,
  • and having access to every feature of the Fallout 3 method (well, theoretically; I'm still not sure about recording).

Tip Random NPC Comments

Drop in Xmarkers at the locations where you want to provide specific comments, and give them a unique Ref-ID. Then put in a condition of:

"Subject: GetDistance to that XmarkerRef < 10000" (as an abstract, pseudo example) on each of the Info/response entries, in addition to a "GetIsID" condition. If the 150 char limit isn't enough then add another 150 char block in the Response field. On the Topic text (at the top) say something like: "Do you have any info on this place?". Flag it as a top level dialogue; then the priority will determine where it shows in the list of options after their "Greeting". If you're not within the maximum distance to any marker then that option shouldn't show up as a dialogue option for the player. - Source: Mktavish, Nexus forums

TIP Say Once use

Thanks to Mktavish of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
The "Say Once" flag is set per "response", not per "Topic". So basically you take the Topic, and add as many responses to it as you want. Flag them "top level", and set "priority" for what order each response will be presented in. You can even set conditions that might change when they are used, such as (for example) a "quest stage" or "gateway variable". Once they have been spoken, the responses you flag as "Say Once" will no longer be considered in the priority list thereafter.

The dialogue tool is pretty versatile. But it is not very intuitive either and one of the harder things to get proficient with in the GECK. However, there is no one set way to do things. See TIP Obsidian Conversation Editor aka OCE.

TIP Standard Dialog

Certain bits of dialog are standard, but have to be added from the correct tab in the Quest Stages.

See the following references:

  • Prompt: This text will be displayed in place of the topic text. If left blank (as is default), the topic text will be used.
  • Result Script (Begin): This script runs when the Info is played, at the moment the actor starts saying his line.
  • Result Script (End): This script runs at the moment the actor finishes speaking.

The following is intended to help clarify the above GECKWiki pages:

  • GREETING only shows up as an option in the topics tab of your Quest when you < right-click > on the Topics tab in the left-hand pane of the GECK "Object Window" under the "Actor Data/Quest" section; and then also select/highlight the info response field in the top right-hand pane: where it shows a piece of the text and conditions. Then you go to that small "list box" on the right side labeled "Add Topic" and < right-click > in there to select from the list of existing topics, or select New to add a completely new one. In case it isn't clear: this GREETING is the NPC's first response when the Player first initiates dialog. If you enable (check) the "SayOnce" box, it does not appear again for that Actor. It can appear for another Actor which meets any qualifying conditions. Do not confuse it with Hello which is all actors' way to start conversations, but usually only between NPCs.
  • Once created, Hello and GOODBYE only show up as dialog options upon < right-click > on the Conversation tab and select Add Topic. They should be "top level", with a priority of 5. Hello is generally used for conversations between two or more NPCs, without the Player. GOODBYE is essential to be able to terminate a conversation. If in the Topics tab you do not set up any topic flagged as GOODBYE, the dialog will end with one of those GOODBYEs from the Conversation tab.
  • You will need Voice "sound" (and corresponding Lip-Sync ".lip") files for your dialog lines so they take the appropriate amount of time before proceeding to the next line. Otherwise they may appear to "skip" over some lines or cut each other off. "Silent" sound files are common for this purpose when the actor is not voiced, but still needed to establish the timing. See the Sound and Voice Tools section entries for the necessary tools.
  • Sort your list of dialog Topics by Priority. ("1" is highest, "100" is lowest.) Place the GREETING and GOODBYE Topics at the top of the list. Topics are processed from the top down until it finds the first one with all conditions "true".
  • Order your list of "conditional test" responses in each Topic by priority as well. Consider all the conditional responses as an "IF ... ELSEIF ... ELSE ... ENDIF" block. The first response which tests as "all true" will be "the winner" and processing will skip to it's "Result Script".
  • "Conditional tests" override Priority values. Think of "Priority" as a way to group Topic statements; but NOT as a "tie breaker" ... especially in the case of those responses which otherwise have the same conditions. The order of the placement of the response lines within a Topic determines the order they are tested. Only the first which succeeds is processed. Later responses with the same conditions will never get processed. Use conditional tests to ensure only one response is appropriate at a time. See also the GECKWiki Using Complex Conditions and Causes of CTDs pages.
  • Any dialog that does not have a "conditional test" should be considered as if in the "ELSE" portion of the hypothetical "IF ... ELSEIF ... ELSE ... ENDIF" block. Again, if more than one response falls into this "condition", only the first will ever get processed.
  • Consider the use of a "token" (a piece of equipment flagged "unplayable" (and thus "invisible") placed in the Actor's inventory) along with the GetIsID function to indicate which Actor is currently speaking. (Otherwise, you would need to convert the "Ref-ID" of the Actor into their "Base-ID" using GetBaseObject first in order for GetIsID to work correctly. But remember: a "Base-ID" is a template for all "Ref-ID" instances of that form. If more than one Actor in the conversation is based upon the same form, the "Base-ID" is not unique. GetIsReference only works for "persistent" references such as unique Actors; not those dynamically spawned from "lists". Which is why a "token"shifted between the speakers works better.) You can use a "ResultScript (End)" block for each response to transfer the "token" to another Actor with the MoveToContainer function. (An example of the use of a "token" is in the GECKWiki tutorial Adding an Options Menu. "Tokens" can also be used to store information on an Actor. See ActorValue.)

TIP Text display timing

Many new mod creators think of "voice" and "lip-sync" files as "optional" when they only intend to display a text message. Then they wonder why sometimes their message only displays briefly in a flash and others wait until something is clicked upon. The latter is because a message displayed under control of a menu block is "paused" until an "input" (key entry or button click) is received. (Sometimes this is not as obvious as a "button", such as using an elipsis ("...") instead. Generally not having an obvious means of proceeding is considered "poor design" unless it is deliberate as a form of "visual puzzle".) This is one way to ensure the message is seen by the Player.

If you are not getting display of the Dialog response text outside of a menu, most likely it is because the text has no "voice" audio and/or lip-sync file attached. (Both are needed.) These files determines how long the text remains on screen before allowing the display to proceed. Even if there is no actual voice to be heard, a "silent" audio file of sufficient length is required to determine the length of the display of the text. The mod Silent Voice Generator by Enter_77 can generate both silent voice and corresponding lip-sync files of up to 30 seconds duration from exported GECK quest and dialog text documents. (See "Voices" under the Music and Sounds section. It is recommended placing your own "silent voice" files under their own sub-folder to avoid the risk of overwriting actual voices used by others.)

FaceGen Heads Faces Hairs and Helmets

This information is compiled from a number of threads, guides, and articles by authors such as DrakeTheDragon, throttlekitty, Ghogiel, scanti, and Skree000. It is an overview at best.

The heads of characters and NPCs in Bethesda games are created using the builtin FaceGen tool, which is a licensed Singular Immersion FaceGen Modeler. According to the FaceGen site "Customizer" tool user manual the resulting information is stored in the following files.

Each model part consists of one or more of the following file types, with the same root name:

  1. TRI. This is the base mesh, which includes UVs and information about morph targets but not the FaceGen shape changes.
  2. BMP. This is the base texture.
  3. EGM. This is the statistical shape information, which is used to modify the base face shape. Without this file, the mesh will never change shape.
  4. EGT. This is the statistical texture information, which is used to modify the base texture image. Without this file, the texture image is fixed.
  5. FIM. This is the UV remapping transform, which is used to transform the detail texture in the FG file (taken from a photograph) into the UV layout of this mesh. Without this file, a mesh cannot have a detail texture applied.

EGM, EGT, and TRI extension files are in turn are used to construct "OBJ" (whole head mesh) files. This is because "faces", "hair", and "helmets" have to be able to "morph" or "conform" to the underlying "head" mesh. Different heads can be used with the same body to provide the customized faces of PlayerCharacters.

Note that everything related to the head must be placed in a BSA for it to be processed properly by the game engine. Otherwise the "loose files" do not get "conformed" to the head mesh properly. (Use the "BSArch" tool linked in the Packaging Tools section to create/update your BSA file.)

From DrakeTheDragon:

Be aware that for EGM and TRI files it is one whole head mesh (OBJ) per morph, the base mesh with the morph applied to its fullest, and when you import them into modeling apps it is paramount the vertex count and order isn't even remotely touched, or they'll be useless to you as they won't fit into the EGM/TRI file afterwards anymore later. Morph offsets are calculated from the difference between the neutral base mesh's vertices and the morphed mesh's vertices, and this can't work when one or more sets of them don't have identical vertex indices anymore. Don't use any fancy scripted modification tools from your modeling app or anything else complex which could likely alter the vertex order either. If I remember right, even alterations to the UV map can change the vertex order and render the OBJ useless beyond repair already.

[The Oblivion mod Adding Eye Morphs to FaceGen Files] is a guide for much more than just adding "eye morphs". It's an invaluable resource and a profound guide how to do all of it at the same time. It covers the basics and all possible tasks likewise and, again, it goes far beyond just eye morphs in all departments. [Curator: As Oblivion utilizes the same underlying Gamebryo game engine as FO3 and FNV, it is still applicable in general. It includes the necessary tools by Scanti. There is a later version of The Conformulator than the one in that package.]

Last I heard the latest NIF Tools im-/export scripts for Blender could also be used to create EGM files, but Scanti's Conformulator is still the better solution and can be used for far more than just that.

I'm 3 years behind though [in Oct 2013] and not 'up to date' with the most recent developments anymore.

From Ghogiel:

It's rather easy to use The Conformulator. I've used it for years since it was very first released.

Once you have your Fallout NIF, just export from Nifskope to OBJ, and use that in the Conformulator instead of trying to use a NIF as input.

So you have your final F3 NIF. (Try not to do anything else to this NIF: nothing that will reorder the vertex numbering index!)

  • Open it in Nifskope.
  • Export as OBJ file type.
  • Open Conformulator.
  • Input that OBJ file.
  • In the TRI file input field, select the "humanhead.tri" file.
  • Hit <conformulate>.

I've experimented with using stuff like, a simple primitive box, make a TRI from the head onto that, then use that TRI to bake the EGMs onto final helmets (the theory is, the helmet mesh(or whatever) will deform much more uniformly in all directions) as an attempt to try to get around odd deformations on some headwear.

Most of the time the quality is set to "vertice". You only need to get more fiddly if your headware deforms oddly (e.g. the brim of a hat bending a bit). Which is where using the box method I mentioned above was developed for. Or trying to copy the face morphs from one TRI to a new one. And hair morphs. Otherwise I can't see how you can mess up.

From ThrottleKitty:

Adding Eye Morphs to FaceGen Files is just about all I know about EGM/TRI/EGT files, and some tools to work with them aside from The Conformulator.

For the problem with the mouth not moving, there's a couple of solutions; first the problem! The Conformulator compares your mesh to the original NIF/TRI/EGM files and creates morphs based on those offsets. So if the mouth isn't 100% perfect, you'll get a 'bad' morph. With my Head06 mod, the goal was to create a high-res version of the original, and stay true to the form. Even with small differences between the mouths, I ended up with a 'sticky mouth' look when talking. (So maybe the first solution isn't much of one).

I got around this by slightly opening the mouth a very little bit, a tip I got from Scanti. The vertices are too close together and the tolerance of The Conformulator was as such that it didn't know which way to move those areas. Took a couple tries, but I successfully managed to copy the morphs from the stock head to my custom one.

You'll need to use one of the other tools (I used the [hex editor] 010 scripts) to take the offending morphs in and out of the TRI file for fixing. You get an OBJ [file] as an output, which can be mangled about, then injected back in.

The EGT file is a package of 50 textures. The only way you'll be able to reuse the existing ones is if your model has an identical UV layout- or close at least. If not, a bit of [fiddling] of models and UVs should yield a good result for baking the textures from one UV set to another. (short of buying the Facegen software to do it the right way).

Fallout 3 EGM manipulation

The following is based upon a FO3 thread entry by Skree000.

EGMs are data files associated with head "accessories" that help deform them to accommodate the Head-Deformation associated with the Character Creation menu.

Without an EGM file, your character skull would stick through the hat, hair or helmet model if you made the skull really wide, tall or deep.

EGMs, without requiring a licensed commercial product, are created through a mod tool called The Conformulator.

The Conformulator takes TRI files; which are basically models that have Morph Targets. Morph Targets are what you manipulate when you change sliders in your character creation screen. These are basically just moveable bones that are skinned to parts of the face. A TRI file is an archive of one model and its morph targets.

The Conformulator also requires an OBJ or NIF format mesh to 'conform' to the TRI file. Basically it skins the mesh to the TRI file's Morph Target parameters, so that whenever you 'squash the forehead', the 'forehead region' of the headgear also gets squashed.

The Conformulator doesn't always do a perfect job, so it has a few options allowing modders to control how sensitive or accurate the conformulation is to the TRI file.

EGM's are REQUIRED for any headgear/hair. Without them, it will look awful; as if you have extremely deformed/altered character faces/heads.

To make your own EGM, export an OBJ of your headgear/hair from your modelling program, [Curator: the mesh transforms are exported when it's output as file type "OBJ" but not in a NIF], and then open The Conformulator.

  • Input the vanilla head TRI file, which is located in the Fallout3.BSA. (Unpack that with one of the BSA extraction tools listed in the Packaging Tools section. Note the warning!)
The TRI files you need are in "\meshes\character\_male\" and the one you want should be called "Humanhead.tri" or something like that. There are also "femalehead.tri" for female versions, if your mesh has problems with one gender over the other.
For the most part "Humanhead.tri" works just fine, since the only real major differences between male and female heads are slightly different facial morph targets, which aren't really that important for hairdos or hats to fit on the skull. (Skull deforms are all basically akin to each other.)
  • Once your TRI file is plugged in, plug in the OBJ of your headgear/hair mesh.
  • Hit "Conformulate".
  • Done. Your EGM is ready!

GECK will auto-detect any EGMs that are present in the folder where the headgear is located. HOWEVER!!! The EGM name must MATCH the .nif file name of the headgear.

Note that if your head "accessory" (hat, helmet, piercings, etc.) is not conforming to the head, you may need to "unequip" and "re-equip" the accessory whenever you edit your face so it will reconform.

Havok Physics

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

TIP Havok a dead NPC

Thanks to madmongo and jokerine of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Positioning a "dead" NPC can be frustrating. Spawning a dead NPC will have them appear as you left them (usually standing in the "T-crucifix" pose). Instead have the NPC alive in a temp holding cell, then move them to where you want them to end up and kill them. If the "dead" NPC just stands there you can have havok kick in if you place a small dummy explosion by the freshly enabled NPC. Jokerine wrote about that here. You could probably copy the same script she wrote there and give it to your NPC. If you do it that way, they'll havok (have game physics applied) and drop in some random-ish fashion, though not too random since they mostly ended up in the same position on the floor. If you have the NPC move to the same room when the player enters the room, the player will see the NPC appear and then fall to the ground; so best to do this out of sight of the player if possible.

Dead NPCs can be havoked in the GECK, though like much in the GECK that seems to be a bit buggy at times. Dead NPCs will spawn as you leave them though, so if you leave them just standing there in the GECK, then they'll just be standing there when the player finds them.

Live NPCs won't havok in the GECK, but if you kill them when they spawn or when a player approaches, they'll havok and fall and will end up in some random-ish position when the player finds them.

Heightmaps

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

Interior Creation

Often neglected topic because the GECK tutorials walk you through the process. Thanks to EPDGaffney and random411 of the Nexus Fallout "New Vegas GECK and Modders" forum for pointing out the need for this section.

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

Angle and Grid Snapping

"Angle snapping" & "grid snapping" buttons are covered under "Categories: Preferences" and in the "Bethsoft Tutorial Layout on the GECK Wiki site. You want to enable this and configure the spacing before you start doing anything else.

Basic Interior location design guide

Thanks to djmystro of the "Fallout New Vegas" Mod Talk" forum for the basis of this section. He is the "I" reference in the following. The original source is the thread "Interior Location Creation Tutorial" in that forum.
I learned a lot of things creating AWOP that seriously sped up my production time creating huge interior locations so I thought I would bundle a load of tips together in a guide to help others getting started with some simple handy facts that will save you a lot of time if you wanna go creating dungeons.

Contents:

  • Position 0
  • Block Size
  • Handy Keys
  • Havoc Engine
  • Walkthrough
  • How I Started
  • Copied vs New
  • Bodging Gaps
  • Cave Gaps
  • Cave Navmesh
  • Interior Size/Object Count
  • Adding NPCs
  • Object Spacing
  • Fast Navmesh
  • Fast travel to Object/NPC in Render Windiw
  • Interior Light and Fog settings.
  • Locating Objects
Position 0

On creating a new interior make sure the first block is placed at 0 on all axis. This will make the auto-move functions much simpler and easy to understand (as well as mathematically predictable).

Block size

Each block is by default 256x256 or in caves double or triple that size. There are however exceptions such as the Office and Factory building sets which have a default height of 288 which can cause blocks moved using the auto-align functions to shift out of place vertically requiring manual readjustment later.

Handy keys

Note: [RMB = HOLD the <Right mouse button>]

  • <F> - Drop object onto nearest surface.
  • <G> - Move object up by a small amount
  • <F5> - Refreshes the scene allowing for viewing of light effects and such.
  • <Ctrl+F> - Swap currently selected object(s) [Very useful for taking a clean Vault and making it dirty by just swapping out all references to one type of object such as a Vault wall in a scene to another similar replacement].
  • <Ctrl-F> (with Navmesh Active) - Checks local Navmesh for errors and allows for deletion or move to warning triangle.
  • <Ctrl-D> - Duplicates object(s)
  • <Z+RMB> and move- Rotates selected object on it's Z Axis.
  • <X+RMB> and move - Rotates selected object on it's X Axis
  • <RMB> & move - Rotates selected object on Y Axis
  • <A> - Turn full lighting on and off.
  • <Right-Click> (Navmesh on) - Drop Vertice
  • A (Navmesh on and exactly *3* vertices selected) - Fill in a Navmesh triangle.
Havoc Engine

To use the Havoc engine (on by default in the FO3 GECK) to realistically drop items and reveal the contents of certain vanilla interiors you need to do the following:

  • Open the 'GECKCustom' ini file (usually in My Documents/My Games/Fallout NV)
  • Find:
  • bUseMultibounds=1 and change the 1 to 0.

[Note that havoc dropped items will hover slightly above the surface they are intended to drop on. For detail objects I recommend using the F-key drop function. However certain objects such as skeletons can only be dropped properly using havoc.]

Walkthrough

Using this info it is relatively quick and painless to create vast rooms. Here's an example of an office block:

  • Choose entrance location, manually place block at 0 on all axis.
  • Decide on approximate size of location and how you intend for it to play out.
  • Find a wall and corner object (or anything else 'room' based that will be used at least once).
  • Drop them into appropriate positions (place at 0 height manually and use the auto-align features to rotate and slot them into place.
  • Use Ctrl-D to duplicate any objects needed more than once such as standard room walls and drag them into place.
  • Use Ctrl-F to select specific wall clusters and replace them with similar objects (e.g OffRmWall01 to OffRmWall02/03) which will vary up the appearance.
  • Drop in essential clutter objects such as desks, terminals etc... and use the previous functions to duplicate and replace with similar objects. Use G and F to reposition vertically. [Duplicating clusters of stuff can vastly speed up creation.]
  • Add detail clutter and loot then enemies.
  • Leave FX until navmesh is complete.
  • Clutter from the bottom upwards. Navmesh from the top down.
Clutter from the lowest floor (including basements) and then add later floors so you can see into the room effectively from all angles whilst adding clutter. Resist the urge to navmesh at this stage until the building is complete. This is because dropping a vertice (or green square used to link navmesh triangles) on top of existing navmesh on a lower level is tricky. It requires you to drop it on the floor from an angle where lower levels of navmesh are not in the way/directly underneath.
  • Add FX after navmeshing. Navmesh Vertices get stuck on FX and even spamming the F key repeatedly will not get them to the floor sometimes.
How I Started

I did not read any tutorials to get started modding (though once I got to dialogue and quest creation aspects those became very necessary).

For level design I began by duplicating rarely visited areas from the vanilla game (back then FO3). I then re-cluttered them myself. I pretty much learned the hard way though. Had I known of the existence of many of the above tips/keys/info I would have got a lot more done a lot faster but that's another story.

Basically I took what was there already, searched for the object in the GECK and just looked at all the similar objects. Sometimes just trying stuff out but mostly going in knowing what I wanted and if need be finding the blocks I needed to 'bodge' it together.

If I wanted a certain object I thought where I had seen it before and sought it out in it's vanilla location, checked out the name, found it in the list then dropped one into my location (though standard keyboard copy/paste commands work fine, just make sure you have the render window selected before attempting to copy).

Copied vs New

Eventually I found that copying vanilla areas was more trouble than it was worth. Most are at unpredictable heights and horizontal positions and a few are even at random angles which makes adding new room blocks onto them very difficult without creating gaps.

Eventually it becomes easier to create a new room and just copy a load of clutter from a few vanilla areas in bulk and redistribute them rather than the other way around.

Bodging gaps

I like to use certain kits together such as Hotel, Office, Utility, Cave and Vault, sometimes just in one interior (the Dead Money AWOP has lots of these locations). However they are not always designed to fit together leaving gaps often along ceiling joins. Look out for simple blocky objects which can be used to fill gaps such as:

  • Free Columns (e.g NVGSRmFreCol) [Eseentaly wall-join features]
  • Wood blocks (e.g CampLog01-04)
  • Concrete (e.g PowerStationBlock01)
  • Rubble (e.g OffRubblePile01/IndRubblePileSmall)
  • Door Frames (e.g OffDoorFrameSmOnly)
Cave Gaps

Cave sets are not like other square room sets. They require much more attention as to which block can go where. They are not symmetrical and floor and ceiling joins in particular will be off unless you put the right blocks next to each other at the correct angle. Here's how I do it:

  • Place initial block at 0 and make sure it is also not at an angle.
  • Do NOT rotate any blocks (apart from Hallway pieces and corner blocks which are more flexible).
  • Each cave piece is numbered 1-4. These represent North, South East and West and are consistent throughout.
  • Drop one in. If you drop a number 2 wall in and need it facing the other way swap it out for a number 4 rather than rotating it 180 degrees. Should be simple from there on out. This way you avoid the gaps.
Cave Navmesh

Quick tip for navmeshing caves is to aim for the rocks when dropping vertices. This stops the majority of it going under ground from several vertices being dropped lower than the average ground height.

Interior Size or Object Count

Making a location too big and adding too many objects will severely impact on performance. I have found the total object count (from a cigarette to a train cart) should not exceed 1500 or thereabouts (though I have many interiors that push this limit, in some cases maybe a bit too far).

To create a very big location is still do-able. For example the main sections of the Collapsed Underpass from AWOP are structurally built from about 40 very large blocks doubled in size though the rooms are probably big enough to contain every Vault in the vanilla game. This cuts down on object count and performance does not take a hit.

Which objects/FX/NPCs etc are more likely to trigger a performance hit I have yet to figure out.

Adding NPCs

I try and limit NPCs of a certain type to about 20 in any given location with no more than 30 overall. Adding more than this caused many problems when FNV was initially released though I believe the patches have resolved most problems I experienced. Even so having too many NPCs seems to be bad for performance, especially if using vanilla spawns likely to be effected by mods such as IWS or VVV.

Also when building an interior try and think how the enemies will react to your entrance. If the enemies are spread out inside a building not far apart with someone near the entrance then they are all likely to spot the player upon entry and mob them even from the back of the building.

There are several ways around this such as adding Guard packages to the NPCs or clustering them in certain spots.

Personally for tight environments such as hotels and offices with numerous NPCs I like to block off several pathways to slow them down. I also try and create gaps within the ranks to allow for breathing space for stealthier players to advance further.

Think about how far in you want the NPC to get before they are attacked. I usually allow at least one empty room or corridor on entry so the player can take stock of their surroundings and if sneaky enough get inside undetected. Vanilla often does this too but not always.

[This does not matter so much with most Creatures who cannot open doors such as Geckos, Mole Rats & Mantises].

Object Spacing

Try and leave a gap the size of a small door frame (approx 4 office/factory floor tiles if I remember correct) wherever you want NPCs or creatures to walk (or wherever you intend to Navmesh). You can get away with less in some circumstances (small bridges with no walls either side) but trying to limit that space with clutter or walls will cause problems for 'wide' creatures such as Deathclaws, Super Mutants and Mantises.

Fast Navmesh

Get used to holding down Ctrl and A when dropping vertices. Every third vertice dropped without releasing control will automatically create a navmesh triange. After this you can just drop a single vertice and the last two highlighted vertices will automatically create a new triangle. Sounds complicated but in practice is very simple. This works better outdoors or navmeshing large areas as for cluttered rooms still require a degree of attention as to which vertice goes where which will eventually cause problems using this approach.

To navmesh clustered environments such as rubble-strewn offices I used to drop a vertice at every corner and then link up all the triangles after. Now I use a combo of this and the holding Ctrl approach which tends to get the job done very fast.

Check out some vanilla navmesh too. It's not that detailed and does not venture into every nook and cranny. Take into account that even melee opponents have a wide radius of attack so you don't need to go right up to every wall. Also if you try and navmesh too small a gap then NPCs will just ignore it as being inaccessible.

To copy an interior and it's Navmesh, it is easiest just to duplicate it in the Cell Window. This will copy the navmesh and keep everything in place.

Copying the bulk of an interior from one Cell to another I can't think of a way to take the navmesh with it. There may be one but I don't know it.

With a little practice Navmesh becomes a very easy mindless repetitive task (caves and very uneven landscapes being the exception). Don't be worried about starting again for the most part. Offices and similar can be done in a few minutes. A bit dull but OK if you have some music on or something.

Fast travel to specific Object or NPC in Render Window

Right click on object in the Object Window & select 'Use info'.

This will list each appearance of said object. Then just double click on each in turn to be taken to it's exact location in the Render Window. This works well for books & guns (but not tin cans or anything too common).

Interior Light and Fog settings

In the interior locations there is an edit window which can be accessed from the Cell View window by right clicking. Im not sure about exterior locations (never edited lighting for them) but with any luck it's similar.

There's 3 color boxes in the lighting window. Make sure to uncheck any ticked boxes relating to predefined lighting settings else changing them will not save properly. One of the two on the left is ambient lighting, I'm not sure what the other one is so I generally make them very similar. The one on the right is Fog.

There are 4 boxes at the end for entering numerical values for the fog (from memory).

  • For Close - the point at which the fog starts forming around the player (128 is about right for dark areas, 512 is enough for a well lit and spacious office).

Fog Far - The distance at which the fog theoretically becomes a solid wall (anything below 1000 is very close, 2000 is about right for a medium lit tight location but in order to see for long distances a very high value needs to be set (around 4000-6000). To compensate for this in big dark areas it is best just to set the colors to very dark tones but keep these values high so light spots in the distance are still visible.

  • Fog Density - Just a multiplier for the amount of fog. 1 is standard.
  • Fog Clipping - The cut-off point beyond which nothing is visible but the color of the fog (or maybe that unknown block on the left). This should always be a higher value than the "Fog Far" setting to prevent a sudden impenetrable wall of fog cutting through objects at a certain distance (which can look very bad through scopes and such).

For reference purposes the height of a standard Office Block unit is 288, a utility hall is 256 and an epic cave is 512.

Locating Objects

Once you get used to building interiors the bulk of the time taken to build a level is spent locating the correct objects in the object window.

Here's some stuff that's not so easy to spot and a few general tips:

  • MINES:
  • Active Mines (all variants) are found in the 'Projectiles'. folder. Make them friendly to a faction by adding ownership in the edit box after dropping them into the Render Window.
  • Inactive mines are found in the 'Weapons' folder.
  • TRAPS:
  • All other traps are found in the 'Activator' folder.
  • In FNV GECK look out for the TestTraps cell the editors included which has most of the traps already set out for easy copy/paste.
  • If you wanna swap a tripwire for a pressure pad or vice versa just use the Ctrl-F function to swap it out after pasting. They are all prefixed by 'traps',
  • FLOOR CLUTTER/RUBBISH:
  • [Static Folder]:
  • AssortedPapers01-06
  • StreetLitter01-02
  • Paper01
  • OfficePaper01
  • ShackPaperDebris01-05
  • Eyechart
  • DLC04Sodacup01-02 (FNV & Point Lookout)
  • DLC04PopcornBox (FNV & Point Lookout)
  • DLC04StreetLitter01-02 (FNV & Point Lookout)
  • RorsaschTest01-03 [FNV Only]
  • MS (or quest) Documents (e.g MS15ConstitutionStatic) [FO3 Only]
  • [Movable Static]:
  • DeskPadPlanner
  • OFFICE CLUTTER:
  • [Static Folder]:
  • Typewriter
  • TerminalDesk... (several variants)
  • HotelLamp
  • LampGeneric
  • HamRadio01-03 (several variants) [FNV Only]
  • ComputerPart01-06 [FNV Only]
  • Clock01
  • SafeCracked
  • StarburstClock01
  • [Movable Static Folder]:
  • Telephone
  • OfficeFan
  • Globe
  • [Activator]:
  • VintageRadio (several)
  • GORE:
  • [Static]:
  • Vault87Blood01-09
  • GorePile01-04
  • RaiderGutsDressing01-08 (FO3 Only)
  • RaiderCorpseDressing01-06
  • FXFlyswarm [FNV Only]
  • NVHeadPike01-06 (FNV Only)
  • [Movable Static]:
  • BrahminRibcage
  • BrahminSkull
  • GoryCorpsePartsTorsos
  • Skull
  • SkullBloody
  • Skeletons (Lots)
  • TIntestine
  • TGoreArmGore01
  • TGoreLegGore01
  • [Misc Items]:
  • BodyPart01-05
  • DeathclawHand
  • [Container]:
  • GoreBags

Static Collections

Others have suggested you might want to add static collections. You can group entire rooms into a static collection, which you can change in game. This makes much easier if you want multiple versions of the same room.

However, it is not always a good idea. Making SCOLs that are very large, composed of many different objects, is just bad practice. SCOLs only help if you're making them out of 2-3 of the same objects, or if all the objects share the same type.

For building purposes, yes: It's convenient. But too many SCOLs, especially if they are large, can produce even worse performance than if the statics were by themselves.

The beauty of SCOLs is that once they are in place, you can ungroup them. It allows you to make more complicated objects and place them with the intent of splitting them later. One thing that this is useful for is if you were to make an indoor garden. You could put the planter and the plants in the same static collection and make a few template planters.

If all the objects share the same textures, then it may be even better to keep them in a static collection (if you use the static collection more then once).

LOD Generation

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

NOTE: The GECK LOD generation process uses "decimation" to create it's "low polygon meshes" for LOD/VWD. Please read the TESTG site sub-topic The problem with LOD/VWD files about why this is believed to be less effective than that used in later games such as Skyrim.

TIP xLODGen

Even the casual user of the tool xLODGen should read the TESTG: LOD/VWD Overview article and the thread TTW: FNVLODGen to gain an understanding of what is involved. Among other things the later thread points out that the "green billboards and trees" are deliberately added by xLODGen to flag that they are missing textures (sort of like the red "!" to flag missing meshes, but specific to LOD). xLODGen lists them in it's log when generating LOD.
The resulting xLODGen.esp file needs to remain in your load order. It should be regenerated whenever you add or remove "background" meshes and textures, as the "load order" affects the "quads" constructed to stitch together the distant view.

Misc Topics

Subjects with only a short list of entries, not yet warranting their own section.

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

ESM and ESP Files

Master Files (those with a ".ESM" extension - e.g. Fallout3.esm) and Plugin files ("TES files" or "mods" for short - files with a ".ESP" - e.g., Fallout3mod.esp) are the core data files of Bethesda games. A master file acts as a database of all of the data for the world, including object data, dialogue, gameplay settings, object placements, AI settings, landscape, script commands, cells, etc. The GECK is the tool we use to view and edit master files and plugins for the "Fallout 3" and "Fallout: New Vegas" series.

(However, not all game data files are Master and Plugin files. Textures, meshes, sounds, videos, etc. are all part of the full game. More about these files elsewhere.)

Master files and Plugins are largely identical in format, but have some important distinctions in practice. The main practical difference is that GECK will not (natively) create Master files. Nor will it allow Plugin files to modify other Plugin files. (The Extender and PowerUp addons overcome this limitation.) See the GECK: Data Files entry for more.

It is possible for more than one Plugin file to depend upon the same Master file. They don't even have to be by the same author. Such Plugins are called dependencies. xEdit (aka FNVEdit) is the primary tool used to identify such "master/dependent" relationships. (See the wiki article Missing Masters.)

TIP When can you use an ESM only mod
Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
When creating an ESM there are rules you have to follow so you don't corrupt everything.
  • All ESM plugins start out life as ESP files.
  • If your mod changes or deletes existing game references, it may not work properly as an ESM.
  • Use ESM master files for resources or NPCs. One rule is add or change, but don't delete. You can delete things while you are creating your ESM, but once another mod (ESP or ESM) references records in (i.e. depends on) your first ESM (i.e. treats it as a "master file"), don't ever delete anything out of that ESM or things can go very bad. If you've created a bunch of NPCs and you decide you don't need one, just leave it in the ESM and don't place it anywhere in-game. If it's already placed by the ESP, then set it to initially disabled and never enable it.
  • Once your mod (as an ESP file) is done: if you then convert it to an ESM using FNVedit (by toggling the "ESM" field flag of the "File Header") and saving, and YOU DO ABSOLUTELY NOTHING ELSE TO IT, it will work. (That's in caps because it's important).
  • Once you change your ESP into an "ESM" in the file header of FNVEdit, make sure you change the file extension to ESM to match. FNVEdit loads files based upon their extension and timestamp, period. It doesn't care about the internal ESM flag on ESP extension files; they get loaded after other ESMs. Besides, it confuses your customers: the players.
  • If you have something like an NPC or a package or pretty much anything in an ESM, and something modifies that NPC/package/whatever in another ESP or another ESM, do not ever change the NPC/package/whatever in the original ESM afterwards. That can really corrupt your mod. You'll also save yourself a lot of headaches if you don't modify things in another ESP/ESM. In other words, if you have an NPC defined in an ESM, but then you place the NPC in the game in an ESP, do not modify the original NPC definition (Base-ID form) in the ESP. You can modify your reference in the ESP all you want. Just don't modify the original NPC definition. (If that sentence confuses you, please see the GECK Form-ID, Base-ID, Ref-ID, and Editor-ID section again for the distinctions.)
  • Any NPC you define in an ESP will likely suffer from the infamous "mismatched head/body texture" bug (e.g. a head with one skin texture on a body with a different skin texture). Some people think that all you need to do is edit your INI files and you can fix this bug, but while that works for some mods and people, the solution doesn't work for others. If you don't want your NPCs to have mismatched skin textures, and you want it to be done reliably so it works for everyone, you need to define the NPCs in an ESM, period. Take the time to plan ahead.
  • If you do modify the NPC in the ESP, do not go back into the ESM and modify it there too, as those changes will get lost. With an NPC it's not so bad, but if you are editing terrain, you can end up with landscape tears and all kinds of texture, navmesh, or world problems. Basically, once something in another mod references something from an ESM, consider that "thing" in the ESM as "locked" and don't touch it again, because if you do touch it you'll break stuff.
  • Another issue with ESM files relates to how you edit them. It's probably easiest to explain using an example.
Let's say you want to fill in one of the unused homes in Goodsprings. This home in the vanilla files has a static door and boards across the door. You create an ESM which deletes the static door and the boards and adds a real door and an interior cell. All is well. You use FNVEdit to convert your ESP to an ESM, and all is still well. But then you edit your ESM in the GECK (using the GECK Extender or Powerup addons, because the vanilla GECK can't edit ESM files) and all of a sudden the static door and the boards are back, blocking your new real door.
There are a couple of ways to avoid this problem.
  • One is to only use ESM files for new things, and use ESP files whenever you modify something in the vanilla game, or in another master.
  • The only way known to keep your mod functioning correctly once it's an ESM, is to convert it back to an ESP every time you edit it, and then convert it back to an ESM using FNVedit when you are done.
  • Another way is to keep a copy of your original ESP for editing, then convert a different copy to ESM for actual use in-game. If you need to make more changes, edit the ESP, then copy and convert to ESM. (This is the preferable method, as it keeps a backup in case things go wrong.)

Because of these issues, depending on what you are doing, you might need to have both an ESP and an ESM for your mod.

There are plenty of mods that have been released as ESM only. As long as you do it correctly, it's not a problem.

Factions and Reputation

GIMP Posters and Images

How to do something

How to create a challenge
How to create a message
How to create a perk
How to create a Primative activators trigger volumes multibounds and occlusion planes

Tip Transparent Activators
Thanks to EPDGaffney and pixelhate of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Sometimes you want an activation prompt based on scripting conditions, not proximity. You need the mesh to be there; but not the texture. Activators require the collision and the mesh to be under the reticle to be activated, but the texture apparently doesn't need to be visible. That might be an invisible texture or the null texture set. Any texture would work (like a 4x4 saved as DXT1 format); so it doesn't need to be transparent (DXT5). Just bring the Alpha of the NiMaterialProperty to 0.

Caution: Some have had the null texture set not work for manual activation, but a fully transparent texture did.

To add an Editor Marker to a mesh NIF (easier to spot and move in GECK) it must have the following structure (nomenclature has to be respected):

  • A NiNiode named "EditorMarker" containing a NiTriStrips named "EditorMarker:0"
  • The Shader of the NiTriStrips must be a BSShaderNoLightingProperty with SF_VertexAlpha ticked.
  • The Color of the marker is changed by altering the Vertex Colors in the NiTriStripData.
  • Bit 5 (Editor Marker Present) has to be ticked in the BSXFlags.
How to make a working pipboy icon

Tip Pipboy Icons
Thanks to Leakingroof of the Nexus Fallout3 forum for the wiki article, and scrivener07 of the New Vegas Mod Talk forum for the basis of the following:
To edit an existing "Pipboy Icon" you will have to extract the default icon out of the vanilla "Fallout - Textures2.BSA" or mod file, and then move it to somewhere under the "Textures" folder in your data folder: such as "Data\Textures\interface\icons\<category>". Don't forget the "Message Icon" as well. (This is the icon that is used outside of the inventory.) It will most likely be named the same but with "glow_" prefixed on the front and located under other sub-folders of the "interface\icons\<category>" folder. The "<category>" may be "message icons", "pipboyimages_small", or "typeicons", etc.

Edit your replacement or create a new icon. The key to a functional Pipboy Icon is that the simple "white" image on a transparent background goes into the "alpha channel", has a square cropped size of a power of 2 (e.g. 256x256 pixels), and is saved as a DXT3 format DDS file. The resulting saved file should be exactly 65,664 bytes and placed in the appropriate "textures\interface\icons\pipboyimages\<category>" sub-folder. (The icon color when displayed is controlled by the HUD color for the Pipboy.) See the Nexus wiki article How to make a working pipboy icon for details.

To replace an existing icon: open the GECK and start a fresh new ESP mod. Name it something to distinguish it from the original like "<original item> - Icon Patch". Open the item in question and click the edit button and navigate to "Data\Textures\interface\icons\<category>" containing the new pipboy icon file and load that icon and the "Message Icon" in and save the mod. Load this "<original item> - Icon Patch" plugin in your game "load order" right after the "<original item>" plugin and it should overwrite the previous icon and you won't loose your tweaks if you ever want to update the original mod. (You can merge both the original and the patch plugins if you know how.) If you want to share this patch on the nexus you would upload the ".ESP" and the textures using the exact file structure you used. See the mod Misc Item Icons - New Vegas as an example of a plugin containing only icons to replace the use of the generic "scrap metal" icon for certain misc. items.

How to Move a Quest NPC
Thanks to madmongo and kingbeast88 of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
If you go to move an NPC (typically a "named" one) to another cell and are warned by the GECK they are part of a quest, you need to stop and check what is going to get broken if you proceed. Check what references them in the GECK (e.g. Scripts, Packages, Linked Markers, etc.). If any of those reference the NPC's location, you will need to update them with your new location for that NPC.

When you do move the NPC, be sure to "<Ctrl+C>" and "<Ctrl+M>".

Import Custom Videos

Item Creation and placement

Make Readius Screenglares

Markers

You don't need to make a new XMarker object. Just drag the existing XMarker static object into the GECK "Render Window" and it makes a new reference to that object. (Look over to the right of the object field a bit and you will see a count of "uses". It's used everywhere and you can use it too.) Then if you need to use and reference your marker in some way, you can double click the one you just placed in the render window and edit it's information to distinguish it from all others (for example, for the Edit-ID you might put "xMyModMarker", then later in a Script or AI Package or what not, use that Edit-ID for reference). The base Form-ID is blocked from view by the game engine. When you made a new one, it automatically assigns a new Form-ID. That is not blocked by the game engine from being viewed in game. Its the same way with all the markers in the game.

TIP Portable xMarkers
Suppose you want an NPC's "home" to be changeable to a new location. You can either place different xMarkers at the potential sites, or use a "creature" that is initially "disabled" for your Marker. Static objects like the default XMarker object cannot be moved, but a "persistent creature" set as a "quest object" can be moved and assigned as a "marker". Then drop the "marker/creature" in the new "home" cell. "Creature" positions are always updated in the game, whereas static objects are not, so you don't need to use the "enable/disable" trick to update their location. You then assign a "GoHome" travel AI Package to the marker as it's destination, and another "sandbox behavior" AI Package to let it wander the immediate area of the marker. See the wiki article GECK: Bethsoft Tutorial NPC population.

PAINTdotNET Normal Maps

Recipes

UV Mapping

XML

XML is a "data definition" structure, based upon a "data schema" which was defined by Bethesda. They didn't publish their "schema", but some things have been learned about it. However, without a published scheme, you must either use only elements found in other XML files, or be willing to experiment.

Music and Sounds

Fallout New Vegas features a brand new music engine versus that of the one used within Fallout 3 and Oblivion, which has effectively rendered the music tab within the creation of cells useless. See the Wiki tutorial Fallout New Vegas Music for the description of how this now works.

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

NOTE: There is a distinction between, and in the requirements for, each type of sound. Stereo won't fade (attenuate) over distance; mono will. This accounts for why some fx and all voices need to be in mono.

Some sounds appear to be "hard-coded" into the game engine in that they are not found as separate files in the loose files under the "Data" folder nor in the "Fallout - Sound.BSA" file. (The "havok" collision sounds are an example of this.) Some sounds have an entry in the GECK, that appear to never be used despite the fact you can open a form and see them entered. (Another example of differences in behavior is with the heartbeat sounds for low health, which can be replaced by other sounds externally in Windows Explorer, despite having entries in the GECK which it claims are unused.) Consequently, some experimentation is usually required.

Stereo sound files are considered superior to mono because they have relative 2D positioning built into them already. However in reality, for games, when you want to achieve a 3D surround sound positioning effect, in almost all cases it's mono files that need to be used. That way the game engine kind of re-stereos them into the entire 3D sound output of your gameplay. There are exceptions to this, and often ways to ignore this rule, but in general, game designers use mono for 3D sounds and stereo for 2D, even in modern games.

File folders by type:
  • collision sounds made by objects hitting other objects or the ground are aspects of the "Havok Material Properties" (edited with NifSkope), and are addressed under the topic of "Collision" in TIP: Collision Impact Sounds. These sounds are hard-coded into the game engine, but the main game typically uses only 32 of the identified 96 possibilities.
  • music (Data\Music): location/event soundtrack. MP3 stereo files.
  • songs (Data\Sound\songs\radionv): radio playlists. Individual song title files begin with the "mus_" prefix, and a "_mono" suffix. Mono: WAV (Pipboy) or OGG (radios/speakers) files; or Stereo: MP3 (Pipboy) files. Besides the obvious problem of a gigantic difference in file size (WAV files are roughly 5 times those of MP3s), this engine will actually play a stereo WAV file on a radio station twice (first the left channel will play, and then the right channel). This problem does not occur with stereo MP3 song files. See the TIP: Format to call a song for more detail on file formats for "radio stations".
  • sounds (Data\Sound\fx): noise/ambience/special effects(fx). WAV mono files. There are a number of sub-folders in the BSA under this category. These are just a sampling of common interest under this category:
  • amb (background noises): OGG files.
  • fx (sound effects): WAV mono files.
  • mus (location music): OGG files. Sub-folders for types:
  • bttl\allcityintro
  • bttl\allcityoutro
  • bttl\allruralintro
  • bttl\allruraloutro
  • endgame
  • inc\night
  • inc\peaceful
  • inc\day
  • inc\creepy
  • mysteriousstranger
  • tenpenny
  • npc (by type of actor): WAV mono files.
  • voc (sound effect "voices"): WAV mono files.
  • voices (Data\Sound\voice): dialog. OGG and LIP mono files.

Tip Adding a new sound noises or fx file

Thanks to EDPGaffney of the Nexus Fallout "New Vegas GECK and Modders" forum for contributing clarifications to the following:
Place your sound file somewhere in "Data\Sounds\fx\<YourModFolder>".
If your sound file (WAV, MP3, OGG, etc.) is imported, be sure to strip out any "metadata" (cover art, album name, author, etc.) it may be encoded with as the game is not prepared to deal with it. There are a number of tools available on the web, including the Audacity (free) sound editor, which can covert other formats.
NOTE: The GECK seems to see/list all sound files as MP3, regardless of their actual extension (i.e. WAV or OGG). The extension does not seem to matter to GECK and the sound plays fine in game, but only WAV files play in the editor.
If you intend to "overwrite" a vanilla sound file, you must first extract the sound file from it's BSA file into it's intended folder. This is primarily to create the correct folder path for your replacement file.
  • Your fx/sound MUST be a mono, 16-bit sample size, and 22, 32, or 44.1KHz sample rate WAV (ADPCM: "Adaptive Differential Pulse Code Modulation") file, if you want to be able to click "play" and hear it in the editor. No other file type plays in the editor, even though many vanilla files are in other formats. Its a GECK thing.
  • MP3 sound files (other than "songs" for "radio") should be mono, 16-bit sample size, 44.1KHz sample rate, Bit Rate: constant, 64 kbps.
  • OGG Vorbis sound files should be mono, 44.1KHz, Bit rate: constant, 48kbps (128kbps for dialogue). Still need to generate WAV files to make LIP files since GECK won't make them, but once the LIP file is done you can dispense with the WAV file. (See the Dialogue & Lip-synch section.) On average, an OGG file uses much less memory.
When in doubt about which "KHz sample rate" to use, be guided by what similar vanilla sound files in the same location are using.
  • Open GECK.
  • Look in the object window for "Audio", then click on "Sound".
The list here is not of actual sound files, but rather a list of GECK Form-IDs that point to the sound files.
Then you must create a sound object in the GECK. You can't directly link the audio portion of your weapon (etc.) directly to your sound file. Again, you MUST create a sound object first. And then link that object to your weapon in the "Art and Sound" tab. You must be able to hear your sound play as a GECK sound object BEFORE linking it to your weapon.
To create a new sound record from scratch:
  • Move to the right window, right click and select "New".
  • Click on "Add sound file".
  • Adjust "Attenuation distance".
Check stock vanilla sounds of the same type (e.g. a gunshot) for a good idea on how to set them.
  • Flag "Mute when submerged", then the "OK" button.
Check stock vanilla sounds for other flags and settings as well.
  • If your sound is a dialogue then flag "Dialogue sound".
OR, edit an existing sound record to create a new one:
  • Right-click and edit one of the existing sounds. Ideally find one of the same type as what you want (i.e, to make a new gunshot sound, use an existing gunshot sound).
  • Make your modifications to that sound, and point it towards your own added sound file.
  • Click "OK", and it will ask: "Create a new form?"; to which you say YES, then make note of the new Form-ID.
  • Now when you are in your "Art and Sound" tab (if its a weapon or something) just click on the sound buttons and find your new sound by the new Form-Id you noted.

TIP Format to call a song

Thanks to EDPGaffney of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
For a radio station, a "song" file will ideally meet the following requirements:
  • Your song must be converted to .MP3 format if you want it to be recognized and used on a game radio station in stereo.
  • 128 kbps CBR ("Constant Bit Rate"; 256 is said to work but not tested) in stereo.
  • Mono files will play, but obviously they won't play in stereo.
  • Most tutorials on radio stations only refer to WAV files, giving the impression that they are the only file format that will work. This is not the case, but there are specific differences to use MP3 songs. (Both Stereo and Mono MP3 songs will work if the same procedures are followed.) Other than the ability to be in stereo, the other huge advantage to using MP3 files is how much smaller they are (roughly 1/5).
  • To call a song in a radio station: .MP3s NEED braces (see example below) around the response name; but .WAV or .OGG files won't work with them. (The reason the vanilla stations have mono .OGG files as well in the Fallout - Sound.bsa file is: those are what plays in the world on a speaker/radio that isn't your Pip-Boy.)
If you look at any of the vanilla radio stations in the GECK, they all use .MP3s, and the name of each entry is something like this:
..{Song 1 A Winter Romance}
Note that like the vanilla script vCountryRadioQuest, you should put two spaces (represented here by two periods to be visible) before the first brace. (Not tested without.)
If you save mono OGG files in the radio folder that are named identically to the "song" files but with _mono appended to them (e.g. "song1.mp3" and "song1_mono.ogg"), the radio station will play them in the game world at the correct time. I've seen a lot of different ways to encode them but I have always used 65kbps mono and (I believe) 22050hz, and have always had them play as intended.
  • Seddons video guide on how to make a station is a good one, but its major flaw is that he was operating under the presumption that mono WAV files were required. You must make the above calling convention adjustments if using MP3 or stereo files instead.
  • DorostheConquerors text-based guide is slightly more comprehensive than Seddon's if I recall, but suffers from the same mono WAV file presumption, and the same adjustments apply.

TIP Replacing Battle Music

Thanks to KadoDragon and DaemonGrin of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
You need to know what audio object (in the GECK) to edit in the audio tab which means you need to know the names of the battle songs you want to replace. All you have to do once you have that information is redirect the audio object to the wav, mp3 or ogg file of the new one. Or you can find the mp3, wav, ogg you want to replace with your own music and just rename yours to the same names of the vanilla files (after backing them up of course); making sure to leave them in the correct directory path(s) in the "Data\sound\" folder path. Not hard at all. Really the hardest thing to do with sound is creating the intro and outro segments: they are super short and need to blend nicely with the fade-in of the battle music.

The game combines the intros and outros from the Data\Sound\fx\mus\bttl sub-folder and then plays the music from the appropriate Data\Music\ sub-folder.

TIP TCD and Gunfire Detection Events

Thanks to punchbattle of the "New Vegas Mod Talk" forum for the basis of the following.
A really helpful command is called ToggleCombatDebug (TCD). Running it in-game adds graphical elements to combat that help give you a better understanding of what's going on under the hood. For instance, one really helpful thing it does is create "teal colored" bubbles (called Detection Events) to mark sounds made by the player and NPCs. If an NPC is close enough to a Detection Event, they'll "hear it" and begin searching for the enemy it belongs to. This revealed something very ... odd. And bad.

The only part of a gunshot that creates a Detection Event is the projectile, and only at the point of impact. This means NPCs will completely ignore the sound of the gun going off, and instead choose to wander right into the enemy's crosshairs. Bethesda is infamous for their "less than realistic" stealth systems, but learning about this completely ruined stealth for the author and made them want to fix it.

There's a function that lets you make your own Detection Events. It's called (strangely enough) CreateDetectionEvent.

An initial idea was to attach a script to a gun, and have it create a Detection Event at the location of the shooter whenever they pull the trigger. This didn't work for a number of reasons. Instead, using a quest that checks for anyone with a gun doing an attack animation, and casting a Detection Event spell on them works perfectly!

For anyone reading this who wants to mess around with Detection Events as well: Any field that asks you to assign a Sound Level to a weapon or projectile is actually asking you how big you want your weapon's Detection Event bubble to be. But remember! Weapons don't actually create Detection Events when fired, despite what the GECK seems to imply: only upon projectile impact! The size of each "Sound Level" bubble is controlled by these settings:

  • iSoundLevelLoud - 100
  • iSoundLevelNormal - 50
  • iSoundLevelSilent - 10

People say that Detection Events can't be larger than 100, but this isn't true. You can assign values into the thousands, and it still works. Also, 100 is ...very small. (As in 128 game units is the equivalent of the default 6 foot tall NPC actor.) Makes one wonder if that isn't perhaps a percentage multiplier to the "standard" bubble size; whatever that might be?

TIP Weapon firing sounds

Thanks to Scott Clemmons of the GameAs "Fallout: New Vegas" forum for the basis of the following:
In New Vegas, there are two different 3D shooting sounds for many weapons: A normal shooting sound, and a distant shooting sound. As the distance between you and the shooter increases and the normal shooting sound starts to fade, the distant sound should start taking over while the normal sound continues fading away.

The distant sound has a bit of an echo, so the effect of using this different sound for shots from a large distance is nice. The distant sound doesn't start playing until the normal shooting sound has stopped playing completely. So as you get further away the normal shooting sound fades until the gun is almost silent. Then, when the sound is completely gone, the distant sound takes over. Usually, this distant sound is disconcertingly louder than the fading at the end of the closer distance sound!

So what happens? You have someone shooting at you, and the further you get away, the less loud the sound gets. But then when you pass a certain distance, the shooting sound goes from nearly silent to relatively loud again.

Using the 'getdistance player' console command, you can track the distance (measured in game units) between the shooting NPC and yourself. Approaching the 2400 unit distance the gunfire sound is almost silent. Then, upon increasing the distance between yourself and the NPC a little more, the louder distant shooting sound takes it's place.

In the GECK Weapon record Form there are "attack sound" fields on two different tabs: "Art and Sound", and "Mod Info".

  • Art and Sound tab: Unmodified weapon attack sounds.
  • Mod Info tab: Weapon attack sounds when an appropriate "weapon mod" is used: i.e. "suppressor/silencer".

Testing showed that adding a "Suppressor/Silencer" "weapon mod" seemed to have no effect on the sound heard in most cases. Turns out a huge part of this is the specific sound files chosen, and for which of the different fields. Apparently many mod makers use the same sounds for both tabs (probably not understanding the different roles).

  • The "3D" field's sound "attenuates" (fades) as you move from the point of origin starting at approximately 255 units up to 2400 units distance.
  • The "Dist" sound is a 3D effect that kicks in approximately at 2400 units up to 8500 units.
  • The 2D field sound does not "attenuate" (fade) with distance. This is the "1st person" sound: "right in your ear".

The following choices illustrate the difference of this effect for a .308 caliber weapon (The 'Gobi Desert Sniper Rifle', using WMX to modify it). The "CCSP" files chosen are from the Combined Community Sound Pack (CCSP). Other choices depend upon the mods installed.

"Art and Sound" tab: (Unmodified weapon attack sounds).

  • Attack Sound (3D): "CCSPsniperrifle3d" (there are several choices and all are generally "loud".)
  • Attack Sound (Dist): "CCSPsniperrifledistant" (this in particular is a more muffled distant sound than other similar options.)
  • Attack Sound (2D): "CCSPsniperrifle2d" (there are several choices and all are generally "next to you loud".)

"Mod Info" tab: (Modified weapon attack sounds).

  • Attack Sound(s): "CCSPsniperriflesilenced3d" (shorter, quieter 3D shot.)
  • Attack Sound (2D): "WPNRifleAssaultSilencedFire2D" (shorter, quieter 2D shot.)

Now an unmodified rifle sounds as expected, and one equipped with a silencer is obviously quieter. The contrast between the fading 3D sound and the "Dist" sound is something the sound file makers will have to calibrate. But using a more faded "dist" sound will reduce the jarring effect.

Navmeshing

(The process is essentially the same between the GECK and the Creation Kit. See also the Worldspace Creation section.)

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

TIP Bug extending NavMesh

Thanks to EPDGaffney of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
There's a massive bug that has a 'cult following' of sorts, in that it doesn't seem to be discussed quite so often as most of the other fundamentals of modding, but when you do find a discussion about it, there is an unmistakable fire at work, and it burns with unmatched vitriol.

It seems that if your plug-in is not a "master file" (.ESM), there's only so much you can do with navmeshes before the game just can't take it and pathing simply breaks.

In my case, I had an interior cell basement with a number of roaches, and they had a very specific 'setpiece' AI. It all worked perfectly. Then I built the rest of the area and it still worked. Finally, when I navmeshed just the adjacent room (extending the same navmesh), I incurred a fully reproducible form of this bug (which takes many forms, though this is my only first-hand experience): everything in the entire space works 100% perfectly -- until I load my save and test it again. That's right, everything; and the amount of intense scripting and 'scenes' occurring here is extraordinary. But if anything causes the navmesh to be re-encountered again after any attempt to resume the same game session from a previous save point (load my current save, quit to the main menu and then load my save, load another save, or anything that doesn't involve closing the application and relaunching the ".EXE"), the roaches will just idle there, or sometimes run full-speed into the wall or door perpetually and never get where their package is meant to bring them. Sometimes they'll even teleport as they idle, gradually materialising closer to the Package Target but not quite getting there. Leaving and returning to the room without loading a save game appears to work fine.

So, I found some information on my trusty Google machine, and decided to try my file as an ".ESM". Flawless results every time. So try that. Just make sure you back up your file. ".ESP to .ESM" conversions have a bit of quirkiness unless you understand the "rules" pertaining to them. (See TIP: When can you use an ESM only mod?.)

Making an ESP file into an ESM can solve some problems with spawning actors appearing "jammed up" in a particular spot instead of where you placed them.

Toggling "ArchiveInvalidation" seems to sometimes clear up an AI package acting buggy when making changes to your navmesh. However, this will not satisfactorily resolve the problem for your users.

ONAM records are special records created that allow Master files to communicate with one-another when references need to be passed. xEdit ensures that as part of the "Plugin to Master" conversion process, these ONAM records are built and correctly ordered. This is why it is better to make the "Plugin to Master" conversion using xEdit. See the TES5Edit Documentation section on "Converting a Plugin into a Master".

Summary from a Skyrim discussion:
Basically when an ESP plugin wants to change something in the base game, it either adds a new object, or has an object that shares it's ID with something in one of it's master files. Since the ID is the same as the one in the master, only the one loaded last is used. This is called an override.

ESMs cannot normally do overrides. If they add something that shares the same FormID, you get a collision error. EXCEPT if you have what's known as an ONAM record. Basically this is a small sub-record in the header of the file that tells the game engine: "This ID is overwritten in this file".

Although the CK won't add an ONAM list [but FNVEdit's "MasterUpdate" function will -Editor], you can still ESM'ify by changing the extension to ESM, opening as "Active", then saving. There's no guarantee it'll fix anything w/o an ONAM list though.

The ONAM lists seem to help the engine's object permanence when an ESM overrides its master(s) cell children, ensuring the overrides A) work properly and B) aren't forgotten when they unload. It's a TES4 (header) subrecord (ACHR, NAVM, LAND, REFR, PHZD). ThePitt.ESM was the first Beth plugin to get an ONAM list and every applicable Beth ESM since has one (save for one iteration of Update.ESM). Not sure exactly how it works but, in Oblivion, if one moved something from Oblivion.ESM around with another ESM flagged plugin, the ground would vanish in game. This is most likely why Oblivion's Shivering Isles was merged in and its ESP was empty. Currently [2011], the only way to get an ONAM list is with FO3/FNVEdit.

Note though, ESM's are not 100% immune to navmesh related bugs.

You cannot slave an ESM to an ESP; only the other way around. You can split an existing ESP into an ESM/ESP pair: as long as the items in the ESP are "non-edits" of the new ESM (things that exist only in the ESP and do not edit anything from the ESM: i.e. "all new content") Such ESP items will be beginning with "mod index"/form-id 02 when only those two files are loaded. It will translate into loaded save games properly. Any records that go directly into the ESM will be treated as a new mod and reset on first load.

TIP Draw Navmesh Quickly

Thanks to kingbeast88 of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
To quickly draw your extended navmesh boundaries:
  • Make your first triangle. (See any of the above tutorials.)
  • Then hold <Ctrl> and <Right-Click> your mouse at each of the next vertice locations. The nearest boundary line will automatically redraw to include that vertice.
  • Press <Tab> when you need to switch sides of the two vertices of the boundary line currently selected to extend in a different direction.

TIP Navmesh Boundaries

Thanks to madmongo and EPDGaffney of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
NPCs will stray slightly outside the bounds of a navmesh, so you don't have to be super-precise in laying down their boundaries. If you're a bit sloppy the NPCs will still usually manage to figure out how to go where they should.

"Off-screen" NPCs do not require any navmeshing. An NPC was set to run his script even when the Player wasn't in the area (meaning: unlike the majority of NPCs, his No Low-Level Processing box was not ticked in the G.E.C.K.) but without any navmeshing. He acted "funny" when on-screen with the Player, but the game updated his task to "completed" once the Player left the area.

If you have a container with items in the area, and the gap between the navmesh and the container is too small, it is at least theoretically possible an NPC in combat might grab a more powerful item from the container. However such instances should be rare.

TIP Navmeshing Exterior cells

Thanks to madmongo, EPDGaffney, and kingbeast88 of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Most tutorials on "navmeshing" are done in interior cells. Which means they don't have to deal with "cell boundaries". However, "exterior navmeshes" DO have to deal with cell boundaries, and this can lead to some confusion.

Outdoor navmeshes work mostly the same as indoor ones, except that the navmesh path can't cross cell boundaries. However, when the navmesh boundaries are adjacent at the cell boundaries, NPCs can cross between cells. See the How to edit pre-existing nav-meshs for an exterior worldspace GECK Video by 001cf73 for the basics.

When you finalize your outdoor navmesh, it will attempt to link up with the neighboring cell's navmesh. Any line segment along the edge of the navmesh that successfully links to the next cell will turn green. Navmesh vertices (the "node points" the lines align with) will often end up being automatically split by the GECK so that it can match up vertices. If part of the cell border isn't green, then the navmeshes between the two cells in that location aren't linked and NPCs won't cross from one cell to the other properly.

You don't have to be exact when lining up vertices on your navmesh, but you have to be reasonably close. If your navmesh triangle edges are too far away from the triangle edges in the next cell, the GECK won't be able to match them up. You don't have to "match vertex for vertex", but if you don't "match vertex for vertex", what can often happen is that part of the triangle is too far away vertically (Z-axis) from the triangle in the next cell and the GECK refuses to link it. (You can just lift a navmesh's vertex a bit up (hold <Z> to lock it to the vertical, or Z-axis) to make sure it's above the ground, and then hit <F> like any other object to snap it to the first piece of collision that's directly below the vertex. But, watch out that you don't drop your vertex onto a piece of virtually invisible light and assume it's on the ground when it isn't.) So "matching vertex for vertex" will generally give you the best results.

If the cell boundary line isn't turning green, delete the navmesh triangles along the cell border and redo them so that the vertices are closer, then finalize your navmesh for that cell again.

Moving vertices is often not the best way to go about adjusting the navmesh. If you're not careful (or aren't used to 3D modelling or UV-mapping) you can accidentally end up with triangles that have flipped normals and a navmesh for that cell that doesn't work. In which case, you're better off deleting any triangles that go under your addition (e.g. in the referenced video: a house straddling both cells) and then add new triangles to circumscribe the addition (e.g. the house). Remember, any cell that you change the navmesh in needs to be finalized. Just making navmesh triangles isn't enough.

Observations:

  • Make sure to check your navmesh work from all different angles (that is: rotate it) to be certain it really is the shape you think it is.
  • Apparently there is a check cover edges button which needs to be pressed before pressing finalize in all cells affected. So as long as you have no warnings, and have your vertex Z-axis lined up close with your triangle edges touching each other, this will most of the time create a new cell boundary (green) line.
You can occasionally create this "green line" where no boundary was before by using only finalize, but this doesn't seem to be the case when you delete them or make edits that remove the "green line".
  • Keep your navmesh "triangle" count to 500 or less, at least in exterior cells. If you exceed that limt, the engine does "weird things" like spawn items randomly that otherwise are not placed there.
  • You don't need to draw cover, really. That gets done by the button designated for it on the navmesh toolbar. Never had a problem with the way the GECK does it automatically. Haven't really pushed its limits or anything, so don't know how it would do in a really complex room, but think the average navmesh would have adequate cover drawn by the GECK with no input from you afterwards.
  • You need to navmesh places where AI will go, but don't need to bother with it anywhere that can't have AI in it. However, remember that the player can have companions, and they will need a navmesh. You can of course force the player not to bring companions in your mod, but you should probably have a good reason for it.
  • Note that nothing bad will happen if your companions can't come with you. They'll just wait where the navmesh ends and then teleport to you when you exit the cell if need be.

TIP Navmesh marker for Portal relocates

Thanks to chucksteel and madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
After editing a navmesh, the green triangle that indicates a portal appears ... not under the door, nor near the marker, but in some completely random location. What gives? Is this a problem?

Nothing is wrong. The portal will function properly, allowing followers and NPCs to use it correctly. The "green triangle" only confirms the connection and does not need to always be under the portal marker itself. The player and NPC's will always spawn properly on the portal marker regardless of where the navmesh green triangle is located.

This seems to only happen if you create a navmesh, save the mod, then edit it later. If it really bugs you, then you can delete the entire navmesh for the cell and re-do it. No big deal for a small simple cell, but probably not something you want to do for a very complex navmesh in a large cell.

NifSkope Mesh Editor

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

TIP Merging parts from different source files

Thanks to madmongo and M48A5 of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
Sometimes you want to "mash up" parts of mesh (and texture) files from different sources. You might think to export parts of models from the source files as "*.OBJ" files, and then import them into your "*.NIF" files as "*.OBJ" in NifSkope. This is not how this is usually done, and will generally produce "array Shader Textures are invalid" and "device position incorrect after block number ##" errors. These are caused by missing BSShaderPPLightingProperty entries, and thus no BSShaderTextureSet.

Generally speaking: "*.OBJ" files are for use importing into Blender, and should be exported as "*.NIF" files to work in NifSkope. Blender is a much better tool for this sort of thing.

When moving parts of meshes between "*.NIF" files in NifSkope, use the "Copy Branch" and "Paste Branch" functions.

NifSkope does not display textures from BSAs by default. You have to point NifSkope to the BSA files location in it's settings. In the NifSkope UI, left click "Options". In the drop down menu, choose "Settings | Resources". In the panel that opens, you will have to add the path to the BSAs. It should be the complete path, starting with the drive letter. When you open "Resources" you should see a complete path to (and including) the "Data" folder. If not, click on "Auto detect game path".

When using custom textures, you need to set the texture relative path to the loose file in the NIF with NifSkope. This is done under BSShaderPPLightingProperty/BSShaderTextureSet. ("Relative" meaning the path starts BELOW the game "Data" folder: as in "textures\<some sub-folder>\<some filename>.dds". No drive letters or any path above "textures\"; without even "Data\". See the wiki article How to fix hard-coded texture paths in NIF files for specific instructions.)

TIP Model Lighting

Thanks to EPDGaffney and pixelhate of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Q: When you change the texture of an item with the GECK it always ends up different then the ground texture even if it's using the same texture. Why? Example: railroad tracks roadbed and ballast is always different than the surrounding terrain.

A: The model determines the lighting in this game. I'm asking, in the vanilla game was it seamless? I don't mean the 2D ".dds" texture file; I'm asking, did it look seamless in-game? [No, it doesn't.]

(For any unfamiliar graphics related terms, please see the TESTG Glossary.)

So, the way it works is an object is lit dependent upon several factors. The first is the normal map and its alpha channel. Obviously, you're telling me these are all the same texture, so that's not the problem here but it is certainly something to be aware of. The normal map behaves as you expect, and its alpha channel is used as the specular map. Generally, you want that specular map to be mostly dark, down to drawing distinctly different effects in-game from a portion of a specular map that is 5% bright and 8% bright, for example (that is, 0% is pitch black, and bringing the RGB values all up 5% from 0 is 5%).

Now, be aware that the specular map is manipulated in NifSkope but its effects are completely ignored visually until you see it in the GECK or the game, though the GECK usually doesn't display it accurately to the way it will look in-game.

So, now that the basics are out of the way, the rest of the lighting stuff is determined per model in NifSkope. Open your train tracks model in NifSkope (located in Meshes\dungeons\metro\exterior), and click on the dirt portion:
TrainTracks_Fig-01
(See TrainTracks_Fig-01. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)


This tells you quickly and easily which NiTriStrips it is. Expand that and go to the NiMaterialProperty node that is attached to the NiTriStrips for the dirt:
TrainTracks_Fig-02
(See TrainTracks_Fig-02. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)


The Specular and Emissive both have an effect but it's really the Glossiness entry that's likely to have the effect you're looking for. It will take a good bit of trial and error.

Other things that can have an effect are the Shader flags:
TrainTracks_Fig-03
(See TrainTracks_Fig-03. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)


and though not in this case (unless the terrain model has it), other texture slots besides the diffuse and normal maps:
TrainTracks_Fig-04
(See TrainTracks_Fig-04. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)


The NiTristripsData can also have vertices colored (used for shading purpose). If that's the case, that part will always look darker no matter what changes are made in the previous settings.

However, looking at images of the vanilla [railroad track] graphics, I think they just did their UV maps in a way that makes the textures look more cohesive just where they meet, perhaps, but they definitely aren't seamless, at least in the screenshots I'm seeing.

Radioactivelad and KiCHo666 add:

The engine only supports a limited number of visible light sources on a given piece of landscape, and that includes the Pipboy light. Static objects can handle more, but even they are pretty limited. Another thing to consider is light radius overlapping. From experience, one object can have up to 3 lights affecting it with the light radius overlapping. If a 4th one is introduced, then the 4th light will simply not affect that object or one of the previous 3 lights will stop working. The 3 light limit seems to be standard for the forward type of rendering that FNV uses.

TIP Rotate Mesh

Summary from How To Rotate A Mesh In Nifskope
  • < Right-click > the object in the NifSkope "viewport", then "transform | edit | R (rotate in +/- 1-180 degrees)".
  • After you have it positioned correctly: < Right-click >, "transform | apply".

TIP Shiny lines in exported NIF normal map

Thanks to TzeHuen, pixelhate, and KiCHo666 of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
The NIF tangents and binormals updater command line tool does a better job than NifSkope to fix this problem, and can do batch jobs. But it can also be resolved manually in NifSkope by:
  • Make a copy of your mesh for this test.
  • Open the test NIF in NifSkope and select the NiTriStrips,
  • <right click> and select "Face Normal" then "Smooth Normals".
If the shiny lines disappear, then they are mesh related and probably due to the export settings from your 3D program.
  • If that doesn't resolve the problem, then select "update tangent space".

Scripting

Other sections have relevant information to this subject. The following "Tips" in particular are applicable.

  • See the Custom NPCs section regarding scripting "AI Packages".

Refer back to the section GECK Form-ID, Base-ID, Ref-ID, and Editor-ID as necessary until the different types of "IDs" become second nature. The distinctions are crucial to getting various script functions to work correctly. They will primarily work with either Editor-ID or Reference-ID values. They seldom work with both, but if so the syntax must be read carefully to determine which type of value is used for each parameter.

Even if you have another favorite text editor, strongly suggest using Notepad++ along with the GECK specific syntax highlighters listed in the Programs and Tools section. These will catch most syntax errors, saving you a lot of grief.

There are 3 kinds of scripts:

  • The default when creating one is an Object script. Which means this is a script that can be attached to anything in the object tree of GECK that has a "script" drop down field ... except for Quests and Base Effects.
  • Quests require you to select the script as a "Quest" type. They are called (triggered) by various "Quest" conditions.
  • Base Effects require you to select the script as an "Effect" type, available when you are on the window with the "Script" drop down list. Only those type of scripts will show up in the list.

Effect scripts attach on "Assoc Item" just below "Effect Archetype". But Object and Quest scripts are straight forward on where to attach the script: to "Objects" or "Quests" respectively.

Reference variables must be "defined" and assigned a value before they can be used in a command. This often occurs in one of the script types that are executed before the one you are looking at in the moment. But don't assume they are: verify if your script won't save.

So in short: creating a script & saving it (which "compiles" it; turning it into actual code instead of "human readable" instructions) is required for it to then exist. If a script fails to compile, then it won't be saved. Use CIPCIS to determine if it is a simple syntax error preventing your script from compiling. But bear in mind CIPCIS is not aware of "script extender" syntax, so such will produce as error as an unrecognized command. Otherwise the problem is most likely either using an inappropriate command choice or the wrong type of value for the function in question.

But merely existing in a saved/compiled form means nothing towards having that script tell the game engine what to do. You must attach it to something (based upon which one of the 3 types it is) to then have the script code interact with the other dynamic game code.

  • GECK Extender NVSE Plugin. Project to extend GECK functionality and bug fixes. Compatible with all NVSE script extender plugins. (Do not use together with GECK Powerup (nor the Forked version), which it replaces.)
  • GECK 1.4 Powerup Mod. Comes in a "standalone" version for the "vanilla" GECK functions, and one for GECK with NVSE functions. It fixes and improves some issues while providing the missing messages when the GECK compiler finds an error or warning, and lets you save a script without compiling it. Considered "essential" by experienced mod creators. (Replaced by GECK Extender. Do not use both together.)
  • CIPSCIS: Scripting for Beginners HTML Tutorial. Does not support "script extender" syntax.
  • Top 15 Best Practices for Writing Super Readable Code HTML.

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

TIP Best Practice Do not begin EditorIDs with numbers

Thanks to madmongo and EPDGaffney of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:

The GECK confuses Editor-IDs, script names, and variable names that begin with numbers for Form-IDs. They are not the same and scripts will fail to compile with (if using the GECK Power-Up plugin) messages to the effect it can't find the (perfectly valid) command. It's "best practice" to avoid prefixing anything with numbers. Do use a consistent naming convention, such as beginning Editor-IDs and variables with the initials of the mod, so they are grouped together in the GECK's lists by type making it easier to locate them for editing later.

When you create Forms for your mod, the GECK assigns them Form-IDs in sequence. This means in the "Object Window" right-hand pane, you can expand the (collapsed by default) column between the "Editor ID" and "Count" field labels so it shows the "Form-ID". You can <Click> on that field label to sort them. As your mod will likely have the last "mod index" of those currently loaded, your forms will be sorted to the top when sorted into "descending" order.

TIP Best Practice Encapsulation Parens Brackets and Braces

Thanks to DoctaSax of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
Do not get careless when choosing how you "group" (Encapsulate) expressions in FNV scripting. For instance, some functions need to be "encapsulated" using "(parentheses)", aka 'parens', in order to return a single value. "Parens" around complete expressions are almost always not harmful and can help the line parser in determining the order in which to process multiple expression combinations on the same line. (See NVSE Expressions on operator precedence and overriding the default precedence.) However, "[square brackets]" are exclusively used for handling arrays and NVSE string vars. "{Curly Braces}" encapsulate a function as an argument to another function. (i.e. "if eval (somefunc {someotherfunc arg1 arg2} arg3)" ). Mixing up their use can allow a script to compile, but fail the first time it is run. Their different uses can often be easily overlooked when trying to determine why things are going wrong. Best practice is to use "parens" unless you know you need to use something else.

TIP Best Practice Function parameter separation with commas

Thanks to DoctaSax of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Some people are under the impression that the use of commas on script functions causes errors.
Using commas to separate function parameters is actually preferable, especially when you use advanced NVSE scripting (CO, arrays, UDFs with dynamically constructed parameters in the call line). Much like extensive use of parentheses, it not only keeps things more readable for yourself, but prevents errors at compile or at run time. It isn't usually needed for simple code, but it's a good practice to get into for when it is needed, so let's please not advise against doing it.

TIP Best Practice Type prefixes for Variables

Thanks to EPDGaffney of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
It's easy to get confused as to what sort of values are "valid" for any given variable once you get beyond a simple script, especially if it was defined elsewhere than the current script. When you "declare" a variable, you give it a "type" which determines both which sorts of values it can accept and how they are stored. If it's expecting a "reference" then you can't assign it a "number" or "string". Experienced programmers have learned it's a "best practice" to use "type prefixes" in front of their variable names to help keep them straight.

These "type prefixes" are lowercase letters that go before a capitalized variable name, denoting a specific programming use for that variable.

  • b - A boolean (aka "bool") is a variable that can be only true (set to 1) or false (set to 0). We don't have true bools in this GECK programming language, but variables that a programmer knows will only ever be set to true or false can be referred to as a bool and its name can be chosen accordingly for organizational purposes. They are technically defined as the short/integer variety of type.
Example:
 short bFoundJohn
 int bFoundJohn
  • f - a float is a variable that can store numbers that are in between integers. Essentially, numbers that can have decimal values (e.g. "1.001"). Some functions will return a number that is in between two integers, and if you want to store that value as a variable for use in your script, it generally must be declared as a float variable. A popular one is GetSecondsPassed for example.
Example:
 float fTimer
  • i - an int variable is the same as a short variable, but we only use the 'i' prefix so that we can use the 's' prefix to denote a string variable, which we'll talk about in a minute. Int/short variables can only be integers, or whole numbers. If you try to use one to store a value that should be a float, it may round down (truncate) to the nearest whole number or it may just not work. These are the most common variables for our use.
Example:

int DoOnce
int iDoOnce
int bDoOnce
short DoOnce
short iRaidersKilled ; (probably the number of raiders player killed)
int bRaidersKilled  ; (probably if the player's killed all the designated raiders, or if they've killed at least one, depending on what you want)

  • s - a string variable is a weird one. It's text, and requires special treatment. It tends to be stuff the scripting language doesn't really understand and just takes on faith that you do. You probably won't work with these for a while. In general, the content of a string variable is for "human consumption"(such as a message or note) rather than use by the script/program.
Example:

string_var sDogName ; whatever the player typed for a dog's name at some point in your quest, so that it can appear in notes
string_var sBone  ; whatever bone/node in the .nif model is relevant to the script for whatever reason

  • a - array variables are incredible, but an "advanced" technique. It's a steep learning curve but they're easy once you've passed that. They are basically like form lists, but they are made dynamically at run-time via script.
Example:

array_var aNCR  ; maybe every actor in the area that is in an NCR faction, or maybe every NCR actor in the entire game, including all loaded mods
array_var aEntry ; this is a standard array variable that could be called anything and still work, but it's typically the name given to a short-lived variable that is used during any number of operations carried out on the larger array that contains all the stuff in the group you're working on.

WARNING: Mixing up references and base objects, especially when assigning them to arrays, is one of the most common and lethal mistakes in Gamebryo scripting. Always double check what the type of value any function you are using to assign them to an array is returning. Unfortunate results can become baked into save game files, causing bloat. The only remedy in such cases seems to be deletion of the ".nvse" file for the "save game" when it occurs, which will affect other mods which depend upon information saved in it with unpredictable results.
  • r - reference variables store a reference to an instance of an object placed in the game world. This is often an actor or a specific object that you'll need to refer to later in your script.
Example:

ref rSelf  ; often used in GetSelf operations for functions that may require it, like some uses of PushActorAway or KillActor
ref rTarget  ; often the choice for functions like GetOwnerLastTarget

Note you can use a different prefix with the same variable name (e.g. see the various "DoOnce" definitions under "i - integer"), and the GECK will treat them as distinct, separate entities. (But note "short DoOnce" and "int DoOnce" are not unique variable names. They are defining the same variable name to the same type.) However, that can get very confusing after awhile and is not recommended as a casual practice. But it can have it's place.

TIP Assigning and Testing variables

Thanks to Mktavish of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Assigning a value to a variable and then attempting to use that variable immediately afterwards usually doesn't work reliably. This is because the game engine appears to need at least one frame between the assignment and then being able to have that assigned value available in the variable in the same "action block" (e.g. "GameMode", etc. block).

The solution is to first check if the variable is set to other than it's default, and if not to then set the variable, and process the "true" condition the next frame. For example:

short DoOnce

Begin GameMode

if (DoOnce > 1)
 ; Already done once, so leave immediately.
Return
elseif (DoOnce == 0)
set DoOnce to 1 ; to be processed next frame
else
 ; do whatever when the value of "DoOnce" is "1", including calling another script (e.g. "QuestScript") if needed.
set DoOnce to 2 ; signal this has already been done.
endif
end

Other variations on this idea can be implemented as well. A timer can be implemented if longer than one frame's delay seems to be needed. Remember that "GameMode" block processing is cumulative in effect from frame to frame.

Note that there are only 3 blocktypes that will continually read the code lines in successive frames:

Each having specific circumstances when they are running. All other blocks (e.g. "On<Event>") are one frame occurrence events. See also TIP: Block Types (Multiple vs Single Frame processing).

TIP Adding Items to Actors aka Leveled Lists

Thanks to Ladez of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
So you've created this fantastic new item (weapon / armor / clothing, etc.) and want it to start appearing in the merchant inventories or NPC loot. How to go about it without manually placing it in every individual's inventory is the question.

The answer is "leveled lists". These are lists which can populate inventories of actors when the Player has attained a specified level of experience. The subject is addressed in the Nexus Forum thread Adding Items to Levelled Lists/GRA and should answer most of your questions, but here is the summary.

The basic process is covered in the GECK Wiki under the topic "Adding items to vendors". Note that avoiding incompatibilities with other mods requires using one of the following three methods:

  1. create a new container owned by the NPC;
  2. create a quest/script to add the items to the NPC's existing vendor container;
  3. create a quest/script to add the items to a vendor's leveled item list.

The third method is recommended by experienced mod makers, especially for Actors who are not "merchants", as the best way to assure compatibility with other mods. Remember: an Actor is it's own "container" and can use anything in it's inventory if the "Use Inventory" checkbox is enabled. Consider the term "vendor" as a specific example of an "Actor".

You need to identify which leveled lists are being used by the Actors you want to have your items, and then add the items to at least one of those lists. Different "groups" of Actors in different locations (even members of the same faction) may use different lists.

  • Find a likely "LeveledCharacter"/NPC under "Actors", "< Double-click >" on the entry to "Edit" it and view the contents of the "Inventory". Items that appear with a "green box" icon are lists which appear under the "Items" category as "Leveled Item" entries. For example:
Under "NPC" is the Editor-ID "188NCRTrooperA", whose inventory contains "CondKnifeLoot" (a "Leveled Item").
You will find "Leveled Items" under the "Object Window | Items" category. If you "< Right-click >" on the entry for a "Leveled Item" (such as "CondKnifeLoot") and select the "Use Info" property, you can see what utilizes that item. Scroll down that list and you want the ones of type "LVLI", which are "Leveled Lists".
EPDGaffney expanded: When you select the "Use Info" property of an item, you see the "Count" and "Users" columns. Levelled items will always have a "Count" of "0" because "Count" is how many instances/references are placed in the game cells, as opposed to a container. Because levelled items can never be placed anywhere but a container (including an Actor of course), they will always have "0" in that column. "Count" from the "Use Info" property is the same as "Count" in the "Object Window".

What makes this really confusing is that you have "Levelled Items" nested inside of other "Lists" inside of other "Lists" and so on, and these can eventually be tracked to a template actor, who has a "Use Count" of "0" because the items are never placed in the game but whose template inventory is used by 100 actors. Meaning that levelled item with a (Use) "Count" of "0" and 1 "User" will in fact (potentially) be in 100 inventories once you start playing the game.

That said, a high "Use Info" Count is going to be reliable in that the item will turn up in the game for sure. But just look at different merchant inventories to see what's really the best way to go in choosing a list for generally adding your item to the game.
  • "Form Lists" are under the GECK "Object Window | Miscellaneous" category. Find a likely list, "< Double-click >" on the entry to "Edit" it and view the contents of the list to determine how suitable it is for your purposes. DO NOT manually add your new item directly to this list. Use one of the three methods above.

Note that by default it takes 72 hours in-game for an Actor's "inventory" to get recalculated (updated from a "leveled list"). You can force the inventory to "reset" by calling the ResetInventory function on the container reference, but remember that "all previously added, removed, or calculated objects will be lost". See the GECK Wiki entry on "Force an actor to equip new stuff" as well.

The vanilla GECK function is "AddItemToLeveledList". As the wiki says:

"This should be used in the RARE case where we want to add an item to a Leveled Item list that already exists in the ESM. Its primary use is for modifying lists from the base game in downloadable content. In most cases you should add items to form lists in the editor object windows. This is for those special cases where you want to alter the contents of a list at runtime or want to change it without putting it in your ESP/ESM file. Once altered using this function, it will persist in the save game data.

It can not be undone."

The "Lutana" extension to NVSE (now part of the "JIP LN NVSE" plugin) has the following "leveled list" functions which are preferred as overcoming the drawbacks of the vanilla GECK functions.

So, scripting added items with functions such as LeveledListAddForm needs to be done every time the game is started. Most do it at "launch", but it can be done at every "reload" instead. The vanilla function AddItemToLeveledList by contrast will save in the "save game" data. It's not necessarily a bad function if you know how to use it (with a bDoOnce condition check most likely). But likewise, modders need to know that the Lutana functions must be done each session/game load. Items already spawned will of course remain in inventories if the Lutana function is called just once, but the items will never turn up anywhere else once the game is closed unless the function is called again next time.

Always test from a "new game" file instead of a save game from a play session.

TIP Basic conditional test syntax

A "conditional statement" (an "IF" is the basic form) consists of a "test condition" (e.g. "<this test must be 'true'>"), possibly followed by yet another "compound conditional test" which may be regarded as "Either/OR" or "AND/Also MUST BE TRUE", all in a single statement which is then followed (in the GECK: on the next line) by the statements to be executed if the overall combined conditional statement is "true" in all respects. That's a mouthful, but simply put all tests in the same statement must evaluate to 'true' for the statement to be true. (Qualifier: Only one of the pair of "individual tests" in an OR "compound conditional test" must be 'true'.) See TIP: GECK parses the entire line before evaluating.

The question of "encapsulation" (see TIP: Best Practice - Encapsulation - Parens, Brackets, and Braces) most commonly arises with "compound conditional tests". You could safely use "(parens)" to enclose the basic test, as in: 'If (IsModLoaded "mod.esp")' in the example below, but in general a "function" (i.e. "IsModLoaded") followed by a single parameter (i.e. "mod.esp") doesn't require it unless you are getting errors. Functions that require more than a single parameter usually do need encapsulation; the type of enclosing characters depending upon the type of function. "(Parens)" are most common and generally safest when in doubt. Liberal use of "(parens)" with "compound conditional tests" ensures they are resolved correctly: (e.g. "If (<condition1> OR <condition2>)" means only one of either condition has to be 'true' for the statement to be 'true'. Whereas "If (<condition1> AND <condition2>)" means both individual conditions must be 'true' for the statement to be 'true'. You can mix compound conditionals (e.g. "If ( (<test1>) AND (<test2>) OR (<test3>) )" can be misinterpreted; whereas "If ( (<test1>) AND ((<test2>) OR (<test3>)) )" is unambiguous (spaces added for clarify grouping): either <test2> or <test3> can be true, but at least one of them must be true along with <test1> for the entire statement to be 'true'. If either <test1>, or both of <test2> and <test3> are false, then the statement fails. However, such can be difficult to debug. "Compound conditionals" are just another form of "nested conditionals" combined into a single statement. (See TIP: Debugging Compound Conditionals.) They are best used when you are concerned about the size of your script. (See TIP: Script Size limit.)

For every "condition" you are checking to be "true" you are also (at least implying) there is a "false" condition that will occur if the test fails. The "conditional block" is made up of the "conditional statement" and is terminated by an appropriate "end" statement (i.e. for an "if" that is an "endif"). Some forms of conditional blocks (such as the "If") permit additional conditional tests to be conducted if the first fails (I.e. "ElseIf <condition>" statements) and a single (optional) "Else" (all is "false") section for when all earlier tests fail. This basic structure is more fully known as the "If ...( ElseIf) ... (Else) ... EndIf" (aka "If/Else") block where the parentheses indicated the statement is (optional). But for every "IF" there must be a concluding "ENDIF". (Notice the different use of case in these various examples. This is to show that case of the statements, commands, and functions is not important, but adopting a consistent pattern will help to make your script more readable. The case of "parameters" however, may be of importance so it's always worth paying attention to.)

So, here is an example of a basic "conditional test": 

If IsModLoaded "mod.esp"
  <some code to run when that mod plugin file is loaded>
; Else - do nothing
EndIf

If the test for "mod.esp" fails, the code that follows is skipped down to the "EndIf" statement and resumes processing with the next statement afterwards. If the test for "mod.esp" succeeds, then all the lines that follow (down to the "EndIf") are then executed in sequence.

(I prefer to document implied "Else" statements with comments (the ";" causes everything else on the line to be ignored) in the code so I know that I did consider the implication and what I thought would happen; in case things turn out differently later on. The implied "Else" here is "do nothing if this mod fails to be loaded".)

Note the use of indentation. This gets to be very important later on as you develop "nested conditions", such as: 

If <condition1>
  some code if <condition1> is true
  If <condition2>
    some additional code only if <condition2> is true (in addition to <condition1> or we never get here)
  ; Else - do nothing if <condition2> fails
  EndIf
Else ; <condition1> failed - <condition2> was never tested
  <code when <condition1> fails>
EndIf

Indenting the beginning and ending statements of "blocks" to the same level helps ensure you have correctly matched them up. (This is one of the most common syntax errors preventing a script from compiling, and hard to track down otherwise.)

Finally, note that "let < var > :=" is NVSE syntax. (Vanilla uses "set < var> to < value >" syntax.) You must have NVSE loaded when running the GECK (use the GECK Extender: link under Programs and Tools) to use it, (and specify NVSE as a requirement for your mod if you publish it) or you will get a compiler error and your users will not be able to get the mod to function correctly without it. Don't let that stop you as almost everyone has NVSE installed anyway, but it is important to realize.

TIP Block Types Multiple vs Single Frame processing

When creating a script it is important to use the correct "Block Type" to contain it. A "block" is bounded by a "Begin <type mode>" line and an "End" line. The most commonly used is the "GameMode" block, but many beginning script authors don't know why that is the case. It has to do with the issue of "single frame" versus "multiple frame" processing of the scripts within a given block type.

The term "frame" here is used very much the same as in "frames per second (FPS)" rendered on the display. But for a script, it is more accurate to think of it as a single "pass" of the game engine through the code within a block.

A "single frame" block type only gets one pass through it's code when it gets triggered. This means if the code is structured such that it needs to be processed multiple times to get the correct result, but is placed in a "single frame" block type, it will not produce a correct result. It only gets one "pass through" for evaluation. Such blocks do not retain "intermediate result (temporary) values" in variables between calls. Every time it is called, it is starting from a "clean slate". Even it's "locally defined variables" (those defined within that script) have been reset to null values. Only "Global Variables" or those "inherited" (defined in another script (typically a "quest script"), which in turn calls the script in question), can pass values between "scripts" or "frames". (This "range of visibility" of variables between different parts of the code is called the "scope" of the variable.)

There are only three "multiple frame" block types, which retain "intermediate result values" between successive frames:

Each having specific circumstances when they are running. All other blocks (e.g. "On<Event>") are one frame occurrence events.

Consequently, if your code requires a "loop" structure or more than one pass through it's conditional logic to get the final result, it must be moved out of a "single frame" block and into a "multiple frame" type. "Loops" are easy to spot; "conditional logic trees" can sometimes be trickier. Some things to watch out for:

  • "Gateway" conditions, such as "If bDoOnce == 0". This implies a second pass is required for the occassion when "bDoOnce == 1" logic to get applied. If "bDoOnce" is defined "globally" or "inherited", then it will retain it's value between calls, so it is not automatically disqualified from a "single frame" block type, but if defined "locally" then it will always be "0".
  • Any logic depending upon a conditional test using a locally defined variable. Such a test is only valid if the value of the variable is assigned during that initial pass and ALL actions depending upon that value are performed in that same pass. This means only one code branch of an "If ... ElseIf ... Else ... EndIf" logic tree will be processed.

By bearing in mind "single" versus "multiple" frame block types, some "unexplained" code behavior can be understood and rectified.

TIP Compiling Scripts

You may notice error messages that report "script is not compiled". This may cause some confusion, so to clarify the situation:

The GECK compiles a script when saving it. This means it turns the "human readable" instructions into binary "machine code". This is more efficient for the game engine to process. Editing and saving a script individually is the preferred method of compiling. A script that is not compiled will still run as long as it is properly constructed; without any errors. But compiling is usually the only way to ensure the script is error free.
If you can't exit your GECK session, it's usually because you failed to actually save/compile a script due to an error. If you are not using the GECK Extender or Powerup plugin (see the Programs and Tools section), this can happen without any error message being displayed to indicate it failed. You may find yourself forced to revert to a backup or remove the script which refuses to compile. Take precautions.
WARNING: There is a compile all command in the GECK script editor, but it compiles ALL the scripts that are currently loaded into the GECK (including by default all, numbering in the thousands, from the vanilla ESMs), regardless of their source plugin INTO YOUR PLUGIN, which will consequently override those scripts in any other plugin. This is best avoided (as in "never used") unless you really understand all the ramifications.

TIP Corpses are not Actors or Objects

Thanks to EPDGaffney of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Trying to get a Trigger Box to react to a "corpse" falling through it fails to work. Apparently "dead actors" are not considered by the game engine to be either Actors or Objects as far as functions and events depending upon one or the other are concerned.

TIP Debugging Compound Conditionals

Here's a programming tip for when a compound conditional (multiple tests on the same line) is not working as expected: split it up into nested conditions. An "ElseIf" is equivalent to an "OR (||)" compound (assuming the "[do something]" portion is identical in both the "If" and "ElseIf" portions of the block), and each nested "If" statement is equivalent to an "AND (&&)" compound.

So, using the example: "If (GetHitLocation == 1 || GetHitLocation == 2) && (rTarget.GetDead != 1) && (rTarget.GetIsCreature != 1)", change it into: 

If (GetHitLocation == 1 || GetHitLocation == 2)
    ; NVSE required: PrintD (string:expression), DBPrintC (formatted string)
    DBPrintC "Script [HeadshotAmmoSCRIPT], GetHitLocation = [%g].", GetHitLocation

    If (rTarget.GetDead != 1)
        ; NVSE required: PrintD (string:expression), DBPrintC (formatted string)
        PrintD "Script [HeadshotAmmoSCRIPT], rTarget.GetDead = [" + $(rTarget.GetDead) + "]."

        If (rTarget.GetIsCreature != 1)
            ; NVSE required: PrintD (string:expression), DBPrintC (formatted string)
            PrintD "Script [HeadshotAmmoSCRIPT], rTarget.GetIsCreature = [" + $(rTarget.GetIsCreature) + "]."

            ForceActorValue Health 0
        Else ; (Can be dropped if you just want it to totally fail.)
            ; [do something]
        Endif
    Else; (Can be dropped if you just want it to totally fail.)
        ; [do something]
    Endif
Else
    ; [do something]
EndIf

Insert "debug messages" (examples given) as required to pin down what values your conditions are actually testing. That should quickly isolate what is not as expected. (I just repeat the '; NVSE required' comment line to remind myself of the required syntax differences with each line. Not required otherwise.)

Use the game console "bat <filename>" command to run a "batch file" similar to this ("_MyDebug.bat") to trigger the debug print statements when testing. You can type any series of console commands (one per line) into a Notepad or other plaintext editor file and save as a simple DOS text file. The filename extension doesn't matter, and can be dropped when entering the command as the console ignores it if found, but the standard for all "batch files" is ".bat". The file should be placed in the game root folder (where the game EXE file is found). If the filename includes "spaces" then you need to enclose it in double quotation marks (i.e. type <bat "_My Debug File">). See also: TIP: Debugging data to file.

  • _MyDebug.bat:
con_SCOF "_MyDebug.log" ; Output console messages to file "_MyDebug.log" in current directory
DBMode 1 65             ; "Enable Debug mode" command using decimal mod index
                        ; Most common reason for failure: incorrect decimal mod index for <ModPluginName>
                        ; NVSE required: PrintD (string:expression), DBPrint[C] (formatted string)
DBPrintC "Starting log for mod index 65(0x41) (<ModPluginName>) ..."  ; descriptive initialization message

Without that "Enable Debug mode" command the debug print statements won't actually do anything normally. The "semicolon" (;) signals an ignored comment from that point to the end of the line, but is not required except to explain the purpose of each command.

Place your "batch file" in the game root folder (where the "FalloutNV.exe" file is found). The filename begins with an "underscore" (_) so it will be sorted to the top of the file list, making it easy to locate.

TIP Debugging data to file

Thanks to DoctaSax of the Nexus Fallout "New Vegas GECK and Modders" forum for help with the following.
The built-in mechanism for debugging is to display messages to the console (or HUD) screen. The console has a ToggleDebugText function, which toggles an extra debug display to the console with 23 screens of data that can be paged through using the < Scroll Lock > key.

There is a list of "designer" debug tools, many of which are disabled in the retail version but may have been or eventually will be provided in a "script extender", listed for posterity here:

To enable the console, make sure the bAllowConsole=1 setting is in your game INI file. The console can then be accessed in-game by toggling the 'tilde key' (the actual key can be <~>, <º>, <¬>, <|>,<^>, <\>, <§>, etc., depending on your keyboard layout), usually found near the "1" key across the top of most keyboards. The console prompt will appear as a single blank line in the lower left-hand corner of your screen. You can scroll the console output using the "Page Up" and "Page Down" keys. The console is not case sensitive: entering any of "tdt" or "TDT" or "TdT" will toggle the debugging text. More general information on the console can be found on the UESP wiki and holds true for later games. Use "#" anywhere on a line to make everything after that symbol into a comment.

The forum article Skyrim Console Script/Bat File Compilation is a tutorial with lots of information and ideas that can (with the appropriate changes) be used for other games.

If you use NVSE (at least while developing/testing your scripts), you can use the SetDebugMode command from FOSE (all of which are supported by NVSE) as a toggle for debug messages.

Then you can test if this mode has been enabled in your script with: 
if GetDebugMode ... endif
or control the output to only appear by using commands with built-in checks such as DebugPrint or PrintDebug.

Note the distinction between these two types of commands.

  • The "DebugPrint" command, like "PrintToConsole" (PrintC), only accepts a string with optional "string format" specifiers as parameters (e.g. "my string: %g", iSomeNumber).
  • The "PrintD/PrintDebug" command on the other hand, like Print, requires "string expressions": concatenated strings, string-returning functions, or ToString'ed forms and numbers.
  • Don't mix the two types of message string formats. So it's either:
set iStage to GetStage <Quest EditorID>
DBPrintC "Failed blah blah [%g], QStage [%g].", <Quest EditorID>.<QuestVariable>, iStage

or

PrintD "Failed blah blah bark = [" + $(<Quest EditorID>.<QuestVariable>) + "], QStage [" + $(GetStage etc- + "']."

  • Other forms of "Print" has similar distinct requirements for their messages. Pay attention to their description's syntax.


Often you want to know the state of various elements that are not stored in variables, for output. A fairly common example of this is to print the current "Stage" in a "Quest". You can use the "GetStage <Quest EditorID>" function in a conditional statement (e.g. If ( GetStage VT47 == 10 ), but that by itself won't work as a parameter to a "PrintC" command. Fortunately NVSE v4 added the ToString function (abbreviated as the "$" symbol) which can be used to turn an "expression" into a string value (e.g. PrintD "Active Quest [" + $(GetActiveQuest) + "Stage = [" + $(GetStage <Quest EditorID>) + "]."). Note the spaces separating the string concatenation "+" symbols are required. Also that the "GetActiveQuest" function returns a RefID which is normally not printable but "$" converts into a string.

Sometimes simply displaying messages to the screen or console is not sufficient to trace a problem. NVSE provides a number of functions enabling you to dump debugging information to a text file. These functions, and examples of how to use them, are listed on the GECK wiki under the subject Debug Dumps. They all reference sending messages to the "console". You need to first use the Con_SCOF command to redirect console messages to a text file instead.

When you need to send a sequence of commands to the console one immediately after the other, it is often useful to put them (one per line) into a plaintext "batch" file (e.g. "enabledebugfile.txt") placed in the game root folder, the same folder as the game executable (i.e. "<path>\common\Fallout New Vegas"), and use the console command "bat <filename>" (no extension and without the quotes) to run it (e.g. "bat enabledebugfile").
Example 'enabledebugfile.txt' file:

con_SCOF "_Debug.log"  # "_" is to cause the file to sort to beginning of Windows Explorer filenames
DBMode 1 61                 # '61' is 'mod index' in decimal
DBPrintC "Starting log for mod index 61(0x3D) (<mod name>) ..."

TIP Dismembering a corpse

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the following.
According to the game [lore], there were a bunch of people beheaded in Nipton, but there were no beheaded bodies. So I created a bunch of NPCs and had them immediately get beheaded as soon as they spawned. This is the script I used: 
scn zzMongoBeheadedScript

Begin GameMode
    If (GetDead == 0)
        Kill zzMongoCrucDead1REF 1 -1
    Endif
End

Just give this script, or rather your modified version of it, to your NPC in the dialog box where you define the NPC, under the ID and name. You probably know this already, but just making sure.

{The "kill" command is a shorthand name for the KillActor function. You could use the "[ActorRef].command" syntax to make it explicitly clear who is the object of the command (being affected by it). When the script is attached to an NPC via dialog, they become the implied "ActorRef". Think of the "[ActorRef].command" syntax as "[subject].action [parameters]". The "[]" are used to indicate it is an "optional" component of the function.}

zzMongoCrucDead1REF is one of the beheaded NPCs. Basically, by using him as the killer, he gets blamed for all of the deaths and not the player or anyone else (prevents any factions from getting angry at the player or with other factions). "1" is the dismembered part, which in this case is the head. You'll want to change this for your exploded NPC. "-1" is the cause of death, which you will want to change to "0" for {an} explosion. The documentation for {the function} GetCauseofDeath has a list of values for the cause of death.

There are ready-to-use scripts available for several combinations of dismemberments in the GECK already. To use them, drop a new cubic activator in the cell where you want to use it and point it to one of the "GenericDismembermentXXX" base forms. Then set its linked reference to the corpse that you want to dismember.

TIP Dispel Effect

Thanks to DoctaSax of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
A Dispel function call often doesn't take effect immediately. There is also a risk the spell will stick on any creature for which the code doesn't apply (depending upon the type of duration set, of course). The following is a "good practice" trick for scripted spells (aka Actor Effect) to keep in mind.

At the end of your ScriptEffectStart Block: 

else
  set DoOnce to 2 ; (or some appropriate value)
endif

and at the top of your ScriptEffectUpdate Block: 

if DoOnce == 2
  dispel <YourSpell/ActorEffect>
  return
endif

TIP Do not overlook EventHandlers

When you want to do something affecting multiple Actors, such as providing a particular dialog option or behavior, instead of editing their scripts directly consider using an NVSE Event Handler instead (functionality added by NVSE 4.6+).

EventHandlers provide the very powerful ability to "trick" the game engine into supplementing or overriding the limitations of the standard GECK "On<Event>" functions such as "OnAdd", "OnActivate", or "OnEquip" into running a script to emulate something else in a "User Defined Function" (UDF). A simple example of this is the "Note EventHandler" script and UDF in TIP: Passing a 'Note' to the player, which is using this technique to "trick" the engine into running a script as if the note had been triggered by an "OnEquip" or "OnActivate" function without ever using that command; in this example instance by a mouse click or key press in a menu. See also Tip: EventHandler-HotKey.

Note that just using an EventHandler isn't sufficient. The normal activation event will still need to occur. You have to disable interaction with the target Actor first if you want to prevent dialog, somehow. With JIP LN NVSE you can use the "SetInteractionDisabled" function.

EventHandlers on objects are invoked before the actual event happens; hence the different timing for them compared to script blocks like "OnEquip".

The mod creator should not be concerned about using "script extenders" and their plugins. Other than providing notice to the downloader of their mod that such are required, there are no "downsides" to using them as far as the game engine is concerned; and they provide fixes to some deep level engine bugs that can only be provided by something working at that level (which mods can't). Almost any load order with more than a dozen mods is likely to already require their use. They are a mod creator asset, providing enhanced capabilities. Utilize them.

Please see the article NVSE4+: Event Handlers & User-Defined Events (UDEs) - Part 5 by DoctaSax for details.

Tip EventHandler for HotKey

Thanks to FiftyTifty of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
Please see the article NVSE4+: Event Handlers & User-Defined Events (UDEs) - Part 5 by DoctaSax for details first.
Required knowledge:
  • UDFs, blocktypes, forms and refs
Also required:
  • NVSE 4.6+

CIPCIS' method in NVSE: Detecting Keypresses is not ideal, as it uses GameMode for the bulk of the scripting. The point of having event handlers, is to only process code when we need to, rather than every frame or every few seconds.

To get a "HotKey EventHandler" to work, you make two scripts. One is the "EventHandlerRegistration" script you attach to the quest, so you can detect the keypress: that has a very barebones GameMode block, which then readies the event handler. 

scn MyHotkeyEventScript
short bDone

Begin GameMode
    if bDone == 0                                        ; Eventhandler has not previously been set
        SetOnKeyDownEventHandler MyEventUDFScript 1 210  ; Establish the Eventhandler for the "<Insert>" key.
        set bDone to 1                                   ; Eventhandler has now been set, so this code will be skipped next frame
    endif
End

You then point it to the second, "User-Defined Event" script you made, which is the one that does all the work. If you look at the first example "EventHandlerRegistration" script (MyHotkeyEventScript) attached to the quest, it calls the following line: 

SetOnKeyDownEventHandler MyEventUDFScript 1 210

The "User-Defined Event" script MyEventUDFScript is the one that does the bulk of the processing. The "1" parameter means we want to enable the event handler, and "210" parameter is the scancode for the "<Insert>" key. (See the wiki article DirectX Scancodes And How To Use Them for a list of the DirectX scancode keys.)

The MyEventUDFScript has to follow the basic structure of a "User Defined Function" (UDF).
Example: 

scn MyEventUDFScript
int iKeyID ; this is the keypress that triggered the EventHandler (e.g. scancode "210": the "<Insert>" key)
; Other variable definitions as required

Begin Function {iKeyID}
  ; Main processing logic for when the triggering key is pressed goes here.
End Function

It's a more difficult concept to understand than to implement.

TIP GameDaysPassed Bug

Thanks to Asterra and DoctaSax of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
NOTE: This bug is now fixed in the game engine by the JIP LN NVSE plugin (linked under the Programs and Tools section).

GameDaysPassed is a GECK "base type" Global Variable used to return the number of days that have passed "in-game". However, it has been found to become inaccurate over time (more quickly if the timescale is adjusted to anything other than the default of 30) and eventually to fail to advance at all. This causes problems with many vanilla and mod scripts; particularly in "Hardcore Mode" where the sudden advance can cause instant, unexpected death.

"The nature of [the problem] seems to be that single-precision floating point math is only accurate up to so many digits, 7 to 8, depending. Sleep, wait and fast travel update the var by sufficiently high values to never go unnoticed. But during gamemode GameDaysPassed [(GDP)] is updated by tiny fractions, every frame. That means that every frame, it should be updated by something close to TimeScale / (FPS * 86400). At 30 timescale and 30 FPS, that's 0.0000157407407407 (etc.); 0.000005787037037 (etc.) at FPS 60.

"If you add it to the existing GDP value, then even at day 1 in the game (day 6, isn't it?), the result of this addition, stored in the GDP var, will only be reliably accurate until 6 digits after the decimal point. The var itself could store more precise data, but it's the calculation that is inaccurate and the result of that is what's being stored. So it may only accurately apply an increase of 0.000005 at 60 FPS or 0.000015 at 30. The following digits of the GDP value will be very much random, and each time the increase is added, it just results in new randomness beyond those digits, possibly rolling over to a higher digit and affecting its accuracy too.

"Then, when GDP hits 10, or 100, the whole problem becomes much larger because from then on only 5, or 4, digits behind the decimal point are theoretically reliable, and because of earlier inaccuracies that happened over time, it's hard to trust them either.

"The sad part is that all numeric variables in FNV are actually stored as double-precision, but math involving any var is single-precision."

The mod Timescale Pacemaker by Asterra was developed specifically to address this issue. It has since been corrected in the game engine by JIP LN NVSE Plugin v51.60 or later.

TIP GECK parses the entire line before evaluating

Thanks to DoctaSax of the Nexus Fallout "New Vegas GECK and Modders" forum for the following.
Bear in mind when using compound conditions [&& (and), || (or); see GECK Category: Conditions] that the GECK parses the entire line at once. For instance: 
If (IsFormValid rActor) && (IsReference rActor)

can crash your script if rActor doesn't hold a valid form, because IsReference will freak out over it and the IsFormValid check does nothing to prevent it. You need to break that line up into two: 

if IsFormValid rActor
   if IsReference rActor

Geck script processes an entire line: substituting the result values from functions, and then determines the "true/false" result of any conditionals last, so if the ref var holds an invalid form or none at all, it will be passed to IsReference in a compound conditional line. The IsFormValid conditional check in the same line doesn't stop that - the only way to prevent it is to split up the line. Overall it's good practice to stagger your validity checks to separate lines as this becomes an issue if you use a function with ref syntax in such lines.

TIP Get Actor Health functions

Bear the following in mind when attempting to determine the health of any actor:
  • [ActorRef].GetHealthPercentage is unreliable as it's determined from "base health" and sometimes returns values over 1.0 (100%).
  • [ActorRef].GetAV Health returns the current, modified health value (not the maximum). It takes into consideration permanent effects (e.g. perks) as they contribute to your "health pool".
  • [ActorRef].GetBaseAV Health returns the base value with no consideration for permanent (e.g. "Life Giver" perk) or temporary effects (eg. Buffout).
  • [ActorRef].GetPermAV < StatName > returns include permanent effects (e.g. Perks like "Tag!", and from Skill Books), but no bonus from situational perks, equipped items, drugs, etc..
  • [ActorRef].ResetHealth Restores the actor's health and cures crippling damage.
  • No function known at the moment can return the max value with temporary effects.

Please see the GECKWiki ActorValue page regarding the "Damage Pool" and that determining an Actor's current health is a multistage process. It looks like "GetAV Health" is what you want to track current damage, as DamageActorValue function implies that it does reflect the "Damage Pool" from frame to frame.

 

TIP Level Lists and GetBaseObject versus GetBaseForm

Thanks to EPDGaffney, DoctaSax, and Mktavish of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
According to the GECKWiki:

There are three types of level lists in Fallout 3 (& New Vegas):

Refer to the individual pages for details about each of them. In general, a leveled list allows the choice of object or actor to be dependent on the level of the player relative to the Encounter Zone. Therefore as the player grows in level, the actor or object generated changes. Loot in containers is better. Creatures and NPCs encountered are tougher.

  • GetBaseObject Returns the base object id of the calling reference. Will return the leveled character/creature Actor form if called on references spawned by one. {The Form-ID will actually be an object that contains a list of other leveled Actors.} Use GetBaseForm to return the Actor "base form" instead.
  • GetBaseForm (A function added by NVSE) Returns the actual base form of a leveled calling reference. {Meaning it goes within the list of the calling leveled object, and finds the Base-ID template of the leveled object it picked at random from that list. Hence this would have to be called in scripting, after the leveled item reference loads.}

The trouble with any actor templated to a leveled list is that their Base Object (GetBaseObject, aka GBO) is not static, but dynamic (i.e. if you called GetBaseObject on the ref in-game you would get a Form-ID that starts with FF (255). This explains the problem with some of the debug readouts, in that IsInList called on the reference won't match the base form that is stored in the GECK. To get that base form, you'd need GetBaseForm (GBF) and look it up in the list with ListGetFormIndex. This is "normal behavior" for GBO: i.e. when an actor's base form is directly templated to a levelled list. Some instances, however, seem to be templated to another actor form which in turn is templated to a levelled list. (There really is no limit to how many levels of templating that can go on, except the restraint of the person making the NPCs.) That may explain the base object not returning as dynamic in some instances, and so, being checked off correctly by IsInList. This is an area not extensively explored.

Recall (from the GECK Form-ID, Base-ID, Ref-ID, and Editor-ID section) that the "Base ID is the number assigned to a template for an object that is used to create many instances of that object." And "the Reference ID is the unique ID of an individual object (unlike the Base ID, which is an ID for an object template)" that is placed in the game world.

In other words: GBO returns the "Leveled" Base-ID (from the leveled list in the instance under consideration). And that can be stored in a reference variable. GBF goes into the list within the "Leveled" Base-ID and gets the root Base-ID that was the template of the leveled object. That can also be stored in a reference variable but is not actually a "Ref-ID" and cannot be used as one, as it has no specific object. (The "reference" / Ref-ID is expected to contain active characteristics, such as world location, current stats, etc. of a specific object instance in the game world.)

GetSelf returns a Ref-ID that you can store in a reference variable, referring to the specific instance of it in-game. GetSelf is only useful when this information is accessed externally, or when the scripted reference's Ref-ID needs to be passed as a parameter to a function like PushActorAway. This can be a problem with inventory objects because they are destroyed regularly.

TIP Limit Radio Range to multiple Interior Cells

Thanks to EPDGaffney and user826 of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
In order to limit a Radio Broadcast to only be heard when the Player is inside a cluster of linked interior cells, you need to set the Talking Activator to Broadcast Range Type = Linked Interiors in the first cell. (Place the Activator out of reach and sight to hide it from the player.) You then use Teleport Doors as usual to link the interior cells together for the Radio Broadcast.

You may find it preferable to use a set of "hidden, dummy doors" to provide the Radio Broadcast linkage. Be sure to flag such doors to be "Hidden from Local Map".

TIP Mannequins aka static Actors

Thanks to b0bulat0r of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
A "mannequin" is nothing more than an Actor that doesn't move: no idle poses, sandbox, travel packages, etc.. All it takes is adding an "OnLoad" script with the line "SetActorsAI 0", e.g.: 
Begin OnLoad
  SetActorsAI 0
End

TIP Master Dependency Checking

Thanks to miguick of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
When the game starts you may want to check for items introduced in DLCs (e.g. "HonestHearts") and store the results in a list.

NVSE's IsModLoaded "HonestHearts.esm" and GetFormFromMod "HonestHearts.esm" "xxxxxx" can't go wrong for such a thing. (The quotation marks around the pluginName and hexFormID strings are required.) Where "xxxxxx" are the last 6 digits of the FormIDs of the records you are concerned about. The GECK displays them in a minimized column that you can stretch.

TIP Mod Additions list

Thanks to DoctaSax of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
Sometimes you want to know about all the additions of a particular type (such as 'weapons' for example) that a specific mod adds to the game.

With the JIP LN NVSE plugin (which now since v40 incorporates the "Lutana" extensions) this is quite easy. Use a combination of the GetModIndex and GetLoadedTypeArray functions with Form Type IDs code '40' ('Weapons'): 

array_var aWeapons
int iIndex

let iIndex := GetModIndex "<TheMod>.esp"
let aWeapons := GetLoadedTypeArray 40, iIndex

TIP NPC Weapon Choice

Thanks to EPDGaffney of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
When trying to force an NPC to use particular combat tactics (such a choice of Weapon) under specific circumstances, remember that the higher cyclic "Damage Per Second" (DPS) rate of the Weapon is what governs their choice; not the base "Damage" inflicted per shot. {For Armor, it's "Damage Resistance" (DR) that governs.} This is hard-coded into the game engine.

Consequently, in order to force the NPC to switch weapons, you may need to temporarily remove their current weapon and any alternative choices you don't want them to use, saving both the baseform of the removed weapon(s) and any timer using either a Token or JIP's Auxvars on the NPC in order to restore them after circumstances change again. (Essentialy this is the same as the "reverse pickpocket" trick to cause an NPC to switch gear so you can steal what they had been wearing.) See TIP: Timers regarding limitations which necessitate this "Token" or "AuxVars" approach.

TIP Pass a variable number into a script message

  • Read the "Formatting messages" section in the GECK article on the ShowMessage function. For an integer: use "%.0f" or "%g". Include the formatting switch in the text in the message form, like this:
    "The winning number was %g."
  • Then pass the script variable to the ShowMessage function along with the message, like this:
  set iWinningNumber to GetRandomPercent
  ShowMessage WinnerMessage, iWinningNumber
  • Here's an example with NVSE, which allows you to show messages without creating a new message form. NVSE also supports a number of extra switches that can't be used in ordinary message forms.
MessageBoxEx "The winning number was %g.", iWinningNumber

TIP Passing a Note to the player

Thanks to EPDGaffney of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
This is a bit lengthy because it covers more than simply commands and functions, but concepts and how to implement them. Unlike the tutorials listed, this tip is about how to pass a "note" to the Player directly or display it outside of the Pip-boy "Notes" tab. (The concepts presented here similarly apply to passing along "recipes". See also TIP: Passing a 'Recipe' to the player in that instance.)
  • The "Note" object:

From a modder’s perspective, it’s important to be aware that GECK: Notes are different to standard items. They store text, and that text will not receive an inventory reference like other objects / "pick-ups" and can never be dropped (though they can be removed in several less standard ways). Additionally, "notes" can’t have a script attached to them directly, though there are several workarounds available. (Most of the tutorials listed on the subject are addressing these workarounds.)

However, like normal "pick-ups", "notes" can be assigned a model (mesh file) and an inventory icon that will be visible when being taken from a container (and not in the player’s Pip-Boy), when the mod creator has placed them in such containers. Any model can be chosen, but it must have collision in order to be "picked up". "Holotape" and "paper" models are most common. If the "note" is to be "picked up" as a model outside of a container in the game world, no icon is necessary; and if the "note" is never to be seen in the game world, no model is needed. If it would not be seen in a container or in a cell, then it wouldn't need either one.

"Notes" can be displayed in a terminal as well, and via the terminal form can be configured to be added to the player’s Pip-Boy upon reading them there, or not be added.

NoteObject

Once in the Pip-Boy, "Notes" are one of four things: text, an image, a voice, or a sound. (See the figure NoteObject. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

It's often easiest to take an existing "note" item that shares the model you wish to use and then change the EditorID to make a new object. That way all the associated mesh and icon/texture files are already linked. Otherwise you have to unpack them from the BSA as the GECK Editor doesn't look there for those files.

(See the Skyrim thread BSAs and You for details about the pros and cons of "Bethesda Software Archives" (BSAs), but bear in mind such files in previous games, like Oblivion, FallOut3 and Fallout New Vegas, don't have "strict order" like in Skyrim. Games prior to Skyrim don't support overriding of assets in archives using other archives; only loose files can. If the same resource is contained in several BSA archives, those games won't use it from the last BSA on 100% of occasions. They may grab the resource from a random one of the BSAs containing the same file.)

WARNING! Do not unpack BSAs directly into your game "Data" folder; potentially overwriting any mod files. The tools don't ask you to confirm the overwriting, either. All the hair textures unpacked to "loose files" will go through the head models in that case; because that's what happens when hair is not packed in a BSA. "Best practice" is to unpack to a unique folder (they are large: 1-2GB) and manually drag the desired files to the appropriate "Data" folder as needed.


  • Scripting with "Notes":

To add a "note" directly to the player’s Pipboy, use the AddNote <NoteID reference> function. Unless the "note" is ever meant to be added in some other way (e.g. as an object dropped into the game world), a "note" added in this way will never be seen in the game world or any container and thus requires no icon or model.

To trigger an OnAdd event when acquiring a "note", as one may be accustomed to doing with other items, a workaround is required. A ‘dummy’ "item" must be placed in the game world or a container, and this item can’t be a "note" item. It must be a separate form, which can be named the same as the relevant note (but can’t share the same EditorID), and this item can have a script attached to it with an OnAdd script block. Then just drop it in a cell (the video Tutorial - Scripting Notes Video by Seddon4494 covers three basic methods of accomplishing this); or use AddNote <NoteID reference> in a (running) script somewhere (such as a dialog End Result Script) to proactively get it into the Player's inventory instead of waiting for the Player to pick up the item. (See the figure NoteObject. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.) You can (if you wish; it's not required) then have your script remove the ‘dummy’ "item" (whose only purpose is to provide a flexible anchor for the note) from their inventory, and add the text/image/sound of the note (e.g. "FCRaiderNote" in the example below) to the player. It will then appear in their Pipboy "Data" tab under "Notes".

For more on the subject see the Bethsoft Tutorial Basic Quest article.

Example script attached to the game world "item" (e.g. the "holotape"):
  begin OnAdd Player        ; Run when player picks up 'misc. item'
    AddNote FCRaiderNote    ; Give note to player
    SetStage COLOMQ1 10     ; Start/set quest 'COLOMQ1' at stage 10
    RemoveMe                ; Remove 'misc. item'
  end
  • Using Message Functions:

Though the traditional method of viewing a "note" is by way of clicking on them in the Pip-boy, "notes" are currently very unwieldy unless they're short. A mod using the concept of an "EventHandler" (see "Employing an EventHandler" below) to detect when the player clicks/presses a key or gamepad button on a note in the Pip-boy could theoretically change that if someone wanted, or someone could add readable books this way, or any number of things. Such can make use of the improved message functions available to us by way of New Vegas Script Extender (NVSE) and JIP LN NVSE Plugin mods; which now include:

(However, as these constantly are updated and added to, the mod creator is advised to search the list of functions on the Community Wiki site lists of NVSE and JIP LN functions. The "official" Bethesda GECK Wiki is not getting those updates to it's function list.)

MessageEx and MessageBoxEx are NVSE functions and allow one to pass the text directly, which is very convenient, but they don't give any options and MessageBoxEx does not offer the ability to "title" the message. The other two are JIP functions that improve upon this greatly.

With the MessageBoxExAlt function (as of JIP version 53.60) it is now possible to pass a dummy, non-script form as the UDF script argument, in which case no script will be invoked when a button (or key) is pressed. This will mean that you can use that same blank form for every message box that you want to give a title but don't need buttons for it. The UDF script is where you would implement button functionality, and it's far quicker than vanilla. Only one such "dummy UDF script" per mod would be needed in the case where you desired to use a message box with a title but no buttons and pass the text directly as a string.

  • Employing an EventHandler:

"Notes" are only Activators if they're being picked up via activating a note's "in-game World model", such as a "holotape" on a table. In a container or when added via script, they are just "Notes". (Technically, all pick-ups are activators that are disabled on activating them and an inventory reference is added to the player's container; with the exception of "notes", which have no inventory reference but are still added to the Pip-boy, and their activator is still destroyed.)

The advantage of EventHandling (added by the NVSE) is that it can "fake" using a standard activator "event" such as OnEquip, but instead trigger when you desire and the standard event isn't otherwise permitted; such as when a key or button is pressed in a menu. "An event handler allows response to game events, without having to attach scripts directly to objects. Instead, the scripter uses SetEventHandler to register a User Defined Function (UDF) as a handler for a specific event. When an event occurs during gameplay, NVSE will invoke any handlers that correspond to it, passing information about the event to their function through its arguments." [Source - Community GeckWiki] See TIP: Don't overlook EventHandlers.

These two scripts provide a functional example of a "Note EventHandler" script and UDFscript.
Example "EventHandlerRegistration" script: 

scn NoteEventHandlerQuestScript

int DoOnce

Begin GameMode
    SetOnMenuClickEventHandler OnMenuClickUDF 1 MapMenu/GLOW_BRANCH/MM_MainRect/MM_NotesList"
    Set DoOnce to 1
    If DoOnce == 1
        Set DoOnce to 2
    EndIf
End

Begin GameMode                                 
    ; Note that I tend to 'over-check' in my scripts, to be certain it will work as intended.
    ; DoOnce probably didn't need to go past 1 before stopping the script.
    If DoOnce == 2
        StopQuest NoteEventHandlerQuest
    EndIf
End

and the "User-Defined Event" script: 

scn OnMenuClickUDF

int iMenuID
int iElementID
string_var sElementName
string_var sNoteName
string_var sNoteNameUI

Begin Function {iMenuID, iElementID, sElementName}
    Let sNoteName := LnGetName NoteEditorID
    Let sNoteNameUI := GetActiveUIComponentFullName
    If eval ((Sv_Find "MM_ListItem", sNoteNameUI) > -1) ; check if UI component is a note
        let sNoteNameUI += "/ListItemText/string"
        let sNoteNameUI := GetUiString $sNoteNameUI ; get the name of the highlighted note
            If eval (sNoteName == sNoteNameUI)
                ; do something
            EndIf
    Endif

    ; Don't forget to put all the string_vars here
    sv_Destruct sElementName, sNoteNameUI, sElementName
End

TIP Passing a Recipe to the player

Thanks to EPDGaffney of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
The "Category" field of the Recipe Editor window determines where the "recipe" is utilized (i.e. "the crafting station"), so it does NOT appear in the Pipboy "Data" tab under "Notes". It can be added to the game in the same manner as other "notes".

It is worth observing that a "Recipe" is a form type of structured list which is used to allow the player to craft items at workbenches, campfires, and reloading benches. (The form list appears in the GECK "Object Window" under "Miscellaneous | Recipe".) If you include a "note" (as simple as "This is a recipe to <do something>") in the "Ingredients" tab of the recipe, it will be a single use "consumed" item unless you also include that note in the "Output" tab as well. (Anything not listed in the "Output" tab is "consumed" in creating the recipe item. See "NVDLC03RecipeSkillBookBarter<Recipe|Note|Script>" in the "Old World Blues" DLC for an example of their use to create a SkillBook.) The "Note" form is used as a "requirement" for that recipe. As such it can use the same "holotape" or other "misc. item" images.

RecipeNote_Fig-01

When the player picks up a "recipe" in the game, they are really picking up a "note" that could say anything. Then the only thing that's done with that "note" is a completely separate Recipe Form can be set to appear to the player only if they meet the condition of having that "note", like so: (See RecipeNote_Fig-01. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.) The "note" itself is nothing more than a requirement to enable the recipe, either initialy or repeatedly.

"Recipe notes" can be passed to the Player in the same manner as described in TIP: Passing a 'Note' to the player.

All "recipes" are always present at their designated crafting station, but if they have Visibility Requirements, they are invisible to a player that does not meet the requirements. It's important to note that this doesn't need to be a "Note". This could be a quest variable, a gender, whether some actor sees another actor (GetLOS), and just about anything else. (See RecipeNote_Fig-01. Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)

Visibility Requirements are separate from Ingredients regarding "notes" in the way mentioned earlier, and Visibility Requirements are separate from the Required Skill above it in the image, in that whilst both can check the player's skill, Visibility Requirements will hide the "recipe" entirely from a player that doesn't meet its skill check, but a player that has a skill value lower than that specified in the Required Skill will see a greyed out, unusable "recipe" that they can read through but not "craft", similar to when the player doesn't have the required Ingredients.

TIP Perk effect on target

Thanks to Mktavish of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
It seems a shame that the Entry Point feature of Perk objects is not available via Actor Effect. But you can perform a "reverse entry point" check to get the same effect ... if it is only the target the Player is shooting at that is of interest.

To accomplish an reduction to damage (-80%) only upon hitting a target's head while wearing the "MyHelmet" piece of armor, you would select menu sequence (just as an example): "Perk | Entry Point | Calculate Weapon Damage | multiply value | 0.2". Then in the "On Condition" field, select the "Target" tab and use: 

"GetEquipped  MyHelmet == 1  AND"
"GetHitLocation == 1 "  ; Head location

TIP Preload Scripts

Thanks to EPDGaffney of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
MenuMode lets you specify which menu (or menus, in some cases) should run your script. MenuMode 4 is the main menu of New Vegas and was added in JIP LN NVSE at some point. It's the most reliable place to run pre-load scripts (before a "save game" file is loaded) in the experience of many, provided they're running on base forms, setting event handlers, and so on and so forth. Obviously, references and other things that are baked into the save data won't be accessible until you load a game.

Also, tangentially related, pretty much anything that gets done to a base form will be undone once the session is exited. (See the section on GECK Form-ID, Base-ID, Ref-ID, and Editor-ID if you need a refresher on the differences.) That includes form lists, models, collision, AI, items added to a base form's inventory, and anything else you can think of that gets done to a base form. However, references spawned with these scripts running may or may not retain the effects (they usually don't, but inventory stuff will stick, in the case of most functions, because that gets baked into the save data, whereas something like whether or not a base form's combat is disabled is not saved in a save file).

TIP Quest Advancement

Thanks to EPDGaffney of the Nexus Fallout "New Vegas GECK and Modders" forum and RangerBoo of the Nexus Fallout "Mod Troubleshooting" forum for the basis of the following:
Quest scripts are the driving force of each and every mod. They need one or more "GameMode" blocks so the engine will examine those blocks of code every frame, but in turn each should be "gated" with conditional statements so their following code statements are only processed when all the "gate" conditions are "true"; to keep performance high. These are often controlled by the value of variables defined in a Quest script (e.g. "DoOnce", "Status", "Bark", etc; the names are immaterial and up to you) which may exist solely for the purpose of defining those variables if numerous other scripts relying upon those variables may be disabled/enabled to improve performance. Otherwise define them in the Quest script in question BEFORE the first "Begin GameMode" block. The variables in Quest scripts persist and are accessible between other scripts.

Sections of code that are described as "Blocks" have a statement that signals the beginning (e.g. a "Begin" or an "IF" statement) and one that terminates the block (e.g. an "End" or "EndIf" statement respectively). Be careful that you use the correct block terminator in the correct place or your scripts will either prematurely halt processing or runaway from your control (infinite loops).

Other Blocks within a "GameMode" block are typically dealing with "Events" triggered by the Player: OnActivate, OnAdd, OnDeath, OnEquip, etc; which are also terminated with an "End" statement. Use "nesting" indentation to keep track of which "terminators" belong to which "beginnings". This not only makes it easier to read but also to track that each "Beginning" has an "Ending". It is possible for such "Events" to be triggered by NPCs. (See the GECK tutorial How to script conversation between two or more NPCs.)

The point is such "Events" need to be detected and reactions initiated within a "GameMode" Block. If your Quest or Dialog is not advancing, it is likely because you do not have the initiating conditions being detected within such a block, and hence you are not getting the response (such as another script or "AI package") started.

Another possibility preventing advancement is that the Quest script is not currently running. (See TIP: Quest - Stopping within it's own script.)

TIP Quest Delay timer

Leave Special variables' fQuestDelayTime alone. That sets the default quest delay for every quest in the game. Try using function SetQuestDelay instead.

TIP Quest Stopping within its own script

Thanks to EPDGaffney of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Sometimes you might have reason to want to stop a quest script when certain conditions are met within that script. Turns out this doesn't work if you try to put everything into a single "GameMode Block". You need to split it out into two such blocks.

The following example is the part of an "EventHandler" which illustrates this technique: 

scn NoteEventHandlerQuestScript

int DoOnce
Begin GameMode
    SetOnMenuClickEventHandler OnMenuClickUDF 1 "MapMenu/GLOW_BRANCH/MM_MainRect/MM_NotesList"
    Set DoOnce to 1
    If DoOnce == 1
        Set DoOnce to 2
    EndIf
End

Begin GameMode      
    ; Note that I tend to 'over-check' in my scripts, to be certain it will work as intended.
    ; DoOnce probably didn't need to go past 1 before stopping the script.
    If DoOnce == 2  
        StopQuest NoteEventHandlerQuest
    EndIf
End

TIP Referencing Objects

Thanks to uhmattbravo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
When you need to perform an action on some object placed inside of the "game world", you need to be able to reference it. The "Reference ID" (Ref-ID) is unique to each instance of an object placed in the game. If you place a "static" object (a "rock" for instance) into the world, there is seldom any need to refer to it specifically, so you normally do not enable it's "reference data flag: persistent reference" setting. When you do intend to refer to that object later (in a script for instance), you simply enable that setting and it automatically gets pre-assigned a "Ref-ID" by the game (in addition to any "Editor-ID" you give it) which you can use anywhere.

If you need to bring a "persistent" object (such as a container) to your current location, the preferred method is to initially have your mod place the "persistent object" somewhere hidden in the game world (underneath "ground level" in a cell is common). (If you intend to be able to return the object to that location later, place an X-Marker there as well. See the sub-entry "X Target Data" on the GECKWiki "Reference" page.) You can then either use the "object reference" (aka "Editor-ID") or create a Ref Variable (see also the Associating data with a reference page), combined with either the MoveTo or PlaceAtMe functions to bring the object to the desired current location, perform whatever actions with/upon it, and then use the "MoveTo" function to return the object to the hidden location "X-Marker".

On the other hand, there are many objects (such as "containers"; which you should recall all Actors are considered to be) that get dynamically spawned by the game during play (for instance from "leveled lists"). Such "spawned objects" are always as "non persistent" refs from a "Base Form" template without a pre-determined "Editor-ID" or "Ref-ID". (They are all given an automatically generated instance "Ref-ID" that begins with the "mod index" of "FF". All undeleted "FF" mod index entries get "baked into" your "save game" files. This is how you get "save game bloat".)

Note that objects flagged as "quest items" apparently are treated as "persistent" by default, regardless of the "reference data flag" state. That appears to be the only way to spawn "persistent refs" in-game as well.

If you specifically need a "non persistent" ref, stick something like this on the script related to that "object" (e.g. container object script): 

Short CurrentAction
Ref ContainerRef

Begin GameMode
; Remove all player equipment and place into this "non persistent" container.
  If CurrentAction == 0
    Set ContainerRef to getself
    Set CurrentAction to 1
  Elseif CurrentAction == 1
    Player.removeallitems ContainerRef
    Set CurrentAction to 2
  Endif
End

Otherwise, if it doesn't really need to be a "non persistent" ref: name it, and use it's Ref-ID.

TIP Relocating objects to Player by script

Thanks to madmongo and Nexusmodsaccountno2 of the Nexus Fallout "New Vegas Mod Talk" forum for the basis of the following:
When dealing with the game "coordinate" system of X/Y/Z axes, it is important to consider if you desire to deal in "absolute" coordinates with respect to the worldspace, or "relative" coordinates with respect to the "calling reference" (e.g. "Player").

Exterior cells belong to a world space, and are part of that world space's landscape, which is basically a grid that extends infinitely in all directions. Each exterior cell is 4096 units by 4096 units or 192 feet by 192 feet or 58.5 meters by 58.5 meters. Each vertex in an exterior cell is 128 units apart - the same height roughly, as a human biped, or about 6 feet.

All exterior cells are automatically given a grid number that represents their X,Y coordinate starting from the center of the world space at coordinate 0,0. Cells to the right of 0,0 have a positive X coordinate. Cells above 0,0 have a positive Y coordinate. ... GetInGrid is similar to GetInSameCell, but checks a grid of cells, making it useful for exteriors. Returns true (1) if the specified reference is within the grid of cells centered on the player, the size of which is specified by depth. Depth defaults to 0, a value of -1 will use the uGrids to load setting. Added by NVSE 4.6. --GECKWiki

The coordinate system uses the "X-axis" to indicate "left-right of zero" and the "Y-axis" to indicate "front-behind of zero" on the same horizontal plane; while the "Z-axis" indicates "up-down/elevation" on the vertical plane relative to the center (0,0,0) grid or reference point.

You could use GetAngle Z (which returns the heading angle of an object relative to the world) to get the angle of the player's rotation, which will be the direction the player is facing relative to the cell North orientation. OR use the GetHeadingAngle which returns the angle between the calling reference and the specified object in a range from -180 to 180 degrees. (The direction the calling reference is facing is considered 0 degrees. Angles measured clockwise from 0 are positive, while angles measured counter-clockwise from 0 are negative.) The choice depends upon whether you want an "absolute" or "relative" reference.

Then decide what distance you want to place the object (item or actor) from the Player.

To get the position offset based on angle and distance, use the following formulas: 

x = distance * sin (angle)
y = distance * cos (angle)

You can either use those offsets in the "MoveTo" function, or add them to the Player's offsets and use SetPos (or JIP NVSE SetPosEx) instead. Since you know the player's angle, adding 180 to that and using SetAngle Z will rotate a relocated actor to face the opposite direction (i.e. directly facing the player). Take heed of the "Notes" for this function. This is a case of "the role of 'Z' axis varies by function", i.e. as "rotation" instead of "elevation".

Example use in a script: 

Scriptname MoveInFrontOfPlayerScript

Begin onequip ;your choice

  int iDistance
  float fOffsetX
  float fOffsetY
  float fPlayerFacingZ

  set iDistance to 70 ; or some desired <integer_value> in "game units"
  set fPlayerFacingZ to PlayerRef.getangle z
  set fOffsetX to iDistance * sin fPlayerFacingZ
  set fOffsetY to iDistance * cos fPlayerFacingZ
  SummonedRef.MoveTo PlayerRef fOffsetX fOffsetY
End

Note that you could use "SummonedRef.MoveTo PlayerRef fOffsetX fOffsetY fPlayerFacingZ" if you want the "summoned" object to appear above or below in elevation at an angle to the Player. However, "z" in the "MoveTo" commands refers to the vertical plane (i.e. "elevation") and not the "rotation angle" from the "GetAngle Z" command stored in "fPlayerFacingZ". That variable will probably work as the value is not likely to offset the object too much, but the name chosen in this instance (while accurate) might lead to confusion in implementation. A different variable (e.g. "fOffsetElevationZ" set to a specific value) might be better, depending upon circumstance.

Use with caution. There is nothing stopping those functions from placing the actor inside a tree or a rock or underneath the terrain if the terrain happens to rise suddenly, In an interior cell, the actor could be placed outside of all existing rooms, causing them to fall into the abyss (they'll usually end up somewhere on the map afterwards). Depending on what you are doing, you might be better off using a trigger and an Xmarker.

"MoveTo" only works correctly if the "SummonedRef" object is in the same cell as the Player. (See GetInSameCell.) If not, you need to use Player.GetParentCell and MoveToCell functions instead, but in a similar manner.

Whether an Interior or Exterior cell is the destination of the "MoveTo" function, the object has to be in the same cell as the calling Reference (e.g. Player), or the "MoveToCell" function has to be used. "Borders/boundaries" are like exceedingly thin walls or "navmesh" lines: on one side or the other, but never straddling.

When in an interior, the exterior world is no longer visible. Each interior cell is essentially its own universe. --GECKWiki

There is no fixed size to interior cells, so it is more difficult to determine if a location is near a cell boundary. A subsequent call to "GetInSameCell" to determine if the moved object was successfully re-located may be needed.

You may need to use "GetPos" for each axis to check for large values which are likely to indicate they are approaching a boundary.

A "relocation" of an object by "MoveTo" or "MoveToCell" can only be determined to succeed or fail while the script is running. For this reason, the incorrect use of one or the other will not prevent the script from compiling/saving. During execution (while running in the game) only that statement will fail, but subsequent statements may then fail as well as a result the statement in question failing to prove a valid (e.g. failing to set a variable or condition). It could happen in the (probably rare) instance of being near a "cell boundary" when using "MoveTo". If you add the "Cell" checks mentioned previously, it will probably be sufficient to prevent that. You may want to split out the "Cell" checks into a "multiframe" block (see 'TIP Block Types Multiple vs Single Frame processing', and only call your "movement" script once you have identified the circumstances: one script for "MoveTo" and a separate one for "MoveToCell".

By default: the engine behavior where a script that has failed (due to any reason) at some point during execution will be effectively disabled by the game and will no longer be processed again until the game is restarted. However, there is an INI configuration setting ("bNoFailedScriptLocks") for the "JIP LN NVSE Plugin" which allows such failing scripts to continue to run instead. Where this is a possibility, requiring the use of "JIP LN NVSE" for your mod is not that big of a deal. The "game fixes" provide by that Plugin are not available any other way, which is reason enough to make people use it. And both NVSE and various plugins for it add functionality not available in the vanilla game, which make many mods possible. Most mod users will already have one or both installed. If they don't, it's their loss; not yours.

TIP Restricting OnActivate blocks

Thanks to uhmattbravo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Some doubt has been raised as to the ability of the "OnActivate Player" block to keep from running when activated by an NPC instead. It is suggested that use of 'if IsActionRef Player == 1' in a normal "OnActivate" block is much more effective alternative.

TIP Script Result vs Result Script

Thanks to Mktavish of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
The terms "Script Result" & "Result Script" are not interchangeable.

The first word in each term is an adjective to the following noun.
"Script results" are an intangible noun of what we are trying to achieve from lines of script coding.
"Result scripts" are a specific batch of coding depending upon the result of some event item, which holds the FormID.
Any "Result Script" field functions pretty much like any other one time event script, such as "Begin OnActivate". You just can't declare variables or use "Begin Blocks". They belong to whatever item/event they are found with as far as a RefID/FormID goes.

When you want to put lines of code into (for example) a "Dialog Topic" conversation or "Quest Script" "Script Result" field, you need to click the "Compile Result" button just below/adjacent to that field in order to save the code.

TIP Special Characters in String Variables

Thanks to Radioactivelad of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Some string characters have special meanings when parsed and can cause unexpected compiler problems. For example, this code won't compile: 
SCN MESLoyalCustomerRewardScript
 
Begin Scripteffectstart
 
Player.addPerk MESPerkDiscount
showmessage MESPerkRewardMessage
 
End

There is nothing obviously wrong with the code. The problem actually lies in the "content" text of the string variable "MESPerkRewardMessage", which happens to contain the character "%" (percent sign). Depending upon which function you use to display that text, some special characters are used to format output and you have to take steps to get them to "display" without being "interpreted" by the compiler. Such frustrations are just one of the reasons "string and character functions" were added to NVSE, to provide means to work around those limitations. A quick glance at the linked GECKWiki page will show that the subject is more complicated than one might suspect; but you can express your special characters (such as "%") so they only get rendered when displayed (e.g. using the 'AsciiToChar' function). What is important is to realize such special "formatting" characters exist and account for them, even when buried in a string variable.

TIP Testing new to you functions

Thanks to Mktavish of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Often in attempting to solve a scripting problem you will find or be directed to a GECK or NVSE function which MIGHT be helpful, but no one is certain if it is really applicable. All you can do is test it out.

The temptation might be to just plug it into your current project code, but this can easily lead you astray. Better by far to create a "stripped down, minimal to function test script" and plugin for the purpose which provides only the essential elements to test the conditions under which you want the function to operate. While it might initially seem to be a waste of time, rethink that.

  1. Creating a test script forces you to think about what you really need in order to have what you want to happen. This alone can clarify your problem.
  2. By producing only the essential code you have eliminated other potential factors in your project that may be clouding the picture of what is actually happening. This may involve pulling elements initially created/stored in other scripts, but having them in one place makes it easier to spot omissions or incompatibilities. This saves time in the long run.
  3. Use debugging statements to your heart's content without worries about it's impact on the rest of the game or your project. You don't even need to make them conditional upon a "debug mode" variable.
  4. Clearly delimit known functional code from your test code with comments. This helps you to stay focused on the problem areas.
  5. Indent code, lining up blocks and conditionals. This helps identify syntax and structure errors as well as making the code more readable.
  6. By focusing on only the one function, you can try various approaches that may have nothing to do with your project, but help you to clarify how the function does and can work. This is especially helpful when the syntax and application is vaguely described. Experimentation then hurts nothing else.
  7. Test "in-game", as this is the only way to be absolutely certain what happens at "run-time". (See the TIP: Debugging data to file on how to produce a "console log file" of your test results.)
  8. When you do test "in-game", be sure to toggle "ArchiveInvalidation" off-and-on again after including your test plugin in the "load order". The conditions under which this "toggling" is required for proper functioning are vague, and it's simple enough to do that it should just be a normal part of your test regimen.
  9. Sometimes you need to use a "save game" from prior to the changes. It's recommended to avoid making any saves while testing, unless the function you're testing needs a "save spot". (For example: "GetGameRestarted" needs a save spot, so create one just for that purpose.) In that case, having a "TEST" game setup (profile) just for the purpose makes a lot of sense if you have the disk space. At the very least, create a new, clearly identifiable character save game for the purpose. Never use your "in-play" game for testing unless you are prepared to revert to a known point prior to starting any tests.
  10. Once you have complete your testing, you now know exactly what is required, and can toss the test file aside or perhaps find a re-use for it later. This is a common practice and you will find that you can often build upon previous testing efforts. If nothing else, a well designed shell of a test script/ESP can easily be re-purposed.

TIP Timers

Thanks to xqdcss of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
Timers are generally based upon the GetSecondsPassed function, which returns the number of real life (not game) seconds that have passed since this function was last called by the calling script (i.e. it always "counts up"). Things to bear in mind:
  • Function will only work in Quest scripts; and inside the GameMode and MenuMode Blocks of an Object/Effect script.
  • Function always returns 0 inside "User Defined Functions" (UDFs).
  • SetGlobalTimeMultiplier will affect the return value of this function in the same way it affects the speed of the game.
  • Each script has its own independent tracking of when GetSecondsPassed was last called.
  • Calling this function multiple times in the same script in the same frame will return the same values for each call.
  • This function is unreliable in a ScriptEffect during sleep/wait/fast travel. Use ScriptEffectElapsedSeconds in a ScriptEffectUpdate block instead.

TIP Script Size limit

Thanks to jazzisparis of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
There is a limitation on the size of scripts in the GECK: based upon the number of characters: including spaces, comments, and "non-printing" control characters like "line feeds" (aka "new lines"). (Note Windows files use a pair of control characters (<CR>+<LF>) to signal a "new line" while Unix style systems use a single <LF> character, and Apple Macintosh uses a single <CR>. Some editors (like Notepad++) allow you to configure this, and to display character counts on a status line.) Various numbers have been cited (usually "around 32,000"), but the most specific seem to put the maximum between 31875 and 32767.

According to the author of the JIP NVSE plugin: "The size of the compiled script is also limited, and is more problematic since it's reached long before the character limit. This is especially true with NVSE-heavy scripts."

In addition, there is a common misconception that "the result script for a quest stage only allows around 1K". This can be worked around by clicking Edit button next to the Result Script box; instead of editing the script directly in the box. This opens the result script in an "editor" instead of a form display control. (The same applies to any Result Script; not just for quest stages.)

Texturing

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

TIP Custom Posters

Thanks to madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
First you need to create or convert your desired poster image into a DDS file. See Programs and Tools section for the available choices of Texture Editor.

The poster mesh NIF that Fallout New Vegas uses for most of its posters isn't well suited for hanging posters from the ceiling or beams since it is one-sided. If you go behind it, there's no surface on the back side of it and you just see right through it as if it wasn't there. It's fine for posters that you hang on the wall though since you can't go behind the wall to look through it.

The way the mesh for the posters is set up, it doesn't use the entire texture. It only uses part of it, which is why your poster may look cut off. All you need to do is shrink your image a bit and the entire image will show up. It's easiest to just copy your new image over an existing one so that you get the size right, but you may need to play around to get a feel for how far the front of the poster extends over the face of the texture image you are using. Copy your new image so that it only covers the image part of the poster, leaving the rest of the image blank, and save that with your new texture name. Then open a renamed copy of the poster mesh NIF file in NifSkope and assign that new texture file to it.

TIP Customizing an existing texture

Thanks to pixelhate on the Nexus Fallout "New Vegas Mod Troubleshooting" forum for the basis of the following summary:
  1. You have to locate the original texture element files in the "Fallout - Textures/Textures2.BSA" file.
  2. Extract them (using BSAOpt; listed in the Programs and Tools section).
  3. Make the desired modification of the texture in the graphic app of your choice and save as a ".dds" file with a unique name.
  4. Place your modified textures inside a created folder with your mod name, place that folder in "Data\textures\< type >", where "< type >" matches that of the original texture.
  5. Place the unmodified texture elements (normal map, glow map) in your mod's Data folder, following the original texture's structure.
  6. Open GECK, create a new "Texture Set", make the "Diffuse texture" (aka "Color") map pointing to your modified texture and the other texture elements pointing to the original ones.
  7. Create an unique instance of the object mesh (with an unique name) using Blender or Nifskope; and make it use your new texture set.
  8. Remove the unmodified textures from point 5 (not needed anymore)
  9. Place the custom object in game, save, test in game.
Never use "Texture Sets" on "Furniture"! It will make your ESP crash, as well as the GECK.
Always make back-ups before making any changes.

TIP Improving Texture Normal Maps

Thanks to pixelhate, EPDGaffney, and madmongo of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
(For an explanation of the specific terms used here, please see the Glossary page of the TESTG wiki site.)

Suppose you want the normal map of a texture to provide as much detail as possible. The key is understanding that it is working on two layers: the RGB "color" one which gives you the surface relief; and the Alpha channel one which gives you the Specularity.

If the specular map is "White": things will be very shiny. If it's "Black": it will be completely dull. Nuance of "Grey" will be in between.

To have the normal map with an effective Alpha channel you have to save it in DXT5 format.

If you want your texture to look even better, make a specular map and put that in the Alpha channel of the normal map. (You can use the DXTBmp Texture Tool for this purpose by exporting the specular map in ".bmp" format from your paint program, opening the ".dds" normal map in DXTBmp, importing the specular map into the Alpha channel, and saving.) Just be aware that depending on the settings on the mesh itself (which I would not change for a "face", unless it's a "custom race" mod), you may need to darken your specular map extremely for it to avoid "radiating like the sun itself".

It's not straightforward to insert an image into the normal map's Alpha channel using just Photoshop CS2, but it can be done. You need to first flatten the image by converting it to Greyscale, duplicate the Grey channel, name it "Alpha 1", remove the original "Alpha 1" channel in your normal map, and then drag the "Alpha 1" channel you've just created into your normal map.

On the subject of tool choice for this purpose, madmongo said:

I have never used Photoshop so I can't compare with that.

I have used both GIMP and Paint.Net. I found GIMP to be less intuitive so there is a bit of a steeper learning curve with it. Paint.Net seems more intuitive and easier to use to me. I personally tend to use Paint.Net for most FNV stuff. Most other modders prefer GIMP. I think GIMP is a bit more powerful, though Paint.Net usually does everything that I need it to do.

Paint.Net includes DDS support right out of the box. With GIMP you need a plugin. GIMP and Paint.Net both require a plugin to make normal maps.

Paint.Net doesn't treat Alpha channel as a different layer, so it's more difficult to work with. If you are messing around with Alpha channel stuff, GIMP is the better choice, IMHO.

Weapons

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

TIP GECK CTD when editing weapons

"Every time I attempt to use the GECK to edit a weapon it crashes, even when only the main NV master file is selected."

This has been traced to the presence of a specific file that is overwritten by "Fallout Character Overhaul" (FCO): eyebrowm.nif in: Data\meshes\characters\hair. Remove it when using GECK, and restore it when playing. If you put it into a batch (.cmd) file such as the following to launch GECK you won't forget.

@echo off cls ::REM As GECK has to be run from an 'Administrator' account, you should launch it from a ::REM shortcut (.lnk file) that has that "run as" setting in the 'Properties'. This will ::REM be run in a separate sub-process window. Otherwise the 'start' command won't WAIT ::REM until GECK is done before continuing with this script. ::REM Change the 'set runpgm=' line to point to your GECK shortcut. set runpgm=C:\Users\Public\Rec\FalloutNV\GeckPU.lnk ::REM Change the 'set gamedir=' line to point to your game install folder. set gamedir=E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas ::REM Nothing else below this point should need to be changed. set tgtdir=%gamedir%\Data\meshes\characters\hair
pushd "%gamedir%" if exist "%tgtdir%\eyebrowm.nif" ren "%tgtdir%\eyebrowm.nif" eyebrowm.nif.hld && @echo SCRIPT: Removed file [eyebrowm.nif]
@echo SCRIPT: Manually close the separate window GECK is launched in. When you do, DO NOT @echo SCRIPT: select to 'Terminate batch job' (answer "N") or you won't restore files properly. start "GECK" /D "%gamedir%" /WAIT cmd /k "%runpgm%" if exist "%tgtdir%\eyebrowm.nif.hld" ren "%tgtdir%\eyebrowm.nif.hld" eyebrowm.nif && @echo SCRIPT: Restored file [eyebrowm.nif]
:DONE pause popd

The GECK should also be patched to use up to 4GB of memory (i.e. FNV 4GB Patcher, NT Core's 4GB EXE Patcher or their more general CCF Explorer, or the like).

The GECK can also appear to "hang" while trying to load plugins. This may be due to failing to select other plugins your target plugin requires as "masters", but which are not ESM files. You can use the xEdit/FNVEdit "File Header" to identify all the files that are masters to your plugin, and then be sure to select all of them when loading it into the GECK. Please see the wiki Missing Masters article for details.

TIP Weapon Effect Animations

Thanks to pixelhate of the Nexus Fallout "New Vegas GECK and Modders" forum for the following:
You can't Import/Export Texture animation in Blender (e.g. "Shishkebab's fire"). Set up for such animations are done in Nifskope. See the Animations section.

TIP Weapon has unexpected zero percent VATS Chance

Thanks to yummy2 of the Nexus Fallout "New Vegas GECK and Modders" forum for the basis of the following:
So, you modded some weapon (either vanilla or from some mod) and suddenly it has "0%" chance to hit in VATS.

The problem is not with your custom weapon mesh or texture; it's with the projectile, which may have inadvertently or intentionally been altered. For instance, a "non-zero" timer and proximity of the projectile's explosion. Even if it was a "Trigger on impact" explosion, the non-zero values can still mess up VATS. Compare such settings with other projectiles working correctly.

Worldspace Creation

(Worldspace creation is basically the same between FO3 and FNV. See also the Navmeshing section.)

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

WARNING: Do NOT use any of these methods to clean the deleted navmeshes in the official ESMs. This will do more harm than good. "Official ESMs" refers to the DLC by the game publisher.

TIP Creating a new world map

All "world maps" are based upon a "bitmap image" in ".dds" format. Depending upon how "original" your worldspace territory is, you may be able to find "satellite images" or "heightmap" or other sources whose copyright permits you to create a "derivative work" by scanning/converting into a bitmap image format. Otherwise you will probably have to take screenshots of the various "render windows" of your unique worldspace in GECK and stitch the results together into a single image for use as described below.

Ptolemy by Alan Broad (included in the mod Ptolemy Maps for New Vegas), being purpose-built for games like The Elder Scrolls, not only came with the Morrowind map but served as a tool for creating game maps from bitmap images. It included a simple but robust suite of tools for creating and organizing locations based on their type, faction, importance, etc. It was used to create the FNV maps included in that mod.

In addition, there is the wiki article Oblivion custom in-game map which is a short tutorial describing one method of creating a working world map for your worldspace in Oblivion. As the same game engine is used for both, the process should work for FNV. Just don't select anything in the "Parent Worldspace" field.

A more complete tutorial on the overall process is Creating a Custom Worldspace for Fallout 3 by truancyfactory.

Packaging Mods for Installation

Once you have created (and tested) your mod, you still aren't done. You have to "package" the ESM & ESP files, and all related "assets" into a structure suitable for installation. And given that there are more than one "mod manager" in use by people, this requires some forethought. Once you have created your "mod package", you then have to "publish" it on the Internet, presumably to the "Nexus Mods" site which is the assumption here.

Note: If you package your mod into an "executable installer" (so it has a ".exe" extension), it cannot be installed with a "mod manager". They can only deal with packages in 7Zip, ZIP, or RAR archive formats. You would have to "run" the installer executable first so it unpacked the package into a folder, and then manually move the contents of that folder to the correct locations under "Data".

[When linking to a Video, be sure to check the page sidebar for additional, related subject videos.]

Re Original images: You can use screenshots from the game, as long as you are the one who took them, or you use those posted by others with their explicit permission. When in doubt, see the "Terms of Service" and the image "file" page to check the permissions there.

Re Music: If you intend to include externally sourced "music", "voices", or "sounds", see the wiki article Illegal Music Pack Uploads and You. Unless it is your own original work, it's copyrighted by someone else. You have to check for permissions.

Re REQUIRED: That setting is for linking other mods/plugins that are essential for your mod to work correctly.

A video does not fall into that category, as it can only be describing how to install or use your mod. Your best bet if you feel it is essential people use it for your documentation is to provide that explanation and link it prominently in your description (as well as under the "Video" tab). (See the wiki Formatting and BBCode in Descriptions article.) However, bear in mind that:

  • Not everyone likes or can even watch some videos: e.g. medical conditions; a different native language (not easily translated from a video; while it is from a text file);
  • A video is no substitute for written instructions which should be included in a "ReadMe" file. That link not only explains that position but links to a "ReadMe Generator" program to help you create a "proper" file.
  • Most players do not want to read/view anything to get a mod installed. People (well, most of them) never seem to RTFM. They assume all they need to do is install, and at most then add it in their mod manager to their current game settings. They will then turn around and complain your mod is "broken" and demand you fix it NOW. This is a "fact of life" for mod creators. Plan for it, and reduce your installation complexity upfront as much as possible.

To that end, learn how to properly package your mod.

Packages can be divided into two categories: "standard" and "private":

  • A "standard" structured package follows the directory structure used by the game: that is vanilla game sub-folders under "Data" (such as "Meshes", "Textures", "Menus", etc.), with possibly additional "mod specific" sub-folders under those (e.g. "Meshes\armor\<ModName>"). Such can be handled by any of the available managers. Note the current generation of mod managers do not require you to include the "Data" folder itself. See the wiki article Modding Etiquette.
  • A "private" structured package introduces layers of non-vanilla sub-folders (e.g. "<Mod Name>\Data\<Mod version folder>\Meshes", etc.). Such have to be manually restructured to remove the offending "non-standard" folders before they can be properly installed using a "mod manager" (or even recognized if installed manually).

Obviously you want to create "standard" structured packages to avoid having to deal with the questions your users inevitably will have in getting your mod installed.

The most common mistake is that people misunderstand the part about creating an archive package that goes: 

go back into the root of the folder so that the address bar once again shows '''C:\<MyMod>''' and then select all the files (.esp & .txt) and folders (meshes & textures) and right-click on them

You are NOT supposed to select the folder C:\<MyMod> in the example. You are supposed to select all the files (and any sub-folders) under that folder. If you select the folder itself, then the package gets created with that folder name as the top level in the archive, and every "mod manager" will treat it as a new folder under the "Data" folder. The files will not get placed in the correct locations; they will be buried one level down and never seen by the game engine.

Even when you build a "standard" package, the structure can be categorized into one of two forms: "simple" and "complex".

Simple structure

All modern "mod managers" can easily install packages with a "simple structure" that starts under (not including) the game "Data" folder (e.g. "Meshes\<category>\<mod name>\<other sub-folders as needed>"). They either add their files directly to the existing vanilla folders, or under their own sub-folder in order to keep them separate. It all depends upon the paths used when building the mesh and texture files. They might create their own, new folders starting at the "Data" level (e.g. "Data\NVSE"), but the package structure simply has the new folder in the package at the same level as the top level vanilla folders, like "Meshes", "Textures", and "NVSE". The "Data" folder is assumed by the manager. This is the reason some package structures, which require they be installed starting in the game root folder (e.g. "Fallout New Vegas\LOOT"), usually cannot be installed correctly with a "mod manager".

Complex structure

The simple structure does not have "conditional install components": meaning some files that are only installed under certain conditions such as the presence of a plugin from a different mod. Complex structure may also require certain "scripted" modifications to existing (usually vanilla) files. The different "mod managers" vary in their ability to handle such scripting (often called "install wizards" or simply "wizards"). If the scripting capabilities of a particular manager are required, it is the author's responsibility to make this adequately clear to the potential mod users. Often such structures use various sub-folders to group the files related to the specific condition together.

Understanding how the various "mod managers" can assist with installation will enable you to use a structure that takes advantage of the most available features of all of them.

Uploading to the Nexus

Mod Publishing Tutorial is written for Skyrim with plenty of illustrative images, but should be pretty universal with obvious changes for any specific game. It's on Nexus, but as the author suggests using the HTML version, that's what's linked first.

An older alternate, shorter version is the wiki How to upload mods article.

The wiki Formating and BBCode in Descriptions article can help you create a more distinctive description page. Remember: this page is where you "sell" your mod to potential players. Like any advertising campaign, "eye appeal" is important.

The next step

So, you wonder if you are ready to step out of the novice stage. You know you are at this stage after you realize the grand scheme you had in your head for your idea isn't going to happen, and scale back your initial ambition.

You should start looking to the forum boards and reading what others are coming up with for idea's on what to mod. Then just take that idea and since now you are more familiar with the GECK and information resources (like the GECK wiki), see if you can solve the problem with their idea. Just in a "lurking" fashion if you don't want to actually go public.

Many mod creators have found this to be a huge source of learning material, since they cannot come up with all the various idea's on what to mod on their own. Helping others is actually helping yourself, and there is nothing like trying to solve a particular problem to consolidate all the various bits of information into an understanding. You will almost always learn something new when investigating how to accomplish another's idea. (Anyone who has engaged in teaching others will tell you they learn more preparing to teach than they started already knowing.)

And just for learning purposes there are all the past posts, some of which have been solved. Many haven't, so there is no shortage of first time solutions to be worked out.


References

(Generally in order of appearance in the article.)

Refs Programs and Tools

Refs GECK Tools

Refs Image Tools

  • Maya (1 month free trial, $185/month or $1470/year subscriptions, 3 yr student/educator license.)
  • NIF tangents and binormals updater (freeware) by zilav.
  • NifSkope (freeware.) Note this is the latest release and may not be the best choice for FO3/FNV.

Refs Packaging Tools

Refs Scripting Tools

Refs Sound and Voice Tools

Refs Misc Other Tools

Refs Details

Refs Common Problems with GECK

  • New Vegas Templates (Hidden Category). This article section consists entirely of file "Template:GECK: Common Problems" content, which needs to be edited directly to update.

Refs GECK and the Active File

Refs GECK Form-ID, Base-ID, Ref-ID, and Editor-ID

Refs Custom items

Refs Custom Creatures

Refs Spawning modded items

Refs Worldspaces

Refs Additional Material

Refs 3D Model and Texture resources

Refs GeckCustom.INI

Refs Factions, Stealing and Ownership

Refs Bethsoft Basic Tutorials

Refs Animation

Refs Armor & Clothes

Note the KGTools web site containing the downloads is no longer accessible. Use the links on this site (adults 18+ only) instead.

Refs Blender (Mesh Editor)

Refs Collision

Refs Conversions

Tools behind a "gated" "Adult (18+) Only site" in their "modder resources" section.

Refs Creature Creation

Refs Custom NPCs

Refs Dialogue & Lip-synch

Refs FaceGen: Heads, Faces, Hairs, and Helmets

Refs Havok Physics

Refs Heightmaps

Refs LOD Generation

Refs Misc Topics

Refs ESM & ESP Files

Refs Factions & Reputation

Refs GIMP: Posters & Images

Refs How to ...

Refs Import Custom Videos

Refs Item Creation & placement

Refs Make Readius Screenglares

Refs Markers

Refs PAINT.NET: Normal Maps

Refs Recipes

Refs UV Mapping

Refs XML

Refs Music & Sounds

Refs Navmeshing

Refs NifSkope (Mesh Editor)

Refs Scripting

Refs Texturing

Refs Weapons

Refs Worldspace Creation

Refs Packaging Mods for Installation



Nexus wiki articles referred to by this article:


Nexus wiki articles that refer to this article:


 
Retrieved from "https://wiki.nexusmods.com/index.php?title=Getting_started_creating_mods_using_GECK&oldid=52601"