sheson

It should still work nonetheless.

Try again with the test version https://dyndolod.info/Downloads/Test-Versions Upload new logs if problem persists. Consider installing/using DynDOLOD DLL NG and Scripts.

If issue persists, try again with the test version https://dyndolod.info/Downloads/Test-Versions. Report results and upload new logs in case there is still something not working.

Windows uses \ as path separator. Fix the command line arguments to -sse -d:"C:\Modlists\Duul\Stock Game\Data\" -o:"C:\Modlists\Duul\tools\Dyndolod\LODS\Output\" See https://dyndolod.info/Help/Command-Line-Argument Upload new logs if there is still a problem.

The DynDOLOD log shows these log lines: [45:25] DynDOLOD plugins generated successfully [45:25] Occlusion.esp completed successfully However, at the prompt where it asks "Save DynDOLOD plugins, save plugins and zip output, exit DynDOLOD without saving, check the log? If 'Check log' is selected, the DynDOLOD plugins will be saved and the log can be checked." you selected to exit without saving the plugins according to the debug log. Make sure to either save or save & zip or to check log the messages, which also saves the plugins.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs how to zip and use a file service for large log files like the debug log.

In that case (most of) the textures not matching errors are because of Additional DynDOLOD Resources was not specifically made to be compatible with Majestic Mountains. DynDOLOD typically is able to substitute the textures on the fly, so it often works out anyways. The message is for easier troubleshooting you end up with visual texture discrepancies between full and LOD model in the game. If you follow a third party modding guide like STEP, they typically verified the selected mods work OK together when following their instructions accordingly.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which entire DynDOLOD log and debug log to upload when making posts. Use search to find existing posts/threads for a message as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-Search https://dyndolod.info/Generation-Instructions Disabling plugins, mods, meshes or textures is a troubleshooting step and not a fix. Whenever you read someone suggesting to disable temporarily something is a fix, ignore them as that does not actually fix anything. https://dyndolod.info/Messages/Property-Not-Found-In-Scripts A property (variable) is defined in the reported plugin and record for a papyrus script, but its definition does not exist in the script. A plugin is setting a variable that does not exist in a script. Whatever the plugin sets is not relevant and can be removed if the script/mod/plugin works as intended. This can happen in case scripts are updated or being overwritten. It can be a sign of load order conflicts of two mods requiring different versions of a script or of a mod author not properly error checking and cleaning up after making changes. With MO2 you can quickly check if a script file has conflicts with other mods. Otherwise, the property names (caelia, caeliadress, caeliashoes for example) might help with testing if that part of the mod works as desired or come back to the messages for troubleshooting if you run into a problem with the mod and script related actions. Missing properties are also reported in the papyrus logs as "X does not have a property named Y, property skipped." In case the script property does not exist in the script anymore intentionally, remove the no longer needed entry from the script properties on the mentioned record with xEdit. Usually that would be the mod authors job, but some do not care about their mods filling papyrus logs etc. with error messages they already know not to be relevant. See https://stepmodifications.org/forum/topic/20485-property-not-found-in-scripts https://dyndolod.info/Messages/Duplicate-Reference Showing the same model twice with exactly the same properties is just wasting resources, in case of animated objects or trees it might even be visually noticeable. If you want to fix that is your choice. The page explains how. Using xEdit that way often becomes second nature when modding for a while. You can always restore a plugin from back up or the download archive. https://dyndolod.info/Messages/Reference-Attached-to-Wrong-Cell That would be good to fix to address visual issues, especially if you notice issue with the reported references in the game. While running the xEdit script on plugins to fix it is trivial, it would be best if the mod author addresses it. https://dyndolod.info/Messages/Potentially-Wild-Edit-Reference In case the reported reference is not a wild edit but its position is intentional, make a post about it on the official DynDOLOD support forum. Thanks for reporting. The references in NightmarePlane.esp are not wild edits and the next alpha version will not report them anymore. Do not disable the plugin when generating LODs, since it is obviously wrong to disable a plugin just to avoid seeing a warning message about something being potentially a wild edit. It would also be wrong in case they were wild edits as disabling a plugin does not remove the wild edits either as explained. https://dyndolod.info/Messages/Textures-Do-Not-Match If and only if there are obvious differences of the textures between full models and LOD models, the log messages can aid in quickly finding the reason. It seems likely you are using ERM which changes a lot of those full models to use different textures. Use https://www.nexusmods.com/skyrimspecialedition/mods/88754. See https://stepmodifications.org/forum/topic/20475-textures-do-not-match. If mountain LODs for LOD level 4 look fine in game, nothing needs to be done. https://dyndolod.info/Messages/Filename-Does-Not-Adhere-To-File-Naming-Conventions Typically the filename of normal map textures ends in *_n.dds. You have RW2 installed that replaces the reported NIF files. Checking the mentioned texture RWTCalmWater.dds in an image viewer shows us that is it is a normal map texture. Either the mod author made a typo when naming the file or does not care about file naming conventions. You could rename the texture and edit the couple NIFs with NifSkope if you do want to see the warning.

It seems that mod (and probably others as well) are just setting the initially disabled flag for things they most likely meant to disable permanently. Well, at least that explains the higher number of dynamic LOD references in that area than usual. The point is, it is not setting or rule accidently causing this. Probably could save quite a few persistent dynamic LOD references (and less work generating and for the DLL in game) if those plugins would use the decade old UDR standards (z=-30000, enable parent opposite player) but fixing that would be more work than converting a couple large ESP plugins to ESM. So if thinks work fine now don't worry about it for now.

I uploaded a new test version that hopefully should run through.

This applies to LOD model using LOD textures that end with *lod.dds For LOD models that define full textures, just copy/paste the shader and textures from the full model and leave as is. LODGen typically adjusts the shader flags in the BTOs to what the LOD shader supports. Glow shaders work as is, but windows should be separate glow_lod models so they can be done as dynamic LOD if the reference sets external emission XEMI records while the rest of the building is done as object LOD. Check existing glow_lod models. The glow windows are often moved to so they are a bit outside the walls so they do not z-fight with the LOD model. Shapes requiring cubemaps usually end up using rendered LOD textures that TexGen generates from special NIFs.

Get the test version from https://mega.nz/folder/JdpU1KZB#cYTSPK6NW2CSbGrvQ-w_6A. If the issue persists, upload new logs and DynDOLOD.esm. A somewhat quicker test run with just Tamriel, object LOD, standard tree LOD and dynamic LOD would be enough.

If the error message does not show anymore it means something changed in the load order or plugin. The logs from the last run with the error should have been already in the log folder. While the debug log is now replaced, the normal log should still contain the complete error message. Plugins loading fine is just a troubleshooting step. Checking all worldspace records and their immediate children would have been the next. Tools or game are not crashing or throwing does not mean there isn't/wasn't a problem. This error used to put xEdit into an infinite loop when accessing the records.

That seems like too many references are having dynamic LOD, something seems off. As a random check, can you look up 0x00059D42 in xEdit to see if it is being overwritten by any other plugin? If not, just report that, otherwise name the plugin.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen log and debug log to upload when making posts. Use the Copy this message to clipboard link of the message to paste the entire message text as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text There is a problem between a worldspace record and its children records in the plugin the full error messages should mention. The issue might be obvious when checking things in xEdit (if it is able to load the plugin). If you need help with that, upload the plugin.