DynDOLOD 3.00 Alpha 198

[mattski123]

Hey, I get a crash after loading my game. And no crash once I disable my dyndolod output. Files attached. https://ufile.io/9577yl0q

crash-2022-11-25-20-49-23.log bugreport.txt

[sheson]

11 minutes ago, mattski123 said:

Hey, I get a crash after loading my game. And no crash once I disable my dyndolod output. Files attached. https://ufile.io/9577yl0q

crash-2022-11-25-20-49-23.log 66.15 kB · 0 downloads bugreport.txt 180.09 kB · 0 downloads

The bugreport.txt has a date from March this year.
The DynDOLOD log contains generation processes from Alpha 94 up to 106

https://dyndolod.info/Installation-Instructions
Use 7-Zip to unpack the DynDOLOD Standalone archive into a new and empty 'DynDOLOD' directory that is outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game, Data or any mod manager folders. For example C:\Modding\DynDOLOD\.

What about the reference 0x090271F4 in Synthesis 1.esp as reported by the crash log? Have you checked the record in xEdit?
Synthesis 1.esp (and Synthesis 2.esp) were not loaded when generated the LOD patch.

https://dyndolod.info/Generation-Instructions#Prerequisites
Typically create all other patches first. Especially all patches affecting exterior worldspaces in any way should be done before generating LOD.

https://dyndolod.info/Generation-Instructions#2-Generate-The-LOD-Mod-with-DynDOLOD
Make sure all mods, plugins and patches (that affect exterior cells and worldspaces and base records used by references in exterior cells) are enabled and their overwrite order is sorted.

[Mousetick]

37 minutes ago, sheson said:

Generally, remove the base record and remove any reference. If for some reason a reference (overwrite) still needs to exist, it should use a base record that does not define any model or defines an existing invisible model, like xmarker.nif. For example have the reference use the base record 0x0000003B

Yep, that's exactly what I've been doing. It's good to know I've not been missing a better solution. It's a big pain in the neck though.

[mattski123]

1 hour ago, sheson said:

The bugreport.txt has a date from March this year.
The DynDOLOD log contains generation processes from Alpha 94 up to 106

https://dyndolod.info/Installation-Instructions
Use 7-Zip to unpack the DynDOLOD Standalone archive into a new and empty 'DynDOLOD' directory that is outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game, Data or any mod manager folders. For example C:\Modding\DynDOLOD\.

What about the reference 0x090271F4 in Synthesis 1.esp as reported by the crash log? Have you checked the record in xEdit?
Synthesis 1.esp (and Synthesis 2.esp) were not loaded when generated the LOD patch.

https://dyndolod.info/Generation-Instructions#Prerequisites
Typically create all other patches first. Especially all patches affecting exterior worldspaces in any way should be done before generating LOD.

https://dyndolod.info/Generation-Instructions#2-Generate-The-LOD-Mod-with-DynDOLOD
Make sure all mods, plugins and patches (that affect exterior cells and worldspaces and base records used by references in exterior cells) are enabled and their overwrite order is sorted.

Oh my gosh, thank you and sorry! First time figuring things out with this more accurate Crash Logger.

[Mousetick]

Are you aware of, or have you encountered issues with object references or navmeshes which Z coordinate is below -30,000?

According to some anecdotal report, it's claimed these coordinates cause performance issues with the engine:

Spoiler

Quote

Kojak and Myself as well as others who have reported in from testing, have discovered that references and navmeshes (especially navmeshes) with z coordinates outside this -30 to +30k range cause issues with the game engine.  Most notably pretty bad micro stutter and hitching.  The best example of this was with Kojak's Enhanced Solitude Docks, which if anyone has used it prior to April of 2022, will know its got some pretty bad stutter and hitching and just all manner of performance issues.   Well we found that in his work to merge the base mods together to create ESD, there ended up being aproxximately 150+ navmeshes placed way below the -30k z coordinate boundary of the worldspace.  And upon deletion of these navmeshes (actual deletion not flagging as deleted)  Boom stutter gone.

We had these scripts created to investigate further in other mods and have found that a loot of mods have stuff set below -30k.  invididually each item doesnt seem to do too much, but en masse the engine just slows to a crawl.  Running the navmesh filter on a 1500 plugin load order in xEdit found almost 800 navmeshes set below -30k, after fixing perf in the effected areas significantly improved.  Evidence seems conclusive to us so heres the scripts so you can see for yourself.

I've used the xEdit scripts (see link above) provided by the mod author, which found and fixed quite a few over-limit Z coordinates in my load order, without ill effects. I can't say that "fixing" the Z coordinates made any difference in-game, because I didn't specifically test before/after.

Anyway, I brought this up as I was wondering if you had an opinion on the subject. I was also thinking, if these over-limit Z coordinates are indeed causing issues - and that's a big IF - they could be reported by DynDOLOD since it already scans a bunch of stuff and reports issues such as potential wild edits which are not strictly LOD-related.

[sheson]

29 minutes ago, Mousetick said:

Are you aware of, or have you encountered issues with object references or navmeshes which Z coordinate is below -30,000?

According to some anecdotal report, it's claimed these coordinates cause performance issues with the engine:

  Reveal hidden contents

I've used the xEdit scripts (see link above) provided by the mod author, which found and fixed quite a few over-limit Z coordinates in my load order, without ill effects. I can't say that "fixing" the Z coordinates made any difference in-game, because I didn't specifically test before/after.

Anyway, I brought this up as I was wondering if you had an opinion on the subject. I was also thinking, if these over-limit Z coordinates are indeed causing issues - and that's a big IF - they could be reported by DynDOLOD since it already scans a bunch of stuff and reports issues such as potential wild edits which are not strictly LOD-related.

I have not encountered or come across such reports. Maybe the reason for UDRs to be set to -30k and not any lower is deliberate. In that case I would assume that to be the result if something in older TES or FNV games.

I would like to see actual testing or something official from UESP or CK Wiki. I will check with the other xEdit devs. Such a message would be to the debug log only in case of navmeshes.

So far every check and message is related to the LOD patch. For example people would constantly report things floating above the center of the map, when in fact it is simply LOD for a reference that is placed there by a plugin. This check prevents LOD being added and to notify the user so they do not blame DynDOLOD only because its plugin is mentioned overwriting the base record or because it is the last thing that was added to the load order.

[IX_Flipyap]

2 hours ago, IX_Flipyap said:

Northern Roads was causing the crashes

 

 

[z929669]

On 11/23/2022 at 2:18 AM, sheson said:

Is this repeatable?

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

It's not repeatable, as my second run without any changes didn't invoke the error. I will be making a second pass from scratch though, as my driver issues and MO profile changes had tweaked some files that resulted in some strange unrelated issues. I re-downloaded the whole game and am going through basic cleaning and config of everything. I'll report any issues once I get to DynDOLOD.

[Cayamc]

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 Skyrim.ini modlist.txt

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