DynDOLOD 3.00 Alpha 198

[sheson]

6 hours ago, yourmusicsucks said:

Wow, thanks so much for the reply, any sorry to take up your time Sheson.  Got a lot of joy out of your work over the years. I'm not sure if the other 2 

bugreport.txt 71.91 kB · 2 downloads

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log and debug log to upload also.

[sheson]

5 hours ago, spacepillow said:

Hey there, dumb question but I couldn't find a recent answer anywhere --

How do I re-generate my Dyndolod without also doing occlusion? Unless something has changed, it used to be that you could rerun dyndolod without also doing occlusion (which you only need to do the first time you run dyndolod + any time you change worldspaces or something). 

Am I missing something? Occlusion's box is checked but greyed out so I can't uncheck it.

Remove Occlusion.esp from the data folder and also do not check the Occlusion data checkbox. After LOD generation put it back.

[yourmusicsucks]

Hopefully I got this right. A bit under the weather! Sorry and thank you. My whole log folder: https://drive.google.com/file/d/1z5QOCFZc8vy5fOqkkw6lqmVU-Wpe76bx/view?usp=drive_link

And the ones I think are needed here:

TexGen_SSE_log.txt DynDOLOD_SSE_log.zip TexGen_SSE_Debug_log.txt LODGen_SSE_Tamriel_log.zip

Edited August 22, 2023 by yourmusicsucks

[sheson]

1 hour ago, yourmusicsucks said:

Hopefully I got this right. A bit under the weather! Sorry and thank you. My whole log folder: https://drive.google.com/file/d/1z5QOCFZc8vy5fOqkkw6lqmVU-Wpe76bx/view?usp=drive_link

And the ones I think are needed here:

TexGen_SSE_log.txt 1.66 MB · 0 downloads DynDOLOD_SSE_log.zip 348.85 kB · 0 downloads TexGen_SSE_Debug_log.txt 131.19 kB · 0 downloads LODGen_SSE_Tamriel_log.zip 9.62 kB · 0 downloads

As explained by https://dyndolod.info/Generation-Instructions, the load order should be cleaned and error checked with xEdit before generating LOD. As further explained pay to attention to all log messages. See https://dyndolod.info/Messages.

Log messages like this reported in the DynDOLOD log are the cause of the access violation. They would also have been reported by the xEdit error check:
 <Error: Unresolved FormID [E70048D3] RealisticWaterTwo.esp might be the wrong version. Error in RealisticWaterTwo - Unique Region Names - MissingEZs_AllExteriors.esp POIReach03 [CELL:00007040] (in Tamriel "Skyrim" [WRLD:0000003C] at -38,11)>
See https://dyndolod.info/Messages/Unresolved-Form-ID. RealisticWaterTwo.esp is probably the wrong version for the patch RealisticWaterTwo - Unique Region Names - MissingEZs_AllExteriors.esp or vice versa. It should run through without an access violation once all the CELLs that have unresolved form ID have been fixed.

[DarkladyLexy]

Hey Sheson think I have found an issue between DynDOLOD and wSkeevers - Windhelm Entrance Offset Fix - Base Object Swapper https://www.nexusmods.com/skyrimspecialedition/mods/98207

here are the Logs since they are too big to upload directly - https://drive.google.com/file/d/1_N8OCrkrNstxpnevJ2FrHdP2fDPcUr-l/view?usp=sharing

 

As you can see from my screenshot there is an issue with Windhelm wall when look towards windhelm near Kynesgrove sawmill

[sheson]

2 hours ago, DarkladyLexy said:

Hey Sheson think I have found an issue between DynDOLOD and wSkeevers - Windhelm Entrance Offset Fix - Base Object Swapper https://www.nexusmods.com/skyrimspecialedition/mods/98207

here are the Logs since they are too big to upload directly - https://drive.google.com/file/d/1_N8OCrkrNstxpnevJ2FrHdP2fDPcUr-l/view?usp=sharing

As you can see from my screenshot there is an issue with Windhelm wall when look towards windhelm near Kynesgrove sawmill

Thanks. Will be fixed next alpha version.

For future reference https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots
If making screenshots of the LOD area, also make screenshots of the close-up object or full model for comparison.
When making screenshots of full models, open console and click the object in question to show its reference form ID. Note that multi pass snow shaders can prevent full models from being selected. Temporarily disable any mod that prevents getting the form ID of full models in case getting the information is not possible otherwise.

Knowing the form ids of one or two of the objects makes troubleshooting things easier right away.

