sheson

The screenshots seems to show 3D tree LOD models that are missing trunk textures. I suggest to really pay attention to log messages and the summary. They most likely report this. The defaults of the tree mesh rule are different depending on the preset.

TexGen generates a front and a 90 degree side view for HD billboards. With standard billboards available - front view texture only - the DynDOLOD_flat_3x2_lod.nif will use the same texture for all planes. If the HD billboard is available, it should be using the front view for 2 planes and the side view for one plane.

Use the "Copy this message to clipboard" and paste the text instead of screenshots as explained at https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text Use "Click on this link for additional explanations and help for this message" to open https://dyndolod.info/Messages/Can-Not-Copy-Resource: "The system cannot find the path specified - The OS, UAC, antivir or some other 3rd party crap ware is blocking write access to the mentioned destination path. Add an exception to whatever it is that is blocking access." Search this forum/thread for the error message to find similar posts as explained on the first post. https://stepmodifications.org/forum/search/?q=system+cannot+find+path+specified&quick=1&type=forums_topic&nodes=223 https://stepmodifications.org/forum/topic/15604-texgen-error-cannot-copy-resource-the-system-can-not-find-the-path-specified/

That explains it. Correct, the clean save procedure includes loading/saving the game without the plugins. For reference https://dyndolod.info/Help/Clean-Save

Can resaver load the save that the game can not load? Have you also tested removing SKSE DLL plugin mods? Like SkyrimSoulsRE.dll, TrueDirectionalMovement.dll, AHZmoreHUDPlugin.dll See what happens if you install DynDOLOD DLL SE - SKSE64 Plugin - Skyrim Special Edition 1.6.353 and the DynDOLOD DLL SE - Scripts overwriting the papyrus scripts from DynDOLOD Resources SE. If nothing else use PapyrusUtil disable that, too. Post the log from the generation session and the debug log (which hopefully still contains the session)

Try [SaveGame] uiCompression=1 or 0. How many plugins? Assuming you increased maxStdio as well? So it happens with a usual clean save and with a clean save that you also cleaned further with resaver? What happens when saving after starting a new game? Have you tried what happens if you remove other mods? Install crash logger to get a crash log. Any chance you can test/get crash log with 1.5.97 and .Net Framework? Check papyrus logs, too.

See https://dyndolod.info/FAQ ILS or CTD "If there are problems saving in Skyrim Special Edition, install SSE Engine Fixes 4.8 or newer and set SaveGameMaxSize = true in the EngineFixes.toml. Alternatively add/set [SaveGame] uiCompression=1 in Skyrim.INI to change from the default 2 for LZ4 to 1 for zlib compression. 0 means no compression like games are saved in Skyrim."

Try deleting the file xEdit/xLODGen stores its settings in: C:\Users\Ian\AppData\Local\Skyrim Special Edition\Plugins.sseviewsettings If you have custom xEdit settings you want to keep, then you can also edit in notepad and just remove everything under [SSE LOD Options]

I can see form the debug that it is reducing the setting automatically down to 6 and still fails. You had success with setting to 10 from the start. Try that again.

That error should be unrelated to updating the Redis. Any changes to the graphics card/driver/OS? What is the graphics card? How much VRAM? Track its usage. It seems that TexGen has less and less of it available until the "render context" (think of it like a hidden window) somehow becomes invalid. Kill any hidden TexGenx64/Texconv lingering in task manager. Try not to run other programs that use (lots) VRAM. Only select one TexGen option at a time, e.g it seems billboards went fine, and its at the start of rendered object LOD were things went wrong.

MO2 replaces existing files in their mod folders and only put new files into the Overwrite folder. The format is -o:"c:\folder" no space between -o:" the entire path needs be wrapped in straight double quotes " Copy paste content of the Arguments field here if you need help with it.

Replace LODGenx64.exe in Edit Scripts with this test version. It uses an alternative method. Let me know how it goes.

