sheson

I am not really convinced it is useful doing this, since the silhouette will still be the same. Unless you have lots of trees that would benefit from that, just use an (optimized) 3D trunk like tundradriftwood01passthru_lod_0.nif in DynDOLOD Resources or use Simplygon to make an actual LOD representation.

Test the same command line arguments with xEdit. Edit: Do not install DynDOLOD into special Windows folders like c:\users\... https://dyndolod.info/Installation-Instructions Use 7-Zip to unpack the DynDOLOD Standalone archive into a new and empty 'DynDOLOD' directory that is outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game, Data or any mod manager folders. For example C:\Modding\DynDOLOD\.

Moved to the DynDOLOD 3 Alpha thread. See the first post which log and debug log to upload when making posts. The message is self explanatory. The INI file is missing from its default location at c:\Users\ealaa\Documents\My Games\Skyrim Special Edition GOG\Skyrim.ini. Use the "Click on this link for additional explanations and help for this message" to open https://dyndolod.info/Messages/INI-Files In case existing files can not be accessed, add an exception to whatever it is that is blocking access. If the shown path is not correct, fix the wrong path you set for the -m command line argument.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts. Read the explanations of the summary https://dyndolod.info/Help/Summary-Of-Messages and https://dyndolod.info/Messages/Property-Not-Found-In-Scripts: It can be a sign of load order conflicts of two mods requiring different versions of a script As explained, make sure the script from the mod is not being overwritten by other mods. If there is a conflict between mods, it should be investigated further.

https://dyndolod.info/Help/Ultra-Tree-LOD#3D-Tree-LOD-Brightness

https://www.amd.com/en/support lists Adrenalin 22.5.1 Recommended (WHQL) The test version is a link to TexGenx64.exe in reply to the problem you reported having with running TexGen. The single log line you posted is a log message from DynDOLOD...? The messages log is saved once the program is closed. You can mark and copy the entire messages log to the clipboardwith the standard keyboard shortcuts, e.g. CTRL+HOME, CTRL+SHIFT+END, CTRL+C. https://dyndolod.info/FAQ "Long running time or output several GB in file size" See all answers and also: Crapware installed with graphics drivers is known to prolong running times. This refers to crapware installed in addition to the AMD graphics driver. https://stepmodifications.org/forum/search/?&q=crapware&type=forums_topic&quick=1&item=17510&search_and_or=and&sortby=relevancy

See if there is anything different with this test version of TexGen https://mega.nz/file/YcIRQZjD#Ea79ZZrTC5lpuR5ThtjN7TCxpvHAdUH9gHwFeULMpX0 If not, upload new log, debug log and bugreport.txt if it exists. Then install AMD recommended driver version instead of optional versions as in all the other cases before https://stepmodifications.org/forum/search/?q=OpenGL Invalid Operation&quick=1&type=forums_topic&item=17510

Thanks for letting us know.

This is deliberate. All overwrites are checked. Reverting the position does not fix the issues that are being caused by a large reference being moved out of its original cell. You will find that all overwrites are being ignored depending on the direction the cell was approached, as can be seen by More Informative Console reporting Skyrim.esm as the only plugin affecting the reference regardless of any other plugin overwriting the record. These are relatively new findings. DynDOLOD large reference bugs workarounds mitigate the issues.

That is terrain LOD. DynDOLOD does not generate or affect terrain LOD. As explained on the first pots of https://stepmodifications.org/forum/topic/13451-xlodgen-terrain-lod-beta-95-for-fnv-fo3-fo4-fo4vr-tes5-sse-tes5vr-enderal-enderalse/ and https://dyndolod.info/Help/xLODGen, use the Optimize Unseen drop down and a low value < 10 for Quality for LOD level 32 terrain meshes to improve coastlines on the map. Also see https://dyndolod.info/Mods/Maps-And-Map-Mods and have a look at https://www.nexusmods.com/skyrimspecialedition/mods/56367

DynDOLOD DLL and DynDOLOD DLL Scripts have no conflicting files. https://dyndolod.info/Help/DynDOLOD-DLL

Moved to the DynDOLOD 3 Alpha thread, assuming you are using it because of Seasons etc. Read the first post which logs and debug logs to upload when making posts. Run TexGen before DynDOLOD. https://dyndolod.info/Generation-Instructions

Great. When you inevetibly update LOD, revert one or the other and let us know if you can.

