sheson

DynDOLOD 2.x reports missing meshes since several years with these messages at the end of the log: Missing models were ignored by DynDOLOD.Below is a list of base records with missing models which are used by references:...References using base records with missing models can cause CTD.Install the missing meshes, then generate LOD again if LOD for reference using these base records is desired. Missing meshes either show red exclamation marks or can cause CTD, depending how the meshes are used.

No.

Thanks. Will be fixed next Alpha.

That's not supposed to happen. This will be fixed next Alpha version.

Look at the files in the log folder.

The LOD level 4 means 4x4 = 16 cells are covered by it, 8x8 = 64 cells and so on. Only chunks for valid coordinates (the lower left cell - which are part of the filename) are generated, obviously. The LOD system of the game does load files that do not fall on the 4x4, 8x8, 16x16, 32x32 grid. Cell 32,7 is covered by 32,4 for LOD level 4 or 32,0 for LOD level 8.

Do not install xLODGen into any game folders. Do not install xLODGen or the game into Program Files x86. The log shows Tamriel.8.32.8.btr was generated. If the file can not be found in c:\XLODGenOutput\meshes\terrain\Tamriel\ it was removed afterwards by something else.

Will be fixed next Alpha.

The log only shows on generation loading DynDOLOD plugins from earlier generation. There must have been some kind of error in one of the earlier generations leaving an incomplete plugin with the NULL base record.

Do not set TreeFullFallBack=0, especially while using a mod like Skyrim 3D Trees which has complex tree full models. On the other hand ultra tree LOD is not checked... No debug log from DynDOLOD was uploaded. Make sure virtual memory / page file settings are automatic. Obviously try without generating grass.

Do not post screenshots of text. Post the text instead. Search only works with text. Read the first post what logs to paste/upload in case of reports. This probably the same as https://forum.step-project.com/topic/15348-dyndolod-300-alpha-12/page-9?do=findComment&comment=243953 which will be fixed next version.

So what did you do that DynDLOD.esm has a reference with a NULL Base record? Did DynDOLOD complete successfully? Check its log.

FAQ: Game: ILS or CTD A: Do not use the experimental TreeFullFallBack setting without understanding what it does and what it is for. A: If heap memory is not the cause of CTD see ..DynDOLOD\Docs\DynDOLOD-README.txt for checking if a missing or invalid nif model used for dynamic LOD is the cause. A: Large load orders with many plugins might surpass the reference handle cap. SSE Engine fixes prints a warning. See https://www.reddit.com/r/skyrimmods/comments/ag4wm7/psa_the_reference_handle_cap_or_diagnosing_one_of/ Setting Temporary=1 in ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GameMode].ini may help in these situations, however converting large new land plugins to ESM is the preferred solution. A: 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 file. 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. Obviously the first best option to troubleshoot CTD is .Net Framework crash log...

The instructions how to properly generate LODs for Open Cities in two steps are in ..\DynDOLOD\Docs\DynDOLOD_Manual.html "Custom Settings For Specific Mods - Open Cities Skyrim" since half a decade. Current instructions are at https://dyndolod.info/Mods/Open-Cities-Skyrim https://forum.step-project.com/topic/14975-open-cities-and-dyndolod/

Generating millions of grass billboards takes time. Make sure there is as much free memory available as possible.

Rather obviously, the DynDOLOD plugins can only be build from data/plugins that exist at generation time. DynDOLOD is a modified xEdit/xLODGen. Its startup log prints which plugins are loaded at start and again when starting the LOD generation. It can not add plugins as masters to the DynDOLOD plugins that are not loaded at generation time.

Read the included manual and follow its instructions. ..\DynDOLOD\Docs\trees.ultra\DynDOLOD-Trees.html explains the ultra tree LOD in detail. Set TreeLOD=0 in the INI and set the tree mesh rule to Static LOD4. Obviously Generate static LOD needs to be checked as well. If LOD distances are short, use the DynDOLOD SkyUI MCM Settings page to increase them. Other than that, obviously pay attention to all log messages.

Obviously something else must have changed between the last time you generated LOD. For example, if you have custom mountain LOD textures installed, they are used regardless of the TreeLOD INI setting. Which means, if the generated LOD does not use the custom mountain LOD textures, then they are not installed anymore / being overwritten by other textures. Again, regardless of the TreeLOD INI setting.

Ultra tree LOD is done in object LOD. One can not work without the other. If object LOD looked and work correctly before, just setting treelod=0 shouldn't change it.

Thanks for the report and all the logs. This will be fixed in the next Alpha version.

FAILED [copy to single level] (8007000e) Check log lines above the exception for additional hints. Check the FAQ and search official forum for those errors. Searching the forum for the error find these: https://forum.step-project.com/topic/14073-error-executing-texconv-returned-error-failed-compress-8007000e/ https://forum.step-project.com/topic/14941-error-creating-textures-for-atlas-access-violation-at-address-x/ https://forum.step-project.com/topic/14998-failed-loading-dds-8007000e/

The original NIF is fine as is. It will be fixed in the next Alpha version.

Set it to 1, then generate LOD again. If it helps, I will know what to change to fix it for the next Alpha without having to edit the NIF.

Is this a problem specific to the DynDOLOD 3.0 Alpha testing? If a texture does not have transparency on the atlas, it typically means the source texture file does not have alpha or there is something wierd or not anticipated with the NiAlphaProperty of the NIF model using that texture. No information about the setup was provided, no logs etc. so nobody knows what was actually setup or done.

1. No idea without actually looking at a NIF file. 2. Probably, look at the log / command prompt window. 3. No information about memory usage was provided. 4. There is no such requirement. If there would be such a requirement it would be part of the documentation. 5. Less triangles, vertices etc. is always better for performance and resource usage.