Mousetick

Edit: This was meant as a reply to Z's post above but I forgot to quote it and I'm unable to do so now for technical reasons. I don't use this particular mod*, so take my comments with a grain of salt. I don't know the exact reason for the ESM, but it's probably not for alleviating LR issues. The main mod content being ESM is a good thing anyway, for whatever reason, so let's just not question it. This mod's worldspace and cell settings are critical to its function. They're also used by DynDOLOD for terrain LOD and occlusion, as such they need to be correct. Since the main mod content is ESM, it's going to be sorted high in the loader order, as such it's likely other mods will be loaded below it. Those other mods below which make changes in the same cells as this mod, will clobber this mod's specific worldspace and cell settings, because they don't know anything about it. The ESL-flagged ESP is there to ensure those worldspace and cell settings are correct. It simply forwards the worldspace and cells records of this mod's ESM and is meant to be loaded very very low (i.e. with high priority) so that it wins over any other mod that have clobbered them. LOOT may have some metarules to automatically sort it very low, or it may need to be manually sorted very low - I don't know. As an analogy, consider another mod you're familiar with: ACMOS. It's the same principle: it must be loaded very low because it makes changes to worldspace records that must win over all other mods. Except ACMOS is a single ESP plugin, so it doesn't need another plugin to forward its changes. It looks like you assumed the ESM/ESP split was LR-related, which sent you down a LR rabbit hole. The 'WTT test.esp' experiment yielded no interesting results because there were no LRs to begin with. The Location records are not forwarded by this mod's ESP because they don't need to be: they're specific, unique to this mod. Nothing else is going to override them. On the other hand, each cell record can have a location property, pointing to a Location record. It's this location property that needs to preserved, among other settings, and forwarded with the highest priority, by the ESP. Even if there are no conflicts with the ESM in your current load order (STEP guide), the ESL should nevertheless still be included, enabled and sorted very low, to avoid issues for users adding their mods to the list. (*) Though I do use many other excellent mods by Sacralletius

If you use The Choice Is Yours, you can talk to Falion without starting the quest. Once you've met Falion, the rumour about him should stop, the next one in the queue should pop up, and there should be no unwanted quest waiting in your journal. Quote from Quests Altered by The Choice is Yours: If you're not using TCIY, I'd strongly advise against installing it in the middle of your playthrough.

You need to finish the guide successfully to completion before attempting to add other mods. You need to run and play the game a bit with the STEP mod list and nothing else. If you're new to modding, I wouldn't recommend using a mod like MLU. It changes a lot of stuff deep into the game. If you don't know how to use xEdit or know what leveled lists are, you won't be able to tell if MLU is integrated correctly or if it works correctly. You'll probably need to find and install lots of compatibility patches too. If you really really want to play with MLU, I'd suggest finding a mod list or guide that is specifically designed and built with MLU at its core. A simpler and less intrusive loot and leveling mod is Open World Loot. It's inherently more compatible with vanilla+ type games and requires less tinkering. I'm using it in my mod list based on STEP. But I still wouldn't recommend it if you're new to modding

Yeah, me too. I decided to take a closer look. It really needs a very close look because I doubt anyone would really notice or be bothered by it. The vanilla orcish weapons have a weird yellow-greenish shine on them. Before WACCF 2.9, it was fixed by WACCF in its plugin by applying an alternate texture set to the model. In WACCF 2.9 and later, the fix was moved out of the plugin and into the mesh themselves, overwriting the vanilla meshes. Not sure why it was done, probably to reduce conflicts and patches at the plugin level. Vanilla mesh + textures > WACCF mesh + textures With LeanWolf meshes, the issue is the same. Greatsword has sheath according to STEP default selection. LW mesh + Vanilla textures > LW mesh + WACCF textures Now the big question is why does WACCF provides a LW patch? I don't see any difference visually between the original LW mesh and the WACCF-patched LW mesh. LW original mesh + WACCF textures > WACCF-LW mesh + WACCF textures There is actually at least one difference inside the mesh, which I noticed because NifSkope threw a warning: One or more textures dimensions are not a power of two. textures/cubemaps/ore_obsidian_waf_e.dds is 3072x512 LW original mesh uses textures/cubemaps/ore_obsidian_e.dds while WACCF-LW mesh uses textures/cubemaps/ore_obsidian_waf_e.dds.