As MO2 mentions there is still a (or more) TexConvx64.exe active when this happens. Can you check in Windows task manager it/they just linger around or eventually dissapear? Add LockTexconv=1 below [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini and see if it makes a difference. If not, use task manager to keep an eye on memory usage of DynDOLODx64.exe and any spawned TexConvx64.exe and LODGenx64.exe processes with task manager.

Upload the realtime log, assuming there is still no normal log / debug log. Also upload the attached files mentioned in the event log. Is that event log entry the only one related to this around this timestamp? There is still not much the program can do about being terminated without its crash handler being invoked. In addtion to chkdsk run sfc /scannow as admin. Doublecheck BIOS (memory timing settings for example) and/or disable overclocking etc.

Read what the event log message tells you about Windows not being able to access the file and follow its suggestions. There is nothing a program can do about the OS terminating it because of file system issues. https://dyndolod.info/Installation-Instructions Use 7-Zip to unpack the DynDOLOD Standalone archive into a new and empty 'DynDOLOD' directory that is outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game, Data or any mod manager folders. For example C:\Modding\DynDOLOD\. Could also be power savings related. Also consider adding exceptions to antivir etc.

Check the Windows Event viewer for related message(s) about the DynDOLODx64.exe or TexConv64.exe

You can also check the dates of the files in the archive to see when it was released.

Moved to the DynDOLOD 3 Alpha thread. Delete all logs. Add realtimelog=1 below [DynDOLOD] in DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini Then execute DynDOLOD again. See first post which bugreport.txt if it exists to upload in a addition to the new files in the log folder. https://dyndolod.info/Messages/Deleted-Reference https://dyndolod.info/Generation-Instructions#Prerequisites Clean and error check the load order with xEdit. Clean every plugin that LOOT suggests to clean

Moved to the DynDOLOD 3 Alpha thread. Read the first post which log file to also upload when making posts. You only uploaded the TexGen log, while the posts hints missing textures problems after the LOD patch generation as well. Read https://dyndolod.info/Messages/File-Not-Found-Meshes and https://dyndolod.info/Messages/File-Not-Found-Textures. Find out which mods are missing assets. Double check their requirements and installation instructions. Check their comments or bugs sections for related posts. https://dyndolod.info/Mods/Beyond-Skyrim-Bruma File not found errors are because not all required assets for LOD generation ship with the mod.

No information which DynDOLOD version is being used. No log has been upload. DynDOLOD closes only after user action and writes the log file. If that does not happen, it means it is being terminated by the OS or antvir maybe. I suggest to actually read the MO2 message what it says is still running. That does not really explain anything. Typically problematic records of assets should create an appropriate error message.

I have not encountered or come across such reports. Maybe the reason for UDRs to be set to -30k and not any lower is deliberate. In that case I would assume that to be the result if something in older TES or FNV games. I would like to see actual testing or something official from UESP or CK Wiki. I will check with the other xEdit devs. Such a message would be to the debug log only in case of navmeshes. So far every check and message is related to the LOD patch. For example people would constantly report things floating above the center of the map, when in fact it is simply LOD for a reference that is placed there by a plugin. This check prevents LOD being added and to notify the user so they do not blame DynDOLOD only because its plugin is mentioned overwriting the base record or because it is the last thing that was added to the load order.

Try with the test version from https://stepmodifications.org/forum/topic/13451-xlodgen-terrain-lod-beta-95-for-fnv-fo3-fo4-fo4vr-tes5-sse-tes5vr-enderal-enderalse/?do=findComment&comment=265077

The bugreport.txt has a date from March this year. The DynDOLOD log contains generation processes from Alpha 94 up to 106 https://dyndolod.info/Installation-Instructions Use 7-Zip to unpack the DynDOLOD Standalone archive into a new and empty 'DynDOLOD' directory that is outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game, Data or any mod manager folders. For example C:\Modding\DynDOLOD\. What about the reference 0x090271F4 in Synthesis 1.esp as reported by the crash log? Have you checked the record in xEdit? Synthesis 1.esp (and Synthesis 2.esp) were not loaded when generated the LOD patch. https://dyndolod.info/Generation-Instructions#Prerequisites Typically create all other patches first. Especially all patches affecting exterior worldspaces in any way should be done before generating LOD. https://dyndolod.info/Generation-Instructions#2-Generate-The-LOD-Mod-with-DynDOLOD Make sure all mods, plugins and patches (that affect exterior cells and worldspaces and base records used by references in exterior cells) are enabled and their overwrite order is sorted.

I do not expect anyone to do anything. It is your load order and your choice what mods you use and if you fix problems or don't DynDOLOD checks every base record to see if it contains a model that might be suitable for LOD. If it discovers a problem, it does not generate LOD for the base record or with the missing model/textures so that here is no problem like CTD or missing models/textures with the generated patch. The message about the problem is to help with troubleshooting, e.g. identify what/where a problem comes from. If mods with problems bother you, tell the mod author about the issues hoping for a fix, fix them yourself or do not use the mod. If you want to fix things yourself, then you will to educate yourself. If there is no model, then there is no point for any base record to define the non-existing model. By extension there should be no reference using such a base record. Generally, remove the base record and remove any reference. If for some reason a reference (overwrite) still needs to exist, it should use a base record that does not define any model or defines an existing invisible model, like xmarker.nif. For example have the reference use the base record 0x0000003B If a plugin contains deleted references, it needs to be cleaned.