DynDOLOD 3.00 Alpha 173

[DarthVitrial]

Got Error C0000142 while running LodGen ("Error: Texconv error C0000142 textures\lod\trees\treeaspenbranchcompautumn03.dds "H:\Dyndolod\Edit Scripts\Texconvx64.exe" -nologo -y -m 1 -aw 256 -f R8G8B8A8_UNORM -o "C:\Users\redhe\AppData\Local\Temp\DynDOLOD_SSE" "C:\Users\redhe\AppData\Local\Temp\DynDOLOD_SSE\596A512B1597405D82F3AE2B6B49D6CD.dds").

 (https://imgur.com/a/xVTojWT)

 

Logs: https://mega.nz/file/Z9NiHbwC#XrZ2gCBv5n-FYC7lycy47NqkcwSqYZJ2C8x3ytxxuTM
No bugreport generated.

The key part from the debug log seems to be this:

[05:51] 00000000 ???                                   
01244e4d DynDOLODx64.exe DynDOLODHelpers  9282 dynLoadImage
0122fcc7 DynDOLODx64.exe DynDOLODHelpers  7378 AddTexture
00ee84e1 DynDOLODx64.exe DynDOLODMain     6991 RetrieveTextureSets
00ef3e4f DynDOLODx64.exe DynDOLODMain     7376 DoObjectLOD$ActRec.$0$Body
00b8c222 DynDOLODx64.exe System.Threading      TParallel.ForWorker$ActRec.$0$Body
00b8f0f3 DynDOLODx64.exe System.Threading      TTask.ExecuteReplicates$ActRec.$0$Body
00b8ece0 DynDOLODx64.exe System.Threading      TTask.Execute
00b905af DynDOLODx64.exe System.Threading      TTask.InternalExecute
00b906dc DynDOLODx64.exe System.Threading      TTask.InternalWork
00b8f2d7 DynDOLODx64.exe System.Threading      TTask.ExecuteWork
00b96544 DynDOLODx64.exe System.Threading      TThreadPool.TQueueWorkerThread.ExecuteWorkItem
00b95f9d DynDOLODx64.exe System.Threading      TThreadPool.TQueueWorkerThread.Execute
005de270 DynDOLODx64.exe System.Classes        ThreadProc
0042aa05 DynDOLODx64.exe BrainMM          2540 BrainMMThreadProxy
0041214a DynDOLODx64.exe System                ThreadWrapper
00511c69 DynDOLODx64.exe madExcept             ThreadExceptFrame
7ffa0ad8 KERNEL32.DLL                          BaseThreadInitThunk

[sheson]

1 hour ago, DarthVitrial said:

Got Error C0000142 while running LodGen ("Error: Texconv error C0000142 textures\lod\trees\treeaspenbranchcompautumn03.dds "H:\Dyndolod\Edit Scripts\Texconvx64.exe" -nologo -y -m 1 -aw 256 -f R8G8B8A8_UNORM -o "C:\Users\redhe\AppData\Local\Temp\DynDOLOD_SSE" "C:\Users\redhe\AppData\Local\Temp\DynDOLOD_SSE\596A512B1597405D82F3AE2B6B49D6CD.dds").

 (https://imgur.com/a/xVTojWT)

 

Logs: https://mega.nz/file/Z9NiHbwC#XrZ2gCBv5n-FYC7lycy47NqkcwSqYZJ2C8x3ytxxuTM
No bugreport generated.

The key part from the debug log seems to be this:

  Reveal hidden contents

 

[05:51] 00000000 ???                                   
01244e4d DynDOLODx64.exe DynDOLODHelpers  9282 dynLoadImage
0122fcc7 DynDOLODx64.exe DynDOLODHelpers  7378 AddTexture
00ee84e1 DynDOLODx64.exe DynDOLODMain     6991 RetrieveTextureSets
00ef3e4f DynDOLODx64.exe DynDOLODMain     7376 DoObjectLOD$ActRec.$0$Body
00b8c222 DynDOLODx64.exe System.Threading      TParallel.ForWorker$ActRec.$0$Body
00b8f0f3 DynDOLODx64.exe System.Threading      TTask.ExecuteReplicates$ActRec.$0$Body
00b8ece0 DynDOLODx64.exe System.Threading      TTask.Execute
00b905af DynDOLODx64.exe System.Threading      TTask.InternalExecute
00b906dc DynDOLODx64.exe System.Threading      TTask.InternalWork
00b8f2d7 DynDOLODx64.exe System.Threading      TTask.ExecuteWork
00b96544 DynDOLODx64.exe System.Threading      TThreadPool.TQueueWorkerThread.ExecuteWorkItem
00b95f9d DynDOLODx64.exe System.Threading      TThreadPool.TQueueWorkerThread.Execute
005de270 DynDOLODx64.exe System.Classes        ThreadProc
0042aa05 DynDOLODx64.exe BrainMM          2540 BrainMMThreadProxy
0041214a DynDOLODx64.exe System                ThreadWrapper
00511c69 DynDOLODx64.exe madExcept             ThreadExceptFrame
7ffa0ad8 KERNEL32.DLL                          BaseThreadInitThunk

 

Use the "Copy message to clipboard" link to copy paste a message as text instead of making screenshots as explained on the first post.

C0000142 just means "failed" without any further information.

There might be a problem with the texture treeaspenbranchcompautumn03.dds (especially if the error is repeatable)_ or something happened to it after it was copied to the temp folder/filename or the OS or antivir interfered with texconv or it had some kind of trouble.

Check the texture is fine and what happens if you execute the command line on a copy on the windows command prompt.

[DarthVitrial]

I tried again and the error didn't repeat, oddly. Might have been a one-off thing.

It did seem to happen during the Seasons part of the generation.

I used the NifOptimizer texture scan tool, it didn't find any issue with that texture.

Edited September 2, 2022 by DarthVitrial

[DoubleYou]

@sheson

I know DynDOLOD allows using LOD via rules for MSTT moveable statics, but since I only have xLODGen for Fallout 4, is there any built-in way to add LOD to MSTT references? For the raider wind turbines, I used fake static references to generate the LODs, but this is less then ideal for a lot of objects, especially as far as mod compatibility is concerned. Fallout 4 has a very large portion of its cars and trucks as MSTT references, since they are designed to exploded if you shoot them. I could develop a script of some sort to generate the fake statics I suppose, but I'd rather save myself the hassle if there already is a way to do this. Could it be possible for xLODGen to automatically use a specific naming structure LOD model (say lod\path_to_model_lod_0.nif) for LOD if I add the Has Distant LOD flag?

[sheson]

3 hours ago, DoubleYou said:

@sheson

I know DynDOLOD allows using LOD via rules for MSTT moveable statics, but since I only have xLODGen for Fallout 4, is there any built-in way to add LOD to MSTT references? For the raider wind turbines, I used fake static references to generate the LODs, but this is less then ideal for a lot of objects, especially as far as mod compatibility is concerned. Fallout 4 has a very large portion of its cars and trucks as MSTT references, since they are designed to exploded if you shoot them. I could develop a script of some sort to generate the fake statics I suppose, but I'd rather save myself the hassle if there already is a way to do this. Could it be possible for xLODGen to automatically use a specific naming structure LOD model (say lod\path_to_model_lod_0.nif) for LOD if I add the Has Distant LOD flag?

xLODGen is a CK replacement LOD generator. It requires LOD models to be defined on base records. Only STAT base records can do that. So only reference that use STAT or SCOL which then use STAT base records can be used for static object LOD generation.

If anything, we would use DynDOLOD for anything beyond that. Either way, that would be a considerable time investment - the list of things to add to xLODGen (bake fake grass for example) and DynDOLOD is already quite long... so  anything like this is still some time in the future.

If you have a fixed list of LOD objects you could add them to the export file manually for the xLODGen or maybe via LOD options file.

Keep in mind though , that the static object LOD will truly be static, it can not move and not change how it looks.

[DoubleYou]

4 hours ago, sheson said:

xLODGen is a CK replacement LOD generator. It requires LOD models to be defined on base records. Only STAT base records can do that. So only reference that use STAT or SCOL which then use STAT base records can be used for static object LOD generation.

If anything, we would use DynDOLOD for anything beyond that. Either way, that would be a considerable time investment - the list of things to add to xLODGen (bake fake grass for example) and DynDOLOD is already quite long... so  anything like this is still some time in the future.

If you have a fixed list of LOD objects you could add them to the export file manually for the xLODGen or maybe via LOD options file.

Keep in mind though , that the static object LOD will truly be static, it can not move and not change how it looks.

Thanks. That confirms what I had expected was the case. I don't want to heap extra work onto that list. I just didn't want to be creating extra work for myself if there already was an easier way to do this.

[Blackread]

After my latest DynDOLOD run I decided to run around the arnimaDuplicate003 worldspace from Beyond Reach to check what the lods look like and if there's anything I would need to fix. While doing this I came across a cell with large reference bugs. The plugin doesn't have large references by default, but I added them myself with the xEdit script. The cell with the bugs is 18 -3. So I started checking the objects in the cell to see if there were any that had the initially disabled flag. I couldn't find any in arnima.esm nor in DynDOLOD.esm or Occlusion.esp, which were the only plugins to edit the cell in question. DynDOLOD.esp does add some tundra stream objects in there that are initially disabled, but since they aren't large refs they shouldn't be the cause of this issue right? There are 8 large refs in the cell, 2 of which are tundra streams. I found 5 objects being affected by this, so it does seem to be a legitimate large reference issue. It also only affects just this cell, neighbouring cells are all completely fine.

Do you have any ideas what might be causing this bug? DynDOLOD didn't report any large ref issues when running it. Here are the relevant log files: https://ufile.io/f/cmfrr

Edit: Noticed that the tundra stream objects might not be affected by this, but I think their LOD is handled a bit differently?

Edited September 7, 2022 by Blackread

[sheson]

1 hour ago, Blackread said:

After my latest DynDOLOD run I decided to run around the arnimaDuplicate003 worldspace from Beyond Reach to check what the lods look like and if there's anything I would need to fix. While doing this I came across a cell with large reference bugs. The plugin doesn't have large references by default, but I added them myself with the xEdit script. The cell with the bugs is 18 -3. So I started checking the objects in the cell to see if there were any that had the initially disabled flag. I couldn't find any in arnima.esm nor in DynDOLOD.esm or Occlusion.esp, which were the only plugins to edit the cell in question. DynDOLOD.esp does add some tundra stream objects in there that are initially disabled, but since they aren't large refs they shouldn't be the cause of this issue right? There are 8 large refs in the cell, 2 of which are tundra streams. I found 5 objects being affected by this, so it does seem to be a legitimate large reference issue. It also only affects just this cell, neighbouring cells are all completely fine.

Do you have any ideas what might be causing this bug? DynDOLOD didn't report any large ref issues when running it. Here are the relevant log files: https://ufile.io/f/cmfrr

Edit: Noticed that the tundra stream objects might not be affected by this, but I think their LOD is handled a bit differently?

Have you tested if problems go away when setting uLargeRefLODGridSize to 5?

Make sure to use latest version to generate large refs  https://github.com/TES5Edit/TES5Edit/blob/dev-4.1.5/Build/Edit Scripts/Skyrim SE - Generate Large References.pas

Only large references can trigger large reference bugs.

[Blackread]

1 hour ago, sheson said:

Have you tested if problems go away when setting uLargeRefLODGridSize to 5?

Make sure to use latest version to generate large refs  https://github.com/TES5Edit/TES5Edit/blob/dev-4.1.5/Build/Edit Scripts/Skyrim SE - Generate Large References.pas

Only large references can trigger large reference bugs.

Tested it now, with uLargeRefLODGridSize=5 there's just LOD models as expected.

The large references were generated with that version of the script.

[sheson]

1 hour ago, Blackread said:

Tested it now, with uLargeRefLODGridSize=5 there's just LOD models as expected.

The large references were generated with that version of the script.

See if there is anything different if you generate large references with the attached version.

Skyrim SE - Generate Large References.pas

[Blackread]

2 hours ago, sheson said:

See if there is anything different if you generate large references with the attached version.

Skyrim SE - Generate Large References.pas 13.08 kB · 2 downloads

I'm afraid not. I removed the old large refs, redid them with this version of the script and regenerated LOD, but that cell was still bugged. But I did notice that a couple initially disabled references that were added with the old script were not added with this one, so that's helpful. With the old one I had to delete them manually afterwards when the DynDOLOD Summary reported them.

[sheson]

2 hours ago, Blackread said:

I'm afraid not. I removed the old large refs, redid them with this version of the script and regenerated LOD, but that cell was still bugged. But I did notice that a couple initially disabled references that were added with the old script were not added with this one, so that's helpful. With the old one I had to delete them manually afterwards when the DynDOLOD Summary reported them.

If the CRC32 of your version of arnima.esm is not EE7FCD5E, send it to me.

[Blackread]

57 minutes ago, sheson said:

If the CRC32 of your version of arnima.esm is not EE7FCD5E, send it to me.

Here it is: https://ufile.io/jews6e37

I have (manually) merged some fixes into it.

[sheson]

3 hours ago, Blackread said:

Here it is: https://ufile.io/jews6e37

I have (manually) merged some fixes into it.

I can not replicate. This is the plugin after generating large refs https://mega.nz/file/MMI0HTwL#o0zRU_fJPzS5iTctFMeN6TUwVnPGXqrwE4i35vJ6x6s

Can you list all plugin that overwrite
Wordspace: arnimaDUPLICATE003 "The Reach" [WRLD:xx000D62]
Persistent Worldspace Cell: [CELL:xx003882] (in arnimaDUPLICATE003 "The Reach" [WRLD:06000D62])
Cell: [CELL:xx01DCBE] (in arnimaDUPLICATE003 "The Reach" [WRLD:06000D62] at 18,-3)

[Blackread]

2 hours ago, sheson said:

I can not replicate. This is the plugin after generating large refs https://mega.nz/file/MMI0HTwL#o0zRU_fJPzS5iTctFMeN6TUwVnPGXqrwE4i35vJ6x6s

Can you list all plugin that overwrite
Wordspace: arnimaDUPLICATE003 "The Reach" [WRLD:xx000D62]
Persistent Worldspace Cell: [CELL:xx003882] (in arnimaDUPLICATE003 "The Reach" [WRLD:06000D62])
Cell: [CELL:xx01DCBE] (in arnimaDUPLICATE003 "The Reach" [WRLD:06000D62] at 18,-3)

I did some quick tests with your plugin and comparing it to mine. With my generated LODs the bug was present with both. With the pregenerated LODs from the mod it was absent with both. I'll do a full LOD regeneration with your plugin just to be sure, as it looks like they are different based on CRC32.

Here are the overwriting plugins:

Worldspace: Beyond Reach - Skyrim Border Tweak.esp, DynDOLOD.esm, Missives - Beyond Reach.esp, Water for ENB - Patch - Beyond Reach.esp, ACMOS - Beyond Reach.esp, Clear Map - Water for ENB Patch.esp (this is my personal plugin patching the latter two together), Synthesis.esp, DynDOLOD.esp, Occlusion.esp

Persistent Worldspace Cell: Beyond Reach - Skyrim Border Tweak.esp, DynDOLOD.esm, Missives - Beyond Reach.esp, DynDOLOD.esp

Cell: DynDOLOD.esm, Occlusion.esp