sheson

Upload the log and debug log as explained at https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs As explained at https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages, click on the "Click on this link for additional explanations and help for this message" to open https://dyndolod.info/Messages/INI-Files for further help and explanations about the message. What are the command line arguments that TexGen is started with? Typically xEdit/xLODGen/TexGen/DynDOLOD do not look for game INI files in their own folders. Creating folders and copying INI files - or doing anything else weird that is not part of the documentation - is a strong hint that something is going wrong that should not be going wrong. The cause should be fixed and not worked around.

You set uLockedObjectMapLOD=8. Which means the map is not using object LOD Level 32. https://dyndolod.info/Help/Ultra-Tree-LOD#Trees-on-the-Map explains to set uLockedObjectMapLOD=32.

Read the first post which log and debug log to upload when making posts. As explained in the first post, click on "Click on this link for additional explanations and help for this message" if an error prompt and read what the error means and suggestions how to fix it. https://dyndolod.info/Messages https://dyndolod.info/Generation-Instructions#Prerequisites Finalize the load order. Install mods and their requirements. Sort and resolve conflict. ... 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. Ignore wrong 3rd party advice to temporarily disable plugins, mods, meshes or textures. Such advice is categorically wrong or outdated. In case of issues, solve the cause or use appropriate rules or settings for desired results. Errors in the patches need to be fixed (for example the patch needs to be generated for the current load order) instead of being ignored.

Read the first post which log and debug log and bugreport.txt (if it exists) to upload

Some of it looks like z-fighting between object LOD and object LOD or maybe terrain LOD. Are the trees affected or not? If there is ultra tree LOD set standard tree LOD to zero. Some of it looks like almost like there is something going on with the snow LOD shaders. https://dyndolod.info/Help/Snow-Ash-LOD-Shader, check what overwrites those records. Test without DynDOLOD plugins to make sure it has nothing to do with dynamic LOD and this the large ref workarounds. Large ref workarounds can only work in the uLargeRefLODGridSize. Test with default INIs. Make sure no custom INI or [plugin].ini in data folder either. Test without the water (falls) mod that has controller blocks in LOD models (the block itself is not causing the issue as it is ignored, but it means somebody made bad static object LOD models). Which version of Water for ENB is it? https://dyndolod.info/Mods/Waterfalls (meshes in DynDOLOD Resources for these mods have the full model CRC32 in their filename) Do you use other full models for LOD. Especially ones with BSEffectShaderProperty. Some shader settings/flags can cause wierd effects. The last few seconds of the video shows switch between LOD levels.

Now what are the actual questions in addition to the explanations from https://dyndolod.info/Messages/Property-Not-Found-In-Scripts or https://dyndolod.info/Messages/File-Not-Found-Meshes? Install the latest version of mods. For example it looks like Serana Dialog add on just had an update today. Maybe the missing property was fixed in case it was an actual problem. In case of Pilgrim checking the https://www.nexusmods.com/skyrimspecialedition/mods/54099?tab=bugs it seems that the 2 meshes are not used. You checked if all BTOs are valid? I am pretty sure they would cause CTD in game in case that error goes through unnoticed. That tree is not used that often, so check where it is positioned to find the filename for the bto to see if it opens in NifSkope without error. What makes debugging this not take some time is that it takes ages to let it do the reuv to see what is happening.

Read the first post which log and debug log to upload when making posts. See https://dyndolod.info/Messages and/or https://dyndolod.info/Help/Summary-Of-Messages for explanations about messages, their severeness and possible (often optional) solutions (obviously only brief/generic and non exhaustive ). If further help is required ask specific questions and provide the log/debug log files.

It reported this in the log [00:04] <Error: File not found textures\DLC03\Architecture\PierShacksSiding03TwoWideRed_s.dds. Used by textures\DLC03\Architecture\PierShacksSiding03TwoWideRed_d.dds> The textures were copied fine to the new _s name, it just didn't look for them in the temp location, only in data. I also made it so that temp textures use uncompressed formats so texconv doesn't complain about multiple of 4 This version should do the trick https://mega.nz/file/dAp1CDLS#tf55DHqIv8p6N5pjilTyVtY9fqbyk7UDtZ5a7O--3E4 See https://dyndolod.info/Changelog to see what changed between versions. >I'm not sure if something has changed You are changing settings. This is what changes. In your last post you said you set uLockedObjectMapLOD=8. Which means the map is obviously not using object LOD Level 32. https://dyndolod.info/Help/Ultra-Tree-LOD#Trees-on-the-Map

