sheson

Read the first post what log and debug log when making posts. If you have problems with or questions about third party guides, you should ask on its appropriate forum. Suspended stacks are the victim of papyrus / scripts / performance problems. Changing settings in the DynDOLOD INI is not required for the default LOD generation. They only need to be changed in case the users follows 1st party or 3rd party mod or guide instructions. https://dyndolod.info/How-LOD-Works Typically object LOD does not have a LOD level 32 - it can only be shown on the map. https://dyndolod.info/Mods/Maps-And-Map-Mods LOD Level 32 object LOD meshes typically do not exist in a vanilla game, so by default DynDOLOD generates object LOD meshes for LOD level 4, 8 and 16. Which means, if a map mod contains LOD level 32 object LOD meshes, there is no conflict with default TexGen output or default DynDOLOD output. See Ultra Tree LOD - Trees on the Map how to generate object LOD level 32. In the case that DynDOLOD is used to generate object LOD level 32 files specifically, they should overwrite the map mod files. https://dyndolod.info/Help/Ultra-Tree-LOD#Trees-on-the-Map To generate LOD level 32 object LOD, set Level32=1 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini From DynDOLOD_SSE.ini ; set to 1 to generate LOD Level 32 *.bto files (indentical to LOD Level 16 but without billboard trees when generating with TreeLOD=0) ; set [MapMenu] uLockedObjectMapLOD=32 in Skyrim.ini Level32=0 From the description of A Clear Map of Skyrim and Other Worlds This feature requires using the latest DynDOLOD 3 alpha and setting Level32=1 in \Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini. When you installed the mod, you specifically selected the option "With DynDOLOD LOD32", which sets the game to uLockedObjectMapLOD=32. The FOMOD installer shows these explanations for the option: Installs INI file with object LOD pointing toward LOD32. This is for users who use DynDOLOD Level32=1. You MUST follow the instructions on the mod page for this to work correctly! Failure to do so will cause LOD to be rendered incorrectly. DO NOT USE THIS UNLESS YOU KNOW WHAT YOU ARE DOING. From the description of A Clear Map of Skyrim and Other Worlds DynDOLOD Instructions (optional but highly recommended) 1. Navigate to the \Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini file in your DynDOLOD install and set Expert=1 and Level32=1. Setting uLockedObjectMapLOD=32 without generating object LOD level 32 files means there will be only terrain LOD shown on the map. From DynDOLOD_SSE.ini: ; set the double_sided shader flag in object LOD *.bto meshes on these lists of meshes / textures masks (partial filename) for mods like Dynamic Volumetric Lighting and Sun Shadows ;DoubleSidedTextureMask=mountain,mtn If you go to the mod Dynamic Volumetric Lighting and Sun Shadows on Nexus you will see it has been replaced by Enhanced Volumetric Lighting and Shadows (EVLaS). From its description: Or (highly recommended) generate a load order specific terrain underside using DynDOLOD 3.0 or newer https://dyndolod.info/Help/Terrain-Underside In addition consider to uncomment (remove the ; ) DoubleSidedTextureMask=mountain,mtn in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini, so that the object LOD for mountains (the rocks) blocks sun rays as well.

Read the first post which log and debug log to upload when making posts. Really read the entire page when doing things. You most likely set WorkaroundLargeReferencesBugs=1 and ignored the requirements to install papyrus scripts version 3 for the experimental workarounds https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Requirements

For people having a https://xkcd.com/979/ moment: ..DynDOLOD/Docs/DynDOLOD_Manual.html Configuration files and settings use the game mode as identifier. It is TES5 for Skyrim, SSE for both Skyrim Special Edition and Skyrim VR, ENDERAL for any Enderal version. Throughout the documentation substitute the 'x' like in xEdit.exe or the [GAMEMODE] like in 'DynDOLOD_[GAMEMODE].ini' with the current game mode. https://dyndolod.info/Help/Game-Mode The term [GAME MODE] if used like DynDOLOD_[GAME MODE].ini means DynDOLOD_TES5.ini or DynDOLOD_SSE.ini for example. In both the offline and online version of the manual the term [GAME MODE] can be hovered or clicked for more information. Windows also hides file extension by default. Enabling to show them should be one of the first steps after OS installation or any modding guide to be honest.

Moved to the DynDOLOD 3 Alpha thread. Read the first post. Upload the the log and debug as explained in the first post. What mod? LOD is only generated for references that actually exist and for which a LOD asset exists. https://dyndolod.info/Help/Tree-LOD Tree LOD is generated if a tree LOD billboard is found for a tree in the load order. In this context trees are references that use base records of the types 'TREE' and 'STAT' with the 'Has Tree LOD' flag set. By default there is no LOD model shipping for tundrascrub01.nif and TexGen does not generate a billboard for it. Do not install any 3rd party billboards. https://dyndolod.info/Help/Tree-Grass-LOD-Billboards#3rd-Party-LOD-Billboards Do not force TexGen to generate billboard generation for things if you do not want LOD for it. Mesh mask rules order matters. Move them to the top to make sure they apply. https://dyndolod.info/Help/Mesh-Mask-Reference-Rules

