Mousetick

That comment was from meh321 (the MA of SSE Gameplay Tweaks) explaining to Parapets (the MA of this mod) how SSE Gameplay Tweaks' reading bonus works. SSE Gameplay Tweaks has a similar but more general and configurable feature whereby reading a book (potentially ANY book depending on configuration) gives a bonus to ALL skills learning, using a complex exponential formula: AllSkillsBonus = Base + (AmountFlat * BookReadCount) + (AmountExponent ^ (BookReadCount - 1)) Whereas this mod's formula is unknown and undocumented, but based on its description and behavior is assumed to be a flat multiplier: SkillBonus = 4 * SkillBookReadCount

Thinking more about this, we can roughly approximate the results of using this mod in a best case scenario. Assuming one skill book is found very early in the game, its bonus will apply to the whole game. For example, in a pure vanilla play, there is an Archery skill book that can be found in Helgen Keep during the escape quest. There are 100 levels per skill, ignoring Legendary skills to simplify. Therefore a 4% bonus would result in gaining a total of 4 skill levels spread over the course of the game, by reading this one book early. Compared to 1 skill level gained by reading the book in vanilla. That's not entirely correct, because skills levels start at 15 for a new character, and at 20 or 25 depending on race: 100 - 25 = 75 * 0.04 = 3 skill levels 100 - 20 = 80 * 0.04 = 3.2 skill levels 100 - 15 = 85 * 0.04 = 3.4 skill levels It does seem like the bonuses provided by this mod can result in significantly more skills levels per book than in vanilla, depending on when the book is read. But the previous calculations are an extreme example - not all skill books will be found simultaneously at the beginning. Let's see what happens with a skill book found later in the game, say when the current skill level is 50, with 50 levels remaining: 100 - 50 = 50 * 0.04 = 2 skill levels. That's still twice as many levels compared to vanilla. It's hard to compare this mod with vanilla in terms of balance and power curve because the payoff is not immediate and varies based on timing, but as-is it looks in theory a little overpowered to me.

Right. The animations are the .hkx files that also stored under the meshes/ folder tree. One for each skeleton .nif mesh. They overwrite files from the vanilla BSAs.

I agree. This mod should be treated as a basic "better than vanilla" fallback fix when it comes to meshes, like USSEP. All meshes from all other mods should win over it. Suggested overwrite order that doesn't require any hiding because it flows naturally and logically (from broad to specific, from basic to refined, with improvements and fixes positioned alongside the things that are improved/fixed, not segregated in their own separate category): DynDOLOD Resources ... Skyrim Landscape & Water Fixes ... SMIM ... Majestic Mountains Majestic Mountains - DoubleSided Meshes (this mod) Skyrim - A Mountainous Experience (Double-sided version) ... Other meshes and mesh fixes... Nothing to hide here, which makes all conflicts clearly visible and the overwrite prioritization easily understandable just by looking at them in MO2. As soon as stuff is hidden it becomes a lot harder to understand why mods are sorted the way they are on the left pane.

I don't think it was me, or I don't remember. But coincidentally I've been using this mod in my current playthrough. It works as advertised. Or at least it appears to, going by the bonuses displayed in its MCM, but it's hard to tell for sure without looking at the actual before/after skill gain numbers and I have no idea how to do that. One thing is working for sure: reading a skill book no longer gives a skill point. As per its description, it grants +4% per book and it's capped at 5 books per skill. I patched it in xEdit to nerf the bonus per book (+2% instead of +4%) and to increase the book cap (10 instead of 5) because I have mods that add more skill books to the game, such as BCS - Lost Library (part of STEP). I also felt that the default +4% permanent bonus per book might be OP... +4% skill points x skill books over the course of an entire game seems to me like quite a lot of skill points compared to a one-time skill level per book. But I really don't know, it's just an impression. Last, I can't tell how balanced it actually is with vanilla levelling mechanics, as my game is modded to decouple character XP and levels from skill XP and levels (i.e. gaining skill XP and levels has no effect on my character XP and level). I also modified the skill XP curves to be much harder at low levels (half of vanilla skill gain) and flatter than vanilla, using Skill Uncapper. So the little skill bonuses provided by this mod are very useful and valuable for my modded game - assuming that they do work.

