Mousetick

That's expected. It's the same in vanilla. These Vampire Thralls are by themselves unaggressive and neutral towards the player faction, as defined in the vanilla game plugins. They don't attack on sight. You'll find other instances in Skyrim (Shriekwind Bastion comes to mind, there is one thrall alone in a room, sitting on a throne). That's expected too. Improved Closefaced Helmets only supports the original SSE vanilla helmets (circa 2016). Iron Plate Helmet comes from the latest AE CC content.

This is all very confusing. To reset the precaching process and prevent it from starting again, delete the file named PrecacheGrass.txt in the game folder (that is the folder containing SkyrimSE.exe). This file must not exist for normal game operation. Its presence instructs NGIO to run in precaching mode, and it's used to store the precaching progress state so it can be resumed where it left off in case of crash. NGIO automatically removes it when precaching is completed, i.e. all specified worldspaces are 100% processed.

Yep. You may notice that you don't need to manually rename the mod with the other files, as Mod Organizer remembers the name last used for a specific mod. This is an expected feature. Just make sure you're told by Mod Organizer that the mod already exists, and choose to Merge when prompted.

Not sure what you mean by "renaming all mods at once". 1. Install 'aMidianBorn Book of Silence SE -- ARMORS'. When prompted by Mod Organizer during installation, rename to "aMidianBorn Book of Silence". 2. Install 'aMidianBorn Book of Silence SE -- DRAGONBORN'. When prompted by Mod Organizer during installation, rename to "aMidianBorn Book of Silence" (same as above). Then when prompted by Mod Organizer about "Mod Exists", choose to Merge. 3. Repeat #2 with the remaining 'aMidianBorn Book of Silence SE -- XXXX' files.

Double-check that you didn't skip point #4 of "Create Mod for Output". If you did, the Nemesis output would have ended up in MO's overwrite folder. There are no chances that the generated plugin would be enabled if this is the very first time you followed the instructions and (successfully) ran Nemesis. The plugin generated by Nemesis is named FNIS.esp. The contents of the 'Step SkryimSE - Nemesis Output' mod should look like this:

Your log doesn't show anything interesting. It doesn't even show that an executable is being launched by MO2. It just shows the MO2 startup sequence. Sometimes MO2 "crashes" but only in appearance: the UI disappears while the ModOrganizer.exe process continues to run in the background. This causes further issues if you're not aware of it and launch another MO process thinking the first one crashed. Check in Windows Task Manager if you don't have stray ModOrganizer.exe processes still running. Kill them if there are any. Other than that, no idea. In my experience, MO seems to become more unstable and crash-prone as the number of mods and plugins increase. When it crashes for me, it crashes when the launched executable terminates and control returns to MO2, never when launching an executable. At the point where the UI should "unlock", it just goes "poof".

Good to know, thanks. I stand corrected.

It's because it's not included in Odin, but in Vokrii (from the same MA) which is also part of the STEP guide. Tech probably confused between the two. See last point at the end Vokrii's FAQ.

Looks very good. There are 3 variants available for download. Which one did you use in your shot?

I've been wondering about it for the longest time but have been too lazy to investigate I suspect this mod may simply be ineffective when Embers XD is used. This mod replaces a vanilla texture, while Embers XD replaces vanilla meshes with meshes using custom textures (i.e. that don't overwrite vanilla textures) and their own glow effects. It'll be good to know for sure based on your tests.

How much are you willing to bet that it most likely isn't smart enough? The engine might omit the object from the rendering queue - this is what occlusion culling is supposed to achieve, if my understanding is correct. But the full model must still be loaded in memory, as the object could be dynamically enabled, repositioned or resized at any time (e.g. via a Papyrus script: https://ck.uesp.net/wiki/index.php?title=SetPosition_-_ObjectReference). Unless the engine uses some kind of object lazy-loading + purge mechanism based on whether the object is visible or not (doubtful). Anyhow, thanks for the clarifications.

