sheson

For a test select a dedicated output path to a new folder that is not part of MO whatsoever. If this doesn't change anything, load the entire load order in xEdit and bring up 000E8ECB. In the left window, right click 000E8ECB, click Deep copy as override into... new ESP If that works without problem, please upload the saved DynDOLOD plugins Then see if it runs through without other problems after hiding the fie DynDOLOD\DynDOLOD_SSE_ProvincialCourierServiceEsp_Tamriel.patch in DynDOLOD Resources If that works, unhide the file and edit it in notepad. Remove the line overwrite=skyrim.esm;000e8ecb, so that just the copy=... is left. Test if that works.

Use pastebin.com, imgur.com or any other free upload service

The log shows Nordic_BashedPatch.esp still loaded for two runs. Start without that and upload that log if problem continues. 000E8ECB being clean means it is added by Skyrim.esm, right. Can you make a screenshot of xEdit showing it? Then check which is the last plugin to overwrite the Whiterun Worldspace 0001A26F. Make a screenshot of that too, please. Use a legal copy of the game.

You could try error checking all plugin (excluding the vanilla files) for errors with xEdit and try to fix them. Start with the last plugin to overwrite the mentioned cell 000E8ECB Before you spend hours though, upload the bugreport and the log and let me know which plugin - if any - modifies the record. Maybe I can replicate and then be able to tell exactly what happens.

It says right there what to do: Check log lines above the exception for additional hints. Check the FAQ and search official forum for those errors. If problem persists post error report with entire contents (not just the last couple lines) of ..\DynDOLOD\bugreport.txt (if it exists) and ..DynDOLOD\Logs\DynDOLOD_[GAMEMODE]_log.txt or a screenshot of the error to official forum. These types of errors are often caused by a broken bashed patch. Use a newer Wrye Bash version to create the patch or do not use the merge patches option. If removing the bashed patch allows the process to continue, delete it and generate a new one. Use a recent version of Wrye Bash like https://github.com/Wrye-Code-Collection/wrye-bash/releases/tag/307.201901211926

Good to hear. Enjoy.

Please check if version 2.57 fixes your issue.

DynDOLOD copies existing world and cell records from the highest plugins for those records in the load order. That should be the same for any version. If any records are corrupted you should check the source plugins. What is the last plugin that served as source for the record? It's of course possible something wierd is happening with the xEdit copyasoverride function. Test if the error happens with the x86 version. Unfortunately you did not include much information about the unused data error itself, like a screenshot of the problematic record, maybe a log showing the errors. Best would be to uploaded the problematic plugin itself. Use a legal copy of the game. Do not install DynDOLOD into any game folders.

Check log lines above the exception for additional hints. Check the FAQ and search official forum... FAQ: DynDOLOD.exe: Exception in unit xxx line xxx: Can not copy xxxx from xxxx.esp into xxx.esp A: Often caused by a broken bashed patch. Use a newer Wrye Bash version to create the patch or do not use the merge patches option. A: There might be plugin in the load order with errors. Check the load order for errors with xEdit.exe before generating LOD. Fix all errors. See this video for help. If removing the bashed patch allows the process to continue, delete it and generate a new one. Use a recent version of Wrye Bash like https://github.com/Wrye-Code-Collection/wrye-bash/releases/tag/307.201901211926

Check log lines above the exception for additional hints. Check the FAQ and search official forum... FAQ: DynDOLOD.exe: Exception in unit xxx line xxx: Can not copy xxxx from xxxx.esp into xxx.esp A: Often caused by a broken bashed patch. Use a newer Wrye Bash version to create the patch or do not use the merge patches option. A: There might be plugin in the load order with errors. Check the load order for errors with xEdit.exe before generating LOD. Fix all errors. See this video for help. If removing the bashed patch allows the process to continue, delete it and generate a new one. Use a recent version of Wrye Bash like https://github.com/Wrye-Code-Collection/wrye-bash/releases/tag/307.201901211926

Often caused by a broken bashed patch. Use a newer Wrye Bash version to create the patch or do not use the merge patches option. If removing the bashed patch allows the process to continue, delete it and generate a new one. Use a recent version of Wrye Bash like https://github.com/Wrye-Code-Collection/wrye-bash/releases/tag/307.201901211926

Better late than never, eh. Thanks for letting us know.

