DynDOLOD 3.00 Alpha 196

[sheson]

43 minutes ago, LF111 said:

I've updated the photos with additional pics that I believe cover what the site asks. Pics. Based on how broad the problem here is, I didn't quite know how many pictures to actually take. Note that it's hard to get an up-close view of the purple squares that bisect that certain tree model, as they disappear when getting too close to them with tfc. 

Requested files and proper logs (let me know if there's an issue accessing the .bto file this way).

I can confirm there is no old output overwriting the new one. 

There's also something funky going on with generation times. TexGen is taking the same amount of time as usual (2-3 minutes), but DynDOLOD is varying a lot. The generation time for my current load order (backed up by the three generations I did for the seam testing) is ~18 minutes. The two Alpha 187 generations I did earlier today both were around 22 minutes, and the one that I just did (that these logs are coming from) was only 9 minutes total. I have never had a DynDOLOD generation go that fast. 

The BTO you uploaded and which should be the one used for the map, uses Data\textures\dyndolod\lod\dyndolod_tamriel.dds for the Whiterun Castle and walls.
Does this texture exist in MO2 right Window data tab? Does it have about the same timestamp from the same session as the BTO you uploaded?

[sheson]

36 minutes ago, AngriusWindstorm said:

I aplogise, I must have missed that part in your reply.

If possible, I would rather not use the interior plugin as per the mod author's recommendation. Others with this mod are having the same issue and were looking for a way to follow the mod authors instructions as well.

Your intention is to not use the interior plugin in the game?
Or is your intention to follow unnecessary 3rd party instructions that only make things more complicated and enable the plugin after generating LOD?

[LF111]

I do not use MO2, unfortunately, so I cannot check it that way.

How else can I go about troubleshooting?

[PRieST]

Just wanted to report a one time Access Violation with Alpha-187:

[Window Title]
DynDOLOD

[Main Instruction]
Access violation at address 0000000001DD2629 in module 'DynDOLODx64.exe' (offset FF2629).

[Content]
Read of address 0000000000000000 while processing HearthFires.esm BYOHHouse1Room08BPart157Roof [REFR:030090B4] (Places BYOHBYOHWRtowerKEXT01 [STAT:03003C78] in [CELL:00000D74] (in Tamriel "Himmelsrand" [WRLD:0000003C]) at -3,-17)

Click on this link for additional explanations and help for this message

For qualified help and advice or to report a problem make a post on the official DynDOLOD support forum.

[OK] [Exit DynDOLOD]

[Footer]
Online Help | Support Forum | Copy message to clipboard

Haven't made any crucial changes in loadorder in comparison to the last successfull run with Alpha-185.

After clicking OK I had to force shutdown the program.
Logs: https://www.mediafire.com/file/u9tj4jruk824k33/Logs.7z/file
Only bugreport.txt (attached).

After starting over no violation happened.


Unrelated, but TexGen still reports as version Alpha-186 instead of 187.

bugreport.txt

[sheson]

39 minutes ago, LF111 said:

I do not use MO2, unfortunately, so I cannot check it that way.

How else can I go about troubleshooting?

Refer to the manual or help of the mod manager you are using how to do everyday modding stuff.

I suppose you can check the files (and their timestamps) directly in the actual data folder.

[sheson]

27 minutes ago, PRieST said:

Just wanted to report a one time Access Violation with Alpha-187:

[Window Title]
DynDOLOD

[Main Instruction]
Access violation at address 0000000001DD2629 in module 'DynDOLODx64.exe' (offset FF2629).

[Content]
Read of address 0000000000000000 while processing HearthFires.esm BYOHHouse1Room08BPart157Roof [REFR:030090B4] (Places BYOHBYOHWRtowerKEXT01 [STAT:03003C78] in [CELL:00000D74] (in Tamriel "Himmelsrand" [WRLD:0000003C]) at -3,-17)

Click on this link for additional explanations and help for this message

For qualified help and advice or to report a problem make a post on the official DynDOLOD support forum.

[OK] [Exit DynDOLOD]

[Footer]
Online Help | Support Forum | Copy message to clipboard

Haven't made any crucial changes in loadorder in comparison to the last successfull run with Alpha-185.

After clicking OK I had to force shutdown the program.
Logs: https://www.mediafire.com/file/u9tj4jruk824k33/Logs.7z/file
Only bugreport.txt (attached).

After starting over no violation happened.


Unrelated, but TexGen still reports as version Alpha-186 instead of 187.

bugreport.txt 223.73 kB · 0 downloads

If the record 030090B4 overwritten by any plugin? I suppose it is not, which makes the error message odd, as it fails to get the "name" of the reference (in a critical section), but then has no issue to get the name when logging the VA to the log.

Is this repeatable?

[PRieST]

15 minutes ago, sheson said:

If the record 030090B4 overwritten by any plugin? I suppose it is not, which makes the error message odd, as it fails to get the "name" of the reference (in a critical section), but then has no issue to get the name when logging the VA to the log.

Is this repeatable?

Started DynDOLOD second time without the error.

030090B4 is not overwritten.

I know DynDOLOD is based on the most recent xEdit version - with that version I get the warnings regarding the FishingModsMerged.esp which wasn't the case with earlier xEdit/DynDOLOD versions. Do you know how harmful these are?

I think they were from Simple Fishing Overhaul before I merged it with some other mods.

Same goes for the mentioned navmesh error which is new - all mentioned FormID from the log are not overwritten, so is this a false positive? I could provide the new logs regarding these questions (from the successful run) if needed.

[LF111]

I don't think Vortex can do what MO2 does there, but I am able to just check the files. I downloaded a texture viewer (WTV) to be able to see the .dds files, and Data\textures\dyndolod\lod\dyndolod_tamriel.dds is blank. It's telling me that the DX10 format is unknown. I tried in GIMP as well and got a similar warning about an unsupported DXGI format. 

I can check the files in the actual folder, I just need to know what is meant by timestamp. If it's referring to date modified, they don't match (although it might be close enough, based on what you mean by "about the same"). The .bto has a date modified of 2/17/25 at 1:15 AM, while the texture has a date modified of 2/17/25 at 1:09 AM (though the "date created" is listed as 2/17/25 at 1:17 AM... after it was modified?) 

Sorry if this is not at all what you mean by timestamp. In case it helps, I've uploaded the texture .dds file to the folder. 

[sheson]

5 minutes ago, PRieST said:

Started DynDOLOD second time without the error.

030090B4 is not overwritten.

I know DynDOLOD is based on the most recent xEdit version - with that version I get the warnings regarding the FishingModsMerged.esp which wasn't the case with earlier xEdit/DynDOLOD versions. Do you know how harmful these are?

I think they were from Simple Fishing Overhaul before I merged it with some other mods.

Same goes for the mentioned navmesh error which is new - all mentioned FormID from the log are not overwritten, so is this a false positive? I could provide the new logs regarding these questions (from the successful run) if needed.

I am not sure what warnings in FishingModsMerged.esp you are referring to. There aren't any in the uploaded logs I can find.

The Navmesh error is unrelated and should be of no consequence to LOD generation.
I believe the missing triangle #382 is added by the unofficial patch, you may have a plugin undoing that change.

[PRieST]

17 minutes ago, sheson said:

I believe the missing triangle #382 is added by the unofficial patch, you may have a plugin undoing that change.

Haven't seen any conflicts in my whole loadorder. And es said before, wasn't mentioned with earliere versions of xEdit/DynDOLOD.

24 minutes ago, sheson said:

I am not sure what warnings in FishingModsMerged.esp you are referring to. There aren't any in the uploaded logs I can find.

Oh, thaught it was mentioned in that one, too.

I'll take a look myself and if I need further guidance I'll ask again.

[sheson]

1 hour ago, LF111 said:

I don't think Vortex can do what MO2 does there, but I am able to just check the files. I downloaded a texture viewer (WTV) to be able to see the .dds files, and Data\textures\dyndolod\lod\dyndolod_tamriel.dds is blank. It's telling me that the DX10 format is unknown. I tried in GIMP as well and got a similar warning about an unsupported DXGI format. 

I can check the files in the actual folder, I just need to know what is meant by timestamp. If it's referring to date modified, they don't match (although it might be close enough, based on what you mean by "about the same"). The .bto has a date modified of 2/17/25 at 1:15 AM, while the texture has a date modified of 2/17/25 at 1:09 AM (though the "date created" is listed as 2/17/25 at 1:17 AM... after it was modified?) 

Sorry if this is not at all what you mean by timestamp. In case it helps, I've uploaded the texture .dds file to the folder. 

You need to use programs or plugins that support BC7 texture compression format. IrfanView has support for example.

However, the problem seems to be missing textures, e.g. a file not found.
Filemanagers like Windows Explorer typically show a filetime, which usually the last time a file has been modified.
The creation time is when DynDOLOD saved it. The modified time is when Texconv converted it to BC7.

According to the provided log, anything within 8 minutes is probably from the same generation:
[01:31] [Tamriel] Executing "C:\Skyrim DynDOLOD\DynDOLOD\Edit Scripts\LODGenx64Win.exe" --inputfile "C:\Skyrim DynDOLOD\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_Tamriel.txt" --logfile "C:\Skyrim DynDOLOD\DynDOLOD\Logs\LODGen_SSE_Tamriel_log.txt"
[01:42] Creating texture atlas C:\Skyrim DynDOLOD Output\textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds
..
[07:17] Waiting for LODGenx64Win.exe generating object LOD for Tamriel.
[08:25] [Tamriel] Generating Pre-Computed Occlusion TVDT

Having all that explained, missing textures are not the issue it seems.

The uploaded diffuse texture atlas has normal map textures included (the *_n.dds textures), which are usually blue and can look like missing texture color in the game.
They should only be on the DynDOLOD_Tamriel_n.dds.

Check the data folder for the textures\lod\wrbuildingslod01.dds. It should be from the TexGen output.
Verify that the file in the data folder has the same filesize and modfied time as the file in the TexGen output mod, or better check their CRC32 to be equal (for example with the right 7zip CRC sha option if you have that installed for example.
It should not be blue. Upload both textures\lod\wrbuildingslod01.dds and wrbuildingslod01_n.dds if you want me to check.

[sheson]

10 minutes ago, PRieST said:

Haven't seen any conflicts in my whole loadorder. And es said before, wasn't mentioned with earliere versions of xEdit/DynDOLOD.

Oh, thaught it was mentioned in that one, too.

I'll take a look myself and if I need further guidance I'll ask again.

I suggest to ask about those on the xEdit discord.

[PRieST]

31 minutes ago, sheson said:

I suggest to ask about those on the xEdit discord.

Thaught the same as you confirmed it will not cause any LOD related issues. Thanks.

[CarlWG2]

8 hours ago, sheson said:

The crash log indicates a problem with an NPC (and their hair physics?) probably related SKEE64.DLL (from Racemenu). The NPCs happen to be in a cell which DynDOLOD.esp and Occlusion.esp are the last plugins to overwrite.

Troubleshoot and fix the CTDs that happen without DynDOLOD in the load order. No crash log without DynDOLOD in the load order was provided for comparison.

Test without SKEE64.dll / Racemenu.
Test with a new game. If it only happens while load existing saves. it might be related to racemenu data in the save  and/or SKSE co-save.
You can clean (most of) the data of mods from the save and co save by temporarily disabling the mod and making a new save.

Make sure to check comments/forum related to Racemenu and hair physics mods for similar reports, updates etc.

Check NPC 0x00013B9B in xEdit and the involved plugins overwriting/patching it.
Skyrim.esm -> unofficial skyrim special edition patch.esp -> cutting room floor.esp -> AI Overhaul.esp -> PAN_NPCs.esp -> AI Overhaul - Cutting Room Floor Patch.esp -> Olfina replacer.esp -> Bashed Patch, 0.esp -> Synthesis.esp

Once the CTD without DynDOLOD are fixed, generate LOD for that load order. In case there are CTDs with only DynDOLOD output activated, upload new logs and crash logs.

Thank you for the quick response.

If desired, I can provide additional crash reports from this same save. I load the save, attack a guard in Whiterun, die, and then the game CTD on autoload. Each time the crashlog has different information. The one I posted happened to have Olfina, but the two tests I just did had different references to Stormcloak Soldiers and no reference to Olfina (all produced from same save...load, attack same Whiterun guard, die). As noted, if I uncheck "DynDOLOD is active" in the MCM, the crashing does not happen on autoload.

I'll do the following next:

1. I will try disabling Racemenu and the physics hair distribution mod I am using and then attempt to recreate the issue with a new character (as well as with the existing save used for the report I posted, cleaned as needed).
2. As requested, I'll also take a look in SSEEdit at Olfina to see if anything is unusual.
3. I will also attempt to get a crashlog from when DynDOLOD is disabled. That is harder to do as the game doesn't crash often when DynDOLOD is disabled/not installed.

I am leaving soon for a trip so my response will be delayed a few days. Thank you!

[sheson]

34 minutes ago, CarlWG2 said:

Thank you for the quick response.

If desired, I can provide additional crash reports from this same save. I load the save, attack a guard in Whiterun, die, and then the game CTD on autoload. Each time the crashlog has different information. The one I posted happened to have Olfina, but the two tests I just did had different references to Stormcloak Soldiers and no reference to Olfina (all produced from same save...load, attack same Whiterun guard, die). As noted, if I uncheck "DynDOLOD is active" in the MCM, the crashing does not happen on autoload.

I'll do the following next:

1. I will try disabling Racemenu and the physics hair distribution mod I am using and then attempt to recreate the issue with a new character (as well as with the existing save used for the report I posted, cleaned as needed).
2. As requested, I'll also take a look in SSEEdit at Olfina to see if anything is unusual.
3. I will also attempt to get a crashlog from when DynDOLOD is disabled. That is harder to do as the game doesn't crash often when DynDOLOD is disabled/not installed.

I am leaving soon for a trip so my response will be delayed a few days. Thank you!

Upload the other crash logs, also the one without DynDOLOD being active.
That would be the crash to fix first to rule out any interaction that would otherwise not happen. Remember, troubleshooting is to remove everything else that is not required for the issue to occur until only the required parts to remain.

When investigating crashes while DynDOLOD output is active, make sure it was generated for that exact load order.

If you want to troubleshoot crashes with DynDOLOD active further, test what happen if you just disable the DynDOLOD.DLL. Ignore any error messages in the game related to that and do whatever you do to trigger the crash to see if it has any affect. Based on that result we can try narrowing it down further.

Reply whenever you are ready, no probem.