DynDOLOD 3.00 Alpha 196

[Gamma_Metroid]

6 hours ago, sheson said:

It seems the EditorID of the replacement texture ends in _

So stonewall01_LSC_ + _lod_0.nif -> stonewall01_LSC__lod_0.nif with two _

Upload new logs, including DynDOLOD_SSE_Object_LOD.txt if it still does not match.

Ah, I see. Now it does seem to find the new lod model, but it still uses the original one. I am not sure why

Logs: https://limewire.com/d/RRClY#aYm34xuOXw

[Gamma_Metroid]

Ok, I deleted the existing LOD model assignments in the plugin, and DynDOLOD successfully assigned the new model correctly. I thought it should have replaced what was already there, since I didn't have "Prefer Base Record LOD Assignments over Rules" enabled.

[sheson]

1 hour ago, Gamma_Metroid said:

Ok, I deleted the existing LOD model assignments in the plugin, and DynDOLOD successfully assigned the new model correctly. I thought it should have replaced what was already there, since I didn't have "Prefer Base Record LOD Assignments over Rules" enabled.

Yes, I was just going to write that it does that. It prefers the original assignment because the base record has a texture replacement and the LOD model does not have any full textures or stitched LOD textures. The assumption in this a case is, that typically the base record assigns a better LOD model with a better matching *lod.dds texture. That code is just not aware that the LOD model filename contains the editor of the texture replacement method - since this case was not needed/reported yet.

Let me know if this is a problem that needs addressing, though I'd would argue if the base record assigns a LOD model as well, then it should be the updated one anyways for CK/xLODGen

[Gamma_Metroid]

Fair enough! I think you're right, that is a good assumption to make in that case. Good to know.

[solcosine3]

Hi, I was wondering if something like this has ever been reported before (and if so, what the solution was)?

https://imgur.com/WZFbaH3

I am using Freak's Floral Fields and most cells do not have an issue. However, in some areas near the Tundra the grass lod is bleeding into neighboring cells, causing it to remain loaded inappropriately when those cells are active.

I'm really hoping this is a Dyndolod problem because the NGIO author does not seem to know the answer.

Logs here. There is no bugreport.txt.

[mostwanted11]

My dlc2 ice has vanilla lods even though I'm using icymesh fixes which repaths those models' lods to custom made lods that normally work with vanilla glaciers but for some reason they get ignored by dyndolod for solstheim. (Attached a picture below of whats happening in the record)

https://imgbox.com/gallery/edit/r905ZwQHLC/SyRCjEe4ztIvJZfY

https://limewire.com/d/R6tQw#5Cqwz1Cosf

Sorry, my dyndolod_log got refreshed but I managed to save the debug_log safely

[sheson]

1 hour ago, solcosine3 said:

Hi, I was wondering if something like this has ever been reported before (and if so, what the solution was)?

https://imgur.com/WZFbaH3

I am using Freak's Floral Fields and most cells do not have an issue. However, in some areas near the Tundra the grass lod is bleeding into neighboring cells, causing it to remain loaded inappropriately when those cells are active.

I'm really hoping this is a Dyndolod problem because the NGIO author does not seem to know the answer.

Logs here. There is no bugreport.txt.

This looks like there may be out of cell data in a grass cache file. Maybe it is related to float 32 to float 16 or vice versa conversion.

Upload the BTO and all grass cache file of the cells that the BTO covers, i.e. its filename coordinates and +1, +2, +3 in each direction.

Set Expert=1 and Verbose=1 in S:\NGVO V6\tools\DynDOLOD newest\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini. In the expert mode set the specific chunk drop down to 4 and the W and S drop down to the coordinates of the BTO file. Then click the Execute LODGen button. See https://dyndolod.info/Help/Expert-Mode

Then also upload the S:\NGVO V6\tools\DynDOLOD newest\Logs\LODGen_SSE_Tamriel_log.txt

[sheson]

7 minutes ago, mostwanted11 said:

My dlc2 ice has vanilla lods even though I'm using icymesh fixes which repaths those models' lods to custom made lods that normally work with vanilla glaciers but for some reason they get ignored by dyndolod for solstheim. (Attached a picture below of whats happening in the record)

https://imgbox.com/gallery/edit/r905ZwQHLC/SyRCjEe4ztIvJZfY

https://limewire.com/d/R6tQw#5Cqwz1Cosf

Sorry, my dyndolod_log got refreshed but I managed to save the debug_log safely

DynDOLOD uses full model filenames to match LOD model filenames. See https://dyndolod.info/Mod-Authors#How-to-add-your-own-object-LOD-models

If the full model is dlc2iceberglarge.nif, then it uses dlc2iceberglarge_lod_[0|1|2].nif etc.

If you want to use iceberglarge_lod_[0|1|2].nif for LOD, the full model should be iceberglarge.nif

[solcosine3]

59 minutes ago, sheson said:

This looks like there may be out of cell data in a grass cache file. Maybe it is related to float 32 to float 16 or vice versa conversion.

Upload the BTO and all grass cache file of the cells that the BTO covers, i.e. its filename coordinates and +1, +2, +3 in each direction.

Set Expert=1 and Verbose=1 in S:\NGVO V6\tools\DynDOLOD newest\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini. In the expert mode set the specific chunk drop down to 4 and the W and S drop down to the coordinates of the BTO file. Then click the Execute LODGen button. See https://dyndolod.info/Help/Expert-Mode

Then also upload the S:\NGVO V6\tools\DynDOLOD newest\Logs\LODGen_SSE_Tamriel_log.txt

