Mousetick

I do not wish to contribute to or edit the Guide in its current form. I've stated the reasons why I dislike it, largely enough already. My contributions to explain, educate on the subject and attempts to simplify it are contained within my posts in this discussion. You can incorporate bits of them into the Guide if you like and you think they're worth anything. Considering that DY does not agree that streamlining and merging the 1.5.97/1.6.x instructions into a single common workflow is a good idea, I see no point in pursuing the discussion. No hard feelings, though. Cheers

From now on, keep your BethINI INIs as they are, only edit SSEDisplayTweaks.ini manually in text editor, and always launch SKSE from MO2. Test after each change (after each following line) and report results: Set Fullscreen=true. Set Fullscreen=false, Resolution=1366x768 (remove the # in front of #Resolution). Set Fullscreen=false, Resolution=1365x768.

Sorry for not answering. I did learn a lot from the guide back when it was 1.5.97 only and 1.5.97 all the way. It helped a lot and I'm grateful for that. Thank you. I've looked at it on occasion, after 1.6.x broke everything, and after GCF became a thing. And I've commented on what I felt were deficiencies or shortcomings in other topics. But I've not used it or learned anything from it since I first used it with 1.5.97.

Is there a particularly strong reason you wish to continue supporting 1.5.97 users in such a way? As I previously said in my lengthy expose, GCF creates a new paradigm. This is the opportunity to let go of all the legacy and think outside the box! I'm suggesting to streamline the workflow and processes so that they are identical on both 1.5.97 and 1.6.x, all thanks to GCF. This was subtly implied in my prerequisite environments: But the idea was not clearly conveyed. So please allow me to elaborate with this crude graph: It's exactly the same whether PLAY is running 1.5.97 or 1.6.x. Benefits: Streamlined and simplified Guide, one text version, same procedures, common to all PLAY users. No more special-cases for 1.5.97 users using NGIO at runtime. This configuration is no longer documented/supported. Ability for 1.5.97 or 1.6.x players equally to use 3rd-party pre-generated caches (skipping the trouble of setting up CACHE or skipping the NGIO learning curve altogether). More clarity for users. Easier to maintain for STEP. Disadvantages 1.5.97 players can no longer use NGIO ExtendGrassDistance=True or DynDOLODGrassMode=2. As it is the Guide is riddled with special cases, every few paragraphs: if you're using 1.5.97 then this, if you're using 1.6.x then that. It's an unwieldy mess. Sorry. Does preventing the loss of ExtendGrassDistance warrant maintaining a special workflow and documentation for the very very small minority of users who might use it? To the detriment of the majority of users who don't need all the irrelevant "noise"? I don't think so, but it's your call. Thanks for reading.

Discussion topic: Green Water Cubemap Fix by wSkeever Wiki Link Fix bug where water defaults to green cave cubemap after exiting interior location that has water in it. Tiny plugin which removes the value of a game setting (GMST record) in Skyrim.esm. Install/Uninstall any time. This bug had been bothering and puzzling me. At first I thought it was weather mod-related, but there was no pattern linking the effect to specific weathers. And it wasn't obvious it only triggered after exiting an interior location with water in it. This is great.

Your comments suggest you don't fully understand what precaching does, what the grass cache contains, and how the precaching process differs from in-game grass rendering. I don't blame you for that lack of understanding, on the contrary, I empathize, as there is no clear information available. Which has been my point since the beginning of this discussion. Most of the information available is based on outdated 1.5.97 setups utilizing NGIO for both precaching and in-game rendering, in which case a clear distinction between precaching and in-game rendering didn't matter. Grass Cache Fixes creates a paradigm shift and some old habits/beliefs have to be thrown out: On one hand, NGIO is only used for generating grass and caching it. On the other hand, Skyrim.exe (1.5.97 or 1.6.x) with GCF uses the cache created by NGIO for in-game grass rendering. These are two distinct components which don't talk to each other, they don't share their configuration, the configuration of one doesn't affect the other. NGIO settings for grass generation, or rather the products thereof, are "baked" into the cache, changing the equivalent settings in Skyrim INIs for in-game rendering has no effect. DynDOLOD uses the cache created by NGIO for generating grass LODs as object LODs, that part hasn't changed. In a nutshell: We require 2 environments/profiles: CACHE (Skyrim.exe 1.5.97 + NetScriptFramework + NGIO + GCF); PLAY (Skyrim.exe 1.5.97 or 1.6.x + GCF WITHOUT NGIO). NGIO settings related to grass size, density, diversity are essential for precaching. They are specific to each grass mod, to user preference, and affect quality/performance. This will determine how the grass is generated and how it's baked into the cache. They can't be changed later at runtime in Skyrim INIs. This will also influence the amount/complexity of grass LODs if DynDOLOD is used. These settings should be changed in NGIO's own configuration, rather than CACHE's Skyrim INIs, for ease of access and to emphasize the fact they apply ONLY to NGIO's precache. NGIO settings related to full grass (optionally extended) distance, full grass fade distance, and grass LOD Mode are completely irrelevant for CACHE. The equivalent Skyrim INIs are also completely irrelevant for CACHE. They only pertain to in-game grass rendering, which is done by PLAY, and doesn't use NGIO. NGIO setting OnlyLoadFromCache is irrelevant for CACHE. NGIO never needs to read the cache in that environment, it only writes to it. Grass precaching produces a grass "coverage map" of each grass model present in a given cell, its size and positions in the cell. The "coverage map" is derived from plugins in the load order: The landscape (LAND) record of the exterior cell, which defines, among other things, the placement of patches of land grass or underwater kelp on the ground; The landscape textures (LTEX) records referenced by the landscape; The grass model (GRAS) records referenced by the landscape textures. NGIO ensures that "there is no grass in objects". A fundamental point that seems to be lost in all the confusion. One cell "coverage map" is stored in one .gid file. There is one .gid file per cell in a given worldspace. For example, Tamrielx0031y-029.gid contains the grass "coverage map" of cell 31,-29 in Tamriel. The grass cache contains the set of all .gid files for all worldspaces used in game. The cache is essentially a snapshot of the grass generated in the entire game world, as if all cells were simultaneously active (infinite uGridsToLoad). Consequently, any consideration pertaining to rendering/fading in active cells or DynDOLOD LOD Mode is pointless on CACHE, as it has no impact on the cache. The cache can be used not only for LOD generation by DYNDOLOD, but also by PLAY at runtime. The later provides a performance optimization for grass in active cells, but also and foremost, no grass in objects. This was not possible on Skyrim 1.6.x until GCF came along. The benefits of the cache are useful and desirable for PLAY, whether grass LODs are generated/used or not: At runtime, PLAY loads the .gid files of the active cells from the cache. Since the list of grass models, their size and position is already pre-calculated in the cache, in a manner such that grass doesn't clip through objects, all PLAY has to do is to render or fade the full models. Hope this is clear enough and it helps a little.

Possibly, but more importantly the last test puts MO2 out of the picture: it's not linked to the issue. Please post the SkyrimPrefs.ini created by BethINI and used in your last test. Also post SSEDisplayTweaks.ini (found inside SSE Display Tweaks mod folder). As attachments.

I agree it's extremely advanced modding. However I didn't mean the information should be beginner friendly, and I disagree it allows advanced modders to learn how it all works. I think the published information fails to explain anything actually. It's just a long series of steps to follow blindly as if it were geared towards mindless newbies. The extremely advanced modders are smart enough to understand, so they can be given more information than simply: do this, then do that, doesn't work at the end? tough, restart from the beginning. If things were really explained, extremely advanced modders would be better equipped to troubleshoot issues or tweak things on their own. Like DynDOLOD-style documentation, but without the dry inscrutable phrasing, and with lots of pictures to illustrate. Moreover the published information is riddled with useless noise or incorrect details. It's doing a disservice to the intended audience, who doesn't really learn anything, or learn falsehoods. Sure. Some of it is irrelevant and confusing/misleading when it comes to grass precaching, though. Example, Step 4 of the STEP Grass LOD Guide: UseGrassCache = True ExtendGrassDistance = True ExtendGrassCount = False EnsureMaxGrassTypesPerTextureSetting = 15 ;set to max count of grass types for the grass mod. This is for Cathedral Landscapes. OverwriteGrassDistance = 6144 ;Optional. This overrides skyrimprefs.ini. OverwriteGrassFadeRange = 14128 ;Optional. This overrides skyrim.ini. OverwriteMinGrassSize = 67 ;Optional. This overrides skyrim.ini. GlobalGrassScale = 1.15 ;Grass-size multiplier. A slight increase will make grass a bit slightly taller. OnlyLoadFromCache = True DynDOLODGrassMode = 1 Half of this stuff above is useless and doesn't matter. It's noise. The actual settings relevant to precaching are: # REQUIRED, Duh! UseGrassCache = True # Disabled. Not recommended. ExtendGrassCount = False # Disabled. Strongly not recommended. SuperDenseGrass = False # Set to max count of grass types for the grass mod (E.g. 15 is for Cathedral Landscapes). EnsureMaxGrassTypesPerTextureSetting = 15 # Grass density. Adjust as desired. 67 is recommended. OverwriteMinGrassSize = 67 # Grass-size multiplier. Adjust as desired. 1.15 makes grass slightly (15%) taller. GlobalGrassScale = 1.15 Sometimes, less is more.

That doesn't make sense to me, but ok. Since you reverted your INIs used in MO2 to "Before BethINI", you'll need to re-apply the recommended settings from the STEP Guide, or restore from backup. Once you're back to where you were before reverting to "Before BethINI", in other words, once you've restored to "after BethINI" , try the following in BethINI: uncheck 'Windowed Mode' on Basic tab to run the game in fullscreen mode. Then launch SKSE from MO2.

About your specs: * CPU: AMD A8-6410 APU with AMD Radeon R5 Graphics (4 CPUs), ~2.0GHz * RAM: 6 GB DDR3 - 1 GB Reserved for GPU - 2.5 GB Shared between GPU and OS - 2.5 GB Reserved for OS (and apps) * GPU: Integrated in CPU * VRAM: None * Display: 1366x768 (60Hz) * Storage: Toshiba HDD 500 GB 5400 RPM Even accounting for the much lower display resolution (1366x768) compared to standard 1920x1080, I'm not sure you can go any higher than Skyrim "low" and even then I have some doubts about sustained play due to heating/throttling, or memory usage and swapping to slow HDD. That could be a factor in the weird color effect. Try copying the BethINI-generated INI files from your MO2 profile folder to the standard location (make a backup before overwriting), then run Skyrim directly (not through MO2). Standard location for Skyrim INI files: Documents\My Games\Skyrim Special Edition

Ok, so it would seem to indicate that with MO2 in the middle, you get the weird color effect. In all the tests so far, unless I'm missing something, MO2 is the least common denominator that triggers the weird color effect. Still, that gives us no clue about the possible root cause. Your actual hardware specs are still not precisely known. If you don't mind, you can share them with us: Run dxdiag.exe. Wait for it to launch (it can take a little while for the window to appear), then wait until the progress bar at the bottom left disappears (if it never appears, it's already done). Click the 'Save All Information' button at the bottom. Save the DxDiag.txt file somewhere. Post* the DxDiag.txt file here as an attachment. [*] The file doesn't contain any personally identifiable information, other than possibly your computer name. You can edit the file in Notepad and redact the computer name (Search for 'Machine Name', it's near the top of the file), if you wish, before posting. I doubt it but I don't really know. Have you tried playing the game as-is, in vanilla form? How did it go? For a pretty barebones mod list you could conceivably go with just the 02-Extenders, 04-Foundation, and 09-Fixes groups of the STEP Guide, minus a few mods that should be removed either because they're only useful with other mods or because they're not "essential". Anyhow, if I'm understanding correctly, your primary purpose for modding is to improve the performance of the base game? I'm aware of Free FPS, but it's not really a guide, more like a grab-bag collection of pointers to performance-improving mods, and of performance improvement tips, for users who like to build and optimize their modlist on their own. No you don't need to delete or reinstall anything. You simply disable or re-enable stuff with MO2. You can also remove stuff from MO2 if it's no longer used and won't be used again (to free up disk space, otherwise your mods will keep piling up on your disk whether you use them or not). That's the beauty of mod managers, you can experiment as you wish and you can always go back to the base game state without reinstalling anything.

I don't mean to discourage you, but you may be embarking on a doomed adventure, so to speak. Your GPU is very very weak, and barely meets the Bethesda minimum system requirements for Skyrim SE 1.6.x, let alone the STEP minimum system requirements for the guide. In your first post at the beginning, you mentioned having to use "low" settings because everything was too slow. That doesn't bode well for the fully modded game. You need to start with a very comfortable performance headroom in order to support all the visual bells and whistles that will be bolted onto the game throughout the guide. If your laptop is already struggling without any mods, it will only get worse from there, not any better. What about your CPU and RAM, what are the specs? Like I said, I don't mean to discourage you, but you're going to spend long hours installing and configuring a mod list that is focused on visual improvements and high quality graphics. It would be a pity if at the end of the day the game were unplayable, because your hardware simply can't keep up. Now back to your color shift issue: Latest AMD driver available for your GPU on Windows 10 is Adrenalin 22.6.1 (June 23, 2022). You should give it a try. What happens if you launch Skyrim (not SKSE) from MO2?

Edit: Never mind, my SKSE logs say the same thing (Windows version 6.2 build 9200, that is Windows 8) and I'm using Windows 10 22H2. I'm not sure what's going on, it's probably Windows 10 lying to Skyrim on purpose. But it's almost certainly not related to your issue. Please ignore and sorry for the false alarm.

They're not helping because they're incorrect, misleading or wasteful. They're confusing because they mix different concepts, procedures and tools together in a single overly long and complicated process. Some of these concepts are outdated or irrelevant when GCF is used and NGIO is no longer used in-game. It's very hard for users to understand cause > effect, role or dependency relationships with such convoluted and unstructured descriptions, making it impossible to troubleshoot when something goes wrong. It's just one big nebulous blob. Case in point: This topic's OP believed the grass cache was only used for grass LODs, not for full grass. I'm not surprised. That's precisely the kind of confusion the current guides induce. The-Animonculory guide in particular shows the author doesn't really understand how NGIO precaching or GCF truly works (DO NOT ACTIVATE YET!), and is often parroting bits of advice from different sources, some copy-pasted from the (outdated) STEP Grass LOD Guide. For example, some fluff can be eliminated from either guide by first removing details and instructions pertaining to NGIO in-game rendering, which are completely irrelevant when NGIO is used only for precaching. Another example, asking users to edit Skyrim.ini [Grass] settings, which are then overridden by GCF's own INI, is useless and misleading. The only correct "grass cache" guide, from my perspective, is the very succinct Usage section of the GCF mod page, which assumes an already existing NGIO grass cache (generated separately), and makes Grass LODs (using DynDOLOD) optional. It's fairly straightforward, and is exactly the same for both Skyrim 1.5.97 or 1.6.x. It's only concerned with NGIO grass cache usage, either for full grass, or for LODs, or both. NGIO grass cache generation is left as an exercise to the user. Arguably the more complicated and delicate part, it deserves its own separate guide, without any consideration for LODs generation, as no consideration is necessary whatsoever. Alternatively the user can use a 3rd-party pre-generated cache for a specific load order or modlist (assuming it matches "perfectly"). The STEP Grass LOD guide could be trimmed down to only the LOD generation part with DynDOLOD, using an already existing NGIO grass cache configured with GCF as a requirement. Apologies for the ramble.

Nothing obvious in the logs. However it appears that: You're running Windows 8. Your GPU is AMD R5 M230 or M330. Is this correct? These products are no longer supported by Microsoft or AMD, respectively. The last AMD driver for this GPU on Windows 8 was released in 2017. You can try updating your GPU driver to the latest available. Other than that I have no advice other than upgrading to Windows 10 if that's possible. You'll have a very hard time finding help for troubleshooting your issue from this community or the online community at large, as very few people run Windows 8 nowadays or are still using circa-2017 AMD drivers. PS: Steam will end Windows 7/8/8.1 support on Jan. 1, 2024. Steam client will no longer work on these OSes.

Update: the strange "completed but not really" behavior is caused by Kezyma's Root Builder which manipulates the contents of the game's root folder on the fly as programs are launched from/returning to MO2. It's interfering with NGIO and the Grass Precacher plugin. The Nordic Souls Wabbajack modlist apparently uses Root Builder. You'll need to figure out how to disable Root Builder for the grass precaching. Ask for help on the Nordic Souls or Root Builder support channels, if necessary. I'm out.

Post PrecacheGrass.txt (the version that remains when NGIO reaches its "done but not really" state), GrassControl.config.txt and plugins.txt as attachments. plugins.txt can be found in the folder of the MO2 profile used for NGIO precaching: Your assumption is reasonable, but the quantity of grass generated is dependent on multiple factors such as NGIO configuration, mods affecting landscape and worldspaces, load order and conflicts within. We still don't know who/what "says it is finished", where you click OK, how it automatically restarts... wording is too vague to figure out what's happening. There are 2 components involved: NGIO running inside Skyrim, and Grass Precacher plugin running inside MO2. Each has its own UI, progress/completion/error messages and buttons. If you've never gone through the precaching process before and are just discovering it, using a large modlist (Nordic Souls) and a grass mod (QW's GrassPatch #2) with grass turned up to 11, that isn't even part of the Nordic Souls modlist (it uses QW's GrassPatch #1 as far as I can tell), doesn't seem to be the best and smoothest way to go about it. Especially if you're not an experienced modder. My advice: create a new MO2 profile for NGIO precaching, containing only the vanilla game + USSEP and nothing else. Successfully generate the grass cache with that profile once, so you know what to expect when everything works correctly. It shouldn't take very long. Pay attention to the messages/buttons displayed by the MO2 Grass Precacher plugin and by NGIO, respectively, at various stages of the process. Note the presence of PrecacheGrass.txt in the game folder, during, and at the completion of the process. Note the number of files in the grass folder, and its size, at the end. That should be your baseline and "known good" reference point. You can then compare and troubleshoot from there with your heavily modded game.

What does "grow" mean? It's unclear if you're complaining about doors in general, or about load doors specifically, or about city gates in particular. Get On With It merely removes the animation. You still have to wait for the cell/worldspace to load when switching between interior/exterior or crossing worldspaces. That's why these transition doors are called "load doors". Open Cities completely removes the load doors/gates of walled-in cities. There are no cell/worldspace transitions any more. Vanilla cities are disabled and completely duplicated from scratch in Tamriel. They exist in Tamriel, same as settlements like Riverwood or Rorikstead, rather than in their own child worldspace. Hence why it's incompatible with pretty much everything. If anyone had a good alternative to load doors, it would have been known and implemented long ago... The game behaves the way it does at a fundamental level that can't be changed. If you have Autosave on Fast Travel enabled in the game options, you can try to disable it to speed up transition loads a little, depending on how large your save files are.

It's wrong but not critical. The biggest mistake is to never tell to activate it at any point of the process. That guide should no longer be prominently featured as a sticky post on GCF's comments, IMHO. I understand @DoubleYou used it as a stop-gap while the STEP Grass LOD Guide was outdated in regards to Skyrim 1.6.x. The STEP Grass LOD Guide has been updated a little to account for 1.6.x and GCF usage, but it's still not up to snuff, it's misleading and incomplete in some places. Honestly the whole situation is a bit of a mess, and it's not helping the community. The main issue I see is that generating the grass cache, and generating grass LODs have somehow become conflated into one gigantic, confusing and error-prone process. These are 2 distinct processes, one depending on the other. The grass cache, as an entity, exists and is useful by itself, whether grass LODs are generated or not. Generating the grass is done using Skyrim 1.5.97, while using it (in-game as regular grass and/or for grass LOD generation) is done - most likely - using Skyrim 1.6.x. Process 1: Generate and set up grass cache with NGIO and GCF. Process 2: Generate and set up grass LODs with previously created cache, GCF and DynDOLOD. At the end of Process 1, the grass cache can and should be used by the game without NGIO, whether grass LODs will be generated or not. This should actually be a prerequisite before even attempting to proceed to Process 2. The grass cache should be checked in-game to verify it looks and works ok. The current mix-up of processes is akin to explaining how to install a tree mod in order to generate tree LODs and then discarding/ignoring the tree mod afterwards (exaggerated analogy for effect). The decoupling of processes further makes sense considering that 3rd-party pre-generated grass caches are available online for specific Collections/Wabbajack load orders, in which case Process 1 doesn't apply.

That doesn't make sense. You mentioned in another topic you were going to open a new topic about that. Feel free to do that if you wish. Who/What "says" that it's complete? As it is, we don't have enough information to make a diagnostic. Grass Precaching is either in progress running, or has crashed and is being restarted automatically by MO2's script to resume where it left off (which may cause an infinite loop if the load order is borked and Skyrim crashes repeatedly at the same spot), or has completed successfully. In the latter case, PrecacheGrass.txt is removed from the game folder. The state "successfully completed with PrecacheGrass.txt still in game folder" is an oxymoron and doesn't logically exist. If PrecacheGrass.txt still exists then by definition we can tell that grass precaching has not successfully completed.

The ones from the Extenders group should certainly not have any effect when disabled on MO2's left side list. So let's make sure they are indeed disabled: Remove this file: Documents\My Games\Skyrim Special Edition\SKSE\skse64.log. Remove this file if it exists: Documents\My Games\Skyrim Special Edition\SKSE\SSEDisplayTweaks.log. Reproduce* the color shift in the same conditions you previously described (enable/disable stuff, start game, observe weird colors, quit game). Post the SKSE log Documents\My Games\Skyrim Special Edition\SKSE\skse64.log. Post the SSE Display Tweaks log Documents\My Games\Skyrim Special Edition\SKSE\SSEDisplayTweaks.log if it exists. [*] If problem is not reproduced on first attempt and it takes several attempts to get the "correct" conditions, repeat steps #1 and #2 before each attempt.

Yes the grass cache can be used for regular grass as well. Not using it for regular grass is kind of a waste after going to such great lengths, taking pains and spending so much time generating it. But if you're unable to successfully generate a complete, accurate cache for your load order, it's probably not such a good idea to use it for regular grass. Skip step #5 from the Usage instructions on the GCF mod page. Or skip step #2 under Setting the game to load the grass cache of the guide you've been following.

The guide you mentioned you're following (in another post) - https://github.com/The-Animonculory/Modding-Resources/blob/main/Grass Lods.md - is pretty well done, but it has one fundamental flaw: at no point does it instruct to enable the Grass Cache Fixes mod and its plugin. And then it goes on to perform a long list of operations without even mentioning GCF ever again. It's omitting an essential component and step in the process. The end result is that GCF is never activated... This will cause the issue you're experiencing. At the point where you switch back to your 1.6.x profile, probably at the beginning of the Configuring the cached data section, you must enable GCF and its plugin in your load order, which will be used for running DynDOLOD and for playing the game. As stated on the GCF mod page, it can also be enabled in the 1.5.97 profile. This simplifies switching between profiles and allows for rendering grass in the immediate periphery outside Whiterun (when viewed from inside the walls).

Explanation of the issue: NGIO doesn't generate grass cache in cells that don't contain texture layers. In vanilla, cell -47,38 only contains water and the bottom of the sea is colored with flat tints without textures. So NGIO skips it entirely. DynDOLOD is told to generate grass LODs from .gid files. Since Tamrielx-047y0038.gid was not generated by NGIO, DynDOLOD uses whatever Tamrielx-047y0038.gid file it can find: the vanilla .gid contained in the vanilla BSA files, which is bogus. All vanilla grass files are invalid. Pointers to resolution: 1. Clicking the provided link on the DynDOLOD error box and taking 5 minutes to read would have given the solution: 2. A simple Google search and taking 15 minutes to browse and read would have given the solution. Google search link: https://www.google.com/search?q=skyrim+dyndolod+unknown+grass+data+format Top result, from this very site:

Discussion topic: Default Face NPCs Fixed by AndrealphusVIII and UnknownG12 Wiki Link The problem: In vanilla Skyrim, several NPCs, even unique important ones, have the generic default face according to their race instead of a unique face. They look like undistinguishable male Nord lambda, for example. The solution: This mod gives a unique face to many vanilla NPCs that have the default face. This is accomplished by modifying the relevant NPC records and adding corresponding facegen data. The facial features are obviously subjectively done by the mod authors, since no one knows how they were supposed to look in the first place. Even Bethesda probably doesn't know as they didn't bother to provide unique faces for these NPCs. But they're tastefully done and seamlessly blend in with the vanilla aesthetics, IMHO. See mod page for full list of fixed NPCs. Illustrated examples: Briehl and Erikur, both are male Nords using default face. UESP Notes: Vanilla Briehl > Vanilla Erikur (same default male Nord face) Vanilla Briehl > Default Face NPCs Fixed Vanilla Erikur > Defult Face NPCs Fixed Conflicts and Sorting As with any mod modifying NPC records, it's prone to conflict with other mods touching the same records (e.g. AI Overhaul). If you're making your own conflict resolution patch(es): If other NPC appearance mods affecting the same NPCs are used, sort them so that the desired one "wins", especially their facegen assets. Otherwise sort order doesn't matter. Make sure to forward all relevant changes from this mod, or other NPC appearance mods if applicable, to avoid "black" faces in-game. Don't mix or merge NPC face sub-records changes from different mods, it must be all or nothing. If you're not making your own conflict resolution patch(es): This mod should be sorted as high as possible in load order (lowest override priority) after USSEP, if it's used. Ideally, set the ESM flag on this mod's header in xEdit and manually place directly below USSEP. Any other mod touching the same NPC records, such as AI Overhaul, should then "win", in which case this mod's changes are lost on the conflicted NPCs. Automated patchers or 3rd-party patches, if available, may correct the loss.