DynDOLOD 3.00 Alpha 180

[Althro]

On 4/1/2024 at 2:44 PM, sheson said:

Check in xEdit if you have a plugin overwriting 0001F049 and let me know.

In any case, replace ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_SSE_ChildworldMatches.txt and generate LOD again. That should fix that.

Nothing overwriting it.

Will try the regeneration with that file and let you know.

---

That's fixed it Thanks Sheson!

[peterhabble]

Northern Roads has an issue with Dyndolod 169 where the solitude bridge will not load in the worldspace: https://postimg.cc/GHTXVP4X.

From what I can tell, this issue is happening because Northern Roads is overriding the vanilla reference of the bridge with a new one in the persistent Tamriel Worldspace which is causing Dyndolod to never load the bridge. When I take the record and move it into a new mod that isn't overriding the vanilla bridge record, it works as expected.

The editor ID of the offending reference is "COTN_SBridge01StoneRoad". Here is a picture of the record along with the hack I used to test: https://postimg.cc/1gfLqjkm

I did test this using just skyrim with only dyndolod/requirements and northern roads but my logs from it were deleted because I wiped that whole instance once I saw the issue wasn't with my modlist(I found the work around in my main list that has 1k+ plugins). If it would be helpful I could find time to recreate it.

[sheson]

On 4/3/2024 at 10:41 PM, peterhabble said:

Northern Roads has an issue with Dyndolod 169 where the solitude bridge will not load in the worldspace: https://postimg.cc/GHTXVP4X.

From what I can tell, this issue is happening because Northern Roads is overriding the vanilla reference of the bridge with a new one in the persistent Tamriel Worldspace which is causing Dyndolod to never load the bridge. When I take the record and move it into a new mod that isn't overriding the vanilla bridge record, it works as expected.

The editor ID of the offending reference is "COTN_SBridge01StoneRoad". Here is a picture of the record along with the hack I used to test: https://postimg.cc/1gfLqjkm

I did test this using just skyrim with only dyndolod/requirements and northern roads but my logs from it were deleted because I wiped that whole instance once I saw the issue wasn't with my modlist(I found the work around in my main list that has 1k+ plugins). If it would be helpful I could find time to recreate it.

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.

Make a useful screenshot with more informative console of the full model when it is not missing as explained at https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots. Also see https://dyndolod.info/Official-DynDOLOD-Support-Forum#xEdit-Screenshots

The screenshot of xEdit shows a record not being touched by any DynDOLOD plugins. It shows that Northern Roads makes a record persistent. It shows a plugin that sets the ignore flag, which usually means whatever the overwrite plugin does to the record is ignored by the game engine.

A reference being persistent or being made persistent by an overwrite is not the cause of the problem alone, obviously. The problem could probably related to a specific trigger of the large reference bugs that might only happens if the reference is persistent and also requires something else.

It is the game that loads and renders objects. DynDOLOD does not do that. DynDOLOD may control enable/disable states of reference.
Just because a reference is persistent does not cause the game to not load or render it under normal circumstances.

Does the issue happen after starting a new game?

You seem to indicate the issue is not happening with a load order that just has Northern Roads and DynDOLOD generated for it? Usurpingly the bridge shows for me with/without DynDOLOD just the same. So what else might be required for the issue to happen?

[LORDSAVEXs]

Hello! There was a question with DynDOLOD 3.00 Alpha 169, I did not find the necessary information in the FAQ. For some reason, the currently created DynDOLOD plugins are Header Version 1.8, and not 1.71? It should be? I have Skyrim AE version 1.6.640 (Backported Extended ESL Support installed).

Here's the log:

DynDOLOD_SSE_Debug_log.zip

[sheson]

2 hours ago, LORDSAVEXs said:

Hello! There was a question with DynDOLOD 3.00 Alpha 169, I did not find the necessary information in the FAQ. For some reason, the currently created DynDOLOD plugins are Header Version 1.8, and not 1.71? It should be? I have Skyrim AE version 1.6.640 (Backported Extended ESL Support installed).

Here's the log:

DynDOLOD_SSE_Debug_log.zip

The DynDOLOD plugins use the highest version found in plugins in the load order.
Only came up once so far https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-169/?do=findComment&comment=276541

