DynDOLOD 3.00 Alpha 196

[DoubleYou]

The very first bug on Heart of the Reach is for this. The tree mesh indicates a tree glow map texture that it doesn't provide, which is likely a mistake in the nif file for that mod. If you know how to use Nifskope, it is an easy fix.

https://www.nexusmods.com/skyrimspecialedition/mods/76494?tab=bugs

[Cayamc]

I don't know how to use nifskope but i will learn, thank you for pointing that out. 

[sheson]

5 hours ago, Cayamc said:

When i generate TexGen texture i get missing textures or meshes and i don't understand why. Everything is fine when i play the game. I allready reinstalled all the main files 3 times to be sure anything isnt missing. 

When i use the output afterwards, i get a lot of blue assets in the world.. I'm using mostly parallax textures btw. The logs, the modlist and the skyrim ini is in the files. Thank you so much for your kindness. 

TexGen_SSE_Debug_log.zip 424.26 kB · 3 downloads Skyrim.ini 2.89 kB · 0 downloads modlist.txt 46.77 kB · 0 downloads

Moved to the DynDOLOD 3 Alpha thread.
Read the first post which log file to also upload when making posts. You only uploaded the TexGen log, while the posts hints missing textures problems after the LOD patch generation as well.

Read https://dyndolod.info/Messages/File-Not-Found-Meshes and https://dyndolod.info/Messages/File-Not-Found-Textures.

Find out which mods are missing assets. Double check their requirements and installation instructions. Check their comments or bugs sections for related posts.

https://dyndolod.info/Mods/Beyond-Skyrim-Bruma
File not found errors are because not all required assets for LOD generation ship with the mod.

[Mousetick]

About the "Moved large reference" warnings, thanks for adding them.

It looks like the warning is issued if any ESM plugin in the stack moves the LR to a different cell, even if the last, winning ESM plugin in the stack places it back into its original cell. Is this the expected warning behavior? If yes, why is that?

Hypothetical example (next plugin overrides previous):

• Skyrim.esm REFR XYZ places Object_1 in cell Cell_A (REFR is LR)
• Plugin1.esm REFR XYZ places Object_1 in cell Cell_B (LR is moved)
• Plugin2.esm REFR XYZ places Object_1 in cell Cell_A (winning override)

DynDOLOD (Alpha 106) issues a warning "Moved large reference from Cell_A to Cell_B Skyrim.esm [REFR:XYZ]..."

This looks like a false positive to me.

Thanks.

[z929669]

6 hours ago, Mousetick said:

About the "Moved large reference" warnings, thanks for adding them.

It looks like the warning is issued if any ESM plugin in the stack moves the LR to a different cell, even if the last, winning ESM plugin in the stack places it back into its original cell. Is this the expected warning behavior? If yes, why is that?

Hypothetical example (next plugin overrides previous):

• Skyrim.esm REFR XYZ places Object_1 in cell Cell_A (REFR is LR)
• Plugin1.esm REFR XYZ places Object_1 in cell Cell_B (LR is moved)
• Plugin2.esm REFR XYZ places Object_1 in cell Cell_A (winning override)

DynDOLOD (Alpha 106) issues a warning "Moved large reference from Cell_A to Cell_B Skyrim.esm [REFR:XYZ]..."

This looks like a false positive to me.

Thanks.

My guess is that it's expected behavior because it's still an issue with the offending plugin (false positive for LO but not for the plugin), regardless of whether or not another plugin resolves it. More errors probably will increase the number of reports to the MA and potentially invoke education/understanding/remediation.

[z929669]

On 11/24/2022 at 11:08 PM, MisterMorden said:

Ok sheson, I finally was able to get my latest logs (106 alpha, no bugreport generated).  This was with the none, none, none, none, far full, unchanged mesh rule for giant campfires.  The other reference dropdown options didn't resolve the issue of the no flaming lod.  I have also included a link to some screenshots I took of walking through the issue.  I'm also currently in talks with the author of embers xd to see if it may be a mod issue.  I hope this information redeems my speculative past posts somewhat, lol.

