z929669

Noted, thanks

This is why it's important to share your logs as described in the OP. I use AMD as well 5700XT, and had the same issues with 107 or thereabouts. 111 fixed it for me.

If making posts or reporting errors, upload/paste these log files (if they exist) to a file or text sharing service: ..\DynDOLOD\bugreport.txt ..\DynDOLOD\Logs\[DynDOLOD|TexGen]_[TES5|ENDERAL|SSE|TES5VR|ENDERALSE]_log.txt (truncate large log files to the entire last meaningful generation beginning with the log message "... starting session ..." ) ..\DynDOLOD\Logs\[DynDOLOD|TexGen]_[TES5|ENDERAL|SSE|TES5VR|ENDERALSE]_Debug_log.txt (always upload entire debug log) If issue involves LODGen upload/paste ..\DynDOLOD\Logs\LODGen_[TES5|ENDERAL|SSE|TES5VR|ENDERALSE]_[Worldspace]_log.txt Consider zipping large and/or many files into a single archive.

The best thing you can do is post your debug logs if you have them from your last run. Otherwise, you can regenerate and post those. Details in the DynDOLOD OP.

You need files for 1.5.97 Everything you need is linked here. My guess is that Papyrus or DynDOLOD DLL isn't a match if you are 100% certain you have the correct SKSE64

xLODGen is terrain and DynDOLOD is objects. Neither should rely on the other or cause issues with the other regardless. One typically generates terrain first followed by objects so that the most accurate terrain meshes are in place before generating objects, but I don't think it's a requirement. Issues with long-running process have to do with GPU drivers at least in part, so it's important to clear out all logs, run DynDOLOD/TexGen, and provide these logs for analysis so that the root causes of issues can be elucidated. Without attempts and outputs from failures, progress cannot be made. Always use the latest available software, since that is the only relevant version about which to post. Old versions are dead and irrelevant ... and inaccessible anyway. logs, logs, logs are of primary importance as can be easily gleaned upon just glancing at the OP.

Do you remember why exactly we stopped recommending Dawhguard manual cleaning? I thought there was a specific reference for not doing this.

Yes, if you have already done the manual cleaning, it shouldn't harm anything. We dropped the manual Dawnguard cleaning for a specific reason I believe. I think we had some evidence for doing so that either @TechAngel85 @DoubleYou or @Greg provided. All of my LOOT-flagged plugins are cleaned using xEdit QuickAutoClean, and I did NOT use the manual cleaning procedure on Dawnguard. No issues as yet.

This is fixed. Thanks.

Posting logs actually helps to resolve issues. That's kinda the whole point of this topic. See the OP.

ENB can add to loading time, particularly when enbcache folder doesn't exist yet. The only reliable way I can think of testing is to disable half your mods and load. then re-enable and do the other half. Repeat this process in batches narrowing down the sample frame from 50% to 25% to 12.5%, etc.

Greg's answer above is the obvious/simplest solution. Super simple and efficient. Then just do as I mentioned as a second step to take care of the loose files problem.

Always follow the instructions. Since the instructions don't say to disable DynDOLOD Resources, don't disable it.

All clarified in the changelog now. Thanks for reporting. NOTE: The FML lavender mesh must be hidden so that Cathedral - 3D Lavender wins

We somehow didn't catch these masters even though they are documented, so look for an updated version of the WACCF patch soon. Thanks for reporting.

As stated in the changelog, we DO NOT advise manual cleaning any longer.

Recreating this post as a topic for posterity, as I always have trouble finding it again. A very simple approach to removing masters from a given plugin that complains: First, add the attached script to your xEdit installation: ../xEdit/Edit Scripts/ (it's just a slightly tweaked version of "Report Masters.pas" shipped with xEdit). The following describes how to remove AOS plugin as a required master to the CR Patch plugin. This same principle can be extended to other situations. Install AOS new version as a different mod name. It can be anywhere in your mod list (defaults to highest priority). Go into that mod (right click, "Open in Explorer") Rename the plugin by adding a suffix or whatever before ".esp" Activate this (and all other Step mods as normal) Run LOOT to sort. Run xEdit and load the CR patch along with the renamed AOS (this will load the original AOS and all other CR patch dependencies) Once loaded, right click on the Step CR patch > Apply Script > select that script and OK. Once you get the report back, tick AOS plugin master and OK (this bolds all records in the CR patch that correspond to the original AOS) Find the record(s) that have no corresponding records in the updated AOS plugin (there is only one under "Weapons" branch I think) Right click the record in the left pane or in the column header of the right pane > Remove (deletes the record) Once all targeted records are removed, right click the CR Patch > Clean Masters Just close xEdit and select OK (the modified CR Patch plugin will be ticked for saving on exit. Otherwise, use CTRL + s to save before closing). This is your updated CR patch, so it's ready in MO now. Simply reinstall the new AOS mod (over the original this time), and remove the renamed new AOS mod, and you're good. Report masters and flag records.pas Other Explanations & Examples Odin - Skyrim Magic Overhaul.esp Using List records referencing specific plugin script General discussion

Yes, well that's the crappy Bethesda policy of letting anyone upload mods. I would not use anything but Isoku's or Tech's, because they are the RWT team along with SparrowPrince. I don't think Tech is supporting xBox any longer though.

Indeed. I provided you the plugin load order specifically because this is what applies to xBox. The mod install priority = plugin load order priority on xBox (I believe), but these are very different on the PC, so it's best if you sort your mods according to the plugin priority that I provided. If you are using other mods not on this list, then you need to determine if they use plugins or not. If they do, then sort on xBox according to the function of the mod. If they do not use plugins, then sort according to asset preference you want to 'win' in the game (i.e., which model/texture you prefer) For this sort of thing, see if you can discover a publish date, and use the latest one. I can tell you that TechAngel's version of RWT is what you want, but I cannot say if it corresponds to the latest version on Nexus. Bethesda.net makes a real mess of things, so using mods from them on xBox will be hit or miss unless you dig more where there is ambiguity. Some mods are no-brainers and should be loaded early (e.g., USSEP, SMIM)

All I can offer is the plugin load order that is best for the mods with plugins we use in the current guide. You can use this as a proxy for xbox loadorder.txt

This should be fixed now. Thanks for reporting.

First, I don't know which screen is which LOD. Second, you want to use xLODGen terrain, as Perfect Terrain LOD will not match your landscape in loaded cells unless you have the exact same landscape mods as the creator of that mod. This is the whole point of using xLODGen: to match your distant landscape terrain to your full one.

The instructions are accurate. Doing it this way will work for everyone without including the conditional caveat.

Did you reinstall Embers XD with 'Optimized'? Yes, it works fine. This cautionary note/advice was considered, but it works well in our testing, so we're linking to it and using it in 2.2.0. Main reason is because this will almost certainly be the standard sooner or later. This mod is not supported and not in the guide. This mod is not supported and not in the guide.

All should be fixed now. Thanks for reporting!