DynDOLOD 3.00 Alpha 182

[PRieST]

4 hours ago, sheson said:

It seems none of the three reasons given at https://dyndolod.info/FAQ#Entire-LOD-missing apply.

Check what happens if you disable Occlusion.esp. If that makes no difference something probably happened to the LOD level 4 files or the engine loading them. Test with default INIs.

The MCM is a bit different for the large reference bugs workarounds, or rather for the dynamic LOD being done by DynDOLOD DLL NG.

Unrelated, but what is this supposed to be doing?
<Warning: Large references found in non master plugin LargeRefResolution.esp RiftenWorld "Rifton" [WRLD:00016BB4]>

Disable Occlusion.esp didn't do anything to this. I also looked at some of the created .bto files, they look quite good I checked 'Tamriel.4.4.-8.bto' as an example, because there are all trees missing when I am at WhiteRiverWatchExterior03 and looking down (good place to test DynDOLO IMO). The bto file itself looks absolutely fine.

I'll see what happens if I use dafault ini of skyrim - but I have to tell you, that I didn't mess with them since ages.

I'll also try and deactivate some SKSE plugins, maybe there is something odd happening (in the past I had a very confusing error with Dynamic Things Alternative, but that's not the case this time, but who knows.

Ok, that's why it's looking different.

Kind of forgot about that plugin and with the Large Reference Bug Workaround it might be obsolete. This was an old approach from me to solve the large reference bugs with this method

Quote

Alternatively, all large references of an affected cell could be moved underground out of view and new references replacing them could be added. These new reference wouldn't be large references. This is also a solution for large reference bugs triggered by the Initially Disabled flag in case it can not be removed.

from the help: https://dyndolod.info/Help/Large-References

Edit:
I checked what happens, if I disable DynDOLOD.esp, .esm and Occlusion.esp and output active, result was:
The whiterun castle was complete there, where it wasn't before. Still, the chunk with the trees (where I checked the .bto file) was 'empty'.

With also the SKSE plugin deactivated, all LOD are there, but also the fullmodels I think, because there is massive flickering.

Without the SKSE plugin, but all DynDOLOD plugins active I get an papyrus version mismatch error (absolutely obvious), less flickering (I know, there is something not working as supposed to be, thats also obvious) - I assume it's because of LOD and Fullmodel renderd at the same time, but the whiterun castle looks good and also the LOD 4 part is there and not vanished as it was, while the DynDOLOD NG SKSE Plugin is active. I only can assume that it's related to the plugin, but it looks like it is.
I'll mess with some SKSE plugins, deactivate a bunch and see, if there is any difference -> nothing found there.

Edited December 21, 2023 by PRieST

[sheson]

7 hours ago, PRieST said:

Disable Occlusion.esp didn't do anything to this. I also looked at some of the created .bto files, they look quite good I checked 'Tamriel.4.4.-8.bto' as an example, because there are all trees missing when I am at WhiteRiverWatchExterior03 and looking down (good place to test DynDOLO IMO). The bto file itself looks absolutely fine.

To test if this has anything with the BTO files, remove/hide them all.

7 hours ago, PRieST said:

I'll see what happens if I use dafault ini of skyrim - but I have to tell you, that I didn't mess with them since ages.

Post results of actual tests.

7 hours ago, PRieST said:

Ok, that's why it's looking different.

What looks diffrent and why?

7 hours ago, PRieST said:

Kind of forgot about that plugin and with the Large Reference Bug Workaround it might be obsolete. This was an old approach from me to solve the large reference bugs with this method

Remove unnecessary plugins that overwrite large references when using the large references bugs workarounds.

8 hours ago, PRieST said:

I checked what happens, if I disable DynDOLOD.esp, .esm and Occlusion.esp and output active, result was:
The whiterun castle was complete there, where it wasn't before. Still, the chunk with the trees (where I checked the .bto file) was 'empty'.

You mean LOD works fine but the content of Tamriel.4.4.-8.bto is not showing? Looking from where?
You mean only the LOD for trees is not showing, but all the other LOD from the same file is?

If vanilla/generated LOD works without the plugins, set PartialWorldspace=0 and PartialPersistentCell=0 in D:\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini and generate LOD for just Tamriel for a test to see if there are any changes.