[sheson]

On 8/18/2023 at 12:31 AM, Blackread said:

Here: https://mega.nz/file/NGtgRJDb#6_qQlqMbMp98j0O2zmDZJV_s844_1KJenJmBXxVccHA

I only included the Tamriel.4.-44.0 and Tamriel.4.-44.-4 blocks, I assumed you didn't want the whole of Tamriel.

The underside should have the correct "holes" next version matching the ones in the terrain LOD.

[Orimagen]

Hello,
I'm trying to do my Dyndolod for Skyrim Special Edition but I have some issues. When I run Texgen, it get stucks on the same texture each time and don't continue to create texture (I know it get stuck because my CPU usage is at 0%). This texture is called "shiprope01lod.dds" and is part of the Dyndolod Resources SE mod. Of course I tried to reinstall the whole Dyndolod, tried to reinstall the Dyndolod resources and script, turn off Windows defender... but nothing, it always get stuck on this texture and I need to close Texgen and unlock MO2. Here the Debug Log
I hope you can help me, thank you in advance !

[sheson]

7 minutes ago, Orimagen said:

Hello,
I'm trying to do my Dyndolod for Skyrim Special Edition but I have some issues. When I run Texgen, it get stucks on the same texture each time and don't continue to create texture (I know it get stuck because my CPU usage is at 0%). This texture is called "shiprope01lod.dds" and is part of the Dyndolod Resources SE mod. Of course I tried to reinstall the whole Dyndolod, tried to reinstall the Dyndolod resources and script, turn off Windows defender... but nothing, it always get stuck on this texture and I need to close Texgen and unlock MO2. Here the Debug Log
I hope you can help me, thank you in advance !

By the time shiprope01lod is reported in the log it has been created from the full textures to the output folder. Textures in the data folder with the same filename as the created textures are irrelevant.

See https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-134/?do=findComment&comment=273438

[Mousetick]

DynDOLOD 3a134 / Resources 3a38 / DLL NG + Scripts 3a11

Not a problem report per se. Wondering if the observed plugin output is expected, as it doesn't look "right" in principle. I don't know how that translates practically in-game.

DynDOLOD.esm makes some changes to the 'Force Hide Land' flags of some WindhelmWorld cells. These changes must be done on purpose by DynDOLOD because they're not forwarded from any previous plugins in the load order. However they're not forwarded to DynDOLOD.esp, so they're lost due to other plugins overwriting DynDOLOD.esm.

WindhelmPalaceOfTheKingsExterior [CELL:00038380] (in WindhelmWorld "Windhelm" [WRLD:0001691D] at 32,10)

[CELL:00038384] (in WindhelmWorld "Windhelm" [WRLD:0001691D] at 31,10)

(Some mod plugins to the left of DynDOLOD.esm were hidden so that the remaining could fit in 1 screenshot)

Full logs here if needed: https://drive.google.com/file/d/19EQbVwyzUSpR3ReaOWITDJFmMuKv5JYF/view

Apologies if this is a stupid or not pertinent remark. Thank you.

[DarkladyLexy]

just noticed that the Seasons option is checked but default in both Alpha 134 and Alpha 135 even if one has no season stuff installed

[sheson]

1 hour ago, Mousetick said:

DynDOLOD 3a134 / Resources 3a38 / DLL NG + Scripts 3a11

Not a problem report per se. Wondering if the observed plugin output is expected, as it doesn't look "right" in principle. I don't know how that translates practically in-game.

DynDOLOD.esm makes some changes to the 'Force Hide Land' flags of some WindhelmWorld cells. These changes must be done on purpose by DynDOLOD because they're not forwarded from any previous plugins in the load order. However they're not forwarded to DynDOLOD.esp, so they're lost due to other plugins overwriting DynDOLOD.esm.

WindhelmPalaceOfTheKingsExterior [CELL:00038380] (in WindhelmWorld "Windhelm" [WRLD:0001691D] at 32,10)

[CELL:00038384] (in WindhelmWorld "Windhelm" [WRLD:0001691D] at 31,10)

(Some mod plugins to the left of DynDOLOD.esm were hidden so that the remaining could fit in 1 screenshot)

Full logs here if needed: https://drive.google.com/file/d/19EQbVwyzUSpR3ReaOWITDJFmMuKv5JYF/view

Apologies if this is a stupid or not pertinent remark. Thank you.

