DynDOLOD 3.00 Alpha 180

[jiggajigga82]

7 minutes ago, sheson said:

Depends on the type of NIF and how it it used. You do not need to worry about any that are not reported. https://dyndolod.info/Messages/Root-Block

Perfect, thanks!

[MisterMorden]

2 hours ago, sheson said:

"LOD associated ini" does tell us which INI setting you are talking about. I can only hope it doesn't mean INI settings for static object LOD under TerrainManager, since they are obviously irrelevant.

What I meant was ini values with LOD in the names.  I didn't mess with anything under [TerrainManager], but I did try increasing fLightLODMaxStartFade, fLightLODStartFade, fLODFadeOutMultItems, fLODFadeOutMultObjects, fLODFadeOutMultSkyCell (although I didn't hold out much hope with these).  I wouldn't push my fBlockLevel0, 1 & Maximum past where I have them now (75000, 165000 & 335000 respectively).

[z929669]

DynDOLOD "ErrorSelectingRenderedContent"

The associated help for this message does not address this one.

Logs

PS: LODGen process continued on in the background, so I killed it myself.

 

[DoubleYou]

7 hours ago, MisterMorden said:

What I meant was ini values with LOD in the names.  I didn't mess with anything under [TerrainManager], but I did try increasing fLightLODMaxStartFade, fLightLODStartFade, fLODFadeOutMultItems, fLODFadeOutMultObjects, fLODFadeOutMultSkyCell (although I didn't hold out much hope with these).  I wouldn't push my fBlockLevel0, 1 & Maximum past where I have them now (75000, 165000 & 335000 respectively).

The giant campfire models from Embers XD appear to have the EnvMap_Light_Fade flag on them, so ensure that you have the associated fade settings high enough to be visible from far away.

Skyrim.ini

[LightingShader]
fEnvmapLODFadeEnd=1.0000
fEnvmapLODFadeStart=1.0000

BethINI also provides this tweak as a part of its presets.

[MisterMorden]

1 hour ago, DoubleYou said:

The giant campfire models from Embers XD appear to have the EnvMap_Light_Fade flag on them, so ensure that you have the associated fade settings high enough to be visible from far away.

Skyrim.ini

[LightingShader]
fEnvmapLODFadeEnd=1.0000
fEnvmapLODFadeStart=1.0000

BethINI also provides this tweak as a part of its presets.

Ah, ok thank you DY I will check that.

edit - No, they were already set there.

Edited November 23, 2022 by MisterMorden

[kookok]

Hello,

I am fairly new to modding, and installed a couple of mods and read somewhere that I need to generate LODs for things to "display properly". So with that, I've gone ahead and followed basic tutorials on how to use DyndoLOD 3.

At the first step (TexGen), no errors or warnings of any kind, but when I start to do DyndoLOD, I get these warnings. Things I've read on the website is untranslatable for me, since it only explains things about references, but it doesn't actually tell me what is going to happen in the game (missing textures, crashes, etc.)

Here's my errors: https://paste.ee/p/Jxspy

Basically, I'm humbly asking for a layman's explanation of what's going to happen to my game if I ignore those errors and proceed to playing, rather than telling me the technical details on why this is happening. I have close to 0 knowledge using SSEdit, and I have very limited knowledge as far as load orders would go. I did order it to the best of my abilities, but I am unsure if that has anything to do with the warnings I see when I use DyndoLOD.

Would also love some advice on what I can do to fix these errors!

Thank you in advance for any help.

Edited November 23, 2022 by kookok
Added dyndolod tag.

[sheson]

47 minutes ago, kookok said:

Hello,

I am fairly new to modding, and installed a couple of mods and read somewhere that I need to generate LODs for things to "display properly". So with that, I've gone ahead and followed basic tutorials on how to use DyndoLOD 3.

At the first step (TexGen), no errors or warnings of any kind, but when I start to do DyndoLOD, I get these warnings. Things I've read on the website is untranslatable for me, since it only explains things about references, but it doesn't actually tell me what is going to happen in the game (missing textures, crashes, etc.)

Here's my errors: https://paste.ee/p/Jxspy

Basically, I'm humbly asking for a layman's explanation of what's going to happen to my game if I ignore those errors and proceed to playing, rather than telling me the technical details on why this is happening. I have close to 0 knowledge using SSEdit, and I have very limited knowledge as far as load orders would go. I did order it to the best of my abilities, but I am unsure if that has anything to do with the warnings I see when I use DyndoLOD.

