DynDOLOD 3.00 Alpha 180

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

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

After a short amount of time Dyndolod will close its self but MO2 insists its still running and gives me an option to unlock it. 
 

[IX_Flipyap]

2 hours ago, IX_Flipyap said:

Northern Roads was causing the crashes

 

 

[sheson]

7 hours ago, IX_Flipyap said:

After a short amount of time Dyndolod will close its self but MO2 insists its still running and gives me an option to unlock it. 
 

No information which DynDOLOD version is being used. No log has been upload.

DynDOLOD closes only after user action and writes the log file. If that does not happen, it means it is being terminated by the OS or antvir maybe.

I suggest to actually read the MO2 message what it says is still running.

5 hours ago, IX_Flipyap said:

 

That does not really explain anything. Typically problematic records of assets should create an approbriate error message.