DynDOLOD Beta for Skyrim Special Edition, Skyrim VR and Enderal SE 2.98

[sm0kem]

LOOT is placing DynDOLOD.esp dead last in LO (i will double check if i don't have any custom rules set for it later today)

 

Does it matter if lean load order used for dyndolod is not continuous? Meaning there are gaps which will be filled with other plugins once full load is enabled. Or do you recommend keeping the continuity of the lod related plugins?

 

By cleaning, i meant stripping DynDOLOD plugins of unnecessary masters IF they were generated with full LO and picked up unrelated masters (i.e. some combat AI mod as an extreme example).

[sheson]

LOOT is placing DynDOLOD.esp dead last in LO (i will double check if i don't have any custom rules set for it later today)

 

Does it matter if lean load order used for dyndolod is not continuous? Meaning there are gaps which will be filled with other plugins once full load is enabled. Or do you recommend keeping the continuity of the lod related plugins?

 

By cleaning, i meant stripping DynDOLOD plugins of unnecessary masters IF they were generated with full LO and picked up unrelated masters (i.e. some combat AI mod as an extreme example).

There are no unnecessary masters in the DynDOLOD plugins. The xEdit Clean and Sort Masters functions are run on them before saving.

 

Are you saying loading a DynDOLOD plugin in xEdit and doing Clean Master from the right click menu removes any additional masters from the DynDOLOD plugins?

 

If that is the case I would like to know the plugin / mod.

Edited March 6, 2018 by sheson

[sm0kem]

Well, to be honest, I haven't done this using latest DynDOLOD, since i've been using "lean" load order for DynDOLOD generation since LE days, and sort of removed the posibility of picking up wrong masters.

But before I started doing that, yes, DynDOLOD plugin was picking unnecessary masters and needed to be manually cleaned (Clean/Sort Masters in xEdit). I still see this surfacing in discussions to this day though, and wanted to get your opinion on manually cleaning DynDOLOD.

 

Also very curious what your thoughts on below are:

 

Does it matter if lean load order used for dyndolod is not continuous? Meaning there are gaps which will be filled with other plugins once full load is enabled. Or do you recommend keeping the continuity of the lod related plugins?

Edited March 6, 2018 by sm0kem

[sheson]

Well, to be honest, I haven't done this using latest DynDOLOD since i've been using "lean" load order for DynDOLOD generation since LE days and sort of removed the posibility of picking up wrong masters.

But before I started doing that, yes, DynDOLOD plugin was picking unnecessary masters and needed to be manually cleaned (Clean/Sort Masters in xEdit). I still see this surfacing in discussions to this day though, and wanted to get your opinion on manually cleaning DynDOLOD.

 

Also very curious what your thoughts on below are:

 

Does it matter if lean load order used for dyndolod is not continuous? Meaning there are gaps which will be filled with other plugins once full load is enabled. Or do you recommend keeping the continuity of the lod related plugins?

There is no such thing as wrong masters, only confusion or not understanding why a plugin is a master. To quote your extreme example of an combat AI mod, that plugin also adds or changes something in a worldspace, cell, reference or base record or it changes a record that is linked by worldspace, cell, reference or base records. In early versions many years ago, DynDOLOD also added masters in case the master changed key values to keep load order consistency. Now it only keeps linked masters (a record referencing another) at the risk of having data in overwrites from plugins long gone from the load order.

 

DynDOLOD is a modified version of xEdit, so DynDOLOD runs the exact same xEdit Clean and Sort Master functions on the plugins before saving. Nothing should change in case someone runs the same functions with xEdit on the plugins again. If it does, I am interested in the plugins names that were removed or their order changed so we can troubleshoot the issue.

 

Gaps do not matter for the DynDOLOD plugins - after all they are very basic and simple. However, changing the plugin load order can cause stuck tree LOD issues  - in case a mod adding tree references is added/removed or the order of plugins that are adding tree references changes.

[sm0kem]

Makes sense. Thanks for detailed explanation.

 

P.S. I will let you know if i spot any masters that shouldn't be there (based on their records)

[sm0kem]

Quick question - is there an option to merge pregenerated tree lod meshes as opposed to generating from billboards?

[sheson]

Quick question - is there an option to merge pregenerated tree lod meshes as opposed to generating from billboards?

They are not really meshes, but data file. The data files do not contain the full load order form ID of trees, so matching the data back to the current load order and the tree references correctly is impossible. This means that it is unclear which trees already have LOD generated just by looking at the existing tree LOD. Then there would need to be quite some trickery to update the texture atlas. How would the software know it has the correct textures for the trees anyways.

 

Just generating tree LOD takes seconds without any such errors or uncertainties.

Edited March 7, 2018 by sheson

[clios_hand]

Hi all - I'm doing a new SE build, using 2.36 in MO2 (output is in e:/skyrim utils/ ) - everything went great except one error in Sovngarde World, LODGen_SSE_Sovngarde_log.txt says:

 

Can not get hash for shader in meshes\lod\sovngarde\sovngardestatue03_lod.nif block
Log ended at 11:33:59 PM
Code: 3005

 

So I did what it suggested: switch to Expert mode and regenerate with LODGEn64.exe.

 

Got same error, different nif:

 

Can not get hash for shader in meshes\lod\mountains\mountaintrim01_lod_0.nif block
Log ended at 9:53:33 PM
Code: 3005

 

? I tried googling round for this, haven't seen anything that helps. Do I need to try to dig these out, or...?

Edited March 12, 2018 by clios_hand

[sheson]

Hi all - I'm doing a new SE build, using 2.36 in MO2 (output is in e:/skyrim utils/ ) - everything went great except one error in Sovngarde World, LODGen_SSE_Sovngarde_log.txt says:

 

Can not get hash for shader in meshes\lod\sovngarde\sovngardestatue03_lod.nif block

Log ended at 11:33:59 PM

Code: 3005

 

So I did what it suggested: switch to Expert mode and regenerate with LODGEn64.exe.

 

Got same error, different nif:

 

Can not get hash for shader in meshes\lod\mountains\mountaintrim01_lod_0.nif block

Log ended at 9:53:33 PM

Code: 3005

 

? I tried googling round for this, haven't seen anything that helps. Do I need to try to dig these out, or...?

See if you get a more descriptive message with this version, just replace LODGenx64.exe in Edit Scripts and then Execute LODGen for the worldspace in expert mode again.

Also do a couple more tries to check if the nif is changing or not.

Edited March 12, 2018 by sheson

[mikegray]

I’m just getting back to Skyrim after a couple years away - and I’m learning how to mod SSE.

 

A stand alone DynDoLOD is a very fine thing indeed, and I’m pretty impressed. Running into one problem: 

 

At night, while most distant lights look terrific (say, Dragonsreach from a distance), the roadside Lanterns from Lanterns of Skyrim come out looking like a string of yellow lollipops - it’s like they’re waaaay too bright, and they have a harsh cut off. My guess is, I’ve got a setting wrong. Any tips? 

[sheson]

I’m just getting back to Skyrim after a couple years away - and I’m learning how to mod SSE.

 

A stand alone DynDoLOD is a very fine thing indeed, and I’m pretty impressed. Running into one problem: 

 

At night, while most distant lights look terrific (say, Dragonsreach from a distance), the roadside Lanterns from Lanterns of Skyrim come out looking like a string of yellow lollipops - it’s like they’re waaaay too bright, and they have a harsh cut off. My guess is, I’ve got a setting wrong. Any tips? 

 

Read the manual section about Glow LOD and Fake Lights in particular. Either change the brightness as explained or o not select the Fake lights selected world checkbox.

[clios_hand]

See if you get a more descriptive message with this version, just replace LODGenx64.exe in Edit Scripts and then Execute LODGen for the worldspace in expert mode again.

Also do a couple more tries to check if the nif is changing or not.

Thanks for the upload! Used that, but didn't get a more descriptive error because it just worked this time :)

"LODGenx64.exe for Sovngarde completed succesfully" and the sovngarde log looks good too.

 

Whatever you did, solved it - or the bug fled in terror, either way, thanks so much!

[Zetaeta]

For some reason DynDOLOD seems to be almost entirely ignoring the contents of my plugins while generating DynDOLOD.esp, and consequentially is overwriting everything it edits with the vanilla records, for example:

Undoing Better Dynamic Snow changes to static objects: https://imgur.com/a/4XXLl

Undoing Realistic Water Two changes to Tamriel worldspace https://imgur.com/a/f0meP

Undoing Cutting Room Floor changes to cell https://imgur.com/a/q07UJ

From a previous execution where I was generating 3D tree LODs it actually changed the meshes https://imgur.com/a/y2R8J

 

This was all with IgnoreLargeReferences=1, so there's no DynDOLOD.esm

Log here: https://pastebin.com/VezGh5ZL

 

Unless I've grossly misunderstood something this is not the intended behaviour?

[Zetaeta]

Also happens if Generate DynDOLOD is deactivated. This is the log for that with debug on: https://pastebin.com/fuMXZcgD

[sheson]

For some reason DynDOLOD seems to be almost entirely ignoring the contents of my plugins while generating DynDOLOD.esp, and consequentially is overwriting everything it edits with the vanilla records, for example:

Undoing Better Dynamic Snow changes to static objects: https://imgur.com/a/4XXLl

Undoing Realistic Water Two changes to Tamriel worldspace https://imgur.com/a/f0meP

Undoing Cutting Room Floor changes to cell https://imgur.com/a/q07UJ

From a previous execution where I was generating 3D tree LODs it actually changed the meshes https://imgur.com/a/y2R8J

 

This was all with IgnoreLargeReferences=1, so there's no DynDOLOD.esm

Log here: https://pastebin.com/VezGh5ZL

 

Unless I've grossly misunderstood something this is not the intended behaviour?

Looks like there is a bug with IgnoreLargeReferences=1. Will check and post an update some time later today.

Edited March 19, 2018 by sheson