Mousetick

I'm not following. The '3 easy steps' describe how to use QuickAutoClean. The STEP Guide instructs to use QuickAutoClean. LOOT links to xEdit's 3 easy steps. Where do you see a discrepancy or inconsistency in the instructions? Section 7.6 of xEdit's documentation is not part of the 3 easy steps. The 3 easy steps are confined to section 7.3, they don't extend beyond that section. The manual cleaning described in section 7.6 is for CELL 00016BCF (Ragged Flagon in Riften's Ratways), which is corrected by USSEP and may be reverted by other mods in the load order, as I mentioned previously. In the end it does not matter: Encounter Zones are used to set the min/max levels of generic enemies automatically scaled by the game based on the player's level. There are no generic scaled enemies in the Ragged Flagon, so the Encounter Zone setting has basically no effect. Section 7.6 of xEdit's documentation refers to https://www.afkmods.com/index.php?/topic/4110-manual-cleaning-skyrim-and-skyrim-se-master-files/ from which this 'Dawnguard manual cleaning' stuff originates. On that page you'll see the recommendation is based on the input of 1 person (from the USSEP team), which is then taken as gospel. The large majority of players don't use mods, not even USSEP, and don't clean masters automatically or manually, particularly console players. Yet I'm not aware of gameplay or stability issues due to the Encounter Zone in the Ragged Flagon for those players. In other words: if it's not broken, there's no need to fix it. The 2 other CELLs are test and/or internal holding cells that are unreachable by the player in the game, and may not even be used in-game (I haven't bothered to check). Yep. QuickAutoClean

Not to mention mods that edit CELL 00016BCF (or its contents) and used Skyrim.esm or Dawnguard.esm as the master: they re-introduce the change that manual cleaning (or USSEP) is supposed to remove. I have 4 such mods in my load order. This manual cleaning is futile.

Completely useless. You may want to do the first CELL if you don't use USSEP. The game won't crash or burn without the "fix". Instead of digging up an old post containing outdated information borrowed from another guide, why not follow the nice up to date guide from this fine site? Link: STEP SkyrimSE Guide 2.2.0 > Cleaning Vanilla Master Plugins

DY is correct, the transition speed in and out of precipitation is controlled by the weather records in plugins, hence is not scripted. However, the water splashes of Wonders of Weathers are scripted and are known to cause script VM overload. I don't use WoW anymore and never really used it, but if I'm not mistaken, you can turn off this feature in the MCM? So I'd suggest you try the following: Turn off WoW water splashes in the MCM Does it make a difference in regards to your issue?

I get your point but loading this type of mod early is actually desirable, so that other mods (99% ESP) which need to move/resize/disable the same references are more likely to override it without special care. If it were an ESP the MA would need to advise users to load it early, to avoid issues with other mods. In case of conflict, the best outcome is obtained by resolving with a patch anyway, in which case the relative order of mods or early/late position doesn't matter one bit.

You're right. I've corrected my post accordingly.

You're assuming that all users of this mod are or should be using TexGen/DynDOLOD. That's not the case. The MA would still need to provide LOD texture variants for users who don't. They could be simplified down to one texture (e.g. glacierslab) though that will require updating the LOD models. Currently the MA uses several LOD textures file names (e.g. glacierslab + glacierpillar + iceberglarge + ...) which are all the same texture.

No, no and again no It should be a master plugin (ESM). There is not any good reason to prefer a patch plugin (ESP) over a master plugin (ESM) when adding or overriding a large number of references, large or not. It can be provided in 2 variants: lite* (for all users except those upgrading from previous versions due to renumbered Form IDs) and full* (for users upgrading from previous non-lite version). IcyFixes override a few large references. Being ESM avoids LR bugs. I know DynDOLOD has LR workarounds, but not everyone uses DynDOLOD or the workarounds. Being ESM also potentially allows it to declare new LRs for some of the references it adds, which would be nice - it currently doesn't AFAIK. Sorry to be ranting and harping on about this, but we've already talked about these plugin differences at length already. Why exactly do you want ESP[-FE], what are the reasons that make it better than ESM? Following your (unknown) reasoning, Landscape and Water Fixes is wrong to be a master plugin (ESM) and should be released as as patch plugin (ESP) too? I'm sorry but that's nonsense (*) lite = ESL-flagged and/or .esl extension, full = .esm extension, not ESL-flagged

By the way, I forgot: Going by your posts on this forum, it appears you have an extremely low tolerance for any kind of quirk or jank, as hardly noticeable or as rare as it may be. Friendly advice: I'd suggest Skyrim, and modded Skyrim even more so, may not be the right game for you.