logs: https://ufile.io/f/8qbp2

pics: https://imgur.com/a/TSzVR6d

Thanks again for your help!

Expanding on what sheson said in his response to this, it may be the root block type for the NIF. You can try editing the NIF yourself to use the proper type:
 

Quote

 

Root Block
The root node block type of a NIF for object models should typically be a BSFadeNode.

Dynamically enabling models with a root node block type other than BSFadeNode, BSLeafAnimNode or BSTreeNode causes CTD, hence the NIF is ignored for dynamic LOD.

The root node block type can be converted or changed with NifSkope. Right click the [0] NiNode, select Block, Convert, Bethesda, BSFadeNode, then save the updates NIF.

Certain types of models like grasses for example may be reported (vanilla grass models use BSFadeNode, so well made mods should follow that convention as well) but are never used for dynamic LOD anyways.

 

 

[z929669]

On 11/25/2022 at 4:11 AM, Mousetick said:

Hello,

I have a few comments and questions.

• I don't mind at all installing new DynDOLOD Alpha versions from scratch each time a new update comes out - that's an understandable, necessary part of the process to ensure a clean, up-to-date slate. I'm a bit annoyed by having to set up all options from scratch in Advanced mode after each update, though. So I've been cheating: I reload a preset saved from a previous version, which can be the default one (DynDOLOD_SSE_Default.ini) that DynDOLOD generates automatically.

Is this bad, doctor? I have a suspicion that's it's not very good, because the preset file appears to contain rules copied verbatim from the "factory/built-in" rules. In case some built-in rules changed from one version to the next, the new rules would not be reflected after reloading the preset.

I essentially do the same in this situation but incorporate a diff analysis (e.g., WinMerge) to see what is unexpected after generating a new preset using my typical DynDOLOD GUI selections and comparing to my previous. Otherwise, yes, this could be bad. I can further confirm that using an old DynDOLOD preset can occasionally prevent DynDOLOD from working (e.g., fails to load).

[koopastroopas]

The only tree mod I use is 'Happy Little Trees' and I am getting these black boxes around trees, they start disappearing as I get closer to them and the trees finally show up. HLT is only losing conflicts to SMIMM which includes the new 4K replacer by Xilamonster, Skyland AIO and Turn of the Seasons. This has never happend to me before.

[sheson]

27 minutes ago, koopastroopas said:

The only tree mod I use is 'Happy Little Trees' and I am getting these black boxes around trees, they start disappearing as I get closer to them and the trees finally show up. HLT is only losing conflicts to SMIMM which includes the new 4K replacer by Xilamonster, Skyland AIO and Turn of the Seasons. This has never happend to me before.

Moved to the DynDOLOD 3 Alpha thread, assuming you are using it because of Seasons etc.

Read the first post which logs and debug logs to upload when making posts.

Run TexGen before DynDOLOD. https://dyndolod.info/Generation-Instructions

[koopastroopas]

I clicked the link you sent and noticed that on the step pictures of MO Dyndolod Scripts is overwriting Dyndolod DLL. In my case I have Dyndolod DLL overwriting Dyndolod Scripts. I am using 'Gamerpoets' most recent guide on setting up DyndoLOD and that is how he says to set them up. So do I change it to how it is on the link? And if I do, do I have to run Dyndo and Texgen again?

[Mousetick]

13 hours ago, z929669 said:

My guess is that it's expected behavior because it's still an issue with the offending plugin (false positive for LO but not for the plugin), regardless of whether or not another plugin resolves it.

Perhaps. It'd be good to clarify the intended behavior, though.

Here's a practical example that should be easy to reproduce. Load order with USSEP and SLAWF (both latest versions):

• Skyrim.esm REFR:0007AE01 places RockPileL03 in cell 000092BD <EastEmpireTradingCompanyDocks>
• USSEP.esp REFR:0007AE01 places RockPileL03 in cell 0000929C <EastEmpireWarehouseExterior>
• SLAWF.esp REFR:0007AE01 places RockPileL03 in cell 000092BD <EastEmpireTradingCompanyDocks>

