EasyNPC FAQ & Troubleshooting
Can't find your issue here? No problem, feel free to ask about it in the Discord chat.
-
App Issues
- All of the previews are blank/silhouettes
- I see two or more previews for the same mod, one says "mod not installed"
- The preview says "plugin not loaded", but it is active
- I can't find a specific NPC in the profile view
- Can I use a "base mod" for most faces, and customize a smaller number on top of that?
- Do I need to rebuild after making changes?
- How do I remove a master dependency?
- Why do some NPCs show as "unmoddable"?
- Why is the Post-Build Checker showing a conflict with vanilla?
- Game Issues
- Compatibility questions
These questions are about issues within the EasyNPC app itself. If your issue is only visible once you've launched the game, skip to Game Issues.
EasyNPC does not generate previews on-the-fly (yet). To see previews, you need mugshots, usually obtained from the Nexus page or the EasyNPC Discord.
Download/installation of mugshots is covered in the installation guide. If you've acquired some packs and still aren't seeing any previews:
-
Make sure you've actually extracted the mugshots. EasyNPC doesn't recognize the .7z archives, only the images inside them. Your mugshot directory should look similar to the following:
-
Check the directory setting. EasyNPC can use any directory for mugshots, but defaults to being inside the app directory:
To use mugshots from a different directory, you have to configure it in the app settings:
-
If you just changed the directory setting above and still don't see mugshots, try restarting the app.
----- OR -----
This is either an inconsistency between the mod name and the mugshot directory name, or an incorrect mod directory setting. Both issues are described in more detail in the Profiles documentation. To summarize:
- Check that your mod directory setting is correct.
- Rename the mod, rename the mugshot directory, or set up a synonym between the two.
Mod Organizer creates a file called meta.ini inside each and every mod directory; this file includes only incomplete information about the mod. Specifically, it includes the mod ID (e.g. Nexus ID), but not the name. If EasyNPC does not know the real mod name, it uses the directory name instead.
When possible, EasyNPC joins the mod ID with Mod Organizer's download metadata in order to discover the true mod name, i.e. as it was named when you downloaded it from Nexus Mods or any other mod site. If you've noticed that sometimes everything lines up even when the directory is named differently, it is because EasyNPC was able to discover the correct name this way. This will be the case for 9 out of 10 users who use a "vanilla" Mod Organizer setup and let Mod Organizer handle the downloads.
Several scenarios can cause this discovery to break down:
- The mod file was downloaded manually, or via another tool like Wabbajack which doesn't always store complete metadata.
- You deleted the download from Mod Organizer, i.e. in order to clear up disk space.
- The download folder location was changed at some point, without moving all the previous downloads.
- The mod ID itself is incorrect or ambiguous; for example, if you have mod "A" installed, and decide to merge a totally different mod "B" into it by giving it the name "A" and telling Mod Organizer to merge. Only the most recent ID is stored, so EasyNPC will think the mod is actually "B", not "A". (Note: This is very similar to the reason why Mod Organizer sometimes gets confused about which version of a mod you have installed)
- The author of the mod changed its name, and the mugshot directory name was based on the old name, and doesn't match either the new name or the directory name.
All of these problems are easy to solve with a synonym and/or rename, but some users wonder why it only "sometimes" needs to match. Thus, the trivia above.
Vortex support in EasyNPC is roundabout and quirky due to the mechanics of Vortex itself. Unlike Mod Organizer's relatively simple metadata structure using directories and INI files, Vortex's metadata system is an internal Redux state, and not even generally accessible to the outside world.
Most programs that are supposed to interact with Vortex do so (and must do so) from inside the app, as an extension. Since that is not a practical option for a standalone app such as EasyNPC, the integration is instead done via a launcher extension, which creates a file named easynpc-vortex-bootstrap.json in your computer's %TEMP% directory, and passes that along to EasyNPC. This is the sole source of information that EasyNPC has about actual "mods". Without this file, all EasyNPC can see in Vortex's staging directory is a bunch of strangely-named directories based on Nexus files, or what EasyNPC internally calls "Mod Components".
If you're seeing a lot of noisy, confusing names in the mugshot list such as Bijin Wives SE 1.1.2-11247-1-1-2, it could be either a missing bootstrap file or a problem with generating the bootstrap file. In one case, it turned out to be a user who migrated from Vortex to Mod Organizer, but wanted to repurpose the old Vortex staging directory as Mod Organizer's mod directory, which didn't work so well. If you're a Vortex user and can't figure out the root cause of a mugshot problem, you might be able to get some clues by looking at this bootstrap file; and if not, we will probably ask you for it on Discord anyway, so it's a good idea to go grab it regardless.
This only applies to options where the mod is installed, but the plugin is not. If the preview also says "Mod not installed", refer to the previous FAQ.
This warning confuses a lot of people, because sometimes it's relevant to their scenario, and sometimes it isn't. Unfortunately, there isn't any clear way for EasyNPC to distinguish between the two types of situations.
"Plugin not loaded" means exactly one of the following:
| Frequency | Problem? | User fixable? | Description | Examples |
|---|---|---|---|---|
| Common | Yes | Yes | The mod has a plugin, and this NPC requires both record edits and facegen edits, but the plugin is not enabled. | N/A |
| Very rare | Yes | No | The mod has a plugin, which is supposed to have record edits for this NPC, but doesn't (i.e. the mod is bugged). | Unknown |
| Uncommon | No | No | The mod has a plugin, which intentionally does not include record edits for this specific NPC, because they aren't required, i.e. the mod does not change this NPC's head parts. | Unofficial Patch (USSEP) |
| Uncommon | No | No | The mod does not have any plugin, for any NPCs, because it is a "ESP-free" mod based entirely around vanilla head parts. | Modpocalypse, Cathedral NPCs (HMB II) |
One quick way to rule out issue #1 is to look at the list of loaded plugins by clicking on one of the plugin filters:
If the plugin that you expect to see is in the list, then the message is showing for one of the other reasons, 2-4. You can still proceed with that option; it is what EasyNPC calls a FaceGen Override.
FaceGen overrides are an "I know what I'm doing" feature. Use them when you know, with reasonable confidence, that the facegen uses the same head parts as the face plugin you've selected. Typically, you can find this out from the replacer's mod page, which will say if it is designed to work with the original ("vanilla") record, USSEP, or some other base mod. EasyNPC does not validate that the head parts are compatible, so use this feature at your own risk.
If you find yourself in the last situation in the table above, wanting to use a large mod such as Modpocalypse as a "catch-all" option for any non-customized NPCs, consider the base mod workflow as an alternative. Otherwise:
- Check the mod page to see if there should be a plugin for this mod, and if so, make sure it is active.
- If the plugin is already active, or if there is no plugin, ignore the warning but proceed with caution.
EasyNPC is based on the assumption that you'll be customizing some, perhaps most, but not all NPCs in the game. To avoid cluttering the list with a lot of useless information, it only shows NPCs who are able to be customized based on your current load order and mod list. This requires that either (a) there is at least one override record that changes the NPC's visual attributes, or (b) there is at least one FaceGen file for the NPC in an enabled mod.
Additional rules apply to template NPCs who have the "Use Traits" flag. For example, in vanilla Skyrim, the two NPCs SummonGormlaith and MQ206Gormlaith are both templates of GormlaithGoldenHilt, and while some mods will provide facegen data for the first two (template) forms, they will generally be hidden from the profile view because their option is tied to whichever option is used for GormlaithGoldenHilt. You can't change the other two to something else without breaking them. This is very common with miscellaneous bandits and other "filler" characters, e.g. almost anything starting with Enc, DA, Dun, etc.
The exception to the "no template NPCs" rule is when the "Use Traits" flag is inconsistently applied in the load order - that is, some ESPs use it, and other ESPs do not. In these situations, the NPC will always be shown, but EasyNPC may block customizations depending on which Default Plugin is selected.
If you are positive that a particular NPC should be showing up, be prepared to include a log file with your question/report as well the name/ID of the NPC in question, and the names/URLs of the specific mods and plugins that are supposed to be customizing him/her. You will most likely get asked whether you've already checked for NPC overrides and/or facegen files.
Sometimes a mod author just forgets to include an NPC in their mod, but most of the time, it's because you forgot to activate those specific mod(s) in your mod manager.
Yes, and most users who want to use a huge sweeping overhaul such as Modpocalypse or High Poly NPC Overhaul will choose to do it this way instead. The specific scenario supported is:
- You have exactly one mod, usually described as "lore-friendly" or "vanilla-plus", that is intended to replace all or almost all vanilla NPCs in the game.
- You want this mod to replace every vanilla NPC that it's capable of replacing; you never prefer the vanilla appearance.
- Whenever there is a choice between the base mod and some other (non-vanilla) mods, you always want one of the other mods.
- In other words, the priority is always: Vanilla < Base Mod < Any Other Mod
You can use facegen overrides to do these one-by-one, but there is a much more efficient workflow:
- Disable the base mod/plugin before starting EasyNPC.
- Set up your profile and build your merge for the NPCs you care about.
- When activating your EasyNPC merge, also activate the base mod, and load the base mod above the EasyNPC merge. Make sure that the EasyNPC mod loads after (below) the base mod.
- If the base mod has an ESP, also make sure that
NPC Appearances Merged.esploads after the base mod's ESP. Otherwise, you can ignore this step. - Use the post-build checker to resolve any remaining inconsistencies, e.g. in case the base mod has loose files.
Your mod/load order should be similar to the following:
Because these base mods can touch thousands of NPCs, the above workflow will typically take much less time than doing the NPCs one by one. However, this only works when there is one single base mod. Do not skip step 5 above. Many of these base mods do use loose files, and EasyNPC creates a BSA, so running post-build is absolutely essential for getting the correct priorities.
This breaks down into two related questions:
-
"Will it break the game if I make changes without rebuilding?"
No, it won't break anything. EasyNPC profiles, as opposed to EasyNPC builds, are stored completely outside of any mod/game data. This is in contrast to other situations like changing animations or body presets, where the game can glitch out if you don't rerun FNIS/Nemesis/BodySlide/etc. This is not an issue with EasyNPC.
-
"Do I need to rebuild in order to see my changes in the game?"
Yes. EasyNPC builds are self-contained mods, so as explained in #1 above, nothing actually happens to the game until you build a new mod/merge, and deactivate the old one and activate the new one in your mod manager. Once built, an NPC merge is just like any other mod.
So you can feel free to play around with EasyNPC as you see fit, and not worry about negatively affecting the game; but if you're asking this question because you are in the process of trying to fix a problem with a prior build, or add a new overhaul, etc., then you have to treat it as an entirely new build.
A proposal for incremental builds exists, but is on the back burner because it does not seem like very many users actually need to rebuild very often. Feel free to add comments about your particular situation if you are one of the few who does.
First, read the wiki on Master Details and check that part of your build screen. Any plugin listed under Master Details will be a master dependency of your merged ESP, regardless of whether or not it is flagged "suspicious".
The "suspicious" classification is to help make it easier to identify when something doesn't look right. However, if you've reached this FAQ because you already built a mod and it has a master you didn't want, then it's probably because EasyNPC didn't realize it was a visual overhaul, or intentionally classified it as something else. To eliminate it as a master dependency, you will have to create a new build.
Plugins become masters for one of two reasons:
-
They are directly specified as the default plugin for one or more NPCs. If this is the case, then double-clicking on the master will show a list of NPCs assigned to that plugin, which you can then reassign to a different default.
-
They are in the transitive dependencies of another plugin that is further down the list, often a patch that shouldn't have been included. This is why the guide advises you to work your way up from the bottom of the list; it is usually faster than going top-down or starting in the middle somewhere. Double-clicking on the transitive master will not show the relevant NPCs; you need to find the real plugin that is responsible.
Being "in the transitive dependencies" of a plugin means that it is "somehow" a master of that plugin, even if it might be indirect. For example, if B.esp has A.esp in its masters, and C.esp has B.esp in its masters, than A.esp is in the transitive dependencies of C.esp, even if it is not listed explicitly in e.g. xEdit. Most of the time, modding tools do force this to be explicit - that is, C must have A as a master because of B, even if C doesn't edit any records from A - however, keep in mind that it is entirely possible to create a "C" mod that doesn't do this. Various modding tools don't like it, but the game itself doesn't mind.
The default plugin is whichever plugin has the behavior, but not the face/visuals, that you want for that NPC. Please do not ask us in Discord which one you should pick; it is up to you to understand what mods you have installed and what they do, and there is a clear explanation of the meaning of this setting at the aforementioned link.
Because some NPCs just can't be modded. It's not anything you did wrong, it's just how the game works.
Examples include:
- Audio templates, which aren't "real" NPCs
- NPCs belonging to any race without facegen support, i.e. "creatures"
- Template NPCs with no un-templated overrides
The unmoddable category is FYI, so that you can reconcile all the different counts and make sure you've accounted for all NPCs in your current load order. Don't worry about them, unless you're having problems with a specific NPC.
It isn't.
While this does say "Vanilla", it is not a conflict with vanilla; it is a missing facegen file. What the report actually tells you is:
- Your merge plugin (
NPC Appearances Merged.esp) changes the head parts of this NPC; and - There is no corresponding facegen file in the merged BSAs/files for that NPC.
If you deleted or disabled a BSA, or deactivated one or more dummy plugins, you might see this error as a false positive, accompanied by earlier warnings about missing BSAs. However, in most cases, it's the result of ignoring earlier (pre-build) alerts about a profile problem.
If this warning showed up in your pre-build, it's going to show up in post-build as well. There is no automated fix; you'll need to do one of the following:
- Test the NPC in game; if there's no blackface, you can ignore the warning. Otherwise...
- Fix your profile and create a new build; or
- Find the correct facegen file and copy it as a loose file into your NPC merge; or
- Delete the NPC record from
NPC Appearances Merged.espso that it doesn't look for a facegen file; or - Create a manual patch (record + facegen) for this NPC.
If you're not experienced with manual patching, the first two options above are generally the best.
Most in-game issues related to EasyNPC can be prevented by following the instructions carefully.
- If you are new to EasyNPC, read the step-by-step guide.
- Make sure you understand the difference between the default plugin and face plugin.
- If the Build tab was showing warnings (alerts) and you clicked on "Build Anyway", and are now having problems, then delete the EasyNPC merge, fix those issues, and make a new build. You can get more information on a warning by clicking the question mark next to it.
- Run the post-build checker.
If you have already completed all of the above, and resolved all warnings/errors, and are still having issues, then read the following sections for more troubleshooting advice.
Run EasyNPC with the -z command-line option. Detailed instructions are on the post-build help page.
🛑 Before investigating any in-game issue, run the post-build checker.
Blackface is what happens when the game is exposed to an inconsistency between record data and facegen data. It is only caused by that. There are no other causes of blackface; it is not obscure, capricious, random or otherwise mysterious. It is trivially easy to reproduce, and usually trivial to fix.
A detailed explanation of blackface lives on this wiki, including screenshots from xEdit and NifSkope. That page focuses on the most common kind of inconsistency, but for the sake of completeness, these are the criteria that need to be met in order for any NPC to not have blackface:
- A facegen (mesh) file must exist at
meshes\actors\character\facegendata\facegeom\<plugin_name>\<formid>.nif - A face tint (texture) file must exist at
textures\actor\character\facegendata\facetint\<plugin_name>\<formid>.dds - Both the facegen and face tint must be valid and readable by the game
- The names of the shape nodes in the NIF (those with type
NiTriShape,BSTriShape,BSDynamicTriShape, etc.) must be identical to the Editor IDs of the NPC's head parts obtained from its winning record.
Files can either be loose, or in a BSA somewhere, as long as that BSA is actually loaded.
If one or both of the files aren't present - blackface.
If one or both of the files are corrupt - blackface.
If the NIF has an extra shape that isn't included in the NPC's head parts - blackface.
If the NIF is missing a shape that IS included in the NPC's head parts - blackface.
One caveat: head parts without a model (that's MODL in xEdit) don't need to (and must not) have a corresponding shape in the NIF. Model-less parts, like MarksFemaleHumanoid00NoGash, are an instruction to the game to "render nothing in this slot", thus it must not have any geometry inside the NIF file. Everything else must match.
Generally: ignoring warnings and/or not following instructions.
Specifically:
- Did you fix all build warnings before building your merge, especially any making mention of a missing facegen file or other asset?
- Did you activate the EasyNPC merge mod and plugins, including all dummy plugins?
- Did you disable all of the original NPC overhauls after activating the EasyNPC merge?
- Does the EasyNPC merge (mod and plugin) load after all other mods/plugins that modify NPCs, with the possible exception of automated patches like Synthesis?
- Did you run the post-build checker and apply any automated fixes?
If you have done all of the above - if the post-build checker shows everything clean, yet the game still renders blackface - then you may have made a mistake with a facegen override, or you may have stumbled across a bug in the original mod. These are extremely rare, especially for popular/older mods, but they are not impossible. The simplest, and fastest way to verify is to switch to a profile with no mods enabled except the specific mod chosen for that NPC and any masters it depends on. If the NPC looks correct under this minimal profile, then the problem is not with the original mod.
If, after following all of the instructions, running the post-build checker, and verifying the correctness of the original mod, you are still unable to track down the issue, and suspect a bug in EasyNPC, then expand the section below for a detailed guide on manual validation of ESP-FaceGen consistency. Very few users should ever need to do this, and modding novices may find it difficult to follow. If you believe it applies to you, consider double- and triple-checking the previous steps first.
-
Turn on Archives Parsing in Mod Organizer.
-
Get the plugin name and form ID for the NPC you're debugging.
-
Check for the face tint file at
textures/actors/character/facgendata/facetint/<plugin_name>/<formid>.dds. It's a good idea to do this first, because it's quick, and the face tint doesn't need to match anything else, it only needs to exist. So you can potentially save yourself a lot of wasted time poring over head parts if the problem is just a missing tint.
Above is an example of what your tint directory might look like. Most files are probably coming from the EasyNPC merge, but for this step, it's actually OK if some don't. As stated above, tints aren't tied to anything else, they're just textures, the only thing that matters is that they have the correct path/file name and that the game can read them.
-
Check for the facegen (NIF) file.
Unlike the face tints in step 3, most if not all of these should be coming from your NPC merge, unless you're intentionally doing manual patching on some NPCs and/or have deliberately excluded them from EasyNPC. Here you can see one from Pandorable's NPCs, which probably shouldn't be there. But the post-build checker catches all of these basic issues, so that's not really the focus. If you don't see any problem here, continue reading.
-
Open the relevant NIF file in NifSkope. If it's in a BSA, Mod Organizer will not let you open it directly; instead you will have to extract it first, using a tool like BSA Browser.
It will probably look ugly/wrong in NifSkope, but the appearance is not important, only the node tree.
The node names you see are what the game expects the head parts to be:
FemaleMouthHumanoidDefault,0SSHeadNord, etc. Make a note of these; write them down, copy and paste, take a screenshot, etc. Close NifSkope when you're done. -
Open your entire load order in xEdit. Find the NPC in question, and scroll to their head parts.
Normally, the only plugins you should see here are the masters (Skyrim, Unofficial Patch, etc.) and
NPC Appearances Merged.esp. In the screenshot above, there is a conflict with the information from step 5. The EasyNPC merge is the winning record, but the facegen data matches the "Shield-Sisters Re-Imagined" record. This is the result of having a discrepancy between mod order (left side of Mod Organizer) and load order (right side, plugins tab).The post-build checker catches obvious issues like the one above, so if you are following this guide, you likely will not see any discrepancy here. For the next few steps, ignore the
NPC Appearances Merged.esprecord and focus on theShield-Sisters Re-Imagined.esprecord instead. The objective is to validate whether the complete set of head parts here is consistent with the nodes from step 5 - in other words, to check whether there might be some problem with the mod itself. Start with these head parts:-
FemaleEyesHumanLightGrey- check, block #11 -
MarksFemaleHumanoid00NoGash- missing from NIF file, but remember that this is a "model-less" part, so this is correct. -
0SSHeadNord- check, block #18 -
000IonaEdge- check, block #31 -
00SS_FemaleBrowsHuman1- check, block #37
There appear to be a few discrepancies at this point; specifically,
000IonaEdgeHLandFemaleMouthHumanoidDefaultappear to be coming out of nowhere in the NIF. But you're not done yet. -
-
Check each individual head part in the ESP for "extra parts". This is especially common for hairs, but can exist for any part.
This accounts for the
000IonaEdgeHLpart found in the NIF. If, at this stage, you find an Extra Part whose editor ID is not in the NIF file (e.g. if the "HL" part was missing in the screenshot from step 5) then you've identified the root cause and can stop here. Otherwise, continue to next step. -
Check the head parts for the NPC's race. Iona is a female Nord, so...
This part is likely to be the most difficult for the less-experienced modders as you have to understand how the overrides work. Head parts are indexed by type. This is actually the
PNAMfield in step 7, and an NPC can only have one head part per type, except for "Misc", which is effectively unlimited.You can see that
FemaleMouthHumanoidDefaultis here, which answers the lingering question from step 7. But what about all the other parts, likeHairFemaleNord04,FemaleHeadNord, etc.? These are overridden by the mod:-
HairFemaleNord04is replaced by000IonaEdge -
FemaleHeadNordis replaced by0SSHeadNord -
FemaleEyesHumanHazelBrownis replaced byFemaleEyesHumanLightGrey -
FemaleBrowsHuman01is replaced by00SS_FemaleBrowsHuman1
Result: Everything is accounted for.
-
If you've been investigating an NPC that is black-facing in the game, and you've already checked the face tint, then you will have found a discrepancy at some point in this process. If you've followed this process from start to finish, and made sure that everything checks out perfectly, and are still getting blackface in game, then congratulations, you win the internet.
What to do when you've found the discrepancy? That depends on where you found it:
-
If
NPC Appearances Merged.espdoes not have the same (cumulative) head parts as the mod you picked in EasyNPC, then you've found a unicorn bug. Very rare, but it has happened, once. Please create a bug report including screenshots from each of the above verification steps, and specify which combination of mods triggered the problem. At this point, you can ignore all the "do you really want to report a bug?" warnings; you're the exception to the rule, having done all of the requisite investigation and confirming that the problem cannot possibly be user error. -
If
NPC Appearances Merged.esphas the same head parts as the original mod, but the facegen NIF makes no sense (i.e. looks like it came from some other mod), you may have found a bug, but probably not; check your profile first, make sure you haven't done anything like a FaceGen override for this NPC. Make sure that the winning facegen NIF from step 4 actually came from the NPC merge; if it didn't, then either it's a problem with your mod priorities, or, if the merge doesn't have a facegen at all (but does have the ESP record), then maybe that facegen file was missing or inaccessible when you built the merge, and doing a new build will fix it. If you're absolutely positive that none of the above apply to you, add a bug report/Discord question with details of the source mod, the specific NPC with the problem, and a screenshot of your profile with this NPC selected or a copy of yourprofile.logfile located in%LocalAppData%\EasyNPC. -
If the discrepancy was anywhere else, then it's a load order problem, which you have to fix on your end. Make sure that the EasyNPC merge is providing both the winning ESP record and the winning facegen. The post-build checker automates this, but it's still possible to break what the post-build checker does by having a mod with loose facegen files loading at a higher file priority (i.e. below the NPC merge in Mod Organizer). Un-break it, and the blackface will go away.
🛑 Before investigating any in-game issue, run the post-build checker.
Known causes for this include:
-
Blackface, when using a SKSE plugin named "Face Discoloration Fix".
Due to the enormous amount of confusion caused by this plugin, and its proclivity to cause more problems than it solves, no link will be provided in this FAQ, and recommendations of it are officially banned from the EasyNPC Discord.
If you have this plugin installed/enabled, it most likely does not do what you believe it does, or work as effectively as you believe it does. Instead, it causes whiteface, which can look very similar to baldness and other missing assets. Remove/disable the plugin and relaunch the game. If the same NPC now has blackface, then that is the real issue; refer to the previous FAQ. If you do not use this plugin, or do not see any difference for the given NPC whether or not the plugin is enabled, then see scenario 2 below.
The technical explanation for why FDF causes this issue is that many NPC overhauls are distributed without the original assets required for CharGen - the in-game routine for generating face geometry from the slider values assigned to the player or NPCs - because they aren't necessary when the mod is installed correctly, because the game does not run CharGen on NPCs with valid facegen data. When FDF forces CharGen to run on that NPC, they appear to be missing entire head parts because the game can't find the original mesh. Custom sculpts of vanilla head parts revert to vanilla (unsculpted) appearance, while custom head parts referencing custom meshes simply disappear or crash.
Users experienced with the Creation Kit may be familiar with a similar phenomenon, in which the CharGen Preview for an NPC does not include some parts or shows a giant exclamation mark in their place. This happens for the same reason.
-
The NPC uses a head part that is not available to that NPC's race.
All head parts refer to a "Valid Races" (RNAM) form list:
Typically it will point to the exact form list shown above,
HeadPartsHumansandVampires, but whichever record it points to will include a list of the supported races:
If the NPC's race is not in this form list - for example, if a child NPC is referencing an adult head part or vice versa - then the game may choose to render nothing at all.
EasyNPC inherits the race from the default plugin - that is, not the face. It does know how to patch head parts to be compatible with merged NPCs, so this normally should not happen. However, if you've found a clear-cut case where they don't match, then there might be a bug. You can work around it by patching the form list to include the NPC's race; patch it in a new ESP, don't edit the original list.
-
The NPC uses an Armor Addon that is not available to that NPC's race.
This is very similar to #2, above, but follows a slightly different path, and is more often responsible for invisible bodies (floating heads), but can affect any part of the NPC.
Armor addons can either be equipped armor or the NPC's Worn Armor (WNAM), i.e. their skin. To rule out the possibility of a bug with equipped armor, you can undress them in the game: open the console with
~, click on the NPC, and typeunequipall. If they are still missing parts of their head or body, then the issue is not equipment-related. Check the Skin (Worn Armor) instead:
Every NPC has a skin. If you don't see one specifically assigned to the NPC, then check their race:
Whether it is inherited from the race or overridden by the NPC, the Armor record has a few fields of interest.
The interesting fields are:
- Race (RNAM): Should either be the NPC's race or
DefaultRace. - Armature (MODL): The Armor Addon (ARMA) records that will replace the NPC's default body or head parts.
- First-Person Flags (in BOD2): The slots that the entire armor occupies; two different armor pieces cannot use the same slot on the same NPC. This can sometimes be confusing because a flag appearing here does not necessarily mean that the armor actually replaces all of those parts; only the addons do that. For example,
CamillaBodyArmorincludes theHeadflag but doesn't include any model for the head; this is expected, not a bug.
Most of the trouble, if there is trouble here, happens in the addons:
First-person flags here work in a complicated way (refer to #4, below), but in general you should think of the addon as actually replacing all of the parts that would otherwise be present. Bijin is a bit confusing here as technically a Worn armor requires fewer slots, but it doesn't really matter. The torso part includes the
Bodyflag, whereas a Hands or Feet addon would specify theHandsorFeetflags instead.As shown above, the interesting fields are:
- First-Person Flags (from BOD2), described earlier. If the specific part that is missing/invisible in game is one of the parts listed here, then that's a very good indication that the Addon is the source of the problem.
- Race (RNAM): Is often the NPC's race, but doesn't have to be; see below.
- World model (MOD2/MOD3): Depending on whether the NPC is male or female. The model must be specified, and must point to a NIF file that exists in your data directory; use Mod Organizer's archive parsing to make sure that it does. EasyNPC will generally alert you of a missing model before you build, but there is always the possibility of it going missing during/after the build, so it is a good idea to check. If the model is missing, the part will appear invisible.
Missing parts can be caused by either a missing model or an incompatible race - but addons, unlike armors, can specify additional races:
The above example is from a wig, used in one of the many NPC hair physics patches. Note the first-person flags; these replace whatever the NPC's hair would normally be, based on their head parts. The race is set to
DefaultRace, which does not match the NPC's race; usingDefaultRaceor some arbitrary race here is common for addons that may be shared by many different NPCs. The "Additional Races" includesNordRace, which is the correct race for the NPC in question (Lisbet).As long as an NPC's race is either the RNAM for the addon, or included in the Additional Races, it will display correctly in game. If the NPC is of a completely different race, then it will not.
EasyNPC automatically patches Armor Addons so that all NPCs using them will be included in the Additional Races. If you've found a bug, then aside from reporting it, you can work around the issue by creating an ESP patch which adds the NPC's race to the addon's races.
- Race (RNAM): Should either be the NPC's race or
-
The NPC uses an Armor Addon with an incorrectly-partitioned mesh.
Partitions are a complex topic that are beyond the scope of this FAQ and generally not worth investigating unless you have a compelling reason to believe that the mod author messed up (i.e. because you've tested the mod in isolation, without involving EasyNPC, and it's still broken).
For those familiar with 3D modeling, partitions are like vertex groups or face groups; they are defined in the NIF file (the "model" from #3 above) and they must be consistent with the First Person flags.
Above is an example of a different, but similarly-implemented wig, occupying partitions 31 and 41, or
HairandLongHair, same as those defined in the addon's first-person flags above. This is what you expect to see when everything is correct.It is complicated to check on partitions because it depends on whether the shape uses
NiSkinInstanceorBSDismemberSkinInstance. Most authors manage this aspect in Outfit Studio. Users who are not experienced in the creation/porting of armors and skins are advised to steer clear of editing, but for those who want to deep-dive, finding partitions that conflict with first person flags may signal a problem.Contact mod authors only after testing their mods in isolation, in an otherwise vanilla load order, in order to be absolutely certain that it is an issue with the mod itself. It is far more likely to have been caused by one of the other scenarios, or a problem with your load order that can be detected by the post-build checker.
🛑 Before investigating any in-game issue, run the post-build checker.
This is a missing texture. You can find out which one using the following process:
- Get More Informative Console or equivalent mod.
- While in the game and viewing the affected NPC, open the console and click on the NPC.
- Hover over "Textures" and press Shift.
- Make a note of all the texture paths listed, or take a screenshot.
- Exit the game.
- Check for the presence of each texture in the game's data directory, e.g. via Mod Organizer's data tab with archive parsing turned on.
There are a few unusual cases where EasyNPC can fail to copy a texture that the game would otherwise recognize, if the texture paths in the NIF have a particularly difficult format to parse. If you've encountered one of these cases, you can resolve the issue by finding the texture in the original overhaul mod and copying it (as a loose file) into the EasyNPC merge, using the same relative path found in step 4 above.
Neck gaps - literally, empty space between the neck and head, as opposed to "neck seams" which refer to inconsistent color/texture without a gap - are a common issue when swapping NPCs on an existing saved game, due to weight inconsistencies. These can be fixed in game by resetting the weight:
- Determine the default weight for the affected NPC. If you know which mod was chosen for that NPC, then you may be able to find it listed on the mod page, but the fastest way is usually to open your NPC merge in xEdit.
- While in the game, open the console with
~. - Click on the affected NPC.
- Type
setnpcweight xx, wherexxis the weight from step 1 (in this example, 30). This will cause the NPC's face to get temporarily bugged, possibly blackface. Don't panic. - To fix the NPC's face, type
disableEnter, and thenenableEnter into the console.
At this point you should have the correct face again, with no neck gap. If there is still a neck gap, then it is a problem with the mod and you won't be able to fix it on your end.
🛑 Before investigating any in-game issue, run the post-build checker.
These types of problems tend to be:
- Unique to your particular load order, operating system, video drivers, hardware, etc.
- Difficult and time-consuming for anyone but you to investigate;
- Very unlikely to be beneficial to any other user if resolved; and
- Almost invariably the result of a poorly-managed mod setup and not related to EasyNPC.
Because of the above, no assistance will be offered for problems of this nature. Issues posted on GitHub will be summarily closed, and requests on Discord will receive a warning in response, followed by moderation as appropriate.
There are two exceptions to the policy:
-
You have a developer or IT background, know how to read a stack trace, have pinpointed a specific corrupted file/archive, and verified beyond a doubt that it is not corrupted in the original mod and definitely became corrupted on its way through EasyNPC during the merge process; please report an asset handling bug, and include documentation of the specific asset, source mod, and profile options.
-
You have found a way to consistently reproduce the issue, in under 10 minutes, starting from a pristine game installation and a clean EasyNPC profile (i.e. removing any prior
profile.logfrom the EasyNPC data directory); please provide clear and detailed instructions with your report. If it fails to repro, or the process takes too long (too many mods, requiring many GB of downloads, etc.), it will be closed without further comments.
We're sorry if you're having one of these issues and feeling frustrated, but the cost-benefit ratio for investigating them is distinctly negative. Only reports in which the reporter has done at least some of the legwork, as explained above, will be accepted.
🛑 Before investigating any in-game issue, run the post-build checker.
Like CTD, ILS, etc., in-game issues usually are not caused by EasyNPC. However, it does sometimes happen, as in the case of the beast transformation bug, so these have to be addressed on a case-by-case basis.
The key is reproducibility. Someone else needs to be able to reproduce the issue you're seeing, on their own machine, in a reasonable amount of time. While the constraints here aren't as severe as CTD/ILS type issues, here are a few suggestions:
- Can you trigger the issue with a relatively small mod list?
- Can you trigger the issue on a new game, without having to load a previous save?
- Does the issue always happen at the same time, or with the same NPC?
- Can you narrow it down to a mod incompatibility by disabling/enabling some mods and seeing the issue consistently trigger or go away?
- Have you looked for anything suspicious in xEdit and, of course, EasyNPC's post-build checker?
- If a specific NPC or group of NPCs is affected, have you ruled out a problem with the original mod by running the game with just that mod (not including EasyNPC in the process)?
- Have you found any other workarounds that consistently work, even if they're temporary and/or you can't use those workarounds in your final build/modlist?
The more effort you've put into your own troubleshooting, and the more answers you come prepared with, the more likely it is that your issue will get looked at and addressed promptly. What no one wants to do is install 250 mods in an attempt to replicate your exact setup, merely to have a chance at seeing the issue you're seeing. So please tell us your issue on GitHub or Discord, but be specific.
Good: "I've used EasyNPC to merge Floop (master/default) with Fleem (face) on NPC Wazzerface. If I start a new game and spawn her with placeatme, her legs are wrapped around her neck 8 times and she has dragons for hands. Post-build only shows one warning which is for a different NPC. There's no problem if I just run with Floop and Fleem mods by themselves, loading Fleem after Floop. Here's everything that xEdit is showing has changed with this NPC. I've uploaded/can upload a copy of the NPC merge to Google Drive/MediaFire/Mega/etc., it's only about 50 MB and doesn't require any masters except for Floop and USSEP."
Bad: "Some NPCs are looking glitched. I think it's caused by the eyes or maybe the hair. It happens on Patty Sweetcheeks and Bigbutt McGee, I'm using Bijin and Pandorable and 362 other mods. I've tried everything. HELP!"
AKA: "Does EasyNPC work with..."
Race replacers are supported, with some caveats.
If you've only used the replacer as a face option (not default), then EasyNPC assumes you might not want to keep that mod enabled after the merge, which is why it copies all of the head parts to the target NPCs, including head parts inherited from the race. That way, if a race replacer changes default head parts, and includes facegen files with the new head parts, those facegens will still work even if the race edits are removed/reverted.
However, some race replacers go far beyond simple visual overhauls and also change behaviors, scripts, or skeletons. In these cases, you generally need to leave that race replacer enabled after the merge, and load it above the EasyNPC merge. "RS Children" and "Project Ja-Kha'Jay" are two commonly-cited examples of this. They work fine with EasyNPC, but unlike conventional "overhauls", they need to stay in your load order.
In some cases, these replacers may also have loose files - worst case, loose facegens. This can interfere with EasyNPC's BSA-ification. Use the post-build checker to resolve these by extracting the necessary files from EasyNPC's BSA, and make sure EasyNPC has priority in both the load order and mod order.
Replacers such as Vanilla Hair Replacer and SUEMR are not currently supported, although they will be sometime in the future.
Generally speaking, most of these mods are relatively harmless to have installed as they only affect the Player Character; the game does not actually look at the internal geometry of the head parts, only what's in the facegen NIF and the morph (.tri file) for the head part. The intended and typical behavior of having a mod like SUEMR is that your Player Character gets the new visuals, and existing NPCs look the same as before unless you regenerate their facegen files in Creation Kit, which usually isn't possible or practical when those NPCs are modded using custom sculpts.
Where this can get dangerous is when some mods - VHR being one of the culprits - modifies or removes the actual morphs. This does affect the game, which has to combine facegen data with head part morphs for the purposes of skinning (e.g. facial expressions and any other modifiable "sliders"). The result is nothing mundane like blackface; it's usually CTDs and other serious problems.
Don't use these replacers today, unless they are known to be usable without patching, such as the original High Poly Head mod or SUEMR; or if you know how to do all of the manual patching required for a replacer like VHR and don't mind putting in the time.
No problems have been reported with modern patchers, although in the case of Synthesis or zEdit/xEdit scripts, it depends on the specific patches you decide to include.
Patchers that try to do similar things, on a smaller scale, like facefixer, are going to cause problems. Patchers that do not alter any head parts or facegen data are fine, such as the AI Overhaul Patcher which is popular and generally recommended for users with heavy mod lists.
Most users of these patchers will run EasyNPC first, and then include the EasyNPC ESP in their load orders when running the patchers. It can be done the other way around, but it is more error-prone.
When in doubt, simply run the patcher and compare the patcher output to EasyNPC's output in xEdit. If it hasn't messed with the head parts, it's compatible.
The philosophy and support around these legacy "auto-patchers" has changed over time. Early development of EasyNPC was agnostic about these, and there is still a lot of help text within the app relating to them. However, the evolving consensus within the modding community in general, and this includes the tiny EasyNPC community, is: don't use them.
Not just "don't use them with EasyNPC", but don't use them, period. Wrye Bash does still have some other uses, but bash/smash patches in particular are obsolete. Virtually everything they can patch can be handled more accurately, and usually with better performance, by Synthesis, and for everything else, there's The Method. Bashing might seem like a great time saver - or, more often, a way for beginners to somehow skip the learning curve and be able to manage a gigantic load order with no effort - but they're simply not reliable. As the literal names imply, they bash or smash things together without any finesse and usually yield a super buggy if not outright broken game.
Because of all the problems with these patchers, EasyNPC is aligning with the Wabbajack community on the issue: use these tools if you feel you must, but don't ask for support if you do. Trying to resolve something that went wrong with a smashed patch is searching for a needle in a haystack. You're on your own.
Use of the term "AIO" (All-In-One) is unfortunately very inconsistent within the modding community, and sometimes even within individual mods, so in order to answer this question, you must first know or find out what the author means.
The majority of AIOs fall into one of three categories:
-
A "give me everything" option for a single mod that has other, à la carte options for installations.
Example: The Bijin Wives SE FOMOD installer has an "ALL IN ONE" option on its first page:
Installing this is perfectly fine, and is precisely the scenario that EasyNPC was designed to work with. You install the kitchen-sink options for every NPC overhaul, and use EasyNPC to pick and choose what you really want to keep.
-
A complete, standalone collection of mods that some author had released separately at one time in the past.
Example: Pride of Skyrim - AIO originally came out as many smaller "Pride of Skyrim" collections. The author merged them into one mega-mod. This mod is what we call a "true AIO" as it includes all of the assets from all of the included mods. You can usually identify a mod like this by the fact that it doesn't have any requirements on any of the mods it "includes". The Pride of Skyrim AIO does not require any of the other PoS mods.
As with case #1, these mods are fine to use.
-
A "merged ESP".
Example: The "Bijin AIO SE" that is included as an optional download with all of the individual Bijin mods:
These merged ESPs are largely a relic from the time before light masters - ESLs, or ESL-flagged ESPs - could be used in order to exceed the cap of 255 plugins, although this may still be an issue for Skyrim VR. Since EasyNPC is already going to merge all of your NPC mods into one, these merged ESPs are entirely redundant in any EasyNPC-based setup. But they are not only redundant, they can cause serious problems.
The first clue that this mod is liable to cause problems is the long list of confusing installation steps:
As you can see, this AIO depends on 3 separate mods and requires you to manually tweak the ESP load order. The problem is that when you install this AIO in your mod manager, it must "belong" to just one of those mods - or in some historical instances, none of them. This is an unsolvable problem for EasyNPC, because the ESP and the assets (facegens) no longer belong to the same mod. Instead, supposing you installed the AIO with Bijin NPCs, what you actually end up with is:
- Bijin Warmaidens Facegen files (no ESPs)
- Bijin Wives Facegen files (no ESPs)
- Bijin NPCs Facegen files, with an ESP including other NPCs missing assets.
These all have the name "Bijin", so it might look to the naive reader that everything is OK, but there are no shared IDs or anything to tie them together; it only works incidentally, when the mod manager dumps all files from all mods into the (real or virtual) game data directory. Imagine if the mods were named differently:
- Bob's Companions Overhaul - Facegens (missing ESP)
- Eve's Mage Guild Overhaul - Facegens (missing ESP)
- Randy's Thieves Guild Overhaul, with an ESP including Bob's and Eve's overhauls.
This makes no real sense, and yet it is fundamentally the same situation.
So: Don't use merged ESPs. Let EasyNPC do the merging.
-
As always, there is an exception to the rule. If the merged ESP is a prerequisite for an all-in-one patch that also includes all of the required facegen files, then it is OK to use both mods at the same time. This is the case with the Bijin AIO Hair Physics Patch. This brings ESP and facegens back into a single mod, undoing the problems that were caused by the Bijin AIO.
If you find yourself in a situation like this, the recommended approach is to install the merged ESP (since it is required for the hair physics patch), but do not disable or remove the original ESPs. When choosing profile options in EasyNPC, always choose either the original ESP, or the complete patch with assets (hair physics in the above example), but not the merged ESP. Do not let any part of your profile touch the merged ESP directly, otherwise you will end up with unresolvable assets, which the build will report as missing.
You must first determine whether the patch is resolving conflicts between two masters ("base patch" or "behavior patch"), or simply carrying over the visuals from one mod with another master ("overhaul patch"). The answer has nothing to do with the contents of the patch, only the mods being patched.
If you don't know whether the mods being patched are behavior mods or visual overhauls: Stop. Take a deep breath. Go back to the mod pages and read the descriptions of those mods. Maybe open them in xEdit to get a sense of what they actually modify. Take the time to understand your own mod list. There is no master list of NPC overhauls, there is no flow chart telling you how to identify an NPC overhaul, because it is subjective. Some cases are a lot more clear-cut than others, but you have to decide for yourself.
Some questions to get you thinking:
- Does this mod only modify the NPCs themselves, or does it modify things relating indirectly to NPCs, like dialogue, quests, factions?
- Does it only affect NPC appearances, or does it affect other aspects like perks, items, levels, etc.?
- Are you intending for this mod to be part of the final merge, or do you expect it to remain in your load order as a master?
If it only modifies NPCs, and specifically only modifies NPC appearances, and you intend for it to be merged, then it is probably what you would consider an "overhaul" or "visual". Otherwise, it is "master" or "behavior".
- Examples of what most users would consider master/behavior: Unofficial Patch, AI Overhaul, RS Children (because of the race edits).
- Examples of what most users would consider visual overhauls: Bijin NPCs, Pandorable's NPCs
As far as classifying the patch: if any of the mods being patched are visual overhauls, then it is an "overhaul patch". Otherwise, it is some other type of patch, which we'll call a "base patch", since it is patching what will be the base (master) mods of your merge.
Use them, and choose them as the default plugin for any NPCs they affect. The patch, as well as all of the patch's masters, will become masters of your NPC merge.
If you don't intend for all of those mods to become masters - if you are trying to merge some - then reread the previous sections and decide if this is really an "overhaul patch".
The short answer: don't use them, as they aren't necessary and might cause EasyNPC to guess wrong when it sets up your initial profile or when you reset.
Longer, technical answer: EasyNPC uses many different signals in order to try to detect these patches and ignore them when they aren't useful. However, a number of conditions can interfere with this magic:
- The patch was based on a newer/older version of one of the mods, so EasyNPC considers it as changing either appearance or behavior when in fact it changes neither.
- The patch includes deliberate "opinion edits" from the author of the patch.
- Your load order is very large and/or complicated and creates too much ambiguity in order for EasyNPC to resolve a "canonical" replacer/master.
- The patch is 3-way or n-way and can't be reduced to a simple "behavior + face".
The list above might not cover every possibility, but is meant to highlight why, if you have overhaul patches in your load order, they might end up getting chosen as the default or face plugin, even though they should be neither. Even if EasyNPC gets it right every time, they are still going to show up on your profile screen, adding another potential source of confusion and error.
EasyNPC does its best to work around overhaul patches that you might have inadvertently left installed, but your results will reliably be as good or better by not having them installed/loaded in the first place.
These are not conflict-resolution patches at all, but tend to confuse some people and deserve their own section.
Mods such as Bijin Hair Physics and The Ordinary Women Hair Physics are making further modifications to the appearance of some other overhaul, rather than resolving conflicts between an overhaul and something else. It is best to think of these mods as overhauls in themselves.
You need them installed/active when running EasyNPC, in order to choose them as the face option, but not the default. In this sense, they are just like any other NPC overhaul. They may depend on a primary overhaul (Bijin, TOW, etc.) as a master, but that master dependency will not be carried over into your merge, as long as you only use the mod for faces, not defaults.
The official releases will not work with the GOG edition, but try the GOG preview build. It may, or may not, work for you. If not, you can help by providing a crash report, or if you're feeling especially generous, a donation toward a purchase of the GOG edition, because USD $50 is a tough pill to swallow for someone who already paid full price for the Steam edition.
If the preview build does work for you, let someone know on Discord or in the GOG issue thread so it can be promoted to an official release.
These games may work partially, or not at all. Support is limited because testing is limited. An unofficial debug build for Enderal SE was posted some time ago, but very little feedback was ever received and so the changes have not been merged into the official release track.
Volunteers for alpha/beta testing are always welcome, with one stipulation: you must already be familiar with EasyNPC and have used it to create working merges on a supported game (Skyrim SE or VR). It normally only takes a few volunteers to get a game up and running as long as it's also supported by Mutagen, but so far there doesn't appear to be much demand.
In absence of testers, the answer is always "maybe". Try it with the relevant command-line option and see for yourself.