Mousetick

The plugin and associated Papyrus scripts are only needed for the Weapon Styles feature (and associated animations). The skeleton meshes and animations overwrite vanilla files, they don't need a plugin to be effective. This is similar to installing ELFX and disabling its plugins to keep the meshes. I believe the XPMSSE mod could be omitted entirely from the guide - AFAIK there are no other mods in the guide that absolutely require it. However it's nice to still include it in the guide simply for the skeleton meshes and animations - without enabling the plugin - because it's the de-facto "standard" and a boat load of mods depend on its skeleton meshes and animations - but not on its plugin, which is a completely separate feature. In that case, as you remarked, the fixes, and fixes of fixes, are not needed anymore. That's essentially what I've done.

What are the other oddities in your load order and what is bothering you exactly? If Dragonborn.esm is not a master of LoS and if there are no conflicts between them (likely if LoS doesn't cover Solstheim), then they can go in any order relative to each other. There must be very good reasons for LOOT to sort LoS before USLEEP. Hypothesis: LoS would otherwise overwrite USLEEP and forward bad vanilla bugs that are fixed by USLEEP. There are no 3rd-party bugfix or USLEEP-compatibility patches available for LoS because it's no longer supported and it has closed permissions. So the only option is to load USLEEP after LoS.

Like many of meh321's mods, this requires .Net Script Framework. Chances of working with STEP 2.x guide: zero.

Part(s) of the guide most likely to be causing this: Generate terrain LOD Make sure LOD32 settings are correct. Re-generate terrain LODs with xLODGen if not. Utilities Make sure DynDOLOD_SSE.ini settings are correct. Re-run DynDOLOD if not. In both cases, ensure ALL Worldspaces are selected. Edit: added worldspaces check.

The mod you linked to, Forest Mounts and Followers, is a Skyrim LE (Legendary Edition) mod. But you're posting in the Skyrim SE (Special Edition) forum. Either you're using the wrong version of the mod, or you posted in the wrong forum. Try (ESL) Forest Mounts and Followers SE for Skyrim SE.

During my initial playthrough with 'Not So Fast - MQ' I wasn't bothered by the time gates it introduced, though I did have to RTFM to figure out those changes - I think they're useful to slow down. However the configuration system is weird and too convoluted for my taste. For my subsequent playthrough I've switched to the MQ module of At Your Own Pace (by agd25) which is very similar to NSF and better than it IMHO: User-friendly MCM configuration system Pacing is controlled by dialogue rather than time delays Optional reminders as quest objectives in journal I think it's better suited to alternate start style games for RPing purposes as it allows for greater freedom and immersion (no configuration via a Whiterun wall), but it can also be configured for a straight vanilla experience.

Where? I don't see any:

There is no official Vokrii-CACO patch provided by Kryptopyr's maintainers. Are you confusing with the Vokrii-CCOR patch perhaps? The Vokrii MA doesn't provide an official compatibility patch either. The reason is that you're supposed to choose one or the other Alchemy perk tree. If you sort CACO before Vokrii, you get the Vokrii perk tree, and if you sort CACO after Vokrii, you get the CACO perk tree. As explained by the Vokrii MA on the compatibility page: The unofficial Vokrii-CACO patch and the Arbor Philosophorum mod I linked to are for users who want to combine both perk trees, so that CACO mechanics and items make sense and can be used with Vokrii's perk tree.

One more - sorry I can't seem to be able to gather all my thoughts at once while multi-tasking: It's entirely possible that your game instability was caused by MO2's hosed virtual Data folder in the first place, without there being anything wrong with the game or the mods themselves. This happens to me sometimes. The scenario is: I run a tool from MO2, usually it's LOOT that triggers the following. Upon exiting the tool and returning control to MO2, MO2 "crashes". It doesn't actually completely crash, its UI front-end simply disappears, but it's still actually running in the background, unbeknownst to me. I relaunch MO2 (now there are 2 copies of MO2 running, and the virtual Data folder component is broken). I run the game and at some point it crashes or hangs, for the reason previously mentioned.

Addendum I forgot in my tip: When running the DynDOLOD tool, as part of re-generating all LODs, look carefully at the Summary report displayed in your browser at the end. Look for warnings related to any mods you added, which may indicate potentially serious problems.

The crash log shows the crash occurred in MO2's UVFS virtual Data folder component which is completely hosed at that point: This can't be used to diagnose the actual source of the problem, because it's merely a consequence of previous crashes or of forcefully killing the game in Windows Task Manager. In my experience, this can leave MO2 and its virtual folder in an unstable/zombie state. If the virtual Data folder doesn't work reliably, neither can the game. You need to return to a pristine stable MO2 state: Quit MO2. Open Windows Task Manager, go to Details tab, sort by Name column. Ensure there is no 'ModOrganizer.exe' running in the list. Kill any instance that you find. Now you're back to square one and can actually try to troubleshoot the real issue(s). Don't forget to check from time to time if you don't have stray 'ModOrganizer.exe' instances running in Task Manager, and always check after a crash. Clean as described above. Are you sure it was an infinite loading screen - I mean, how long did you wait? Tip: When you add mods to your setup and you're not sure what they change, try them out first without DynDOLOD (disable all 3 plugins). If everything looks ok and is stable, re-generate all LODs, enable DynDOLOD and test again. If you add a mod that only changes some dialogue or NPC appearance for example, obviously you don't need to do that, but if in doubt, it's safer to do it that way.

This discussion about Overwrite and modding practices could go on endlessly. It appears we have fundamentally diverging views about whether acquiring certain knowledge or learning certain practices are worth spending their free time by common users. I believe most users don't wish, and shouldn't need, to spend their free time learning things that will only be useful to them once or twice in a blue moon, especially if the end goal is leisure and entertainment. Judging by the large early success of Collections on Nexus, it looks like I'm not completely wrong. As long as expert users, and geek users willing to spend time learning the finer details, are not prevented from doing anything they want to accomplish, I think making things simpler and easier for everyone else, which is the majority, is a net positive. Ok, I've already rambled too much I just wanted to add one correction and one clarification: Correction: I was mistaken about NGIO. If you use the 'Precache Grass' MO2 plugin to generate the grass cache (which I'm hoping you do, for your own sanity), it actually doesn't matter how you configure the SKSE launcher executable in MO2, because the 'Precache Grass' plugin bypasses all that. It starts the SKSE launcher directly, which is logical, since it doesn't know how you configured the SKSE launcher - you might have named it 'My Little Pony'. So the grass cache generated by NGIO always goes to Overwrite regardless. Nice, heh? Clarification: It's not that I think common users shouldn't RTFM. But the simple fact of the matter is that common users don't RTFM. I don't blame them for that (see ramble above). Hence the need to design and present things as much as possible in a way that does not require RTFMing by the majority of users.

I see. I've set it up like you so far: WMF first and then this mod overwriting it. I'm more bothered by the conflicts between this mod and Flickering Meshes Fixes. It's a hard choice for me between the two. Looking at the comments section, where all these conflicts are reported and asked about, it seems the MA is not interested in incorporating compatibility changes and always recommends overwriting this mod. Regarding the moss: it's built into some meshes, like pieces of Whiterun walls for example. But to get the "full" moss and water splashes changes/additions I believe you need to use the optional plugin.

1.6-compatible version here: https://www.nexusmods.com/skyrimspecialedition/mods/69326 This is not an update to this mod, it's a new mod, using the same code, rebuilt for "AE".

Discussion topic: XPMSSE Weapon Styles Uncloaked by chuckseven1 Wiki Link This basically does to XPMSSE what SPID for Footprints does to Footprints. I only briefly tested this. I was having some Papyrus overload and growing stack issues with the scripts from XPMSSE despite the Fixed Scripts and Papyrus Stack Fix. Important Notes: This is only useful if you intend to use the Weapon Styles feature of XPMSSE, which is enabled by default. Otherwise it will just add useless bloat to every NPCs in game. If you don't intend to use the Weapon Styles feature of XPMSSE, you should disable the "Weapon Styles Cloak Spell" in the XPMSSE MCM at the beginning of a game (i.e. after character creation). Don't enable this on an existing game that had the "Cloak Spell" enabled. NPCs will end up with 2 copies of the effect applied, which is probably bad if not completely broken. This mod provides a straightforward SPID configuration and a plugin that removes the cloak spell enable/disable option in the MCM. Again as pointed out above, it's equivalent to turning the Weapon Styles option ON, but in a much more efficient way. Subjective Notes: I eventually ended up completely disabling the XPMSSE plugin in my game, as I don't care about the Weapon Styles feature at all. I don't know what the plugin does besides providing an MCM to configure the Weapon Styles, and adding a cloak spell to the player. So I'm only using the skeleton meshes and accompanying standard animations that XPMSSE provides, without any other features, totally script-free. And my game is much happier, and snappier, for it. For those users who care about fancy equipment displays and/or animations, there are far better mods nowadays implemented as SKSE plugins, than XPMSSE: Immersive Equipment Displays (by SlavicPotato) Dynamic Animation Replacer (by Felisky384) Technical Notes: Both XMPSSE and Footprints are old mods that use a very inefficient method of applying effects to NPCs. The player constantly casts a "cloak" spell within a certain radius around them. Whenever that spell hits an NPC (or a creature, or any actor, as the case may be), a Papyrus script is executed. This script must check certain conditions to determine whether the effect should be applied or not. The effect that is applied to each actor is actually another spell with another script attached that implements the specific feature (weapon style, or footsteps, respectively). The benefit of the cloak spell method is that it's very compatible: it doesn't edit any NPC record, and it works with any NPC, vanilla or mod-added. The downside is that it's entirely based on (more or less badly-written) Papyrus scripts that run every time an NPC is near the player.

I downloaded and installed that patch some time ago but I don't think I ever used it, so can't vouch for it. Instead I've been using Arbor Philosophorum - Alchemy Perk Tree for CACO and Vokrii (by celadoneiron) which is basically a fusion of CACO and Vokrii alchemy perk trees, with a few additional tweaks. I think it's quite good and has been working fine for me, but you may not like the other changes it makes, in which case you'd probably want to use the CACO - Vokrii patch instead. Neither are officially supported by STEP. Note: I'm not sure either solution would work on your current level 28 game, you'll likely have to start a new game.

There is only one conflict with Unofficial Material Fix as far as I can see: the SkyForge. I'd recommend Whiterun Skyforge - Reforged (by MrNeverLost) to overwrite this mod, as it uses Majestic Mountains as a base, and incorporates the UNF fixes. I don't mind using a ton of tiny mesh fixes and improvements myself, but I reckon the guide may become too long and daunting with too many of them. Edit: Never mind. It's already in the guide! So I'm not sure what the issue is then. As for the conflicts with Assorted Mesh Fixes, the MA recommends that AMF overwrites this mod (see Compatibility section on main page).

Double-check and make sure 'Projected UV Diffuse Normals' is enabled 'Improved Shader' is disabled on the Visuals tab of BethINI.

I don't understand. What exactly among the output produced by SKSE-mediated mod would require special attention by the average user? Please provide a concrete example, based on the guide, that makes redirecting to a mod a bad option compared to Overwrite. I haven't seen a compelling argument. Just a matter of personal preference, old habits, and "RTFM", which don't seem to consider the general experience of common users. A separate mod for SKSE launcher output is actually more convenient and cleaner, as it separates all these configuration files and doesn't clump them together with Overwrite. Sending them to Overwrite is worse for multiple reasons: This triggers a warning by MO2 for something that is completely normal and expected. It creates unnecessary busywork for every single user to repeat the same meaningless menial tasks of sorting out its contents. It's another opportunity for users to mess up by performing manual tasks. It forces novice users (and old timers who just forgot how) to RTFM on something they will rarely, if ever, encounter or need, when following the guide. Most of the files are INI configuration files generated by MCMs. They're not meant to be user-editable. Most users don't care one bit what these files are, and they don't need to be aware of them. A case could have been made that .Net Script Framework crash logs would better go into Overwrite, triggering a MO2 warning in the process, than being silently shoved into a mod folder. Or that the NGIO grass cache would better go into Overwrite for "easier" finding and sorting. Neither applies today, so this is moot.

I can't help but throw in my 2 cents on the Overwrite issue Please take a chair... are you sitting comfortably? The OP's experience is typical and an indication that something is amiss with the guide in its current form. "After completing the guide and launching the game, I've got a MO2 warning and stuff in my Overwrite folder. I've no clue what it is: is it normal, did I do something wrong, what am I supposed to do with it?" is a recurring question. It's a FAQ that I'm fairly certain no one here enjoys answering for the umpteenth time. It's also a bad first-time experience for users. This particular experience is guaranteed to happen in the guide's current state. It's not an "accident". Don't you think something should be done about it? DY's and Greg's position, while understandable from an expert user point of view, fails to acknowledge the issue to begin with, and doesn't provide any solution to address it. "Git gud" is not a solution I think Z's suggestion could be a simple and effective solution, with a touch of tweaking. Using an existing mod (SKSE) as a repository for game files generated at runtime should be avoided. It mixes SKSE with unrelated configuration files. Furthermore, it's "dangerous": in case SKSE is updated/reinstalled by the user, all configuration settings that were stored there are lost. So I'd suggest creating a separate, dedicated (initially empty) mod for that. It could be named "MCM Configuration Settings" to simplify, or something like that. And then configure MO2 for the SKSE launcher to create files in this mod. I'd bet most users don't care what "Fuz Ro D'oh.ini" is, what its purpose is, or where it should go. Same for all the configuration files dynamically created by MCMs or SKSE plugins at runtime. They don't need to know or be bothered by useless Overwrite "noise": Z's solution takes care of that. Such a setup makes the Overwrite folder and the MO2 warning sign truly unexpected, unusual, and alarming. Some indication that something is truly wrong. As it should be. The alternative is to leave everything in the Overwrite folder and let the users sort it out. Fine, why not, but then the guide should explain what the user should expect, what this Overwrite stuff is, and how to manage it. Currently the guide does none of that. Either way, the current status quo is not acceptable IMO. It's easy to lose track of the end goals. For the vast majority of the guide users, "modding" is a means to an end, which is to play the game, it's not an end by itself. So the more that is done to ease them into reaching their goal while skipping all the technical minutiae, the better - in my book. I'm glad you were able to sort out your issues in the end. Sorry for hijacking your topic with our Overwrite "debate"

Too many compatibility issues and crashes Some mods bundle old versions of FISS scripts, causing conflicts and instability. Furthermore, it's been found that it can't cope with multiple mods accessing configuration files simultaneously (such as when starting or loading a game). Last but not least, it's not "officially" supported with AE (Skyrim 1.6.x). It's the right move to dump it, in my view. I recommend using the Settings Loader series to add the auto-load/save settings feature to MCMs lacking it. Many popular mods are covered. The modern and reliable replacement of FISS is MCM Helper, on which the Settings Loader series is built.

Speaking of transitions, and the possible incorporation of this mod into the guide, some caution must be exercised and some manual assembly would be required to achieve the best outcome. The problem: STEP uses Just Ice textures for the full glacier models. The LOD textures don't match the full model textures. I think the same issue must exist anyway without this mod, but I can't be arsed to regenerate all my object LODs with DynDOLOD in order to compare. It probably looks different but still mismatched resulting in noticeable transitions. So the remainder of this discussion and all screenshots will be with this mod's meshes. Note: DynDOLOD Resources don't provide LOD meshes for glaciers. When using DynDOLOD for object LODs, the vanilla LOD meshes are used for glaciers. This point may have been missed in Z's comparisons. As can be seen in the comparison screenshots, there is no difference between 'Vanilla LOD' and 'DynDOLOD Resources LOD' - which is expected. This mod provides LOD meshes only, they replace the vanilla meshes. Its LOD meshes use textures/lod/glacierslablod.dds for the LOD textures, which exists in vanilla, and is overwritten by DynDOLOD Resources. The version provided by DynDOLOD Resources appears to be simply an upscaled version of the vanilla one. In any case, it doesn't look at all like the Just Ice textures, resulting in this visual mismatch: Far (LOD) > Near (Full) In the Far view, you can see in the center one of the glacier pieces' full model is already loaded and looks noticeably different than the rest, due to the mismatched textures. This mod provides some optional downloads for LOD textures to properly match. The Cathedral Snow LOD textures option would not work either, because it doesn't match Just Ice. To remedy this, the MA provides a manual procedure for making LOD textures that match whatever glacier retexture might be used. I tried to follow that procedure to produce the LOD textures based on Just Ice's full glacier texture. But the results were completely wrong. Probably due to my incompetence, I can't tell. Finally, I found an easier solution: it happens that TexGen generates a glacierslab texture that matches perfectly, because it's actually based on Just Ice full textures, and it has the right properties: Correct brightness for LODs, 512x512, no alpha channel. This texture is textures/landscape/glacierslabnoalpha.dds. So I just copied this texture to textures/lod/glacierslablod.dds and ta-da, beautiful LOD textures matching with Just Ice, and very smooth transitions: Far (LOD) > Near (Full) Some other shots for your perusal: LOD Textures: DynDOLOD Resources > This mod's Cathedral Snow version > Just Ice version from TexGen

I've been using it since DY suggested it in the OP. I like it, it's a nice improvement IMHO. It's even officially recommended by sheson, the God of LODs personified: DynDOLOD: Useful 3rd Party Mods. Which is a plus. Unless that page is just a collection of "sponsored" product placements. (joking, of course)

It means to make sure every plugin that is listed in the right pane is enabled (checked), and just these ones. Don't enable those which were specifically skipped or excluded on the left pane, during the mods installation. These "missing masters" errors are a serious problem and are likely the cause of your crash. As I mentioned before at the top of my previous post, missing masters are the main cause of crashes at startup. A missing master means that a plugin depends on another plugin which is not enabled in the right pane of MO2. It may not be enabled in the right pane of MO2 because its checkbox is not ticked in the list on the right pane, or because it's not enabled in the list on the left pane, or because it's excluded (moved to optional) on the left pane, or simply because it's not installed at all (on the left pane). So your first order of priority is to fix that problem. You can use MO2 or LOOT to figure out which master(s) is(are) missing. I'd suggest LOOT as it may be a little easier to read. Make note of the name of the plugin master(s) that are reported by LOOT as missing and report them back here so we can tell you how to correct them if you can't figure it out. You probably forgot to install one or more mods on your way through the guide. Example: The guide specifically says "Ignore any reported missing compatibility patches or other warnings." It doesn't say "Ignore any errors". BAD, BAD, BAD: The error count in LOOT should be zero at all times, and the warning sign icon in the upper-right corner of MO2 should be greyed out at all times. If not, you need to stop and correct those errors before continuing or doing anything else. Please try to be patient and stay focused. We have no way of knowing what's causing your crashes based on the information you provided. The list of tasks I gave you previously was a troubleshooting checklist to try and narrow down the possible causes and perhaps identify the culprit. Ensure there are no errors reported by MO2 (warning sign in upper right corner). You could have stopped right there at that step, since there were errors. There was no need to proceed further down the checklist. Sorry I didn't explain this earlier. Hope this helps. Don't hesitate to ask if something isn't clear.

So the game crashes while the gear is spinning in the lower right corner, before displaying the main menu? Or does it crash even before displaying its (initially black) window and spinning the gear? Crashes at startup are typically caused by: Missing masters Incorrect sort order Corrupt/faulty plugins Old LE plugins or LE plugins incorrectly ported to SE Too many plugins Corrupt/faulty SKSE plugins or DLLs Failure to initialize DirectX graphics or audio Interference from 3rd-party software That Cathedral Weather mod is unlikely to cause crashes on its own, so it must be an interaction with something else which is broken. Did you perform the Game Launch Test earlier in the guide? Ensure all plugins are enabled in the right pane of MO2. Ensure there are no errors reported by MO2 (warning sign in upper right corner). Ensure you have sorted with LOOT before launching the game. Ensure there are no errors reported by LOOT. Load up your entire load order in xEdit, right-click on the Cathedral Weathers plugin and select 'Check for Errors'. Errors found, if any, are displayed in the Messages tab. If there are no errors, repeat with each plugin, including the 'vanilla masters' that were cleaned at the beginning of the guide. Examine the log files in Documents/My Games/Skyrim Special Edition/SKSE. Their contents are usually cryptic informational messages but error messages are easier to identify, and would likely appear towards the end of a log file. Ok. But strictly speaking you can't simply disable Cathedral Weathers, as the STEP Lighting & Weather patch depends on it. So I assume you disabled it too, right?