DynDOLOD DLL

[sheson]

2 hours ago, GiraPomba said:

Again, I don't have the debug logs, like I said I'm playing with pre generated outputs included in a modlist, Dyndolod Standalone tool is not included, neither are its logs. The LOD was made following the correct procedures and the load order is exactly the same in both tests, the only thing different is the version of Dyndolod NG DLL. Hendraheim comes with its own LODs apparently, so they were probably skipped during LOD generation.

So it's not a "Output" generation thing, it's a DLL thing.Alpha 36 works fine, Alpha 39 has this issue.

I'm just trying to report this issue. I'll stick with Alpha 36, which works fine for me and the modlist, have a good day.

How do you know the LOD patch was generated following the correct procedures if you didn't generate it yourself? How do you know things were done as intended without the logs? How am I supposed to actually know or verify anything without logs?

What version of DynDOLOD Standalone was used to generate the LOD patch?

The 2nd screenshot does not show a DynDOLOD plugin modifying the reference, so something was not generated the typical way or the LOD patch plugins were not active when the screenshot was taken. Let me repeat, there is already something not right in that 2nd screenshot.

The DynDOLOD.log indicates that certain plugins changed their load order. What is the load order? Mods, plugins? What changed in the load order since the LOD patch was generated?

The LOD patch is most likely outdated and needs to be generated with the latest DynDOLOD Standalone with the latest DynDOLOD DLL NG and Scripts for the current load order in order for everything to work as intended.

Here is a screenshot of how it looks when generating the LOD patch with DynDOLOD 3 Alpha-196 with DynDOLOD DLL NG and Scripts Alpha-39 after walking from coc RoriksteadExterior01 to the location:

The building loads and the reference is last modified by DynDOLOD.esm as expected. Unsurprisingly, there does not seem to be a problem when doing things properly ...

https://dyndolod.info/Official-DynDOLOD-Support-Forum
Always use the latest version of DynDOLOD Standalone, DynDOLOD Resources and DynDOLOD DLL NG and Scripts. Bugs and other problems may already be fixed or addressed.

[MisterMorden]

Hi sheson, just a question not a bug report....does using the NG dll theoretically make it harder on the pc system when setting ugrids higher than 5?  I was using ugrids=7 for the entire time running with the old dll and scripts without a hitch, but when I regenerated recently with the newest NG dll now I find I freeze outdoors if a lot is going on in the game.  If I set ugrids=5 then everything runs great.  I realize that using ugrids greater than 5 isn't good for long term stability but the change happened so quickly that I, perhaps incorrectly, attributed it to the increased amount of references generated with the NG dll.

[sheson]

2 hours ago, MisterMorden said:

Hi sheson, just a question not a bug report....does using the NG dll theoretically make it harder on the pc system when setting ugrids higher than 5?  I was using ugrids=7 for the entire time running with the old dll and scripts without a hitch, but when I regenerated recently with the newest NG dll now I find I freeze outdoors if a lot is going on in the game.  If I set ugrids=5 then everything runs great.  I realize that using ugrids greater than 5 isn't good for long term stability but the change happened so quickly that I, perhaps incorrectly, attributed it to the increased amount of references generated with the NG dll.

https://dyndolod.info/Official-DynDOLOD-Support-Forum#Rudimentary-Troubleshooting

https://dyndolod.info/Official-DynDOLOD-Support-Forum
Report the actual problem or error message without making unverified assumptions or asking leading questions. Read the explanations and tips below, especially about what information and logs to provide and how.

DynDOLOD DLL NG requires considerably less helper (non LOD) references than using PapyrusUtil/DynDOLOD DLL SSE.
Skyrim INI settings do not affect the number of dynamic LOD references being generated.

uGridsToLoad defines the area of cells around child worldspaces that require parent->child copies.

Increasing uGridsToLoads means LOD starts further away - that means there is less LOD and more full models being shown.
Decreasing uGridsToLoads means LOD starts closer - that means there is more LOD and less full models being shown.