Personally yes I install them separately, below CACO on MO2's left side. It's easier to manage IMHO. Like with this update, I updated CACO and didn't need to re-install the cleaned textures on top of it, they simply remained where they were, below. Yes they do take precedence over BSA files, and "merging" into the same mod is okay. Not the most practical or flexible in terms of maintenance, as mentioned above, but it works just fine.

No, there is no need. I'm not quite understanding why you'd want to do that in this case. Is there something that you're worried about specifically? If the game needs to load a file that is not provided by the cleaned textures mod, it will look into the 'Complete Alchemy & Cooking Overhaul - Textures.bsa'. This is the same mechanism taking place between the vanilla BSAs 'Skyrim - Textures0.bsa, ..., Skyrim - Textures8.bsa' and any texture replacer installed as loose files.

If you want "big" trees to be made LRs, so that their full model (as opposed to their 3D LOD or Hybrid model) is rendered within the LR grid, you need to use DynDOLOD's 'Large' option. Tree replacers typically only override the base records (TREE signature), not the tree references (REFR signature) placed into the world, nor do they add new tree references to the world. So they have no "impact" on the 'Large' option, or vice-versa. All the tree references created by the vanilla masters (ESMs) will be "promoted" to LR if they're "big" enough and all other conditions are satisfied (don't have non-ESM overwrites, or enable parents and are not initially disabled). Counter-examples: Aspens Ablaze moves/resizes/rotates ~7000 tree references, overriding the vanilla references. Happy Little Trees 'All trees' version adds ~400 new tree references. The aspens touched by AA, and the new trees added by HLT, can't become LRs with the 'Large' option, no matter how big they are, because the AA and HLT plugins are not ESM. A simple solution is to ESM-flag those plugins. Hope this helps.

The cleaned textures have not been incorporated into the new 2.1.0 version. The BSA still contains the original textures in the old format. So you should still install (or keep them as the case may be) the cleaned textures, and since those are loose files, you can rename ironwood_n.dds to ironwood01_n.dds as needed. Basically: no changes from the current guide instructions, except 'Temporary Patch for Complete Crafting Overhaul Remastered' no longer exists, as it's been merged into the main plugin.

Understood. But a record being overwritten by non-ESM triggers LR bugs. Rephrasing my question of what happens in the previous case with the 'Large' tree option: The tree reference is promoted to LR in DynDOLOD.esm RNAM and a LR-bugs workaround is applied in DynDOLOD.esp? OR the tree reference is ignored by the 'Large' option to avoid LR-bugs?

In other words and in plain English, the 'Large' option will not apply to trees references added by EVT or AA, regardless of their size, because their plugins are not ESM. These references are not eligible for being 'promoted' to LR, as technically, their plugins being non-ESM, they can't define Large References. Corollary question for sheson, out of curiosity, considering this example: Plugin1.esm adds REFR ID1 places BigTree at x1/y1/z1 Plugin2.esp overrides REFR ID1 places BigTree at x2/y2/z2 (non-ESM plugin overrides Plugin1.esm) If the reference ID1 is "big" enough to become a LR with the 'Large' option, what happens in that case? Probably nothing I'd assume, i.e. the 'Large' option doesn't apply.

Alternate mod for preventing Bolar's Oathblade from disappearing, available on Nexus: Ill Met Bolar's Oathblade (by lilebonymace). See the sticky post on that mod's comments section where the MA gives their opinion about Quests Conflicts Fixes.

Off-topic, but what really irritates me are the capitalization style changes USSEP made in 4.2.7 (2022-06-18). So now we have multiple inconsistently styled versions: The original vanilla text USSEP 4.2.7 and later Mods that don't forward USSEP Mods that forward USSEP changes from before 4.2.7 I try to forward USSEP changes as often as possible just for consistency too, even if I don't always agree with the changes. As I use a lot of mods that change quest objectives, dialogue, or item descriptions, it gets very tedious. For users who don't or can't make their own CR patch, it's a complete mess.

This combines 3 mods into 1: Morning Fogs SSE (by MannyGT) Cresty's Distant Mists (by Crestycomb) Volumetric Mists (by Robanco) The mod page doesn't bother to link to the original mods and assumes prior familiarity with them? There is a one-liner description: The mists and fogs are placed in specific locations. Unless one RTFMs each original mod, we have no idea where they are, whether the mods works or not. There is talk of "thin" and "thicc" textures: What the heck is a Thicc texture? How is one supposed to know how the "original" looks like? The MCM is well made, though it allows enabling subtle, medium and dense volumetric mists simultaneously, which doesn't make any sense, as each denser level hides the previous one. I've only seen the volumetric mists so far. The mod's plugin is designed for vanilla weathers, it adds new cloud types to weathers. There are patches for many weather mods. I've used the RAID Weathers patch, it's wrong IMO. I don't know if the other weather patches are the same. The issues: The patch simply forwards its new clouds to the vanilla weathers, without taking into account the changes made by the weather mod. For example, RAID Weathers removes all clouds from clear sunny weather (I don't know its exact name from the top of my head). The patch adds the new clouds. So now we have volumetric mists on bright clear sunny days. As a consequence of the previous, these mists are blindingly bright due to the very high light level. The MA released an update with "reduced emissive" for the mists meshes, but it's still too bright. The issue would be less noticeable or not at all be an issue if the mists clouds were added to the correct weathers, and omitted from the inappropriate weathers. The patch completely ignores the new weathers from the weather mod. It only forwards clouds to the vanilla weathers. So mod-added weathers that would be appropriate for mists and fogs don't receive them. These issues with the patch can be fixed by redoing the patch from scratch, properly tailored to the specific weather mod. I haven't had the motivation to do it for RAID Weathers. PS: I don't use ENB.

USSEP's change is ok IMHO. It can be confusing for players accustomed to the Thief and Warrior classes in Oblivion. If players really don't want this particular change, they can use this mod to revert it to vanilla: Archery is a Stealth Skill.

They are not mutually exclusive, nor is there any conflict between the two, as they leverage different occlusion methods. They work completely fine together. It's explained on that mod's front page, in big orange text, and on https://dyndolod.info/Help/Occlusion-Data.

Again, have you uninstalled/disabled or installed/enabled a mod recently? Try this: start a new game, finish character creation, receive first quest, save, quit. Relaunch, load previous save. Does this work? If not, disable mods and repeat the cycle until it works. Or you could proceed the other way: start with clean vanilla, and add mods until it breaks. That information is not useful to me. It's for you. There's something wrong with that mod.

Have you uninstalled/disabled or installed/enabled a mod recently? You can try cleaning the save with Resaver. I don't think the reported problems could cause a crash, but you never know and it doesn't hurt to try. Find a guide/tutorial online and follow the instructions. Make a backup copy of the save beforehand, just in case. Also figure out which mod the script OM_ConfigMenu is from, looks like it's not correctly installed. To be clear: I meant to load an earlier save in Skyrim. Can you load an earlier save in Skyrim, without crashing, or do they all crash?

Mod has been updated for latest 1.6.x (using CommonLibSSE NG). Also recommended: Dialogue More NPC Info by the same MA, using the same UI style. Can be considered like a cheat/spoiler, though. But it only shows basic info and is more convenient, less disruptive than a trip to the console.

If you can start a new game but loading your save crashes, it means the save is bad. You can try: Open the save file in Resaver. Don't do anything else with the tool, just open the save and see how far Resaver goes in loading it. Load an earlier save.

Skyrim doesn't generate crashlogs on its own. You need to use a crash logger for that. Are you using a crash logger? Is it working? The Windows Event is showing a Windows runtime library has forcibly terminated the process because it has detected some data corruption (like a buffer overrun for example). It's possible that in this case the crash logger, assuming there is one active, doesn't get a chance to kick in. I'm only speculating.

Are you not seeing that 00_lod is not the same as sse_lod?

It's unclear where "you would expect it to be" really is. DynDOLOD expects it to be in meshes > sess_lod > rocks, as that is where the mod plugin says it should be.

What you read elsewhere is correct, and I was wrong. The Unofficial patch (USSEP), which STEP uses, changes it so that Archery is only accelerated by the Warrior Stone. My bad, sorry for the confusion. Now you have an interesting choice to make for your stealth archer.

You are missing a file that should have been in 'Solitude Exterior Sovngarde Statue Set'. The warning tells you which file: File not found meshes\sess_lod\rocks\rockl04_lod_1.nif Notice the file path: meshes\sess_lod\... is a folder specific to that SESS mod.

You'll also find some gold in chests and various containers in dungeons. Not much to tell really. Pick the best bow and light armor you can find or buy. Imperial bow is good early on. If you're playing in Survival Mode, pick an armor that is warm, which may not be the best one in terms of armor rating. You'll stumble upon enchanted items (jewelry, armor, weapon), in random loot, that provide various buffs. Use them as you see fit.