The NIF is fine, it just that something falls apart when it tries to re-uv the trunk.

The reason the first post does not say anything about posting screenshots of the the tools/settings because the debug log includes the settings. This thread is for testing and reporting about DynDOLOD 3 Alpha. No reason to post about xLODGen terrain LOD here. Nothing changed how DynDOLOD Alpha 99 generates LOD in comparison to the versions before. Read the changelog https://dyndolod.info/Changelog If something drastically changed/broke in DynDOLOD causing visual issues like in the video, people would already have posted about this. Changing resolutions in DynDOLOD does not change how the game works - loads/unloads LOD. Read "Object LOD shows in active exterior cells" at https://dyndolod.info/FAQ, It was already suggested to check the INIs for the uLockedObjectMapLOD setting.

Read https://dyndolod.info/Help/Seasons#Grass-and-Grass-LOD and https://dyndolod.info/Help/Grass-LOD#No-Grass-LOD-Check-List There should 5 sets of grass cache, the default cache and the cache files for the 4 seasons.

So far I have isolated it to this model jbtreepineforest05.nif - that's the first that triggered the exception anyways. The NIF is fine, it just that something falls apart when it tries to re-uv the trunk. That thing is way too complex for that (more triangle than the leafs) but not enough to be skipped. Still should not have any exception. It may not always CTD. In that case it might produce broken BTO. For general LOD generation I strongly recommend optimized 3D tree LOD models... just saying.

Yes, but it most likely will only produce a diffuse and normal and not the specular textures. I will add that to the next version. 0 1 1 1 textures\input.dds r 270 0 0 DynDOLOD-temp\textures\outputrotated.dds 1 1 270 is the angle, use between 0 and 360 Then use the output as input for the stitched ... 0 1 1 1 DynDOLOD-temp\textures\outputrotated.dds 0.5 0.25 0 0.75 textures\awesome_lod.dds 1 1 ... Edit: Use this test version which should also do _s.dds https://mega.nz/file/xNwUUDBT#EQhIRLCeUtbbQtDhLQDdzmzQEaPYyRw-82EAE9m23Ac

Read https://dyndolod.info/Changelog to see what changed between versions. There is no change how object LOD meshes and textures are generated. You determined that this is a problem with with a save file that has nothing to do with the DynDOLOD plugins. If I remember correctly you reported that the game shows object LOD fine with a new game or without other mods. The object LOD meshes and textures do not affect save files. They are just models the game engine loads at specific positions based on INI settings. LOD generation does not care about save files or the INI settings. I would would narrow done involved mods/plugins, check INI settings, check papyrus logs and maybe look into the save. All without any DynDOLOD/Occlusion plugins, since you reported they are irrelevant and narrowing down mods/plugins is about only keep the stuff in the load order that contributes to the problem.

I get the same crash with the your files so I am able to debug this next days and see whats up. Also have 8GB peak, that nothing. At the time of crash it's 3GB.

Oh boy "tree" full for LOD4. This going to take a while ... Any indication how much memory the LODGen process peaks at when you run that with grass LOD as well?

Thanks for this. This constellation should properly try to fix in both (all) affected cells in the next versions. The moved large reference check did not see did see this as moved because the master record and the last overwrite both have the same position.

Clean all plugins that contain deleted references. 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. Clean every plugin that LOOT suggests to clean - ignore misinformation that cleaning any plugins is not needed or causes problems. The Batch Plugin Cleaner for Mod Organizer or the xEdit Cleaning Extension for Vortex help to automate some of that. https://dyndolod.info/Messages/Deleted-Reference That should fix that issue.