From the log:
[00:00]     670    669    FE 231    ESL    EE903CD7    1.8    Patch for Waterplants Verdant V1_8.esp

[LORDSAVEXs]

33 minutes ago, sheson said:

The DynDOLOD plugins use the highest version found in plugins in the load order.
Only came up once so far https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-169/?do=findComment&comment=276541

From the log:
[00:00]     670    669    FE 231    ESL    EE903CD7    1.8    Patch for Waterplants Verdant V1_8.esp

Thank you! You saved me!

[The_Franks]

I am getting an integer overflow error. It occurs when running texgen for the first time on an completely unmodded Skyrim VR. All requirements are present so it is not completely unmodded, I have SKSEVR and DynDOLOD.dll and PapyrusUtil.dll, The Resources are installed and then the VR scripts over that. I ran XLODGEN first, then went to run textGen64 and I got the integer overflow error with no other explanation. Here is a link to logs and bugreport. dyndolod logs and bugreport - Pastebin.com I do not want to speculate what is causing this error. Please Help.

[sheson]

8 hours ago, The_Franks said:

I am getting an integer overflow error. It occurs when running texgen for the first time on an completely unmodded Skyrim VR. All requirements are present so it is not completely unmodded, I have SKSEVR and DynDOLOD.dll and PapyrusUtil.dll, The Resources are installed and then the VR scripts over that. I ran XLODGEN first, then went to run textGen64 and I got the integer overflow error with no other explanation. Here is a link to logs and bugreport. dyndolod logs and bugreport - Pastebin.com I do not want to speculate what is causing this error. Please Help.

https://stepmodifications.org/wiki/SkyrimSE:SkyrimPrefs_INI/Display#iSize_H in C:\Users\jason\OneDrive\Documents\My Games\Skyrim VR\SkyrimPrefs.ini seems to be set to 0.

[The_Franks]

Thanks. 

[bread-dreams]

Hi. I installed DynDOLOD (for 1.6.1170, with NG, all necessary plugins cleaned and large reference bugs workaround) and generated new LOD recently for my existing save with a tiny mod list and everything was running fine for a while until I started experiencing CTDs upon entering/exiting interiors, especially around Winterhold and the College. I checked the logs and DynDOLOD kept showing up with references to form id 0x00033DCB or 0x00033DCA, which seemingly points to the huge Azura statue.

I tried regenerating LODs, with and without the large reference bugs, but it didn't seem to help much. The CTDs are fairly inconsistent, and I couldn't find a way to make them happen consistently. But it does seem to always happen when entering/exiting an interior, even to another interior (I had a crash happen when exiting Saarthal to Saarthal Excavation). The crashes do seem to happen more often when near the Shrine of Azura but one happened far away, somewhere near Riften.

Thankfully, disabling DynDOLOD in the MCM menu does seem to fix it! At least after a bunch of hours playing I didn't have any crashes, whilst before it wouldn't take long for a crash to happen.

Every single crash log I had seemed like the exact same, many references pointing to 0x00033DCB. In another similar post I found, they also had issues with the Azura statue but they had installed a replacer or something, something I have not done at all, it's just the vanilla statue. Sheson seemed to want the editor ID of that form ID, so preemptively in case it helps here it is: skyrimesm_033DCB_DynDOLOD_REVERT https://i.imgur.com/QjmzVyu.png

Also, I did not run xLODGen before generating LOD, because I absolutely despise the meshes and textures xLODGen creates. Hopefully that's not a problem? The required logs are here: https://ufile.io/slbtft3b Also, sorry the debug log is huge and doesn't correspond to the generated mod I'm actually using because I regenerated a bunch of times trying to fix this even with xLODGen and all but hopefully it's still helpful in case you need it.

Thanks~

[vrnord]

Can I make a suggestion for a possible future feature tweak?  Grass LODs are really awesome: having grass beyond the active cells is a whole other level of immersion because I don't have to tell my brain to ignore bald terrain that is often very visible.  I will downgrade other things so I can keep my grass LODs.  A challenge is that, to balance performance with visuals, I need to set a fairly low grass LOD density so Pine Forest and Fall Forest areas run smoothly.  I can get away with that visually, because there is enough tree density and shadows in those regions to distract from or obscure the patchy LODs - you get a nice impression of distant grass detail but don't really focus on it.  However that leaves the Tundra and Reach with patchy grass LODs too, where it is much more noticeable and distracting because of the lack of trees.  The irony is that the lack of trees and other forest clutter means I could have afforded denser LODs there.