Would also love some advice on what I can do to fix these errors!

Thank you in advance for any help.

Moved to the DynDOLOD 3 Alpha thread. Read the first post.

See this existing answer https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-106/?do=findComment&comment=265482.

It is unclear what warning or error message about problems in the load the order you need further help for in addition to the existing explanations.

Always use the latest version.
Do not install the game into special folders like Program Files x86 to avoid issues with Windows UAC, antivir etc.

[sheson]

11 hours ago, z929669 said:

DynDOLOD "ErrorSelectingRenderedContent"

The associated help for this message does not address this one.

Logs

PS: LODGen process continued on in the background, so I killed it myself.

 

Is this repeatable?

If so, does adding TextureCache=100 below [DynDOLOD] to DynDOLOD_SSE.INI change anything?

[MisterMorden]

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!

[sheson]

3 hours ago, 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!

All further away fires look the same to me regardless of the original reference/base record in Skyrim.esm or the ones copied to DynDOLOD plugins. 

As I already said, it probably has to do with the how the NIF is made and corresponding INI settings. Particles count, decal fade maybe.

Since just flying away with tlc from the fire just changed by the mod has the same effect, there is nothing any DynDOLOD setting can do about it.

[Mousetick]

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.

• If all REFRs to a STAT are marked Deleted in a patch, DynDOLOD still considers that the STAT has references and keeps validating it. So even if there are no more references to this STAT in the full load order, it still issues warnings about a missing mesh or texture, even though they will never be loaded by the game.

I understand this is probably a byproduct of how xEdit works (as xEdit still counts those deleted references), but it's rather misleading. The only way to suppress the validation and warnings, is to completely remove the REFRs directly from the plugin. Which is fine if it's an old mod that's not been maintained in ages, but much less viable, compared to a patch, for a mod that's actively maintained and regularly updated (in which case the removals have to be applied again, and again).

• After I reported some issues with missing meshes and textures detected by DynDOLOD to a mod author, the mod author replied that I wasn't supposed to generate LODs for the new worldspaces in their mods, because some of them are unfinished (fair enough, thanks for not telling us) and the others "are too small for LoD to be an issue". Yet the mod is packaged with ../lodsettings/*.lod files for some of those worldspaces.

What exactly is the purpose of the lodsettings file? I know DynDOLOD uses them to determine if they are eligible for LOD generation, and thus selectable in the list of worldspaces. But how are they used by the game? Are they generated on demand by the mod author in CK, or automatically by CK without the mod author's knowing?

Is there a configuration file-based mechanism to tell DynDOLOD to ignore a whole mod or specific worldspaces? Preferably an ad-hoc external mechanism, not by editing ../Edit Scripts/DynDOLOD/DynDOLOD_[GAMEMODE].ini or ../Edit Scripts/DynDOLOD/Configs/DynDOLOD_[GAMEMODE]_mod_world_ignore.txt which are reset to factory state with each update (see 1st point above).

And now for something that has nothing to do with DynDOLOD:

• What is the meaning of the 'Small World' flag on a worldspace, and what is its significance in regards to LODs, if any? I can't find any useful information online, other than "small world loads faster". Why is it a flag that can be set at will by a mod author, seemingly regardless of the actual world size, and why is it not determined automatically, either by CK or the engine?

Thanks

[sheson]

1 hour ago, 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.

• If all REFRs to a STAT are marked Deleted in a patch, DynDOLOD still considers that the STAT has references and keeps validating it. So even if there are no more references to this STAT in the full load order, it still issues warnings about a missing mesh or texture, even though they will never be loaded by the game.

I understand this is probably a byproduct of how xEdit works (as xEdit still counts those deleted references), but it's rather misleading. The only way to suppress the validation and warnings, is to completely remove the REFRs directly from the plugin. Which is fine if it's an old mod that's not been maintained in ages, but much less viable, compared to a patch, for a mod that's actively maintained and regularly updated (in which case the removals have to be applied again, and again).

• After I reported some issues with missing meshes and textures detected by DynDOLOD to a mod author, the mod author replied that I wasn't supposed to generate LODs for the new worldspaces in their mods, because some of them are unfinished (fair enough, thanks for not telling us) and the others "are too small for LoD to be an issue". Yet the mod is packaged with ../lodsettings/*.lod files for some of those worldspaces.