This is an important detail that may be lost on mod authors wishing to disable large references. Setting Z to -30000 is an effective workaround, but the object is still enabled and its full model becomes useless overhead. Replacing it by a dummy object, like DynDOLOD does, would be better. It may be worthwhile to incorporate this advice to https://dyndolod.info/Help/Large-References. This would be even more important advice when disabling existing large references and recreating them as regular references in a split ESM+ESP combo, to work around overwritten large reference bugs. In that case, without replacing the original object by a dummy one, we end up with 2 "full" instances of the object. Please correct me if I'm wrong. Ok, so in other words, the record has to conform exactly to xEdit's "Undelete and disable reference" convention. What if the object is initially disabled, opposite enable parent, but Z = -20000? Thanks. A little off-topic but may be useful to readers: I've had good success simply flagging plugins as ESM to avoid large reference bugs. It works very well with mods that only change the scenery, such as landscape-focused mods, for example. It's not a guaranteed blanket solution, for example if the mod overwrites a large reference and moves it to a different cell, the results are unexpected and require manual patching, as I had reported earlier in this topic. There are also some issues with larger mods that add NPCs and/or quests (e.g. Cutting Room Floor, Helgen Reborn, ...). Without going into too many off-topic details here: due to the way the engine handles temporary references in ESMs vs. ESPs, and mods not being correctly written, quests referencing NPCs can be completely broken. Fortunately there are 2 little known xEdit scripts which can automatically fix these bugs: ESMifyer - Easily convert quest mods to ESM with xEdit (Nexus) ESMifyer Addon - Set unique NPCs persistent (Nexus) Caveat emptor: use at your own risk. YMMV.

Understanding DynDOLOD.esm initially disabled large reference autofix. The following example illustrates an instance of a large reference initially disabled by an ESM and automatically fixed by DynDOLOD in its ESM: I'm curious about the object being replaced with the WorshipperActivator, which is a simple invisible X Marker using a vanilla model unlikely to be replaced by a mod. I'm assuming this is done for dependability, efficiency and performance reasons. Even though these references are buried deep underground and can't be seen by the player, they're still enabled and their full model is still loaded in the extended large reference grid. So using a simplistic object instead of the original one is more efficient and consumes much fewer resources. Please correct me if I'm wrong. What are the exact criteria DynDOLOD uses to determine if this automatic fix can be applied? Here is an example that is not automatically fixed: This reference is created and initially disabled by the same ESM plugin. It's not disabling an existing reference added by another ESM. It's declared as a large reference in that same ESM. No other plugin overwrites that reference. It's completely standalone. It's kinda weird. Its 'Enable Parent' field is set to PlayerRef, which means the reference is initially disabled, but then not really? I'm not sure what it's supposed to mean. Why not simply let it be enabled? Anyway, this is flagged by DynDOLOD as an 'initially disabled large reference' because it can't be fixed automatically. Thanks.

It's fine. MO2 tries to be helpful but can be a bit dumb in some cases. It uses a hard-coded list of folder names (meshes, scripts, textures, ...) to determine if a folder contains a valid mod. 'grass' is not among them. Either of these solutions will get rid of the error: Create a 'textures' folder inside your 'grass cache' mod folder. Leave it empty, doesn't matter. Right-click on your 'grass cache' mod and select 'Ignore missing data'.

Sounds good. Another option might be to simply enable that reference. I don't know, maybe there does need to be a wet rock pile added at that particular location That would also fix the large reference issue. Thanks.

Apparently you have a corrupt or invalid mesh: meshes\architecture\farmhouse\walkway\walkwaycwall01.nif

Thanks for the detailed and clear explanation. I understand it's a corner case that's not worth worrying too much about or working too hard to resolve. Right. But I'm still a bit worried, perhaps overly so, about the following scenario. Let's say you're on vacation or unavailable for whatever reason for a couple of weeks (sometimes I wonder if you ever sleep or take a break off DynDOLOD). It happens that some new mod with the latest and greatest waterfalls has been released and users are trying it out with DynDOLOD 3. These users will be faced with the missing CRC-matched lods and the weird DynDOLOD behavior. They probably won't notice the 'file not found' error message but they may see the missing texture warning in the Summary report, and become utterly confused as to what's going on and what could be the root cause. They may also wonder why the waterfall lods are missing in game. So, what can users do in this case where you're not available for support? This is why I think a clearer diagnostic from DynDOLOD in this particular case could be helpful.