I wonder if there could be an option to add a rule to Dyndolod to override the overall grass density for certain regions, maybe by landscape texture?  So if the rule is Reach = 50 density (but overall density is 35), then Dyndolod knows Reach = Reachgrass01, Reachmoss01, Reachdirt01 and Reachmossyrocks01, and finds the corresponding grasses to override from the overall density setting: all other grass types would be 35. 

Alternately, is there a way to run Dyndolod by region "chunk"?  That way I could output Dyndolod with 35 density, then change to a higher density to output just the Tundra and Reach mesh chunks and have that override the overall output in MO2.  

Thanks for all your work on this awesome tool!

[sheson]

3 hours ago, bread-dreams said:

Hi. I installed DynDOLOD (for 1.6.1170, with NG, all necessary plugins cleaned and large reference bugs workaround) and generated new LOD recently for my existing save with a tiny mod list and everything was running fine for a while until I started experiencing CTDs upon entering/exiting interiors, especially around Winterhold and the College. I checked the logs and DynDOLOD kept showing up with references to form id 0x00033DCB or 0x00033DCA, which seemingly points to the huge Azura statue.

I tried regenerating LODs, with and without the large reference bugs, but it didn't seem to help much. The CTDs are fairly inconsistent, and I couldn't find a way to make them happen consistently. But it does seem to always happen when entering/exiting an interior, even to another interior (I had a crash happen when exiting Saarthal to Saarthal Excavation). The crashes do seem to happen more often when near the Shrine of Azura but one happened far away, somewhere near Riften.

Thankfully, disabling DynDOLOD in the MCM menu does seem to fix it! At least after a bunch of hours playing I didn't have any crashes, whilst before it wouldn't take long for a crash to happen.

Every single crash log I had seemed like the exact same, many references pointing to 0x00033DCB. In another similar post I found, they also had issues with the Azura statue but they had installed a replacer or something, something I have not done at all, it's just the vanilla statue. Sheson seemed to want the editor ID of that form ID, so preemptively in case it helps here it is: skyrimesm_033DCB_DynDOLOD_REVERT https://i.imgur.com/QjmzVyu.png

Also, I did not run xLODGen before generating LOD, because I absolutely despise the meshes and textures xLODGen creates. Hopefully that's not a problem? The required logs are here: https://ufile.io/slbtft3b Also, sorry the debug log is huge and doesn't correspond to the generated mod I'm actually using because I regenerated a bunch of times trying to fix this even with xLODGen and all but hopefully it's still helpful in case you need it.

Thanks~

If the CTD also happens with a LOD patch that is either using DynDOLOD DLL SSE and Scripts or PapyrusUtil as you seem to report, also upload a crash log of that. Not need for the DynDOLOD log or debug log for that generation.

To make sure, nothing overwrites textures\clutter\ShrineofAzura.dds or textures\clutter\ShrineofAzura_n.dds?

Unrelated, how are the better terrain LOD Meshes without the vanilla bugs and with almost perfect coast lines a problem? What is the issue with better terrain LOD textures that match full terrain in color and tone? What alternative are you using that was not made with xLODGen? I suggest to read the first post, https://dyndolod.info/Help/xLODGen and/or to follow a modding guide.

[Modslave]

So, sorry to bring this here but I'm kind of not clear on what's happened here and its very concerning.

I recently updated Dyndolod and its resources to 3.0 Alpha 169 and over the last two days had some very concerning lodgen sessions with it.

Prior Dyndolod sessions would take me around 13 to 20 minutes generating a file on the average of about 2.5gb in total compressed size.

But yesterdays session generated a compressed Dyndolod Output of 11.2 GB in size and it took about an hour and a half. It was mostly fine in the general Tamriel worldspace and then I got near Whiterun and the giant fight at the farm and it was such a simulation slide show that even Aela was saying her lines well after they appeared on my screen. I have an insanely high spec PC running a 3080 Ti, 64GB of RAM on a 4.5ghz clocked I7-9700 running at 1440p on a Nvidia G-Sync monitor and surprisingly it all held together and eventually settled down enough for me to be able to walk again but it was really awful so something was obviously wrong cause normally I can run Skyrim with another game or app in the background without a problem.

