sheson

Changing tree LOD brightness in xLODGen before DynDOLDO was a thing usually works for everybody since Skyrim LE. Other than that there are also the mentioned controls in TexGen. Sounds like a problem with the ENB preset or its requirements (specific weather mod or tree mod for example). Standard tree LOD lighting always works the same way regardless of what the diffuse texture depicts.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen and DyNDOLOD logs and debug logs to upload when making posts. Ask ENB related questions on the ENB forum or discord as whatever it does to tree LOD is unrelated to the tool, if any, that was used to generate tree LOD. https://dyndolod.info/FAQ#Billboard-tree-LOD-does-not-match-close-up-full-model-trees If the billboard tree LOD seems overly dark or bright, use the billboard brightness setting of the advanced mode to account for lighting changes made by ENBs or weather mods. https://dyndolod.info/Help/Advanced-Mode#Tree-LOD Negative Billboard Brightness values will make the billboard tree LOD darker, while positive values will make it brighter. Also see https://dyndolod.info/Help/TexGen#Direct-Ambient-Smoothness Consider to use https://dyndolod.info/Help/Ultra-Tree-LOD with 3D tree LOD models and/or HD Tree LOD billboards. Consider generating HD Tree LOD billboards with normal map textures for better looking tree LOD that reacts more naturally to lighting than standard tree LOD.

The DynDOLOD.ini and TexGen.ini are really only used to store the last window position.

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\. https://dyndolod.info/Updating Rename the DynDOLOD Standalone folder, for example from C:\Modding\DynDOLOD to C:\Modding\DynDOLOD.OLD Unpack the new DynDOLOD Standalone using the same original installation path. See Installation Instructions. If desired, reapply any customized INI settings. Open the old and new ..\DynDOLOD\Edit Scripts\DynDOLOD\[DynDOLOD|TexGen]_[GAME MODE].ini in notepad++ to compare to make sure to not accidentally remove any new INI Settings. If the Changelog does not mention any new or changed INI settings, the old INI can typically just be copied in case any settings were customized. The download archive does not contain a ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD.ini, so it can not be accidentally overwritten when doings things wrong.

The copies are for now are deliberately not copying all flags, and some elements like linked references or locations. They are supposed to be "dumb" static copies on purpose. The respawn flag will most likely not be needed if the copy uses the parent as enable parent. Need to check which flags are really save to keep. Might probably be better to copy ACTI with scripts and remove the scripts. We'll see.

The principle is the same as the 3rd bullet point at https://dyndolod.info/Updating#New-or-Updated-Mods-or-Plugins

See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log and debug log to upload when making posts. As explained use the "Click on this link for additional explanations and help for this message" from the message to open https://dyndolod.info/Messages/Record-Is-Being-Overridden Plugins randomly replacing records in master plugins is an error that needs to be fixed. Not having encountered an issue in the game is not a valid method to assume something is fine. If you check the overwritten record in xEdit you will see it has to do with moving children to another home. You would have to create the right conditions that rely on this record in order to test what happens if the game, scripts can not find the record and data they are expecting. Temporarily disabling the plugin is not going to fix its problems. The plugin needs to be fixed to work properly with the game plugins of Skyrim Special Edition.

Moved to the DynDOLOD 3 Alpha thread. Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which logs and debugs to upload or how to enable the realtimelog and check the Windows Event log. See https://dyndolod.info/FAQ#TexGen-DynDOLOD-stuck-while-creating-textures https://dyndolod.info/FAQ#High-memory-usage-Out-of-memory https://dyndolod.info/FAQ#Long-running-time-or-output-several-GB-in-file-size https://dyndolod.info/Help/LODGen#Out-of-Memory

Download this file DynDOLOD_TES5_TexGen_copy_skyrimesm.txt Replace the existing one in ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\ with it. TexGen should then run through. Will be fixed next Alpha version, too.

Moved to the DynDLOD 3 Alpha thread. You already posted this before. See https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-142/?do=findComment&comment=274141 It is pretty much guaranteed that the requested log files contain more than that line.

There is an example here https://dyndolod.info/Help/xLODGen#Installation "C:\Modding\xLODGenx64.exe" -sse -o:"c:\Output\" Which splits to "C:\Modding\xLODGenx64.exe" for the Target field and -sse -o:"c:\Output\" for the command line field. Adjust the actual paths as required.

You do not need the -m command line argument to set the standard INI folder of the game as shown in your screenshot with the missing " at the end. That default INI folder will be found automatically when setting the game mode with the -sse command line argument as explained in the first post and the readmes included in the download archive. As the quote says, you only need to do that if you have the GOG version installed, which does not use the standard SSE folders. You need to define the game mode -sse either way or else xEdit/xLODGen will default to FO4.