What exactly is the purpose of the lodsettings file? I know DynDOLOD uses them to determine if they are eligible for LOD generation, and thus selectable in the list of worldspaces. But how are they used by the game? Are they generated on demand by the mod author in CK, or automatically by CK without the mod author's knowing?

Is there a configuration file-based mechanism to tell DynDOLOD to ignore a whole mod or specific worldspaces? Preferably an ad-hoc external mechanism, not by editing ../Edit Scripts/DynDOLOD/DynDOLOD_[GAMEMODE].ini or ../Edit Scripts/DynDOLOD/Configs/DynDOLOD_[GAMEMODE]_mod_world_ignore.txt which are reset to factory state with each update (see 1st point above).

And now for something that has nothing to do with DynDOLOD:

• What is the meaning of the 'Small World' flag on a worldspace, and what is its significance in regards to LODs, if any? I can't find any useful information online, other than "small world loads faster". Why is it a flag that can be set at will by a mod author, seemingly regardless of the actual world size, and why is it not determined automatically, either by CK or the engine?

Thanks

1. The rules can/should be updated by clicking low, medium, high. All the other settings might change, removed or added and thus interfere, so you are on your own doing this. If you have custom rules for specific mods that you want to keep, put them into a rules file for the mod's plugin and make them available in games data folder.  https://dyndolod.info/Mod-Authors#How-to-add-a-rule-file-for-a-plugin

2. Plugins should be cleaned. There should be no deleted references. How would you know about a plugin having unneeded/defunct records that all can/should be removed without DynDOLOD reporting them? As explained at https://dyndolod.info/Messages/File-Not-Found-Meshes, it is up to a human to verify/decide.

3. That statement ignores the error/problem you reported which exists regardless of generating LOD or not. The statement ignores that LOD is unique to the load order and user preferences and that DynDOLOD is the advanced and improved version of xLODGen to generate a patch - it does a many things more than "just" generate vanilla style LOD. 
The lodsettings file tells the engine that are LOD files to show beyond the active cells and contains information about the origin cell of the LOD (required to know the filenames) and the LOD levels.
If you do not want to generate LOD for a specific worldspace, then simply do not check it in the worldspace selection box. If there is a problem or issue with LOD generation for a mod/worldspace, then it should be reported here, so it can be investigated, troubleshooted, fixed or addressed properly. See https://dyndolod.info/Mod-Authors.

4. No idea what/if the flag actually does anything in the game. If a worldspace has LOD or not is determined by the existence of the lodsettings file.

[sheson]

On 11/15/2022 at 8:25 PM, Saint_Chewy said:

I fully agree with you Sheson I think that whatever is happening is unique to me because before I ever posted here I tried about a hundred different Google searches trying to see if anyone else had a similar issue and fix and really didn't find anything that was even close to what I am experiencing. Its extremely frustrating that this is happening because I am so close to having a perfect mod list set up. Its just strange that after all my testing it comes down to two very well made mods that somehow seem to be conflicting for just me (and my wife's computer). Also, I tried that mod that you linked and I regret to say that I still have that same exact stutter as before.

I thought the same thing as you that my ini files were the cause and because of that I have tried several different tests with my ini files. I have tried just plain vanilla ini files with no input from Bethini set from low to high, I have tried using Bethini to set the quality rather than the launcher, I have tried removing the custom ini and yeah all of that doesnt seem to make a lick of difference. I actually got my skyrimcustom.ini file from here. I even tried bypassing MO2 and installing these mods manually and using the ini files in the documents folder and that still doesnt make any difference. And probably more to be honest these were just at the front of my mind. It is quite maddening really. This is what my MO2 looks like right now when I do my tests, so nothing seems to be overriding the ini files for now.

I am really hoping that my new computer will fix this really dumb issue, but at the same time I am skeptical because I am also able to replicate the issue on my wife's computer. We both have Intel CPUs and Nvidia GPUs (she gets my hand-me-downs). My new computer is also going to be the same Intel/Nvidia combo, but I am hoping that with much faster RAM and a faster SSD that it might be good enough to push through. Fingers crossed!

Is there any change after saving and immediately loading that save without restarting? Anything different when saving and actually restarting the game and loading?

[Mousetick]

Thanks for your reply.

46 minutes ago, sheson said:

