DynDOLOD 3.00 Alpha 190

[DerpyBun]

I am also having the same issue as @miceZipper said above, but with Legacy of the Dragonborn.esm when trying to generate LOD with the latest DynDOLOD Alpha 45 build. Here's the Error Message:

[Window Title]
DynDOLOD

[Main Instruction]
Error processing Meshes\architecture\whiterun\wrbuildings\wrguardhouse01.nif: '-INF' is not a valid floating point value LegacyoftheDragonborn.esm WRGuardHouse01WWW [STAT:071219B1]

[Exit DynDOLOD]

[Footer]
DynDOLOD FAQ | Support Forum | Copy message to clipboard

[sheson]

  On 10/5/2021 at 8:49 AM, DerpyBun said:

I am also having the same issue as @miceZipper said above, but with Legacy of the Dragonborn.esm when trying to generate LOD with the latest DynDOLOD Alpha 45 build. Here's the Error Message:

[Window Title]
DynDOLOD

[Main Instruction]
Error processing Meshes\architecture\whiterun\wrbuildings\wrguardhouse01.nif: '-INF' is not a valid floating point value LegacyoftheDragonborn.esm WRGuardHouse01WWW [STAT:071219B1]

[Exit DynDOLOD]

[Footer]
DynDOLOD FAQ | Support Forum | Copy message to clipboard

Expand  

Read the first post which log file to upload when making posts.

[DerpyBun]

[sheson]

  On 10/5/2021 at 8:53 AM, DerpyBun said:

Expand  

It is very unlikely that vanilla meshes have infinite UV values. If that is what you are trying to show. No text explanations what we are supposed to be looking at were provided.

[DerpyBun]

Adding the log txt now

[DerpyBun]

Here are the LOG txt files

bugreport.txtFetching info... DynDOLOD_SSE_log.txtFetching info... DynDOLOD_SSE_Object_LOD.txtFetching info... DynDOLOD_SSE_Dynamic_LOD.txtFetching info...

  On 10/5/2021 at 9:05 AM, DerpyBun said:

Here are the LOG txt files

bugreport.txt 38.31 kB · 0 downloads DynDOLOD_SSE_log.txt 78.68 kB · 0 downloads DynDOLOD_SSE_Object_LOD.txt 407.19 kB · 0 downloads DynDOLOD_SSE_Dynamic_LOD.txt 18.39 kB · 0 downloads

Expand  

@sheson

[sheson]

  On 10/5/2021 at 9:05 AM, DerpyBun said:

Here are the LOG txt files

bugreport.txt 38.31 kB · 0 downloads DynDOLOD_SSE_log.txt 78.68 kB · 0 downloads DynDOLOD_SSE_Object_LOD.txt 407.19 kB · 0 downloads DynDOLOD_SSE_Dynamic_LOD.txt 18.39 kB · 0 downloads

@sheson

Expand  

Thanks. This is fixed in DynDOLOD 3.0 Alpha-46

[DerpyBun]

  On 10/5/2021 at 9:07 AM, sheson said:

Thanks. This is fixed in DynDOLOD 3.0 Alpha-46

Expand  

Thank you, by the way. I have generated the billboards for objects & tree LODs prior to making this report using the TexGen from DynDOLOD 3.0 Alpha-45 build without any errors.

Do I need to re-generate a new batch with the current Alpha-46 build or I can just continue using the current batch without problem?

Edited October 5, 2021 by DerpyBun

[sheson]

  On 10/5/2021 at 9:53 AM, DerpyBun said:

Thank you, by the way. I have generated the billboards for objects & tree LODs prior to making this report using the DynDOLOD 3.0 Alpha-45 build without any errors.

Do I need to re-generate a new batch with the current Alpha-46 build or I can just continue using it without problem?

Expand  

Check the change log what was updated between versions. If TexGen is not mentioned, then there is no change how it generates LOD assets.

As explained in the manual, DynDOLOD will print log messages if full models/textures used for billboard generation changed. If you see messages like "Billboard for model * does not contain texture" or "Billboard for model * has different CRC32", then you should run TexGen to generate up-to-date billboards.

[DerpyBun]

  On 10/5/2021 at 9:58 AM, sheson said:

Check the change log what was updated between versions. If TexGen is not mentioned, then there is no change how it generates LOD assets.

As explained in the manual, DynDOLOD will print log messages if full models/textures used for billboard generation changed. If you see messages like "Billboard for model * does not contain texture" or "Billboard for model * has different CRC32", then you should run TexGen to generate up-to-date billboards.

Expand  

Okay, thanks for the INFO.

[baron]

Can someone help me with this? This pops up every time I run the DynDOLODx64.

[sheson]

  On 10/5/2021 at 10:47 AM, baron said:

Can someone help me with this? This pops up every time I run the DynDOLODx64.

Expand  

Read the first post which log files to upload when making posts.

Read the first post which explains how to use "copy message to clipboard" in order to post error message instead of posting a screenshot.

Search this thread for similar error message and its discussion/solutions.

Use the latest version.

[narphous]

  On 10/5/2021 at 7:56 AM, sheson said:

Check the myriad of the warnings from the xEdit loader :

[00:04] Background Loader: Warning: Record [GLOB:00000037] in file Skyrim.esm is being overridden by record [TXST:01000037] in file NewStyleEyes.esm.
[00:04] Background Loader: Warning: Record [STAT:00000001] in file Skyrim.esm is being overridden by record [HDPT:01000001] in file NewStyleEyes.esm.
...

[00:05] Background Loader: Warning: Record [HDPT:01000027] in file NewStyleEyes.esm is being overridden by record [ENCH:01000027] in file RaijinSaku.esp.
[00:05] Background Loader: Warning: Record [STAT:00000001] in file Skyrim.esm is being overridden by record [REFR:01000001] in file RaijinSaku.esp.
...

Troubleshoot and fix those load order problems.

It seems the compacting of form IDs to flag plugins ESL went wrong somehow.

Expand  

So how would I do that? As I said, I re-ran the compact operation in CK, but no change. And loading my entire load order in xedit shows that none of those mods actually touches any of the records that DynDolod claims they overwrite. So as far as I can tell, it's not the mods that are the problem. For example, dyndoload claims that:

Computer says "Worldspace Editor ID Tamriel is changed to RecipeSED7fGbarbellGemEmerald HDT Piercingsets.esp RecipeSED7fGbarbellGemEmerald [COBJ:0000003C]"

The actual ID of RecipeSED7fGbarbellGemEmerald is FE00003C and it does not overwrite 0000003C] according to xedit.

Edited October 5, 2021 by narphous

[sheson]

  On 10/5/2021 at 12:53 PM, narphous said:

So how would I do that? As I said, I re-ran the compact operation in CK, but no change. And loading my entire load order in xedit shows that none of those mods actually touches any of the records that DynDolod claims they overwrite. So as far as I can tell, it's not the mods that are the problem. For example, dyndoload claims that:

Computer says "Worldspace Editor ID Tamriel is changed to RecipeSED7fGbarbellGemEmerald HDT Piercingsets.esp RecipeSED7fGbarbellGemEmerald [COBJ:0000003C]"

The actual ID of RecipeSED7fGbarbellGemEmerald is FE00003C and it does not overwrite 0000003C] according to xedit.

Expand  

DynDOLOD is a modified xLODGen, which is a tool mode of xEdit. If you use a current xEdit 4.1.3 experimental version, you should see the same warning messages when loading the plugins.

DynDOLOD does not claim anything. It is the xEdit loader that reports the facts about the plugins as it loads the plugins and then creates the internal data structures.

A form ID of FE00003C is an invalid object ID since it is is not in the allowed range between 0x800 and 0xFFF for light plugins (ESL). See ..\DynDOLOD\docs\help\LightPlugin.html

No plugin but Skyrim.esm shoud have form IDs < 0x800

All form IDs under 0x800 regardless of their plugin load order ID are always mapped to Skyrim.esm/exe and always mean the same records.

If you believe there is a problem with how xEdit loads plugins or reports such errors, make a report on its github or Discord.

[hitmantb]

Just to ask a newbie question, we are still supposed to use xLODGen to generate terrain LOD's right? I understand Occlusion.esp is no longer needed.

And install it to the end of load order before we run TexGen + Dyndolod?

I wish TexGen can just take care of this too haha.

Edited October 5, 2021 by hitmantb