Keep it simple: just move the XPMSE.esp plugin to 'Optional' on MO2's 'Optional ESPs' tab. No need to hide anything but the plugin, which MO2's Optional conveniently does. The plugin starts hidden quests to set up the MCM and the whole cloak spell thingamajig, which run scripts. Without the plugin, the scripts and MCM interface resources are completely harmless and can stay where they are. If users want to use these features, they can just move the plugin back from 'Optional', without unhiding anything. That's it.

Sounds good, but it may not be wise to just take my word for it. It would be best if at least someone else confirmed the same issue and fix. The wench outfit is the easiest to test: Hroki at the Silver-Blood Inn in Markath, Narri at the Dead-Man's Drink in Falkreath, Alva in Morthal... The Forsworn female armor exhibits the same issue. For the Dawnguard vampire robes, I'd have to check more closely next time I see one, I don't recall noticing it. To be clear: I'm using the STEP recommended selection for Tempered Skins (i.e. A7 - Bikini type IV).

Installed. I noticed a tiny issue with the FOMOD installer: the preview picture for the horse Yes/No selection shows mammoths

You might want to switch it to 'Testing', or tag it in some other way so that it doesn't fall through the cracks again

I don't know if it's worth creating a topic for it: Crash Log Tools for Mod Organizer (by Parapets) This makes the Crash Logger logs look a little closer to .Net Script Framework crash logs by replacing numeric memory addresses in the log with symbols (e.g. variable or function names) if they are known to the Address Library Database (same database used by Address Library for SKSE plugins). It operates post-mortem, after the crash, on the generated log files it finds in the logs folder. As they currently are, without symbols, the Crash Logger logs are pretty much useless for troubleshooting by novices and experts alike. I have no experience with this tool, I'm just informing you of its existence. I'm still using the 1.5.97 runtime with .Net Script Framework, sorry.

I've been using the setup described in the OP. I also turned off double-sided mountain LODs in DynDOLOD. It's been working fine for me. No visual or performance issues that I could notice.

Shoot, I missed the already existing topic: https://stepmodifications.org/forum/topic/17159-vanilla-body-with-unp-textures-by-shiva182/ For some reason, it's marked as accepted but it's missing from the guide?

A set of meshes to address an incongruous 'nip slip' issue when Tempered Skins for Females - UNP (by traa108) is used with vanilla female body. The problem: Even though Tempered Skins is compatible with the vanilla female body, its textures are primarily designed for UNP body meshes. This results in nipples peeking out from certain female outfits when they're used with the vanilla body meshes. This had been bothering me a while, as it's unexpected for a Vanilla+ setup such as STEP and it's out of NPCs' character. The solution: This mod. It's actually mentioned in a sticky post on the Tempered Skins for Females Nexus comments section. It's also mentioned if you select 'Vanilla' body type in its FOMOD installer: Installation & Conflicts: These are just meshes so they can be installed/uninstalled at any time. The mod provides replacement meshes for certain outfits (vampire robe, forsworn armor, wench) adjusted to cover the nipples. They overwrite vanilla/USSEP meshes and don't conflict with anything else. It also provides replacement meshes for feet and shoes. These meshes conflict with Tempered Skins for Females, which also replaces female feet and shoes. I don't care much for feet so I haven't looked closely at each version or whether one might be better than the other. These conflicts can easily resolved by sorting in MO2 left pane or by hiding. Comparison Shots: Below is Alva (Morthal). Hidden because slightly NSFW. Another easily noticeable example is Narri (Falkreath), not shown here.