That works too. But this method is typically used to patch mods that overwrite and disable existing references. This reference is not overwritten, it's created by the RWT mod itself. It's useless, isn't used by anything and it doesn't make any sense. Why not get rid of it entirely instead of wasting resources? You can bury it underground, but it still exists for no reason.

Ok, here goes: Configure xEdit > Options > General and uncheck: 'Hide "never shown"'. May need to restart xEdit to take effect. In xEdit, load 'RealisticWaterTwo - Resources.esm', only it and its masters. Uncheck 'Hide no conflict and empty rows' in right pane right-click menu. In left pane, expand Worldspace node of 'RealisticWaterTwo - Resources.esm' and select Tamriel. In right pane, hide Skyrim.esm and Dawnguard.esm columns. You should see the list of Large References defined by RWT right below the EDID field. Scroll the list of Large References down to 'RNAM - Grid #70'. Select 'Reference #0', right-click and select 'Remove'. Be careful to select this specific reference only, and not the 'References' node or 'RNAM - Grid' node above it. This removes the large reference declaration and will prevent the bug and DynDOLOD warning. (Optional) Remove the reference itself REFR:XX00AE48 under Worldspace > Tamriel > Block 0,-1 > Sub-block 1,-1 > 00095D7 > Temporary, since it's useless, for extra cleanliness. See screenshot below for illustration. I had used this fix a while ago with success and I had to redo it recently after reinstalling RWT. It would be nice if it would be made an official fix. I guess an alternative would be to remove the reference first and then run sheson's xEdit script to re-generate the list of large references. I have no experience with it so can't comment. Hope this helps.

Anybody else noticed RWT 5.2.1 triggers a large reference bug warning with DynDOLOD 3? Warning: Initially disabled large reference in RealisticWaterTwo - Resources.esm [REFR:1300AE48] (places RockPileL02Wet [STAT:00039393] in GRUP Cell Temporary Children of [CELL:000095D7] (in Tamriel "Skyrim" [WRLD:0000003C] at 10,-1)) This specific reference doesn't make any sense to me: it's defined in 'RWT - Resources.esm', it doesn't overrides any vanilla reference and it's not used or overridden by anything else. It's initially disabled and enabled to state of opposite of player. In other words, it's completely useless. And yet it's declared as a large reference in the same ESM. I have a simple solution to fix it and would gladly share it but first I'd like to make sure I'm not missing anything about the presence of this reference, its purpose and its triggering of large reference bug warning. Thanks.

Success with Resources SE α23 and the newly added waterfall lod meshes. Thanks as always for your help and kudos for your dedication and quick turnaround. I haven't checked the results in game yet. Will report back if I find any that could be traced back to DynDOLOD [Resources]. Out of curiosity, would you mind shedding some light on what exactly caused DynDOLOD to become schizophrenic and not to find a texture that was right under its nose, so to speak? It's fine if you don't want to elaborate, no grudges will be held against you I'm probably going off assumptions that are completely wrong, so for the sake of understanding, is the CRC-less waterfall lod model (e.g. fxwaterfallbodytall_passthru_lod.nif) a fallback to vanilla lod when no matching CRC is available for the full model? Or is it something else? If it's not designed as a fallback mechanism, and waterfall lods are only designed to work by CRC-matching them with their full models counterparts, I'd like to offer a suggestion for possible improvement that you didn't ask for and may not care about. Here it is anyway: If a waterfall lod model (or other similar object lod model if applicable) cannot be found by matching the CRC32 of the full model, DynDOLOD should fail and issue an error message reporting the reason, such as: "Unsupported mod or unsupported version of mod for <insert full model name here>. Requires matching lod from DynDOLOD Resources. Refer to https://dyndolod.info/Mods/Waterfalls". Thanks.

That sounds great but you may want to hold off on that and wait a bit until this mod is deemed "stable". It's very new and might be subject to changes/fixes in the near future. Anyway, it's your call but I wouldn't mind using a workaround to make the lod fallback mechanism work, if that's possible. It's ok if the lods don't match the full models for the time being for testing/evaluation purposes, as long as I'm aware of the differences. If I can just ignore the error and warning emitted by DynDOLOD and assume everything is working correctly with the fallback waterfall lod meshes, I'll go with that for now. Thanks.