There seems to be a problem with the NIF used by reference 7B014DDC in JKs LITE - Merged.esp. Typically that should be Meshes\Architecture\Windhelm\WHshorttower.nif defined on base record 0009A359. That is a vanilla mesh of course. In my test load order it is replaced by the ENB particle patch. Those two are fine here. In any case, see if you have a mod replacing it. Use xEdit Asset Browser (CTRL+F3) to search for the file in a all available BSAs in case there is no loose file. Replace by a working version.

This seems to be a general problem with something in Skyrim as you will find similar reports for many load orders that do not include DynDOLOD. There are many posts and discussions around Skryim and Skryim Special Edition crashing when saving. Sometimes people have success with using older saves that work fine and killing the player, then loading a problematic save and kill the player again and then can save again. The DynDOLOD plugins contain data that was copied from other plugins, keep their changes and then make a few simple updates for LOD. So far there have been no problems with DynDOLOD and saving games. Makes sure the LOD was generated for the current load order and no plugins or their order change in the meantime. It is also possible that a resource limit reached and just removing certain plugins elevates the issue. After removing DynDOLOD and making a clean save and then add the DynDOLOD plugins again, does the issue return immediately? Test if the issue can be replicated in a new game. Run around and fast travel in worlds that have dynamic LOD. Find a save that still works and compare to a problematic save. Enable and check the papyrus log for messages about scripts being dumped. The engine might be overloaded Check the saves for active scripts. Try DynDOLOD DLL as an alternative to PapyrusUtil. This involves a clean save procedure and maybe cleaning the save with a save tool. Install .NET Script Framework to get a better crash log that might us more about the issue.

If problem persists, post error report with entire contents (not just the last couple lines) of ..\DynDOLOD\bugreport.txt and ..\DynDOLOD\logs\DynDOLOD_TES5_log.txt to official forum Enable Debug=1 in DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5.ini so there is a bit more info in the log.

Yeah that is actually a blue LOD texture, not a missing one. A mod is replacing textures\lod\wrbuildingslod01.dds

No problem, enjoy!

Probably missing textures. The DynDOLOD log will most likely have printed messages about them. It is a bit weird though, because typically those vanilla LOD models use vanilla LOD textures, so even if a mod replaced the LOD textures... everything should fall back to use the vanilla LOD textures from the vanilla BSAs. Unless of course a mod changed the LOD models. You can check all this by looking up the base records for those buildings in xEdit and check what models they have defined, and from here you get to the textures. Let me know if you need more detail.

That mod just seems to replace the full model tree meshes with versions that do not show anything when loaded in the game. The easiest solution would be to use xEdit to unset the "Has Distant LOD" flag on the base records for those trees.

Use tcl to go close to such a tree and get its base record form ID. I believe it to be 00051126. Look up that base record form id in xEdit and check the OBND - Object Bounds. The last plugin to overwrite the values wins. If it is SFO - Expanded Diversity.esp then Y2 is out of whack. Best to load the plugin in Creation Kit, find the tree in the "Object Window" and right click to Recalc Bounds. Save plugin. Check bounds changed in xEdit (because CK does not show them AFAIK). Generate LOD. Alternatively you could set a useful Depth= in the txt file accompanying the billboard dds. It would be TreePineForest05_00051126.txt in this case. Depth should be somewhat close to the Width.

The DynDOLOD SkyUI MCM simply lists the currently used terrain LOD files for convenience. By default the map uses terrain LOD Level 32 and object LOD Level 16 files. Changing map settings does nothing to the static LOD files. The static LOD files never do anything to plugins or save games. They are simply loaded as is and displayed. They either match the load order visually or don't.

That depends how the mod removes the trees. LOD is added only for objects that are currently placed into the world.

Use tfc to get close to LOD models without cells/full models loading. So before, those trees didn't have XESP Enable Parent, then would get normal tree LOD and that tree LOD would show when inside Whiterun. Now with the XESP Enable Parent, those trees are done as object LOD and usually use the Internal billboard mesh based on the billboard texture. What is the number of "current" version of DynDOLOD and DynDOLOD Resources? Post the DynDOLOD log so we can see what it uses for the trees in object LOD Level 4. Open meshes\terrain\tamriel\objects\tamriel.4.4.-4.bto in NifSkope and see if the odd shapes for the trees show.

Probably running out of memory when generating atlas textures, try the x64 version.

Well we can't check the log either without you posting it. This post might be helpful https://forum.step-project.com/topic/13894-dyndolod-beta-for-skyrim-special-edition-and-skyrim-vr-256/page-82?p=233251&do=findComment&comment=233251