The vertex alpha flag itself should be irrelevant for LOD models as it is typically removed in the BTOs - any actual vertex alpha would be transparency with a threshold of 128. The high/low vertex color alpha value for the snow LOD shader should still exist and make it into the BTO unchanged. The update is to make sure that these remaining vanilla LOD models have the same BSTriShape names as the full models so the base record texture replacements can be correctly applied. The updated LOD models should now have the exact same BSShader / BSTexture settings as the full model.

DynDOLOD makes use of texconv.exe (which the list of all processes in the task manager would show) and also uses the GPU while working on textures. https://dyndolod.info/FAQ "Long running time or output several GB in file size" Crapware installed with graphics drivers is known to prolong running times. https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-103/page/187/#comment-254612 Also, the larger the resolution of full textures the longer things take.

Use the latest xLODGen terrain LOD beta version. The screenshots do not provide the information what version is being used. The logfile would. Make sure xLODGen uses the correct data path. The screenshots do not provide the information which paths are used. The logflle would. The filename needs to match the EditorID of the last overwrite. The EditorID is truncated in the screenshot. Give the worldspace a Name. It is unclear if the plugin adding that worldspace is being loaded. The screenshots do not provide that information.

You are loading the Low preset, which has a rule for \rockl setting None for all LOD levels. Remove that rule or move any custom for rockl04.nif above it so it can take effect. https://dyndolod.info/Help/Mesh-Mask-Reference-Rules Pay attention to the log messages, for example clean all plugin containing deleted references, the log messages about duplicate references seems to indicate that single plugins that have been merged are still active.

The majority of cells contain one reference Tamriel_worshipper* that should not cause anything. You need to narrow down the problem to specific cells in order for us to see what kind of (overwrite) records might cause the issue.

Since the DynDOLOD.esp has the DynDOLOD.esm as master it will typically no load without it. If the problem happens only with the DynDOLOD.esm, then it is pretty straight forward now, as there are not that many records in the persistent cell D74 but mostly a single references (Tamriel_Worshopper*) in the temporary cells. Those are for dynamic LOD, so they do not really do anything with the DynDOLOD.esp. So the binary search goes like this: Restore backup of plugin if problem goes away, continue removing "half" the records from plugin that has the problem until only a specific record remains. First remove all other worldspaces. Then remove the persistent cell D74 in the Tamriel worldspace. Then start removing half the blocks until you are down to a block, then same for sub-blocks, then same for the cells in the last remaining sub-block.

You are testing with a new game, right? coc whiterun from main menu console can be sufficient. Checking the papyrus log shows no stack dumps, however (in addition to the appalling lack of mod authors not QAing their mods/scripts) you want to look at the hundreds of "cannot fetch variable named * of type int, returning 0." There might be something amiss with the animation setup. If deactivating dynamic LOD and hiding object LOD does not change anything, then it narrows it down pretty much to records being copied/overwritten from other rmods maybe. Test what happens if you hide the SKSE folder (ignore any error messages about not being able to find things). It is just to double check without dynamic LOD. If that does not change anything, see what happens without DynDOLOD.esp, only DynDOLOD.esm. If there is not change see what happens without any plugins. Depending on which plugin makes a difference, the next step would be to remove records from DynDOLOD.esp in a binary search. Typically only worldspaces/cells/references but never references with the Editor ID Tamriel_Firstborn* or Tamriel_Minion*, as explained here https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-103/page/314/#comment-260724. I would start with removing overwritten references in the persistent cell D74.

Those are the files at the path I mentioned. You might start hiding all BTO for the first test. If there is a difference, hide the files of one LOD level at at time to start narrowing it down. Then continue in a binary search. LOD 4 will contain the grass and ultra tree LOD. So if there is a change there, generate LOD without one or both options to compare, though the billboard4 tree LOD should not really be a problem in itself. If those files make a difference that can not be really pinpointed to a group/single file, shrink the texture atlas Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds for a test. Clean every plugin that has deleted references. https://dyndolod.info/Generation-Instructions#Prerequisites

You did not upload the DynDOLOD log and debug log. It is odd that the memory has a flat max limit like this. You should investigate if the graph to show 0 to 100% usage or whatever else. Check the papyrus log for stack dumps. Check if there is any change deactivating dynamic LOD from the DynDOLOD MCM - it will enable again when crossing cell borders. Test if there is a change if hiding all object LOD Level 32, 16, 8, 4 files respectively. Meshes\terrain\Tamriel\Object\Tamriel.X.*.*.bto where X is 32, 16, 8 or 4.

Moved to the DynDOLOD 3 Alpha thread. Read the first post. Post/upload logs and debug logs as explained on the first post. DynDOLOD 3 is ALPHA. This is an ALPHA test. It seems the setup might be overmodded and could be exhausting resources. The memory and RAM usage graphs at https://imgur.com/rhWKbX6 hitting the top, seems odd. Check draw calls with ENB.