So I dug into my modlist and removed a few texture and mesh addon mods, specifically Traverse the Uvenwald and Wigfrids Trees (both mods I've had in my load order in the previous 2.5 GB outputs and have been in my mod list for months) and cut some base object swapper mods for farmhouses as well. Leaving my prior install shorter on details.

And I just ran Dyndolod again and it took another hour and a half and this time the compressed Output file is literally 19.2 GB compressed and 39.4 GB uncompressed which is quite literally 3 times the size of the entire game unmodded.

Something is dreadfully wrong here and I can't figure out what. The only changes I've made should have reduced the total mesh and texture load, not increased it, and the only custom rules I'm setting in the expert level config are the ACMOS default billboard setttings for tree and /, everything else is just default run on High as I've always done.

[sheson]

2 hours ago, Modslave said:

So, sorry to bring this here but I'm kind of not clear on what's happened here and its very concerning.

I recently updated Dyndolod and its resources to 3.0 Alpha 169 and over the last two days had some very concerning lodgen sessions with it.

Prior Dyndolod sessions would take me around 13 to 20 minutes generating a file on the average of about 2.5gb in total compressed size.

But yesterdays session generated a compressed Dyndolod Output of 11.2 GB in size and it took about an hour and a half. It was mostly fine in the general Tamriel worldspace and then I got near Whiterun and the giant fight at the farm and it was such a simulation slide show that even Aela was saying her lines well after they appeared on my screen. I have an insanely high spec PC running a 3080 Ti, 64GB of RAM on a 4.5ghz clocked I7-9700 running at 1440p on a Nvidia G-Sync monitor and surprisingly it all held together and eventually settled down enough for me to be able to walk again but it was really awful so something was obviously wrong cause normally I can run Skyrim with another game or app in the background without a problem.

So I dug into my modlist and removed a few texture and mesh addon mods, specifically Traverse the Uvenwald and Wigfrids Trees (both mods I've had in my load order in the previous 2.5 GB outputs and have been in my mod list for months) and cut some base object swapper mods for farmhouses as well. Leaving my prior install shorter on details.

And I just ran Dyndolod again and it took another hour and a half and this time the compressed Output file is literally 19.2 GB compressed and 39.4 GB uncompressed which is quite literally 3 times the size of the entire game unmodded.

Something is dreadfully wrong here and I can't figure out what. The only changes I've made should have reduced the total mesh and texture load, not increased it, and the only custom rules I'm setting in the expert level config are the ACMOS default billboard setttings for tree and /, everything else is just default run on High as I've always done.

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.

See https://dyndolod.info/FAQ#Long-running-time-or-output-several-GB-in-file-size
In particluar:
Beware of mods adding or defining full models or not really well optimized LOD models for LOD.
Check ..\DynDOLOD\Logs\DynDOLOD_[GAME MODE]_ModelsUsed_[WORLDSPACE].txt for a list of meshes and their total contribution to the object LOD meshes file sizes.

It is unclear what the actual content of the archive or the output folder is, you are just reporting the size. Checking the actual content and finding and reporting the largest folder and files might help to narrow it down, in particluar if textures are involved. Make sure the output folder is empty before generating new DynDOLOD output from scratch.

[Modslave]

 

Apologies for the delay.  I'd already started a fresh texgen/dyndolod output after trying to eliminate potential issues and even downgrading the Dyndolod script package to the last version and noticed the log requirements after that. I just had to sit through a 2 hour  Dyndolod output to ensure I have the logs required. One hour and 44 minutes of that literally being generating the Tamriel LODGen.

Here are the relevant logs I believe.

https://drive.google.com/file/d/1j2puHpv6JfE2sszQkgj_TQQXpOqbWeRj/view?usp=drive_link

The debug log alone is 185mb something is very not right here.

The largest asset folder in the output is the \DynDOLOD_Output\Meshes\Terrain\Tamriel\Objects folder, which is coming in at a whopping 27.6 GB uncompressed.

Here is the Tamriel ModelsUsed.

https://pastebin.com/Sa5REP8n

The strange part of this is I haven't added anything that should be doing this, I've actually been removing things that add objects. And its not helping.

My Texgen output.....by comparison, is literally less than 130 MB.

Edited April 10 by Modslave