The warning emitted by DynDOLOD a106 in this case is:

<Warning: Moved large reference from [-17,23] to [-17,24] Skyrim.esm [REFR:0007AE01] (places RockPileL03 [STAT:000185BD] in GRUP Cell Temporary Children of EastEmpireTradingCompanyDocks [CELL:000092BD] (in Tamriel "Skyrim" [WRLD:0000003C] at -17,23))>

If the goal is to incriminate USSEP, the warning is not doing that.

13 hours ago, z929669 said:

More errors probably will increase the number of reports to the MA and potentially invoke education/understanding/remediation.

Great idea but wishful thinking, I'm afraid. Apart from mods maintained by STEP and a few MAs, the overall attitude seems to be ignorance or plain rejection. Following are some concrete examples:

Spoiler

• From the Beyond Reach MA, a pretty big and popular mod:

Quote

Stop posting bugs related to DYNDOLOD. Take it to the bugs section. I will be deleting any comments related to DYNDOLOD or TEXGEN in the comments section.

The bugs section is closed. There is bugs topic in the forum section, where a lot of DynDOLOD warnings are reported, completely ignored by the MA.

• Midwood Isle, another pretty popular mod, has a bugs section where DynDOLOD warnings are reported, and ignored.
• From the Changelog of Legacy of the Dragonborn, a very popular mod: (emphasis added)

Quote

Fixes #1313 - DyndoLOD will no longer moan about irrelevant meshes.

There are still warnings despite the fix, LOL.

I could find more examples, but you get the idea.

Not to mention issues with mods that are no longer maintained: reporting to the MA is pointless.

[sheson]

7 hours ago, koopastroopas said:

I clicked the link you sent and noticed that on the step pictures of MO Dyndolod Scripts is overwriting Dyndolod DLL. In my case I have Dyndolod DLL overwriting Dyndolod Scripts. I am using 'Gamerpoets' most recent guide on setting up DyndoLOD and that is how he says to set them up. So do I change it to how it is on the link? And if I do, do I have to run Dyndo and Texgen again?

DynDOLOD DLL and DynDOLOD DLL Scripts have no conflicting files. https://dyndolod.info/Help/DynDOLOD-DLL 

[sheson]

20 hours ago, Mousetick said:

About the "Moved large reference" warnings, thanks for adding them.

It looks like the warning is issued if any ESM plugin in the stack moves the LR to a different cell, even if the last, winning ESM plugin in the stack places it back into its original cell. Is this the expected warning behavior? If yes, why is that?

Hypothetical example (next plugin overrides previous):

• Skyrim.esm REFR XYZ places Object_1 in cell Cell_A (REFR is LR)
• Plugin1.esm REFR XYZ places Object_1 in cell Cell_B (LR is moved)
• Plugin2.esm REFR XYZ places Object_1 in cell Cell_A (winning override)

DynDOLOD (Alpha 106) issues a warning "Moved large reference from Cell_A to Cell_B Skyrim.esm [REFR:XYZ]..."

This looks like a false positive to me.

Thanks.

This is deliberate. All overwrites are checked. Reverting the position does not fix the issues that are being caused by a large reference being moved out of its original cell. You will find that all overwrites are being ignored depending on the direction the cell was approached, as can be seen by More Informative Console reporting Skyrim.esm as the only plugin affecting the reference regardless of any other plugin overwriting the record. These are relatively new findings.

DynDOLOD large reference bugs workarounds mitigate the issues. 

[Mousetick]

Thanks for the clarification, sheson. That makes sense and I was wrong about the false positive.

38 minutes ago, sheson said:

You will find that all overwrites are being ignored depending on the direction the cell was approached, as can be seen by More Informative Console reporting Skyrim.esm as the only plugin affecting the reference regardless of any other plugin overwriting the record.

I didn't notice Skyrim.esm being reported in MIC before. That's quite useful for telling that something's definitely wrong.

[kingpatzer]

Getting an OpenGL: Invalid Operation error when performing the Run Texgen step. 

log attached (log file is slightly larger than limit, so zipped it up).

TexGen_SSE_Debug_log.7z