Bring up the reference 000DDD36 in xEdit and check the last plugin / column to the right. There might be something going on with the EditorID having weird characters. Let me know what you find.

As explained, always test with a new game. If something doesn't work with a save game, then there is a problem or setting baked into the save game that is out of the control of DynDOLOD. LOD meshes and textures do not care about save games and are not part of the save game data. The game simple loads and displays them. LOD generation does not care save games. The clean save is about data from plugins and scripts. If the game is started without the plugins, then most of the data for those plugins and scripts from the save is discarded already, .e.g a clean save. The data is all about the position of dynamic LOD references. The orphaned scripts can be cleaned with a tool. To also remove data form the SKSE co-save you would need to start without PapyrusUtil once (or delete the co-save for test), but that will also remove co-save data for other plugins. DynDOLOD does not load save games. Unless further specified or explained what the problems are, save game issues have to do with INI settings and the entire load order. For example unfixed issue and errors in plugins. You can not add and remove plugins all the time. DynDOLOD is pretty safe because it is pretty much self contained. The worse that can happen is that a full model does not show anymore because its disable state got baked in the save. DynDOLOD does not change or affects whatever the last screenshot shows, which looks like a textures problem of the cloud cover of the map. If things work with a new game, then the object LOD meshes and texture work as expected. The meshes and textures are most likely not the problem, since they can not really affect a save game. Though I would do a binary search to see if it can be narrowed down to single BTO. I am not going to suggest any more concrete troubleshooting steps, since things work with a new save and you seem not to be able to just do them and report back to determine the next step.

That should still not be posisble to cause that error in .net with things randomly become undefined though. I would be interested in the grass cache files for the worldspace and the all files with the worldspace name in the filename from the..\DynDOLOD\Edit Scripts\Export\ folder and also LODGen_SSE_FlatTextures.txt and LODGen_SSE_Grass_Map_Tamriel.txt so I might be able to debug this properly in LODGen. At least a better error message should come out of this.

@DoubleYou Add FO4 support for TexGen stitched object LOD textures. Start with -FO4. Let me know in case there are any issues. If you have updated config files to update vanilla textures I'd happily include them.

The fact that there is no disciple explains why the large references bugs still happen, the cell is not detected as having any bugs. Why exactly, I am not sure without redoing the changes you did, if you still have the changed plugin, you could upload them so I might have a look in the next days. On the other hand, if it is a typical constellation of things with "normal" mods/plugins we will come across similar cases anyways I suppose. Do not kill yourself checking every report cell, do it other way around. Just play the game (yeah right) and whenever you notice large ref bugs, check if the cell coordinates were reported. I am pretty confident that the reported cells will look fine. What also needs testing is that the scripted workaround do not cause script problems with larger load orders or persistent large references (HearthFires houses for example) to vanish (be disabled when they shouldn't).

Can you check if cell -38,2 in DynDOLOD.esm has 2 references, one called Tamriel_Worshipper_%38_2 and the other Tamriel_Disciple_%38_2? It seems you did something to the large reference 000DDD35 that is moved by Updates.esm from -39,2 to -38,2? I believe the issue in -20,1 is because there is still a duplicate non large reference in RedBag's Rorikstead.esp with xx0012D8 and thus its non large ref LOD shows. I need to check and fix why that duplicate is not detected and ignored for LOD. It is not reported because the records xxxxx800 and xx0012D8 are not equal, while the model, position, rotation is. So you will need to address in your edited plugins.

Upload ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_aaChanterelle2.txt so I can compare it to mine here I did with a vanilla game + mod only which worked so far. Could you test if not not unpacking the BSA and hiding the loose files makes a difference? You would need to do a normal generation for that worldspace so the list of BSA files is updated for LODGen or manually add these lines under the existing ones to the file mentioned above: Resource=D:\Games\Steam\steamapps\common\Skyrim Special Edition\Data\Chanterelle World - Textures.bsa Resource=D:\Games\Steam\steamapps\common\Skyrim Special Edition\Data\Chanterelle World.bsa Resource=D:\Games\Steam\steamapps\common\Skyrim Special Edition\Data\Chanterelle World0 - Textures.bsa