z929669

See previous post and let us know if this resolved.

For posterity: The wiki is basically an editable, structured article (aka 'page') and data repository that maintains semantic relationships among articles and article attributes ... as well as the history of edits made to each article. The data are used in associating mods with modgroups, guides, and games. Maintaining the data relationships with each change to an article in real time is a constant (and often performance-demanding) process. With each edit to a semantic data property (i.e., adding new mods or changing the modGroup of existing mods) and associating them with a guide can have a significant performance impact while all of the semantic data associations are rebuilt, which begins almost immediately after the change. The cost can be a lack of expected data or failure of a mod or modList form to render completely or increased page load time. A suggested workflow to avoid bottlenecks (and wasting your time) during the data build process: Start with the forum mod topic, since it creates the desired wiki URL link that can be clicked to allow the next step. Create the wiki page. Add the text, {{mod}}, and save the page. Use the page edit button to bring up the mod form to add all required data to the mod page (I need to flag the required fields). Continue adding all mods needed for the guide of interest. Wait 30 minutes. Add the mods to the modList. Load the guide page - this should trigger the recalculation of semantic data referenced by the queries on the guide page, which will appear as a small, animated vertical bar chart at upper right. If it doesn't, try using [...] > Refresh from the top menu. If it's grayed out, try a hard refresh of the page. Wait 30 minutes. Edit the guide (after the edit is saved, the ModGroups should all have the expected mods). Let me know if this works smoothly or if you find a variant that allows you to be more productive while at the keyboard.

Searching this forum using the term, "old files" (with quotes), yields your answer: Delete your current \DynDOLOD folder, and replace it with the \DynDOLOD folder from the downloaded archive. Retry.

I think you are misunderstanding how it works and just doing it wrong: Set path to 'Binary' to see EXEs ^ Set path to containing folder for "Start in" (you will not see EXEs here, siunce it's only looking for directory locations ^ (but this piece isn't even necessary for 99.9% of use cases) Note that the latest build (v4.1.5f) has several copies of the 32-bit and 64-bit binaries (EXEs). They are the same files with different icons. The name of the EXE doesn't matter if you use the command parameter method to define the game compatibility mode (aka the command line switch ... -sse in this case). I can point to xFOEdit64.exe, xSFEdit64.exe, or xTESEdit64.exe with the exact same result. If this bothers you, you can rename xTESEdit64.exe to xEdit64.exe. Always use the 64-bit binary if you run a 64-bit system (all modern PCs use 64-bit arch).

Never used it, since it would complicate testing.

FINALLY. This mod has been updated thanks to DwemerEngineer. Consider giving DwemerEngineer some kudos on Nexus. Rather than pregenerating grass, the Step 2.3. guide will include grass cache generation instructions similar to DynDOLOD instructions. Tagged for testing

The NULL path needs to be removed from BSSHaderTextureSet nodes where indicated: Then save the NIF. NOTE: if you do this, you will need to also check the LOD model crown (and possibly trunk if it's not a hybrid LOD model) for the same issue and fix it. Then you will also need to update the LOD model name with the new CRC32 (and all four BSSHaderTextureSet paths of the flat trunk if it's a hybrid LOD model). It's not a trivial thing, which is why it's best if the MA fixes it in both cases (full model and LOD model). Otherwise, this is a benign DynDOLOD error that can be ignored. EDIT: Actually, the trunk one should probably point to the normal map instead of removing "textures\". MA needs to fix it, IMO.

Thanks for reporting this. We'll need to see what may be causing it. Very likely an error in our patch or a loophole one of the mods we're using.

I can relate to your preference for "load after/before", which is also correct and arguably more universally applicable in a semantic sense. But it only applies to plugins, which is only applicable to load order. The layperson also often confuses LO with install priority, causing another huge source of miscommunication and misunderstanding. This is why I use 'priority'. It's the only nomenclature that applies to the order of both installed mods and plugins in relation to the winner/loser.

Priority is the only absolute way to correctly describe it. Above/below is relative

The error message explains the problem and gives you the problem plugin and record. Click the link for explanations. Then report the error to the mod author if you don't know how to fix it yourself.

First, I want to confirm you are referring to LO (plugin ssort order) rather than mod installation priority. If the former, does LOOT sort Grass Cache Fixes.esp at higher priority than Step Patch - Conflict Resolution.esp? Second, the GCF plugin does not conflict with the CR Patch plugin. Same goes for the INIs. It's the BSA priority that matters. The Step Patch - Conflict Resolution.bsa should override Grass Cache Fixes.bsa, so that's the problem if the GCF plugin is sorted at higher priority than the CR Patch plugin by LOOT (BSAs are loaded by the game according to their plugin priority). The Step grass must override the GCF grass (both use GID). @mikael_cz @RustlersDeluxe @slidingotter @Mercury71 If DynDOLOD was generated with the GCF plugin sorted at higher priority, then LOD will need to be regenerated after moving the plugin to one-lower priority than Step Patch - Conflict Resolution.esp. Otherwise, the grass LOD will be off.

No grass period or no grass LOD?

Id the plugin is hidden, then LOOT won't message about it

I recommend checking the Nexus mod Description linked in the OP for the best info. Also see this topic, which asks the same question but does not provide an answer to the OP question (your second question).

It was almost certainly not related to VRAM unless you have less than 4 Gb of GPU RAM

That's correct. We leave it up to the user.

Not if you don't notice any problems with Aspen LOD.

Mod updated with CNO (and Infinity UI) compatibility: Version 4.1.0 DLL Update: Infinity UI (2.0.2+) and Compass Navigation Overhaul (2.2.0+) compatibility DLL Update: Fixed log location for SkyrimSE 1.6.1130+ New Designs: Deadlands, DeadlandsTower Config Updates: Atlas Map Markers (Both versions) JSON files updated with tweaks and fixes (thanks to Enodoc). Wiki mod instructions updated

The CoMAP 4.1.0 update will likely obviate this mod or at least change the requirements.

Just adding a reminder for myself to retest now that CoMAP has been updated with Compass Navigation Overhaul (2.2.0+) compatibility.

Compatibility with CoMAP should be resolved now with CoMAP 4.1.0

Does this happen for you in vanilla in a new game with all mods disabled (except SKSE, SSE Engine Fixes, SSE Display tweaks, and the Unofficial Patches)?

In skyrim, body replacers come with all sorts of compatibility headaches though ... some of them caused by plugin records. Not sure how it works in FO though.

Moved the respective mods topic.