DynDOLOD 3.00 Alpha 169

[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'?

[sheson]

1 hour ago, Mousetick said:

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.

All base records and associated assets are scanned (before any worldspaces are processed). It only matters if a base record is reference by a reference (REFR) regardless of interior or exterior cells and if their worldspace is selected for LOD generation or not - since missing assets is an issue regardless of LOD generation.

1 hour ago, Mousetick said:

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 can only repeat that missing assets is a problem regardless of LOD generation. To make a message about a problem go away, fix the actual problem. Ignoring a problem whatever way does not fix the problem.

1 hour ago, Mousetick said:

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?

The last plugin to overwrite is typically blamed - typically DynDOLOD is supposed to just leave anything that cause bugs alone but with the large reference bugs workarounds things are in flux. The debug log tells us NoBrokenWhiterunTower.esp is probably the plugin causing it. With the large reference bugs

33 minutes ago, Mousetick said:

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'?

If a diffuse texture for Shader/BSTextureSet is missing there is no point in reporting if other textures are missing, too. They typically do. It also should be easy to spot when checking the model and or the folder where the texture are expected. It is a common programming method to fail early/fast to be faster. The primary function is to know if something is usable or not and to only keep a list of usable assets while printing a log message why something wasn't used.

[tooandrew]

hello again @sheson - last time i was dialing in my grassbrightness settings, i think you had me change values in LODGen_SSE_Export_Tamriel.txt and click execute lodgen, then when i figured it out, change those same values in DynDOLOD_SSE.ini and run dyndolod again. now, i don't have an execute lodgen button. in alpha 106. do i just dial it in by running dyndolod for tamriel only now? or is there something i can do to enable the execute lodgen button again?

thanks for all the work you do and all the help you provide.

[sheson]

21 minutes ago, tooandrew said:

hello again @sheson - last time i was dialing in my grassbrightness settings, i think you had me change values in LODGen_SSE_Export_Tamriel.txt and click execute lodgen, then when i figured it out, change those same values in DynDOLOD_SSE.ini and run dyndolod again. now, i don't have an execute lodgen button. in alpha 106. do i just dial it in by running dyndolod for tamriel only now? or is there something i can do to enable the execute lodgen button again?

thanks for all the work you do and all the help you provide.

https://dyndolod.info/Help/Grass-LOD#Updating
To test different GrassBrightnessTop*/GrassBrightnessBottom* or GrassBrightnessBottom*/ComplexGrassBrightnessBottom* settings, change them in ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_[WORLDSPACE].txt, start DynDOLOD in expert mode, select the desired worldspace and click the Execute LODGen button. 

https://dyndolod.info/Help/Expert-Mode
To start DynDOLOD in expert mode, use a text editor to set Expert=1 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini.

[Mousetick]

5 hours ago, sheson said:

All base records and associated assets are scanned (before any worldspaces are processed). It only matters if a base record is reference by a reference (REFR) regardless of interior or exterior cells and if their worldspace is selected for LOD generation or not - since missing assets is an issue regardless of LOD generation.

Wonderful. Thanks for clarifying and confirming this crucial detail.

5 hours ago, sheson said:

I can only repeat that missing assets is a problem regardless of LOD generation. To make a message about a problem go away, fix the actual problem.

But I'm not a mod author, I'm just a mod user. What do you expect me to do to fix the actual problem, exactly? I have no control over the mod author's ability or willingness to fix the actual problem. I can't produce missing meshes or textures out of thin air. Well, I could produce dummy ones, but that'd be silly. The only options at my disposal, as far as I can tell are:

• Either make a mental note that some warnings are "hopeless" and ignore them - something that bothers me greatly;
• Or go in xEdit and get rid of all the references to the broken base records

And the second option brings us back to a previous comment I made earlier and to which you replied:

8 hours ago, sheson said:

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.

To be honest I didn't understand your answer, and I may not have expressed my thought clearly in the first place.

In order to get rid of all the references to the broken base records, I have 2 options:

• Either remove them directly from the mod's plugin (right-click menu > Remove in xEdit)
• Or I can leave them intact in the mod's plugin and mark them as deleted in a patch plugin. A custom-made patch that is privately used by me only, and is not overridden by anything else.

From an in-game standpoint, both approaches are equivalent: the references are no more, they're not there, they're never loaded, never used.

The former approach is fine to operate on a dead mod, a mod which plugin is no longer maintained and will never change again. However it's not viable to operate on a mod that is updated regularly, because the references that were removed will come back with the next update, will need to be removed again, will come back again, will have to be removed again...

The latter approach is still effective even if the mod is updated and the broken base records come back in the updated plugin. My custom patch doesn't change. It's a time- and aggravation-saving feature, it's more efficient.  It doesn't get rid of the DynDOLOD warnings however, because deleted references are still counted for determining whether a base record should be scanned or not. So I'm back to square one, with warnings that I must ignore.

5 hours ago, sheson said:

The last plugin to overwrite is typically blamed - typically DynDOLOD is supposed to just leave anything that cause bugs alone but with the large reference bugs workarounds things are in flux.

Yeah that's fine, I can see which plugin is the actual culprit in xEdit, no worries. I just mentioned what looked to me like an unexpected diagnostic, because I wasn't sure if it could be indicative of a real issue.

5 hours ago, sheson said:

 It also should be easy to spot when checking the model and or the folder where the texture are expected. It is a common programming method to fail early/fast to be faster. The primary function is to know if something is usable or not and to only keep a list of usable assets while printing a log message why something wasn't used.

I beg to differ strongly on that point First, I'm not convinced that it's easy for the average user to "spot when checking the model and or the folder where the texture are expected", or that the average user knows intuitively that "other textures are missing too if the diffuse is missing". There is an apparent contradiction between the goal to validate assets and inform the user with easy to read/understand messages + helpful advice provided in the summary report, which is akin to hand-holding on one side. And then the decision to stop halfway through the validation, because "the rest is easy to figure out", which is akin to leaving the user to their own devices on the other side.

Second, the fail-fast approach is not appropriate in this case, IMHO. It's not like the file-check operation is overly time- or  resource-intensive to justify skipping it. Moreover, the validation phase is not a time-critical operation: it doesn't need to be completed as soon as possible. Nothing bad will happen if it takes a little while longer in order to be more comprehensive.

Third, in case a texture is found, the validation will move on to the next texture in the set on the mesh. All textures need to be checked in the end, no matter what. Why not simply check them all, always, in a single pass? Doing it incrementally as a result of the fail-fast takes much much longer for the end user.

Thanks. I hope you don't mind my comments and they're not interpreted as gratuitous criticism. My intent is to provide constructive/inquisitive feedback on my experiences using the tool, as well as to find ways to use it more effectively.

[tooandrew]

54 minutes ago, sheson said:

https://dyndolod.info/Help/Grass-LOD#Updating
To test different GrassBrightnessTop*/GrassBrightnessBottom* or GrassBrightnessBottom*/ComplexGrassBrightnessBottom* settings, change them in ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_[WORLDSPACE].txt, start DynDOLOD in expert mode, select the desired worldspace and click the Execute LODGen button. 

https://dyndolod.info/Help/Expert-Mode
To start DynDOLOD in expert mode, use a text editor to set Expert=1 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini.

what happened was i changed the ini files to expert mode in the backup of my installation and not the actual installation haha. thanks again

[sheson]

59 minutes ago, Mousetick said:

But I'm not a mod author, I'm just a mod user. What do you expect me to do to fix the actual problem, exactly? I have no control over the mod author's ability or willingness to fix the actual problem. I can't produce missing meshes or textures out thin air. Well, I could produce dummy ones, but that'd be silly. The only options at my disposal, as far as I can tell are:

• Either make a mental note that some warnings are "hopeless" and ignore them - something that bothers me greatly;
• Or go in xEdit and get rid of all the references to the broken base records

And the second option brings us back to a previous comment I made earlier and to which you replied:

I do not expect anyone to do anything. It is your load order and your choice what mods you use and if you fix problems or don't

DynDOLOD checks every base record to see if it contains a model that might be suitable for LOD. If it discovers a problem, it does not generate LOD for the base record or with the missing model/textures so that here is no problem like CTD or missing models/textures with the generated patch. The message about the problem is to help with troubleshooting, e.g. identify what/where a problem comes from.

If mods with problems bother you, tell the mod author about the issues hoping for a fix, fix them yourself or do not use the mod. If you want to fix things yourself, then you will  to educate yourself.

59 minutes ago, Mousetick said:

To be honest I didn't understand your answer, and I may not have expressed my thought clearly in the first place.

In order to get rid of all the references to the broken base records, I have 2 options:

• Either remove them directly from the mod's plugin (right-click menu > Remove in xEdit)
• Or I can leave them intact in the mod's plugin and mark them as deleted in a patch plugin. A custom-made patch that is privately used by me only, and is not overridden by anything else.

From an in-game standpoint, both approaches are equivalent: the references are no more, they're not there, they're never loaded, never used.

The former approach is fine to operate on a dead mod, a mod which plugin is no longer maintained and will never change again. However it's not viable to operate on a mod that is updated regularly, because the references that were removed will come back with the next update, will need to be removed again, will come back again, will have to be removed again...

The latter approach is still effective even if the mod is updated and the broken base records come back in the updated plugin. My custom patch doesn't change. It's a time- and aggravation-saving feature, it's more efficient.  It doesn't get rid of the DynDOLOD warnings however, because deleted references are still counted for determining whether a base record should be scanned or not. So I'm back to square one, with warnings that I must ignore.

If there is no model, then there is no point for any base record to define the non-existing model. By extension there should be no reference using such a base record.
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
If a plugin contains deleted references, it needs to be cleaned.

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