I use all: SSE Display Tweaks, with VSync enabled on 60Hz monitor, and Increase Actors in a Cell, and Actor Limit Fix, and NPC AI Process Position Fix - NG. To no avail. I have a theory on the circumstances that make it happen, but this is only mere speculation. If you pay close attention you'll see that the NPCs actually spawn on the ground, are immediately thrown up very high in the air at very high speed, then fall down. This scenario actually happened once with my own player character. My horse was standing "precariously" on several small rocks and I mounted it. As the mounting animation finished, I saw the game sliding the horse with me on it over a slight distance, apparently on flatter ground, but it's hard to tell because it all happened in a fraction of a second. At which point the horse and I were propelled high up in the air. We then fell back down obviously, I don't remember if I died. So my theory is that if the game cannot place the NPC in an "appropriate fitting space" (TBD) on the ground, the physics engine sends the NPC out flying. This is more likely to happen with large NPCs (which need more "appropriate fitting space"), so it's more likely to encounter it with mammoths in the Whiterun tundra. Horses are also more susceptible to it (such as random encounters with hunter or noble on horse). But it can also happen in cities with human NPCs when using mods that add more NPCs making cities more crowded. The issue in that case is not a limit on the number of NPCs to process, it's that multiple NPCs can't fit in tight spaces and sometimes spawn "on top" of one another, or on top of an object. I also speculate that while NPC AI Process Position Fix doesn't cause the issue, it may exacerbate it when entering cities (or exiting buildings back into the city). As it tries to update the real-time position of human NPCs when the player enters the location, it may place them in a not "appropriate fitting space". You were asking for a fix, I'm afraid there isn't any. This appears to be a long-standing engine issue with no solution. If you google "skyrim mammoth falling from sky", you'll see there are many results, some of them going as far back as the Oldrim days. But if you have other ideas or suggestions, I'd be interested to hear them.

Bottom screen showing DDDM with Oxygen Meter 2: Regarding the cursors, I went back and tried the DDDM static cursor again. I ought to correct my earlier comment. The style is fine and mostly consistent with the overall theme, which is actually not that flat. But to me it's just too damn big, as I'm used to the Small Vanilla Cursors. So please take my view with a big grain of salt.

You can ignore that. They are LOD textures for CL ice textures. STEP is using Just Ice ice textures, so instead pick FOMOD > LOD Patches > Just Ice. Good question.

As DY mentioned, it looks exactly like the kind of bug caused by incorrectly placed eFPS occlusion planes. I'm using eFPS and coincidentally encountered such a bug very recently. Since the OP is not using eFPS, I'm guessing the Hendraheim plugin places its own occlusion plane where the house is. And somehow, the model for the house has been disabled, but the occlusion plane is still enabled. This could be verified by looking up the ref ids in xEdit and checking them in the console. I don't have the Hendraheim CC so I can't help you with the details, but perhaps someone else would. What else did you update beside CL and AYOP? Did you update DynDOLOD itself before regenerating LODs? You could try the simple following test with your bugged save: Go to interior cell. Verify DynDOLOD has shut down/is turned off in its MCM. Save and quit. Disable all DynDOLOD plugins on right pane of MO: DynDOLOD.esm, DynDOLOD.esp, Occlusion.esp. Load save, accept warning about missing plugins. Go to Hendraheim exterior. Is the house there?

You're making things more complicated than they are. ESL extension implies ESL+ESM, the ESL and ESM flags in this case are redundant and unnecessary. You'd want to use the ESL variant for all plugins, except IcyFixesFull which is provided only as ESM. The non-lite ESP variants, when available, are provided for VR users. I agree however the FOMOD installer is a confusing mess: LOD plugin options are presented first, while they depend on choice of IcyFixes options that are made later in the installation. We don't know if 'ESL' is a flag or an extension, so we don't know if those 'ESL' plugins are lite masters or ESPFE. The choice of IcyFixes plugins make no sense, with mention of large references that are irrelevant to the variations, ability to uninstall mid-game which is also irrelevant, and the 'Full' version not being offered in a lite variant, even though it's technically ok to ESLify it. I think the MA is a great 3D designer but may not be totally up to snuff on the finer points of master vs. patch plugins and full vs. lite plugins, or the implications with regards to large refs, or what can/can't be safely uninstalled mid-game. I have no idea what the LOD plugins do, I haven't looked at them, they don't exist in the version I'm using. I ESLified the IcyFixes 'Full' ESM plugin because it doesn't need to occupy a full plugin slot, there is no reason it can't be ESLified and I don't know why the MA seems to believe it shouldn't.

I use it with DDDM. I converted it to Form 44 in CK and ESLified it in xEdit. It improves the skills & perks UI, fits more information at once on the screen, supports different aspect ratios. Has an MCM to configure it. For use with DDDM: install this first, then DDDM overwrites it. That's all.

I'm still using an older version (2.0) and haven't updated in a while. I've been watching the updates as they come, and waiting a bit until the dust settles The 'ESL' I looked at in the current version are lite masters (ESL + ESM). The 'ESP' are full patch plugins (not ESL, not ESM).

