DynDOLOD 3.00 Alpha 173

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

[leostevano]

I just noticed both dyndolod.esp and occlusion.esp doesnt carry over worldspace records. Is this intended?

[PRieST]

Yes, this is of the 'new' 'partial form' flag.
If the worldspace itself doesn't need to be edited (in which case we are here) you can set this flag and so the worldspace data doesn't get overwritten by DynDOLOD.esp/Occlusion.esp. That's why you also see no records inside these two plugins for the worldspaces.
That's a feature which was forever in the engine, but only recently included in xEdit and now DynDOLOD makes also use of it.

Edited December 22, 2023 by PRieST