But it's not missing. It's there: Relevant excerpt: So the mod I'm using is understandably not listed there. Therefore: The CRC32 (0DA88E1A) of its fxwaterfallbodytall mesh doesn't match any of the premade lod meshes in meshes/lod/waterfall from DynDOLOD Resources. DynDOLOD falls back to meshes\lod\waterfalls\fxwaterfallbodytallpassthru_lod.nif which corresponds to the vanilla model. Am I correct so far? For some reason DynDOLOD doesn't find textures\effects\fxwatertile02_n.dds even though it does exist as a loose file inside the Data folder. It can find the other textures such as fxwatertile01.dds, which sit next to it in the Data folder as shown in the screenshot above, and also used by fxwaterfallbodytallpassthru_lod.nif, just fine. What about the "<Error: File not found>" message reported previously, you don't think it's strange/spurious? There's something funky going on here. Does meshes\lod\waterfalls\fxwaterfallbodytallpassthru_lod.nif actually require the vanilla version of textures\effects\fxwatertile02_n.dds based on its CRC32 too? Does DynDOLOD actually go and fetch this texture specifically from the vanilla BSA archives? Or can it use any version present in the load order?

Hello, DynDOLOD 3 α84 + Resources α22 in SSE mode [03:11] <Error: File not found> [03:19] <Warning: File not found textures\effects\fxwhitewater02_falls_n.dds. Used by meshes\lod\waterfalls\fxwaterfallbodytallpassthru_lod.nif Skyrim.esm FXWaterfallBodyTall_static [STAT:000FC85E]> First error message is worrisome but doesn't give any details. Exactly the same message appears in Debug log, without any more context or details. However it's almost certain that it's linked to the warning after it, because resolving the issue that causes the warning also suppresses the first error. Sometimes they appear in reverse order (Warning first, Error second) which may due to multiple processes or threads writing to the same output stream, I'm guessing. Second warning message is confusing and misleading. It refers to a mesh provided by DynDOLOD Resources, but the actual mesh that's the root of the issue is in meshes/effects and is meshes/effects/fxwaterfallbodytall.nif. Same issue occurs with fxwaterfallbodyslope.nif, fxwaterfallbodytall.nif and fxwaterfallbodytall02.nif. These meshes come from Water Effects Brightness and Reflection Fix - Realistic Water Two Patch. They tweak some BSShaderProperty lighting/emission/reflection parameters and are otherwise identical to the meshes of Realistic Water Two SE. As far as I can see in NifSkope, textures\effects\fxwhitewater02_falls_n.dds is not referenced by the mesh so I don't know why DynDOLOD thinks it needs it. textures\effects\fxwhitewater02_falls.dds is used by the mesh as the 'Source Texture' property of a BSShaderProperty. The corresponding mesh in RWT also uses the same texture in the 'Source Texture' property of the same BSShaderProperty, but doesn't cause any trouble to DynDOLOD. My rough guess is that the patch mod's meshes don't match any known CRC32 special cases so DynDOLOD falls back to the generic passthru_lod.nif and snafu ensues somehow. For the time being I removed the patch mod's meshes and reverted to the original RWT meshes to suppress the error/warning messages. But I'm wondering what the results were exactly? From DynDOLOD's point of view, despite the error and warning, everything was fine and the generation process ended successfully. What should I expect in-game in regards to those dynamic waterfall lods? Full logs at https://drive.google.com/drive/folders/1fQvv6PVQ5uC3w_lQuFlT0K29O6BkgAeO Should be easy to reproduce if you like: install RWT then the patch mod linked above. Thanks for your attention.

It's very nice, works very well, and can be customized according to user preferences. I didn't care for the original Dear Diary "Paper" mod but this is completely different. The "golden" UI gives me faint and distant nostalgic vibes for Morrowind. You mean the red arrow that points at selected/equipped items? Yes it can feel a bit out of place somehow but I quickly got used to it. I don't like the 3D cursor but it's an option that can be skipped in the FOMOD installer.