I've been using this mod (Warm Text variant) ever since it was released. It set it up a while ago, so my memory is a bit rough. Installation Options FOMOD > Sleep-Wait Menu > Install Sleep-Wait Menu replacer? Yes. The configuration panel is shown twice in a row on the wiki page: FOMOD > HUD Menu > Install HUD? Yes. Should be 'No'. This option doesn't apply to STEP Guide, as it requires SkyHUD, which is currently not included in STEP Guide and is not even in Testing. I personally use it and would recommend it, though at this point I'd be hard pressed to tell you exactly what SkyHUD does and how it differs from/improves upon vanilla. FOMOD > Compass Navigation Overhaul > Yes, beige markers. Should be 'No'. This option doesn't apply to STEP Guide, as it requires Compass Navigation Overhaul, which is currently not included in STEP Guide. I see CNO is currently in 'Testing' though, so it could be considered. Beware however that DDDM is not compatible with CNO 2.x (the compass will be completely broken when both are used together, even with DDDM compatibility option). This can be fixed by borrowing the compass SWF from other DDDM-based mods, albeit with a vanilla-white style. I personally use CNO with DDDM, with the manual borrowed SWF overwrite hack, and would recommend it. FOMOD > Quick Loot Menu > Install QuickLootRE replacer? > Yes, Quick Loot EE. I don't use Quick Loot EE or RE so can't comment on that. FOMOD > Wheel Menu > Install Wheel Menu replacer? > Yes. Should be 'No'. This option doesn't apply to STEP Guide, as it requires UIExtensions, which is currently not included in STEP Guide and is not even in Testing. I don't use it so can't comment on that. Seems to be geared towards console controller users. FOMOD > Cursors > Replace the cursor? > Yes, static. The cursor replacers, even the static one, are too fancy/distracting for me and not in the same flat style as the overall design. I prefer the vanilla flat cursor style of Small Vanilla Cursors currently included in STEP Guide, even though they have different color (white vs. DDDM gold). FOMOD > Font > Replace the main font? > ENG (Latin). This will conflict with Font Overhaul. I don't care much for the main 'Friz Quadrata' font so I don't use it but I like the 'Consolas' font for the console so I kept it. Requires manual editing of fontconfig.txt to pick and choose fonts from DDDM vs. Font Overhaul. FOMOD > New UI Sounds > Install new UI sounds? > No. You may want to give the new UI sounds a try. I think they're nice. They're softer than the vanilla sounds. For example, vanilla has a loud 'whoosh-bang' sound for crafting potions at an alchemy table, while DDDM uses a more natural and subdued 'gurgle' sound. Conflicts As noted on the mod page, this should be installed dead last in the UI mod group and overwrite everything. Font Overhaul See previous point above. Icons For Skyrim Character Sheet Redundant, can be removed as DDDM provides its own complete set when the Skyrim Character Sheet option is selected in FOMOD. Wider MCM Menu for SkyUI Better Dialogue Controls Better MessageBox Controls Redundant, can be removed as DDDM fully incorporates them. Convenient Reading UI While DDDM incorporates the main reading UI from that mod (same MA), I'd recommend keeping and overwriting Convenient Reading UI for its other features that are not included, such as faster page turning animations and other stuff I can't think of at the moment. Other Oxygen Meter should be replaced by Oxygen Meter 2. The original Oxygen Meter uses the enchantment charge bar for its widget. Oxygen Meter 2 uses a custom widget. DDDM replaces the custom widget with its own DDDM-style widget, similar to Magik/Health/Stamina bars, integrating seamlessly with the UI theme. Final Words The 'Warm text' variant and its golden-colored theme may not be to everyone taste and may cause issues with vision-impaired users. While I prefer it over White, you may want to evaluate and consider the more neutral White option as the default. This mod is a beast with all its components and dependencies. Customizing it requires navigating a maze of configurations, and identifying the source of issues can be a hassle. This might create technical support headaches. Nevertheless I like this mod a lot and can't imagine playing without it. I made a few tweaks to the configuration, matter of personal preferences. Can be discussed later if needed, if I can find/remember what changes I made and why.

I just tried it, blocking wolf attacks with a metallic shield: no sound. It appears to be a vanilla issue that neither Audio Overhaul nor Immersive Sounds Compendium address. Here's a link to a discussion from 4 years ago that would suggest the issue has existed in vanilla for a while: [Bug -SE] Shields don’t have a block sound when blocking attacks (Reddit) I haven't tried with a pure vanilla setup myself to confirm.

Ok I see. Thanks for the screenshot. Looks like the instructions are not applicable and they'll be corrected. So for now you can skip step #2 in the profile creation and keep going with the remainder.