This is the DynDOLOD 3 alpha thread for testing LOD generation etc. DynDOLOD reports facts about records/plugins/load order, just like LOOT or the xEdit error check does. Refer to https://tes5edit.github.io/docs/7-mod-cleaning-and-error-checking.html how to properly clean plugins. To avoid user error, consider using Batch Plugin Cleaner for Mod Organizer or xEdit Cleaning Extension.

Double check the command line is correct, for example -o: points to a valid drive. I problem persists, upload the log and bugreport.txt if it exists.

Should be fixed in Alpha-81

Terrain underside needs to be done in the second pass. If you do Glow LOD Windows High, do them in second pass only. If they are not high do them in the first pass only. Can you also upload seasons\blacklist_roastmodularwhiterun_wrcastlestairs01_snow.ini?

The logs show that different settings where used, high/medium, Level 32 on/off etc. but in regards to dynamic LOD, things appear to be pretty much the same - none of that code that creates the dynamic LOD records/data was modified in recent versions. If you have problems with dynamic LOD: Test with a new game. Check the DynDOLOD SkyUI MCM Main page for the last message. Check the DynDOLOD SkyUI MCM Information page that plugins and data files have same bunch of numbers. Check the papyrus log for messages from the SHSESON_DynDOLOD_* scripts. Do not install the game into Program Files x86 to avoid issues with UAC, anitvir etc.

This might be fixed next version. If not upload new log, debug log and bugreport.txt if it exists. This should be fixed in the next version. If not upload new log, debug log and bugreport.txt if it exists. Test with the next version. Should be fixed. If it still happens upload all new logs and bugreport.txt.

Check/Upload the LODGen_SSE_Test_log.txt file and check the event log.

Read the first post which log and debug log to upload when making posts. Read the explanations for the message https://dyndolod.info/Messages/File-Not-Found-Textures The message should list the NIF that uses the texture and the record that use the NIF. https://dyndolod.info/Messages/Deleted-Reference There can be plugins in the load order that where made before the current version of Updates.esm. The foundation of a load order should be as stable and error free as possible. I suggest to read the xEdit documentation and/or use its Discord for questions regarding the use of xEdit. Undeleting records in dirty plugins is established modding practice to avoid CTD caused by them. DynDOLOD simply reports the problem, similar to LOOT. Clean every plugin that LOOT reports. Clean dirty plugins that have deleted records. It will be one of the first troubleshooting steps in case of CTD or other problems in the load order anyways. Reporting such issues in mods/plugins is to help users to better understand, identify and fix problems in their load orders instead of assuming issues happen because of the last tool they used or mod they added

Replaced references in the DynDOLOD INI to the old html docs with URLs.

The OS is what controls resources. A simple program requests a resource from the OS, it may grant or deny it. Then the simple program deals with it. In this case DynDOLOD prints a error message and stops. If the OS freezes while doing its job, it has some kind of problem or is not a very well programmed OS. Texconv also ran out of memory. Same thing: a simple program requests memory from the OS. OS says no. Program chooses to stop with error message. Without logs I can not really make further suggestions that could help to reduce memory usage of the tools. It is possible there are huge grass cache files or some other problem with one causing LODGen to consume a lot of memory. Maybe its log provides clues (setting Verbose=1 for more info could help). Setting LODGenThreadSplit= to same number as virtual cores might help.

I am simply stating a fact. if the OS freezes or has BSOD because it told a program it can not have any more memory, then there is a problem with the OS or the system. DynDOLOD wanting to use as much memory and CPU as possible to speed up things is how it is programmed. Grass LOD creates huge BTO files. Reading many large BTO files at the same time requires lots of memory. Nothing unusual about it. The INI setting to limit number of threads exists for this very reason. Read the first post which entire log of the session of interest, entire debug log and bugreport.txt (if it exists) to upload when making posts. Typically operations are aborted when user clicks X top right of window to close the program.

If a program running out of memory causes the OS to freeze, there is some kind of a problem with the OS, drivers, setting, BIOS settings or hardware. DynDOLOD stopping the process because of errors in mods/plugins is not a problem with DynDOLOD. It means it is working as expected. It reports the error so it can be fixed.

Run this test version, see if it works any better. Check for bugreport.txt in case it doesn't and upload with debug log.