They are changed on purpose by DynDOLOD_SSE_skyrimesm_tamriel.patch. The vanilla land not showing can cause visible holes especially in the mountain north/west behind the palace while I did testing with the parent/child copies. Many of the mountain references in the child world do not match with the ones in the parent world.

They only being done in the esm is on purpose (albeit not the perfect solution). It is assumed that any non vanilla plugins changing the areas/cells should win any comnflict.

[sheson]

2 hours ago, DarkladyLexy said:

just noticed that the Seasons option is checked but default in both Alpha 134 and Alpha 135 even if one has no season stuff installed

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log and debug log to upload when making posts.

https://dyndolod.info/Help/Seasons
The checkbox is only available if swap data for a season has been found and loaded successfully.

Without a ..\Data\Seasons\*[SPR|SUM|AUT|WIN].ini. the Seasons options are disabled. The debug log typically reports the found INIs.

[Mousetick]

1 hour ago, sheson said:

They only being done in the esm is on purpose (albeit not the perfect solution). It is assumed that any non vanilla plugins changing the areas/cells should win any comnflict.

Thanks for the explanation. I must be missing something, but I don't understand the reasoning or the rule of thumb.

Here I have unhidden some mod plugins to the left of DynDOLOD.esm:

Let's assume CWRepairs.esp is not in the load order, this would give:

In which case, the changes from DynDOLOD.esm would apply.

If the DynDOLOD.esm changes are considered to be OK for USSEP and OK for Legacy of the Dragonborn, why wouldn't they be OK for Civil War Repairs as well? Or taken from the opposite perspective, USSEP and Legacy of the Dragonborn are "non vanilla plugins changing the areas/cells", and yet DynDOLOD.esm changes win over them.

I understand this is an extremely complex and inextricable problem to solve generically when dealing with arbitrary load orders. A 'perfect' solution may not exist.

What if hypothetically I wanted the DynDOLOD.esm changes/fixes to apply to my mostly vanilla Windhelm load order, on which I used the Parent > Child feature. Could I forward them into a custom patch so they're not lost?

--

I noticed a similar loss of DynDOLOD.esm change, unrelated to previous:

arnimaDUPLICATE003 "The Reach" [WRLD:XX000D62] (from Beyond Reach)

DynDOLOD.esm changes the LOD Water Type. This change is unique to DynDOLOD so it must done on purpose. But it's lost because it's not forwarded to DynDOLOD.esp. Is this for the same reason as above? I.e. "It is assumed that any non vanilla plugins changing the areas/cells should win any conflict."

Thanks.

[sheson]

12 minutes ago, Mousetick said:

Thanks for the explanation. I must be missing something, but I don't understand the reasoning or the rule of thumb.

Here I have unhidden some mod plugins to the left of DynDOLOD.esm:

Let's assume CWRepairs.esp is not in the load order, this would give:

In which case, the changes from DynDOLOD.esm would apply.

If the DynDOLOD.esm changes are considered to be OK for USSEP and OK for Legacy of the Dragonborn, why wouldn't they be OK for Civil War Repairs as well? Or taken from the opposite perspective, USSEP and Legacy of the Dragonborn are "non vanilla plugins changing the areas/cells", and yet DynDOLOD.esm changes win over them.

I understand this is an extremely complex and inextricable problem to solve generically when dealing with arbitrary load orders. A 'perfect' solution may not exist.

What if hypothetically I wanted the DynDOLOD.esm changes/fixes to apply to my mostly vanilla Windhelm load order, on which I used the Parent > Child feature. Could I forward them into a custom patch so they're not lost?

--

I noticed a similar loss of DynDOLOD.esm change, unrelated to previous:

arnimaDUPLICATE003 "The Reach" [WRLD:XX000D62] (from Beyond Reach)

DynDOLOD.esm changes the LOD Water Type. This change is unique to DynDOLOD so it must done on purpose. But it's lost because it's not forwarded to DynDOLOD.esp. Is this for the same reason as above?

Thanks.

If you want those changes to always win and to survive updating, make a new patch file in (virtual) ..\Data\DynDOLOD\DynDOLOD_SSE_updateesm_tamriel.patch with
overwrite2esp=skyrim.esm;00038380,XCLC\Land Flags=11
overwrite2esp=skyrim.esm;00038384,XCLC\Land Flags=2
They will then be added to the DynDOLOD.esp as well.

The water record is done by
DynDOLOD_SSE_arnimaesm_arnimaduplicate003.patch

These patches are "for me" and this avoids forcing them on everybody.