Is there a particular reason you want to reorder those DLCs in the left pane? If you're following the STEP Guide as you said, nowhere are you instructed to do so. It's not a MO bug, it's a feature. If you mouse over one of these DLCs on the left pane, you'll see a tooltip: This pseudo mod represents content managed outside MO. It isn't modified by MO. In other words, MO doesn't allow you to manage these items like mods, as they're not mods. It shows them so you know they're there, but that's it. Plugins are sorted on MO's right panel. And if you're following the STEP Guide, you should be using LOOT to automatically sort plugins rather than ordering them manually.

A huge file, are you kidding? 380 MB is really not much compared to all the GBs of textures, or compared to stuff generated by xLODGen and DynDOLOD. Grass not growing in objects and the performance optimization are pretty nice features to have. Also, as mentioned by DY in the Grass Cache Fixes comments section: I don't know which NGIO settings STEP uses for the provided grass cache, so some of those other features may not apply. I reckon most users probably generate grass LOD, so they'll install it. But for those who don't, there is really no good reason to avoid it. It's a simple matter of downloading the Grass Patch and installing it. There is no configuration change, no deviation from the guide, no explanation/context necessary. IMHO.

I don't know how it's supposed to look normally with or without Hendraheim CC as I don't use CC content, so it's hard to tell what's wrong from your screenshots. It looks like an occlusion issue. I doubt Cathedral Landscapes or At Your Own Pace would cause this. You can try Save Unbaker, though I doubt it will solve whatever issue this is in this case. We don't have enough information to make a diagnostic and offer a remedy.

Explanation 1: NGIO with 1.5.97: NGIO completely bypasses the engine grass generation and caching. It has its own configuration in a separate configuration file. It uses its own cache files if precaching is used, with a different .cgid extension than vanilla's .gid. This complete separation ensures NGIO works as intended without conflict or interference with vanilla grass generation or precache, which is borked in several ways, or with users' incorrect Skyrim INI grass configuration. 1.6.x without NGIO: NGIO is not possible with 1.6.x. However its grass precache files can be used by the vanilla 1.6.x engine, as they use the same data format and naming convention as vanilla, albeit with some restrictions on NGIO features which must not be used when precaching. The trick is simply to change the NGIO-specific .cgid file extension to vanilla .gid, and overwrite vanilla .gid files. DynDOLOD assumes precache files have .cgid extension by default for generating grass LODs, but it can be changed in its configuration. Renaming the precache file extension from .cgid to .gid is only necessary if the grass precache is to be used for rendering grass in near/active cells. If it's to be used only for Grass LODs, renaming is not necessary since DynDOLOD handles .cgid by default. Explanation 2: The current STEP Grass LOD Guide stops short of explaining how to use the NGIO grass precache with 1.6.x for rendering grass in near/active cells. It's only focused on using the NGIO grass precache for the purpose of generating grass LODs with DynDOLOD. I'd suggest at least mentioning the existence of Grass Cache Fixes and pointing to its instructions would be helpful. In order to replicate the grass setup of the STEP SSE Guide with your own NGIO precache, you need to follow the instructions from both STEP Grass LOD Guide and Grass Cache Fixes. Tangential Note: I don't understand why the STEP SSE Guide instructs users to install the STEP Grass patch only "when grass LOD will be used". The NGIO precache would benefit all users in all scenarios, whether they use grass LOD or not. When installed along with the appropriate INI configuration, the grass precache is used by the vanilla 1.6.x engine for rendering grass in near/active cells. It doesn't make sense that this feature/optimization is used only when Grass LOD is also used, as the latter depends on the former, but not the other way around. It seems both the SSE Guide and Grass LOD guides completely ignore the technical basis given by Grass Cache Fixes, which are made by no other than DY. Puzzling. What is the rationale for this?

It depends what you meant by "Everything crashed". If the whole system went down, including Linux, requiring a reboot to recover, that's not expected What is expected is that SkyrimSE.exe may crash several times during the cache generation process. But only SkyrimSE.exe. Everything else should stay up and running normally, including MO. In any case, NGIO writes a file PrecacheGrass.txt in the game directory (alongside SkyrimSE.exe) where it keeps track of its progress. If this file exists, and you restart Skyrim, NGIO will resume the cache generation from where it left off at the time of the crash. This can be repeated until all exterior cells of all applicable worldspaces have been processed, at which point NGIO removes that file, indicating that grass precaching has been successfully completed.

Is it making any progress at least? If it's chugging along and steadily producing output, why not let it finish? Sure, it's time-consuming and hogging the machine, but it's a one-time process normally, if you've got everything set up correctly. It's not like you'll be doing it again on a regular basis. Are you following the STEP Grass LOD guide that Z pointed you to previously? Have you followed the instructions Step 3 (optional): Take Steps to Speed Up Grass Pregeneration?