xLODGen is a tool mode of xEdit. The first post and the readmes included in the download archive are mod manager agnostic. They neither mention MO2 or Vortex by name, since the same instructions apply to any manager or even using none. You seem to have a problem with using Vortex. Read its manual/documentation https://wiki.nexusmods.com/index.php/Tool_Setup:_xEdit Use its forum, discord etc. in case of questions how to use it or problems with it. Command line arguments and Start in are rudimentary OS features that are just replicated in mod managers. https://www.bleepingcomputer.com/tutorials/understanding-command-line-arguments-and-how-to-use-them/ All command line arguments need to be in the command line argument field. Separated by space. All paths need to be enclosed by " at the start and also at the end. The start in field expects a path only. It sets "the current folder". It can not be used for command line arguments. https://dyndolod.info/Help/Occlusion-Data DynDOLOD offers both options - generate the occlusion data into the DynDOLOD.esp or a separate Occlusion.esp (which is equivalent to using xLODGen) - in the advanced mode options.

This is the DynDOLOD 2.x thread. Its TexGen version does not generate billboards. Billboards are required to generate tree LOD. They are also required for ultra tree LOD, e.g. LOD for trees done in object LOD. Use DynDOLOD 3 Alpha. Its TexGen version generates billboards for the current load order. See https://dyndolod.info/Downloads, https://dyndolod.info/Installation-Instructions and https://dyndolod.info/Generation-Instructions.

This test version https://mega.nz/file/sMQk3LDT#1g6LdrN5Pw90QmesBCmB1N5vwj7ZhM-CPw32s9v2a0o removes the IsInitiallyDisabled condition. So if the source reference is persistent and has no enabled parent itself, it is used as enable parent for the copy.

Moved to the DynDOLOD 3 Alpha forum. Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum which TexGen log and debug log to upload when making posts.

This test version should fix scanning Markarth with ScanParent=0 https://mega.nz/file/VI5TVDCS#r8EsTQqlIQ_8_3O5XdTrpv2lYbiOnBdD2tBINSEKfT4 Is the range error 100% repeatable?

Check if this test version runs through https://mega.nz/file/VI5TVDCS#r8EsTQqlIQ_8_3O5XdTrpv2lYbiOnBdD2tBINSEKfT4 If not upload new log, debug log and bugreport.txt if it exists.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log, debug log and bugreport.txt (if it exists) to upload or how to enable the realtimelog and check the Windows event log in case the normal logs were not saved because the program was terminated. https://dyndolod.info/Generation-Instructions#1-Generate-The-Required-LOD-Assets-with-TexGen Click Start and wait for the process to complete without errors. Pay attention to all log messages (especially "file not found textures"). It should end with the log message 'TexGen completed successfully'. Do not use the output if there were errors that stopped the process prematurely. If TexGen is being terminated prematurely, then it can not generate all required LOD assets.

Upload the log and debug log to properly report the supposed bug.

Moved from the xLODGen thread to the DynDOLOD 3 Alpha thread, assuming that you are using it. Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts. Also see https://dyndolod.info/Mods/Open-Exterior-Cities

Your DynDOLOD log show two generations. The first one worked. Can you tell what changed? They seem to have the same exact same plugin list and order. Does it work with this test version? https://mega.nz/file/VYhQ3SqQ#wLIhiHVcYxN_m8Rw0xmBAAidLG0TlIJXLKl4fV4-pFQ If not upload new log and debug please

It is intended because the cell/area right outside the maingate would otherwise not have copies for the drawbridge etc.

If you have problems following or questions about third party guides, then you need to ask the author of the third party guide or use its forum, discord etc. From the official documentation: https://dyndolod.info/Generation-Instructions#Prerequisites Finalize the load order. Install mods and their requirements. Sort and resolve conflicts. Clean and error check the load order with xEdit .. 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 Finalize the load order as explained in the prerequisites above. 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. .. Activate the plugins(s). In case Occlusion.esp was generated, it should be the last plugin to load right after DynDOLOD.esp. If a DynDOLOD.esm was generated it should be the ESM with the highest priority possible or just before the first non-ESM. Ignore any contradicting third party instructions. Instead use correct options and settings for the desired results. https://dyndolod.info/Help/Load-Overwrite-Orders#Before-Generation When the plugins are generated, records from the last plugin that is the winning overwrite are copied to create the DynDOLOD plugins and Occlusion.esp. Sort and finalize the load order before generating the LOD patch. If any other plugins are added later consider to generate new output from scratch again. Generating patch plugins like DynDOLOD.esm, DynDOLOD.esp and Occlusion for the finalized and current load order priority of plugins/records and then activating and sorting them as explained, does not change the load order priority of plugins/records. Patch plugins typically need to be installed last in the same order the patches were created.

The references are not exact copies, scripts are removed for example. If the source reference has an enable parent, then the copy should already have it set. An initially disabled reference without an enable parent that is copied would be 00062832. (Also 0005227F but it is ignored since it triggers large reference bugs. The harbor can typically not be seen from inside Windhelm anyways) Enable parents need to be persistent. So one can not just blindly add the source references as enable parent without overwriting them and making them persistent - something to avoid at all cost This test version will set an enable parent to the source reference if it is initially disabled, persistent and does not have an enable parent. https://mega.nz/file/IMowTbJK#30H0goSCiowS1jMqJYs_HaSe4rUu7lyG4m5GzEY8OtU There are potentially more things (changing position, scale for example) that can happen to source references that are not covered. Those would be addressed if they actually happen / are reported.