From the first post: xLODGen beta 95 - based on 4.1.4b Unzip into a dedicated folder outside of any Steam, game or mod manager folders or special Windows folders like Program Files. You will notice it says nothing about unzipping or overwriting into any existing xEdit folders. When you open the archive, you will notice that the archive starts with its own xLODGen folder already. There is no reason to invent steps or complicate anything. Simply unpack into its own folder and start it with -fnv -o:"c:\OutputPath\" command line arguments.

Read the first post which log and debug log to upload when making posts. Read the explanations for log messages, like https://dyndolod.info/Messages/File-Not-Found-Scripts The compiled script is missing from the vanilla game files. dlc1testphilvortextrigscript.psc is part of the Scripts.zip that installs with CK, so you can compile it. Just install the Unofficial Skyrim Special Edition patch which fixes thousands of errors and bugs and also contains the compiled script.

Use x64 version.

Thanks. Will be included in next version.

Read the first post how to upload the debug log to a file service. I assume you need help with the CTD in the game? Have you tested without DynDOLOD in the load order? DynDOLOD.esp is not even the last in the load order. For example, water seam fixes and other patches should be done before generating LOD. E.g. finalize the load order before generating LOD. This seems like a problem with the quest TESQuest(Name: ACFWhiterunVampires `Vampires of Whiterun Hold`, FormId: E6000BEE, File: `AI_Merge.esp`) and the BGSLocation(Name: `Broken Fang Cave`, FormId: 0001914D, File: `Skyrim.esm`) Check with xEdit if the quest E6000BEE in AI_Merge.esp accesses/links the location 0001914D. If not, go through the list of the listed TESObjectREFR, so if one of the links to 0001914D. Typically the listed references in the DynDOLOD.esp do not link to locations.

Moved to the DynDOLOD 3 Alpha thread. Read the first post. Do not paste screenshots of messages, use the "Copy message to clipboard" link and post the text instead. The message "Found Plocktons Culling Glitch Fix.esp" also already explains the reason and solution: "DynDOLOD replaces it. Remove it permanently from the from load order. Click the help link to open further instructions:" As explained in the message and on the first post, click the "Click on this link for additional explanations and help for this message" to open further explanations. https://dyndolod.info/Help/Occlusion-Data You can see that DynDOLOD has the option to generate the occlusion data while generating LOD, so plugins "fixing" it by removing the data need to be permanently removed. Installing/Enabling/Disabling/Removing mods/plugins is handled by the mod manager. For example https://stepmodifications.org/wiki/Guide:Mod_Organizer Best to learn modding with a mod manager before using tools like DynDOLOD and participating in the DynDOLOD 3 Alpha test.

By default DynDOLOD 2/3 generate plugins with version 2.45, hence they use the same version of scripts 2.8x since years. They are the first download link on the Nexus page. https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Requirements This will generate DynDOLOD plugins and data files with the version 3.0 instead of version 2.45. That means updated papyrus scripts are required. https://dyndolod.info/Help/Mod-Configuration-Menu#Large-References-Fix If the large reference system is used (uLargeRefLODGridSize > uGridsToLoad), the Large Reference Fix checkbox should be checked, so that dynamic LOD objects for large references in the FarGrid switch correctly.

On the contrary, things are not thrown all over the place and the website is as modern as it gets. https://mother****ingwebsite.com There is exactly one page that explains everything about the experimental workarounds: https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds. The requirements with the links are already there and fully explained. Nothing else is needed for the current experimental state of the workarounds. DynDOLOD 3 is an ALPHA version to ALPHA test and find problems. https://dyndolod.info This website and DynDOLOD 3 are currently an ALPHA version to test things and iron out bugs. Certain things may be incomplete, not work as expected or change considerably between versions. The experimental workarounds are obviously for experienced users already participating in the ALPHA test. The experimental scripts are not shown on Nexus deliberately for the time being, because Nexus users would just mindlessly download them because they are newer and thus there would be thousands of posts about the scripts being the wrong version since those users would not know about and also should not test the experimental workarounds.

The papyrus scripts are independent of the runtime version. There is one version for DynDOLOD 2/3 generating DynDOLOD plugins of version 2.45 and one version for DynDOLOD plugins version 3.00 for the large reference workarounds. As I already explained, all runtimes / DLLs use the same scripts, that is why the sentence says to "always download the DynDOLOD DLL [SE/VR] - Scripts archive"

If WorkaroundLargeReferencesBugs=1 is used, install the DynDOLOD DLL SE - Scripts 3 as linked from the requirements. https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Requirements

None of the files from DynDOLOD contain the text "wrong script error", so it is unclear if that is the actual message or where it comes from. The papyrus scripts are independent of the runtime version. There is one version for DynDOLOD 2/3 generating DynDOLOD plugins of version 2.45 and one version for DynDOLOD plugins version 3.00 for the large reference workarounds. Provide an actual proper error report. Refer to the DynDOLOD 3 Alpha thread.