8 hours ago, PRieST said:

With also the SKSE plugin deactivated, all LOD are there, but also the fullmodels I think, because there is massive flickering.

You mean DynDOLOD DLL NG? It does not affect how the engine loads terrain, object and tree LOD meshes.

[PRieST]

32 minutes ago, sheson said:

Post results of actual tests.
You mean LOD works fine but the content of Tamriel.4.4.-8.bto is not showing? Looking from where?
You mean only the LOD for trees is not showing, but all the other LOD from the same file is?

So I went in the game with the default ini, and yeah I am surprised, because this is the result (and compared to the other screenshots, there are even more trees visible..hm):
https://ibb.co/568XKXv

This is with my ini settings, so maybe there is something wrong I'll have to check, but as I said even with earliere alphas from DynDOLOD it worked, because the only setting I touched was the setting for particles:

https://ibb.co/ncvSMZX

Quote

You mean DynDOLOD DLL NG? It does not affect how the engine loads terrain, object and tree LOD meshes.

And this again is with my ini settings, but without the DynDOLOD DLL NG loaded:
https://ibb.co/MfHTsJG

Quote

What looks diffrent and why?

I meant the MCM, that it looks different now than I was used to, nothing special.

Quote

Remove unnecessary plugins that overwrite large references when using the large references bugs workarounds.

Of course, will get rid of it the next generation - just forgot about it to be honest.

Quote

If vanilla/generated LOD works without the plugins, set PartialWorldspace=0 and PartialPersistentCell=0 in D:\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini and generate LOD for just Tamriel for a test to see if there are any changes.

I'll give this another test and see what the results are.

Edited December 21, 2023 by PRieST

[sheson]

8 minutes ago, PRieST said:

So I went in the game with the default ini, and yeah I am surprised, because this is the result (and compared to the other screenshots, there are even more trees visible..hm):
https://ibb.co/568XKXv

If everything works as it should, then there is no need to generate with the changed settigs.

The DynDOLOD DLL NG is required for the full trees which are flagged as large references to to show to the edge of the uLargeRefLODGridSize where their object LOD starts. Otherwise full trees will only show to the edge of uGridsToLoad.

[PRieST]

2 minutes ago, sheson said:

If everything works as it should, then there is no need to generate with the changed settigs.

The DynDOLOD DLL NG is required for the full trees which are flagged as large reference to to show to the edge of the uLargeRefLODGridSize where their object LOD starts.

But than I'll have to figure out which setting is messing up the LOD loading for LOD 4, I don't have so much under [LOD] section which looks odd.

[PRieST]

The culprit is this in Skyrimprefs.ini under [General]

uLargeRefLODGridSize=11

Without that line everything looks fine.
But why? This wasn't a problem with earlier alpha versions.
This is from the DynDOLOD_SSE.ini:

; Because Bethesda simply does not comprehend people are modding exterior worldspaces ...
; set to 1 if uLargeRefLODGridSize=5 (value of uGridsToLoad) in SkyrimPrefs.ini, do this if it is certain that the large references system will not be used, so that no DynDOLOD.esm is created
; set to 0 if uLargeRefLODGridSize>5 (value of uGridsToLoad) in SkyrimPrefs.ini
IgnoreLargeReferences=0

 

Edited December 21, 2023 by PRieST

[leostevano]

Hi sheson, I just generated output with the new alpha. But it seems dragon's reach lod is bugged out. I didn't get any error except textures doesn't match warnings.

Screenshot : https://pasteboard.co/y5ZkqKJnVW2B.png

Logs : https://ufile.io/q2v18fr5

[sheson]

Just now, PRieST said:

The culprit is this in Skyrimprefs.ini under [General]

uLargeRefLODGridSize=11

Without that line everything looks fine.
But why? This wasn't a problem with earlier alpha versions.
This is from the DynDOLOD_SSE.ini:

; Because Bethesda simply does not comprehend people are modding exterior worldspaces ...
; set to 1 if uLargeRefLODGridSize=5 (value of uGridsToLoad) in SkyrimPrefs.ini, do this if it is certain that the large references system will not be used, so that no DynDOLOD.esm is created
; set to 0 if uLargeRefLODGridSize>5 (value of uGridsToLoad) in SkyrimPrefs.ini
IgnoreLargeReferences=0

Removing a setting from the INI, means its default value is used in the game.
You can check it with console getini "uLargeRefLODGridSize:General"
Do not remove the setting, simply leave it at 11. All large references should be shown up to its distance.

The uLargeRefLODGridSize setting does not affect LOD generation. Whatever its setting it should not affect terrain LOD that was also shown missing in your initial screenshots.

Upload a BTO from an area that you believe has issues.

[PRieST]

31 minutes ago, sheson said:

You can check it with console getini "uLargeRefLODGridSize:General"

(Maybe a dumb question, because I could just have tried both ways) With or without quotation marks? Because with it I just get "unknown type"
https://ibb.co/tbj0kgm
But I checked, if I get the default SkyrimPrefs.ini, what the value is and it is set to 5 (which is working). In my case setting it higher as 5 it breaks somehow the LOD display.

Quote

The uLargeRefLODGridSize setting does not affect LOD generation.

Generation was fine, but the display ingame is the culprit.

Quote

Upload a BTO from an area that you believe has issues.

https://www.file-upload.net/download-15241320/Tamriel.4.4.-8.7z.html

Definetly that one (the same spot jus looking left if you compare it to the screenshots). But as far as I can tell the .bto looks absolutely correct.

Edit:
Comparison between

uLargeRefLODGridSize=5

https://ibb.co/wR6FT1M
https://ibb.co/Bs8cYRd

uLargeRefLODGridSize=7

https://ibb.co/t3hRkbP
https://ibb.co/dpK5Xy4

uLargeRefLODGridSize=9

https://ibb.co/Nr2PX9C
https://ibb.co/0K1tYgh

and

uLargeRefLODGridSize=11

https://ibb.co/kXKDCZV
https://ibb.co/Bcs1jxd

Edited December 21, 2023 by PRieST

[sheson]

Just now, PRieST said:

(Maybe a dumb question, because I could just have tried both ways) With or without quotation marks? Because with it I just get "unknown type"
https://ibb.co/tbj0kgm
But I checked, if I get the default SkyrimPrefs.ini, what the value is and it is set to 5 (which is working). In my case setting it higher as 5 it breaks somehow the LOD display.

Generation was fine, but the display ingame is the culprit.

https://www.file-upload.net/download-15241320/Tamriel.4.4.-8.7z.html

Definetly that one (the same spot jus looking left if you compare it to the screenshots). But as far as I can tell the .bto looks absolutely correct.

This should be fixed generating the L:OD patch with Alpha-162.

[PRieST]

Ok, will give it a try, thank you.
What was the issue if I may ask? For me it looks like the display between uLargeRefLODGridSize 5 -> 11 was 'switched' /the wrong way round?

[leostevano]

47 minutes ago, sheson said:

Removing a setting from the INI, means its default value is used in the game.
You can check it with console getini "uLargeRefLODGridSize:General"
Do not remove the setting, simply leave it at 11. All large references should be shown up to its distance.

The uLargeRefLODGridSize setting does not affect LOD generation. Whatever its setting it should not affect terrain LOD that was also shown missing in your initial screenshots.

Upload a BTO from an area that you believe has issues.

Here you go, from this point Dragon's Reach is missing https://ufile.io/nmqg7wte

Screenshot : https://pasteboard.co/eQ95OQ2dDtXh.bmp

[sheson]

Just now, leostevano said:

Hi sheson, I just generated output with the new alpha. But it seems dragon's reach lod is bugged out. I didn't get any error except textures doesn't match warnings.

Screenshot : https://pasteboard.co/y5ZkqKJnVW2B.png

Logs : https://ufile.io/q2v18fr5

This should be fixed in Alpha-162.

[leostevano]

Just now, sheson said:

This should be fixed in Alpha-162.

That was fast, many thanks!

[PRieST]

40 minutes ago, sheson said:

This should be fixed generating the L:OD patch with Alpha-162.

Can confirm, it's fixed, thank you again.