As a general principle, allowing the web browser to run external programs outside of its sandbox is a security risk. This is what happens when MO2 is configured for Nexus "Mod Manager Download" integration: you click on a "Mod Manager Download" link on Nexus in your web browser, the browser launches MO2 (or activates it if it's already running) and hands it the URL to process, then MO2 handles the download from Nexus servers using a custom 'protocol'. You need to trust that all 4 components are secure: The Nexus site may be bugged or compromised. MO2 may be bugged or compromised. The configuration that associates Nexus links with MO2 on your machine may be compromised. The custom 'protocol' may be bugged or may contain holes that can be exploited. You can use security software that constantly monitors some of these components' state and activity on your machine to potentially detect and stop abnormal behavior. That's one way of reducing the risks. Or you can prevent the web browser from running external programs (which implies manual download from Nexus web site). This doesn't eliminate the need to use security software altogether, as this addresses only one security area, and there are many many others remaining to be covered. Each has pros and cons. Typically, the higher the security, the less convenience or vice versa.

Don't get too excited, this is pretty boring stuff The thing is, I actually don't use any antivirus/malware/security software (except firewalls and ad-blockers which I do use). I find they're more trouble than they're worth, they're horrible intrusive hacks similar to the malware they're supposed to protect against, they tend to slow down everything and cause all kinds of compatibility issues. I briefly tried MS Defender when Windows 10 came out and quickly disabled it. I rely on my own set of security "policies" and frequent + comprehensive backups which have served me well and kept me safe for ~30 years of Windows computing (knocking on wood). One of these policies is to not let any software handle custom protocols off the browser as this mechanism is easily and commonly hijacked by malware. I'll admit this is borderline overly-zealous, to borrow Z's words. In my case it doesn't hinder me, as I like to take a look at the archives' contents and I often rename the archive files (many of them are very poorly named by the MAs) inside my browser's downloads folder, before moving them to MO2's downloads folder. It's easier for me to do all this from Windows Explorer, rather than switching back and forth between MO2 and Explorer. I think MO's Downloads tab interface is very poor and cumbersome to use. I have an IT background too. I can't stand the babysitting of security software and having to exclude a bunch of apps and folders all the time just to get trivial work done. I know what I'm doing, I don't need this kind of 'protection' - thank you very much. To anyone else reading this: don't follow my example, it's not helpful. Please use security software.

Thanks for following up with all the details and clarifications. At this point it's pretty clear the issue has nothing to do with DynDOLOD and is specific to your navmesh patch so I'll keep my comments short: Editing navmeshes in CK is way beyond my knowledge so I can't help you there. As far as I understand, if the Navigation Mesh Info Map links to door/portal/passage references, they need to be persistent. Not being explicitly defined as persistent in the ESP may not be a problem, but could become one once the plugin is ESMified, as they would now be truly temporary. That's good advice and is actually much easier and safer than ESMifying whole plugins if the goal is to fix a few large references bugs rather than limiting the number of references.

No offense, but your analysis doesn't demonstrate or explain anything regarding the root cause of your crashes, and is not readily applicable to other users, because it's completely specific to your load order and it doesn't precisely identify the root cause. All we learn from your analysis is that there is some interaction/conflict (maybe related to navmesh(es)) between some mods in your load order that causes a crash depending on their relative order. ESMifying a mod changes its position in the plugin load order, and if that mod uses a BSA, it also changes the overwrite priority of its assets and resources in the load order. This is a critical detail that may be easy to overlook. If this mod conflicts with other mods in the load order, the conflicts are now resolved with a different priority with a different outcome. Unless manual patching is done in xEdit and/or manual extraction of BSAs is done to properly resolve those conflicts, the end results will vary in-game. Another important detail that may easily be missed, and is a corollary to the previous, is that once the load order is modified, especially in the ESM range, the DynDOLOD output should be considered invalid and unsafe. It needs to be re-generated from scratch. This is crucial to ensure DynDOLOD.esm is properly synced up with the load order. When you ESMify a plugin without re-generating DynDOLOD, the previous DynDOLOD.esm doesn't account for the change. For example, it may overwrite references that should be marked persistent but are not because the outdated DynDOLOD.esm doesn't forward changes from the now ESMified plugin. Non-persistent references defined in an ESM are removed from memory when their parent cell is unloaded, causing unpredictable behavior or crashes when they're accessed. You mention in your analysis that the crash stopped when you disabled a group of mods, including DynDOLOD Output. You didn't specify whether you had re-generated DynDOLOD after ESMifying and re-sorting your mods. I've ESMified a number of mods (~20), using the script you referenced, including Moon and Star, without any issues. My current load order contains 668 plugins and I've yet to experience a game-breaking bug or crash that is not due to my own mistakes. If I may offer some advice to help ensure a stable setup: Sort load order with LOOT. Use custom ordering rules only as a last resort. Systematically clean plugins with xEdit. Systematically check for plugins errors in xEdit. Systematically check for plugin conflicts and patch them in xEdit. Systematically check for conflicts among BSAs, and between BSAs and loose files. Enable 'Archives Parsing' experimental feature in MO2 if using MO2. Overwritten Papyrus scripts require particular attention. Re-generate DynDOLOD plugins whenever the load order changes, especially if it changes in the ESM range. Religiously pay attention to warnings in DynDOLOD's Summary Report. For extra care, review the warnings in DynDOLOD's log files. Some of them are not reported in the Summary Report but are still noteworthy and may require action. Fix as many found issues as possible depending on severity, by yourselves, or seek out solutions and patches elsewhere. Re-generate 'dynamic/automatic' patches, such as Synthesis or similar, whenever the load order changes. Needless to say, this is not a simple matter of ESMifying plugin with an xEdit script. It's a lot of time-consuming work that requires some "expertise". So perhaps the best advice would be not to ESMify mods in the first place unless you understand the implications and are prepared to deal with them.

Count me in as one of the folks who doesn't download Nexus mods via MO2 Mainly for security reasons. But I do use the workflow described above by DY. This requires linking my Nexus account to MO2, so it can fetch metadata from Nexus, which is fine by me. I download all mods manually via web browser, move them to MO2's download folder, and finally "Query Info" in MO2, before installing them. This way the mods look exactly as if they had been downloaded directly by MO2, and the automatic naming and other metadata-based features are available and working as expected. Anyway, I agree I'm probably in the 0.01% of users and I wouldn't expect a guide like STEP to account for this scenario. Focusing on the 99.99% is the correct approach, IMHO.

If you're absolutely sure that you (re-)installed both parts of SSE Engine Fixes correctly, using the right version in the right place, and it's still failing, look at these log files: Documents\My Games\Skyrim Special Edition\SKSE\skse64.log Documents\My Games\Skyrim Special Edition\SKSE\EngineFixes.log They may give you some clues as to why SSE Engine Fixes is failing to be loaded by SKSE. The second logfile may not exist if SSE Engine Fixes can't initialize at all. Clear the folder beforehand to ensure you're not looking at old files.

I've been using BSArch (by Zilav, Sheson and ElminsterAU) to unpack/repack entire Skyrim BSAs, and BAE for extracting specific files from archives. BSArch is a command-line tool, so no GUI. It's supposed to support FO4's BA2 format with streamed DDS. There is BSArch BSA BA2 Batch Extractor and Packer for MO2 (by DullCandle29) that provides Windows batch scripts and integration with MO2. I haven't used it.

Follow the guide to completion, strictly as described, without any additional mods. Give the game a thorough spin (i.e. a couple of hours of gameplay, not five minutes) to ensure it's looking and working as intended. Add other mods to taste, with their compatibility patches if applicable. Sort with LOOT. Run Nemesis to update animations and re-generate LODs with xLODGen/TexGen/DynDOLOD, if needed.

It's telling you exactly in the message which SKSE plugin failed: EngineFixes.dll. So, look for the correct version of SSE Engine Fixes.

To satisfy the DynDOLOD 3.0 requirement specifically, you only need '.NET 6.0 Runtime' (Run console apps). If you install '.NET 6.0 Desktop Runtime' (Run desktop apps) instead, it's fine, as it includes the former. So either one will work for DynDOLOD 3.0. In any case, make sure to select the appropriate CPU architecture corresponding to your PC: x86 or x64. If you don't know what that is, pick x64.

10 years later, they finally come to their sense and revert their ludicrous capitalization "fixes". Better late than never, I guess. LOL. Too bad many mods have been forwarding those changes. Wondering why it took so long for BGS to let the USSEP team know that, yes, in fact, the game's capitalization of words (mostly consistent throughout) was as intended, it wasn't broken and needn't be fixed.

If you do this on an ongoing game like I did, beware there will be XPMSSE remnants in your game save file: "orphaned/unattached" script instances, so-called because the plugin that started/used them is no longer present. They'll be stuck in there forever. That's not really a problem, as they are now "inert" - it's just useless bloat. If you want to keep a lean and clean game save, I'd suggest using FallrimTools ReSaver to get rid of these leftovers. Make and keep backup before/after saves to be safe, in case something goes wrong.