Thank you for the fast reply! All requested files (hopefully) here.

One more thing I thought I should add is that I feel there is very little randomness. The issues are always in the same cells, and it happens every time I generate grass cache and lod, without exception. I can't say every individual grass is in the same spot every time, but certain ones definitely are. In some cases I even hand-placed pillars and trees to hide the floating ones.

Again, thank you so much for your time and help.

Edited December 31, 2025 by solcosine3

[sheson]

17 hours ago, solcosine3 said:

Thank you for the fast reply! All requested files (hopefully) here.

One more thing I thought I should add is that I feel there is very little randomness. The issues are always in the same cells, and it happens every time I generate grass cache and lod, without exception. I can't say every individual grass is in the same spot every time, but certain ones definitely are. In some cases I even hand-placed pillars and trees to hide the floating ones.

Again, thank you so much for your time and help.

You can see in the LODGen_SSE_Tamriel_log.txt that it reports lots of lines like
pos 6272, 2126, -5528 outside cell 0, 0 center 3145.304, 3055, -5792 0,0
In this case it means that Tamrielx0000y0000.cgid also contains grass positions that are actually in cell 1,0

You can test it by only keeping one cgid file - for example the Tamrielx0000y0000.cgid you uploaded. Then make sure that NGIO INI is set to not generate grass cache files on demand with Only-load-from-cache = true and DynDOLOD-Grass-Mode=1 etc. Then cow tamriel -2,0 disable LOD with tll, and use tfc to fly to cell 0,0 and 1,0:

So, the issue exists in the cgid files. Assuming NGIO still uses the unchanged native routines in the game code to generate grass, the first thing to check would be the object bounds of the involved grass records.

[Spike2112]

Hi Sheson, Happy New Year. I have only one error so far. This is what I got. 

Warning: File not found textures\creationclub\bgssse002\clutter\notesoulstealer01_large_n.dds. Used by DBM_CC_ACArcaneArcherHOWPatch.esp DBM_CC_ACArrowDiagramTexture [TXST:FE0F0801]

I am not an expert at this, but I copied the bsa out and looked at it and I only see the file extension _d.dds not _n.dds. I asked at the Lotd CC Patch Hub website and was attacked for asking the question.

Is there anything I can do about this? I use MO2 and the latest version of everything.

[sheson]

1 hour ago, Spike2112 said:

Hi Sheson, Happy New Year. I have only one error so far. This is what I got. 

Warning: File not found textures\creationclub\bgssse002\clutter\notesoulstealer01_large_n.dds. Used by DBM_CC_ACArcaneArcherHOWPatch.esp DBM_CC_ACArrowDiagramTexture [TXST:FE0F0801]

I am not an expert at this, but I copied the bsa out and looked at it and I only see the file extension _d.dds not _n.dds. I asked at the Lotd CC Patch Hub website and was attacked for asking the question.

Is there anything I can do about this? I use MO2 and the latest version of everything.

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.

See https://dyndolod.info/Messages/File-Not-Found-Textures about this warning.

Looks like someone forgot to make that normal map texture after creating the texture set record. If you simply want to address the warning, you could remove the normal map entry from the record or replace it with textures\default_n.dds with xEdit for example.

The notesoulstealer01_large_d.dds diffuse seems to be based on textures\clutter\books\largenote01.dds, so a "correct" solution would be to to create the normal map based on textures\clutter\books\largenote01_n.dds. The size of note changed a bit, looks like it was scaled in the x direction, so that involves a bit of work.

You can also just ignore the message, you are not going to notice/care that the note might look a bit flat if you ever going to see it.

I suggest to not pay any attention to ignorant people attacking you for asking a question about a factual warning message. Such clueless people do not comprehend that a program nor an end-user does not magically know the actual reason why a file might be missing without troubleshooting/asking. The reason could be an actual error in the installation of assets/requirements or just someone releasing mods/patches forgetting or not caring to QA - just to give a few examples.

[Spike2112]

Thanks Sheson, I guess I will have to ignore it.  I am still trying after all these years to keep up with these mods.

[deadshoes]

Hi Sheson. Happy new years. 

I have had trouble running dyndolod. No specific errors however it takes days to get anywhere and I have not been able to get it to complete so far. TexGen runs perfectly fine in about 20-30 mins. It ran once for over a week and still didn't complete. This run failed at the occlusion step. I didn't have realtimelog active for that run however so I don't have the logs for that. 

The logs for my most recent run are here: https://www.mediafire.com/file/rtekfps0cu7assb/Logs.tar.gz/file

Dyndolod seems to get stuck and certain parts and runs very slowly. At these points it uses exclusively 1 core ~8.3% cpu but it is not maxing out memory and stays using only 3Gb of RAM. At these points the DynDOLOD window also becomes unresponsive and I have to manually kill the process. I only have 16GB of RAM but I have set up 32GB of swap which I've seen it make use of when it needs. 

I am running on linux with proton 9.0. I was previously running with GTX 1070 and nvidia propiertary drivers 580.xx. I now have a new graphics card and the problem is persisting when running on now a RTX 6800 XT with latest AMD drivers. I do have a Ryzen 5 6500g which has an igpu but I don't think this is the issue as texconv processes seem to run relatively quickly. I am using MO2. 

I have read the FAQ about long run times. I have a few tree files that are >100MB so I get this may be the issue. However I believe these trees come from Nature of the Wild Lands mod which people have used DynDOLOD for before so I'm assuming I have a different problem. 

I have manually ran LODGen from the Expert Mode menu and although its not super fast Tamriel LODGen completes within ~30-40mins.