3. That statement ignores the error/problem you reported which exists regardless of generating LOD or not. The statement ignores that LOD is unique to the load order and user preferences and that DynDOLOD is the advanced and improved version of xLODGen to generate a patch - it does a many things more than "just" generate vanilla style LOD.

I couldn't agree more, but the unfortunate fact of the matter is that some mod authors do not understand, or are not even trying to understand the value of DynDOLOD as a custom LOD generation tool, and as a validation tool. They get very touchy and jumpy, and tend to be dismissive. In that particular case, I suspect the mod author gave me a bogus reason just to dismiss my report.

57 minutes ago, sheson said:

If you do not want to generate LOD for a specific worldspace, then simply do not check it in the worldspace selection box.

Right. I actually just did that and I still got the missing meshes/textures warnings. So either the objects are placed in vanilla worldspaces such as Tamriel, in which case the mod author is lying or has no clue how their mod works. Or DynDOLOD still validates all references even if they're in unselected worldspaces? I need to double-check in xEdit.

It's not that I don't want to generate the LODs but if the mod author is not cooperating there is not much choice than blacklisting specific worldspaces or the entire mod. I don't want to see the DynDOLOD warnings if I can't do anything myself to fix them and the mod author is not going to fix them - it's just noise that drowns the useful, interesting messages.

---

I have been getting these unexpected LR bug warnings with Alpha 106. Expected because they are indeed initially disabled LRs, but unexpected because the warnings refer to DynDOLOD.esm rather than the last overriding plugin before it in the load order. It's not a bug per se, as DynDOLOD.esm is indeed the last plugin to override these references (swapping the base for a NOFLAG variant), it's more of user interface / message clarity issue. Is this normal?

Warning: Initially disabled large reference in DynDOLOD.esm [REFR:000D3F51] (places ImpExtRubble01_DynDOLOD_NOFLAG [STAT:7C025EA4] in GRUP Cell Temporary Children of WhiterunWatchtowerExterior [CELL:00009A26] (in Tamriel "Skyrim" [WRLD:0000003C] at 0,-4))
Warning: Initially disabled large reference in DynDOLOD.esm [REFR:000D54D9] (places ImpExtRubble01_DynDOLOD_NOFLAG [STAT:7C025EA4] in GRUP Cell Temporary Children of WhiterunWatchtowerExterior [CELL:00009A26] (in Tamriel "Skyrim" [WRLD:0000003C] at 0,-4))
Warning: Initially disabled large reference in DynDOLOD.esm [REFR:000D54DA] (places ImpExtRubble01_DynDOLOD_NOFLAG [STAT:7C025EA4] in GRUP Cell Temporary Children of WhiterunWatchtowerExterior [CELL:00009A26] (in Tamriel "Skyrim" [WRLD:0000003C] at 0,-4))
Warning: Initially disabled large reference in DynDOLOD.esp [REFR:000E43B7] (places Farmhouse05Destroyed02_DynDOLOD_NOFLAG [STAT:7C025E6E] in GRUP Cell Persistent Children of [CELL:00000D74] (in Tamriel "Skyrim" [WRLD:0000003C]) at -2,-2)

Full relevant logs here if you want to take a look: https://drive.google.com/file/d/1nf_iChx9u8uXy1FxKzAe7A_etR3fMa_r/view

* Only running DynDOLOD for validation and sanity checking at this stage, ignore complaints about TexGen textures missing etc. Not using LR workarounds.

[Mousetick]

It seems that when DynDOLOD validates textures used by meshes, it stops at the first not found and reports it, then skips to the next mesh. Is this correct?

For example, it gave a warning like this:

Warning: File not found textures\texture1.dds. Used by meshes\mesh1.nif plugin.esm TreeEditorID1 [TREE:xxxxxxxx]

So I provided the missing diffuse texture1.dds, expecting that that mesh would be good to go on the next run. But the next time I ran DynDOLOD, it gave a new warning:

Warning: File not found textures\texture1_n.dds. Used by meshes\mesh1.nif plugin.esm TreeEditorID1 [TREE:xxxxxxxx]

Same mesh but now it's the normal texture.

It's done the same with several meshes. Can you confirm this is the intended behavior as implemented?

If it is, may I suggest, as a possible improvement, to report all missing textures for a given mesh at once, rather than incrementally, as the current behavior can be a bit counter-productive and time-consuming.

Unless the idea with the current behavior was to save processing time by skipping over as soon as a mesh is deemed 'defective'?