DynDOLOD 3.00 Alpha 171

[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. 

[yourmusicsucks]

Just reporting that my problem was resolved-- coincidentally or not-- after installing the latest version. Wooo thanks!

[IskanderStep]

Hi, i have a puzzle to solve and hope to get some insights.

Skyrim Latest Version (1.6640).

Open Cities (yes)

Jks' Skyrim AIO and a bunch of other Mods ( > 1000) 

 

I used the latest Dyndolod Version on an new Save and the "Palace" in Whiterun has a slight Problem.

Maybe you can set me up on the right track.  

 

 

I tried the update Procedure with the clean save and something happened.

The Palace looks as before  but the Bridge to the palace is gone  .

I can bring the Bridge back with prid though, but it is disabled after generation ? Do you have an idea, why this is occuring ?

 

If you need any further information, please let me know. 

Thanks for your time, i really appreciate your efforts. 

[sheson]

1 hour ago, IskanderStep said:

Hi, i have a puzzle to solve and hope to get some insights.

Skyrim Latest Version (1.6640).

Open Cities (yes)

Jks' Skyrim AIO and a bunch of other Mods ( > 1000) 

 

I used the latest Dyndolod Version on an new Save and the "Palace" in Whiterun has a slight Problem.

Maybe you can set me up on the right track.  

 

 

I tried the update Procedure with the clean save and something happened.

The Palace looks as before  but the Bridge to the palace is gone  .

I can bring the Bridge back with prid though, but it is disabled after generation ? Do you have an idea, why this is occuring ?

 

If you need any further information, please let me know. 

Thanks for your time, i really appreciate your efforts. 

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.

Make screenshots in broad daylight as explained at https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots.

Explain in a sentence what the "slight problem" with the palace is.
What do you mean by new save? A new game? The clean save procedure can only be applied to an existing save that had old DynDOLOD output.

The 1st screenshot has a glow model marked and not the palace. It is unclear what the worldspace is.

The 2nd screenshot shows that no plugins affects the marked bridge reference. You should double check with xEdit that no plugin overwrites the reference.
It also shows that the reference is in the Whiterun childworld, which seems pointless to enter when using Open Cities.
Typically DynDOLOD does not do anything to existing references in childworlds, especially when a plugin like Open Cities is installed.

[psyyo]

yo uh .. is https://dyndolod.info/ okay?

keep getting blocked with cloudflare warning error page

[IamHovah]

Hello Sheson, 

I support the Flying Crows mod on SSE and have had intermittent reports of issues with crows missing/not showing up. Only just recently have I been able to reproduce any of these issues and only after updating to the newest version(s) of DynDolod 3.0 (134 & 135).

At current, it appears crows are not loading/appearing within the Tamriel worldspace. Child worldspaces (Whiterun/Windhelm) appear to load the models without issue both within the child worldspace and when viewing them from the Tamriel worldspace. I'm unsure if this is something that needs to be resolved from my end with the DynDolod config but figured it would be best to inquire with you first. 

I've uploaded the DynDolod/Texgen logs & debug logs here: https://mega.nz/folder/BXYykDCL#1DraJOIX9KaEuo7YDft4Kg

The link should contain each document in plain text and a zipped folder containing all 4 if that is easier to download. Please let me know if you have any difficulty in accessing the logs and/or if I can provide any further details. Thanks and have a great day!

[sheson]

1 hour ago, psyyo said:

yo uh .. is https://dyndolod.info/ okay?

keep getting blocked with cloudflare warning error page

Moved to the DynDOLOD 3 Alpha thread. Thanks for the notification. I fixed it.

[Mousetick]

On 8/22/2023 at 10:30 PM, sheson said:

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.

Thanks for all your clarifications. I understand now:

• copy/overwrite: low priority overrides for DynDOLOD ESM that can be overridden by mod plugins
• copy2esp/overwrite2esp: high priority overrides for DynDOLOD ESP that win over everything else

Instead of following your suggestion I opted to forward the changes into a separate plugin using xEdit, so that I could easily test the changes by enabling or disabling the plugin without performing a DynDOLOD generation-update pass:

Your 'Force Hide Land' fix really improves the view outside the walls. It seems the defects or the fix can only be noticed if the player flies/glides or somehow manages to climb over the walls or buildings, otherwise they're obstructed by them.

This was taken by disabling collision and walking on the wall: Without Fix > With Fix

However I managed to find a spot where the defect is visible from inside the walls, without performing unnatural acrobatics. I simply stepped on a small ledge: Without Fix > With Fix

But one has to really pay attention and look hard to notice. There may be other viewing spots like that inside the walls, I didn't find them.

Anyway, I'm going to keep forwarding the fix 

--

Following are thoughts to be taken with a big grain of salt. Feel free to skip, or read at your leisure during your coffee break. As noted above, the missing landscape defects appear to be hardly noticeable in normal gameplay, so the issue is arguably not worth sweating or losing sleep over.

I'd like to point out a couple of shortcomings about the "any non vanilla plugins changing the areas/cells should win any conflict" rule of thumb used to apply the fix. You're probably already aware of them:

• Due to the position of DynDOLOD.esm in the load order, the rule is actually: any non-vanilla non-ESM plugins changing the areas/cells should win any conflict, in which case the fix is not applied, while non-vanilla ESM plugins changing same the areas/cells "lose" and the fix is applied. Which doesn't really make sense, because ESM or not ESM does not indicate how specific plugins might change the areas/cells or how they might visually conflict with the fix.
• The rule doesn't account for (potentially, but unlikely, extensive) changes made to the areas/cells by mod plugins in the persistent cell of the worldspace, since it considers only conflicts with the specific cell record.
• The approach is very conservative in order not to break anything with random load orders, but it means the fix is not applied for the majority of (non-ESM) mods which make very few or minor changes, or changes only inside the walls - changes which actually wouldn't be affected at all by the 'Forced Hide Land' fix.

A somewhat ambitious idea for an alternative approach:

• Refactor the patching infrastructure to make it dynamic / conditional / context-sensitive.
• In its simplest form, tailored to this specific patching issue, a mod plugin blacklist is used rather than relying on the cell conflict rule of thumb.
• The patch is not applied if the loader order contains at least one mod plugin listed in the blacklist.
• The patch is applied to DynDOLOD.esp otherwise, so it wins over all other plugins in the load order.
• The contents of the blacklist need to be determined empirically. In all likelihood, only very few mods would need to be blacklisted, e.g. the Big City Overhaul type of mods.

Would the amount of 'plumbing' work to implement this approach be justified by the minuscule 'Force Hide Land' fix that most users may not notice? Arguably not at all. I'm just throwing the idea out there anyway. Also once the 'plumbing' is in place it could be reused or extended to handle other dynamic patching scenarios...

I can't think of any reasonably feasible heuristics- or analysis-based approach. Like the exceptions for the Parent > Child copying, it seems to be way too complicated to handle algorithmically. ChatGPT maybe? (joking)

Thanks for reading.

[sheson]

2 minutes ago, Mousetick said:

Thanks for all your clarifications. I understand now:

• copy/overwrite: low priority overrides for DynDOLOD ESM that can be overridden by mod plugins
• copy2esp/overwrite2esp: high priority overrides for DynDOLOD ESP that win over everything else

Instead of following your suggestion I opted to forward the changes into a separate plugin using xEdit, so that I could easily test the changes by enabling or disabling the plugin without performing a DynDOLOD generation-update pass:

Your 'Force Hide Land' fix really improves the view outside the walls. It seems the defects or the fix can only be noticed if the player flies/glides or somehow manages to climb over the walls or buildings, otherwise they're obstructed by them.

This was taken by disabling collision and walking on the wall: Without Fix > With Fix

However I managed to find a spot where the defect is visible from inside the walls, without performing unnatural acrobatics. I simply stepped on a small ledge: Without Fix > With Fix

But one has to really pay attention and look hard to notice. There may be other viewing spots like that inside the walls, I didn't find them.

Anyway, I'm going to keep forwarding the fix 

--

Following are thoughts to be taken with a big grain of salt. Feel free to skip, or read at your leisure during your coffee break. As noted above, the missing landscape defects appear to be hardly noticeable in normal gameplay, so the issue is arguably not worth sweating or losing sleep over.

I'd like to point out a couple of shortcomings about the "any non vanilla plugins changing the areas/cells should win any conflict" rule of thumb used to apply the fix. You're probably already aware of them:

• Due to the position of DynDOLOD.esm in the load order, the rule is actually: any non-vanilla non-ESM plugins changing the areas/cells should win any conflict, in which case the fix is not applied, while non-vanilla ESM plugins changing same the areas/cells "lose" and the fix is applied. Which doesn't really make sense, because ESM or not ESM does not indicate how specific plugins might change the areas/cells or how they might visually conflict with the fix.
• The rule doesn't account for (potentially, but unlikely, extensive) changes made to the areas/cells by mod plugins in the persistent cell of the worldspace, since it considers only conflicts with the specific cell record.
• The approach is very conservative in order not to break anything with random load orders, but it means the fix is not applied for the majority of (non-ESM) mods which make very few or minor changes, or changes only inside the walls - changes which actually wouldn't be affected at all by the 'Forced Hide Land' fix.

A somewhat ambitious idea for an alternative approach:

• Refactor the patching infrastructure to make it dynamic / conditional / context-sensitive.
• In its simplest form, tailored to this specific patching issue, a mod plugin blacklist is used rather than relying on the cell conflict rule of thumb.
• The patch is not applied if the loader order contains at least one mod plugin listed in the blacklist.
• The patch is applied to DynDOLOD.esp otherwise, so it wins over all other plugins in the load order.
• The contents of the blacklist need to be determined empirically. In all likelihood, only very few mods would need to be blacklisted, e.g. the Big City Overhaul type of mods.

Would the amount of 'plumbing' work to implement this approach be justified by the minuscule 'Force Hide Land' fix that most users may not notice? Arguably not at all. I'm just throwing the idea out there anyway. Also once the 'plumbing' is in place it could be reused or extended to handle other dynamic patching scenarios...

I can't think of any reasonably feasible heuristics- or analysis-based approach. Like the exceptions for the Parent > Child copying, it seems to be way too complicated to handle algorithmically. ChatGPT maybe? (joking)

Thanks for reading.

The hide quad flag changes should really be part of the unofficial patch just like all these other visual tings it already fixes. They will then be part of many properly made mods eventually.