DynDOLOD 3.00 Alpha 180

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

[sheson]

2 hours ago, IamHovah said:

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!

This is a bug with the scripts.

Make a clean save. Download and install DynDOLOD Resources 3 Alpha 40. That hopefully should fix it.

[IskanderStep]

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

 did it now , sorry i did my first post during a coding session with limited time 

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

ok

 

-> Explain in a sentence what the "slight problem" with the palace is. The 1st screenshot has a glow model marked and not the palace. It is unclear what the worldspace is. 

That is the Problem, the Palace is a little bit inside of it , i simply do not understand why, it looks a bit odd and i can move through and inside is the original model of the palace

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

 yes, sorry i meant a new Game

 

-> The 2nd screenshot shows that no plugins affects the marked bridge reference. You should double check with xEdit that no plugin overwrites the reference.

 ok, will do

 

Thank you very much for your assistance

[sheson]

11 hours ago, IskanderStep said:

ok

That is the Problem, the Palace is a little bit inside of it , i simply do not understand why, it looks a bit odd and i can move through and inside is the original model of the palace

 yes, sorry i meant a new Game

 ok, will do

Thank you very much for your assistance

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.

Sounds like the LOD version of the castle was active together with the full model. Make a useful screenshot with the LOD model marked in console and not its glow LOD. If it can not be marked use tll in console to see if it is object LOD. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots.

[IamHovah]

1 hour ago, sheson said:

This is a bug with the scripts.

Make a clean save. Download and install DynDOLOD Resources 3 Alpha 40. That hopefully should fix it.

Confirmed, issue appears to be resolved. Thanks for your quick response and attention on this. Have a great day!

[khaosjimena]

The items from the anniversary edition appear partially buried, what's the problem? excuse my english 

[RASTAPASTA]

yea I have ran this 1000 plus times I just cant get this thing to work.

YES I patched ussep for vr it just still says form id error it also dose this with cathedral mountain flowers, skyrim immersive creatures and weathered road signs. ALL of these mods work NONE have errors in xedit gonna try dyndolod 2 but that just tells me my load order is wrong in the mcm menu when I know I did it right. 

PLEASE ALL MY OTHER MODS HAVE BEEEN WORKING FOR LIKE 2 MONTHS ITS JUST THIS 

DynDOLOD_TES5VR_Debug_log.rar

DynDOLOD_TES5VR_log.txt

Edited August 25, 2023 by RASTAPASTA

[sheson]

42 minutes ago, RASTAPASTA said:

yea I have ran this 1000 plus times I just cant get this thing to work.

YES I patched ussep for vr it just still says form id error it also dose this with cathedral mountain flowers, skyrim immersive creatures and weathered road signs. ALL of these mods work NONE have errors in xedit gonna try dyndolod 2 but that just tells me my load order is wrong in the mcm menu when I know I did it right. 

PLEASE ALL MY OTHER MODS HAVE BEEEN WORKING FOR LIKE 2 MONTHS ITS JUST THIS 

DynDOLOD_TES5VR_Debug_log.rar 575.91 kB · 0 downloads

DynDOLOD_TES5VR_log.txt 1.7 MB · 0 downloads

DynDOLOD is based on xEdit. Unresolved form ID errors reported by DynDOLOD are from the xEdot code. If the same load order is checked for errors with xEdit, it will report the same unresolved form ID errors as DynDOLOD plus any additional errors for records that DynDOLOD does not consider for LOD generation.
If xEdit does not report the same errors as DynDOLOD, then the load order is different.

Update.esm with a CRC32 of DE522C22 according to the logs you uploaded, indicates it is still Skyrim VR vanilla and not patched and not cleaned.

See https://dyndolod.info/Mods/Skyrim-VR
Typically something like Skyrim VR - USSEP 4.2.2 and SSE 1.5.97 Compatibility Patch is required to fix unresolved and other errors in the load order. Refer to modding guides how to setup the base game properly.
Follow any proper Skyrim VR modding guide that includes the Skyrim VR - USSEP 4.2.2 and SSE 1.5.97 Compatibility Patch, then the record with form ID 01002EE7 will exist in Update.esm (and also be overwriten by Dawnguard.esm) and then it can be resolved/used by the unofficial patch.