DynDOLOD 3.00 Alpha 169

[Mousetick]

About the "Moved large reference" warnings, thanks for adding them.

It looks like the warning is issued if any ESM plugin in the stack moves the LR to a different cell, even if the last, winning ESM plugin in the stack places it back into its original cell. Is this the expected warning behavior? If yes, why is that?

Hypothetical example (next plugin overrides previous):

• Skyrim.esm REFR XYZ places Object_1 in cell Cell_A (REFR is LR)
• Plugin1.esm REFR XYZ places Object_1 in cell Cell_B (LR is moved)
• Plugin2.esm REFR XYZ places Object_1 in cell Cell_A (winning override)

DynDOLOD (Alpha 106) issues a warning "Moved large reference from Cell_A to Cell_B Skyrim.esm [REFR:XYZ]..."

This looks like a false positive to me.

Thanks.

[IX_Flipyap]

Alright i changed my power plan and moved the dyndolod install folder to my D: drive and added it to an exeption list. i ended up getting a bugreport txt file but the problem still persists. i also missed a new report left by the even viewer it also came with a report file. im going to give CHKDSK a try aswell.  

Fault bucket 1266036580241557564, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: DynDOLODx64.exe
P2: 3.0.0.0
P3: 636f6136
P4: KERNEL32.DLL
P5: 10.0.19041.2251
P6: 73bb7c6b
P7: c000001d
P8: 00000000000204e3
P9: 
P10: 

Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERC9F.tmp.mdmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERD4C.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERD5C.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERD5A.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERD7B.tmp.txt

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_DynDOLODx64.exe_a1a2964fe15fe8d846ff13fd2d7e82a82ffab9_76ec4113_3422fec7-78a4-4af9-a4b8-66ee941ee573

Analysis symbol: 
Rechecking for solution: 0
Report Id: abb8aaf2-edb1-49a6-965d-007adb0a4bbc
Report Status: 268435456
Hashed bucket: f7a4d1104eaf8d0f0191dd8fddf2c83c
Cab Guid: 0

bugreport.txt Report.txt

[sheson]

43 minutes ago, IX_Flipyap said:

Alright i changed my power plan and moved the dyndolod install folder to my D: drive and added it to an exeption list. i ended up getting a bugreport txt file but the problem still persists. i also missed a new report left by the even viewer it also came with a report file. im going to give CHKDSK a try aswell.  

Fault bucket 1266036580241557564, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: DynDOLODx64.exe
P2: 3.0.0.0
P3: 636f6136
P4: KERNEL32.DLL
P5: 10.0.19041.2251
P6: 73bb7c6b
P7: c000001d
P8: 00000000000204e3
P9: 
P10: 

Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERC9F.tmp.mdmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERD4C.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERD5C.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERD5A.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERD7B.tmp.txt

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_DynDOLODx64.exe_a1a2964fe15fe8d846ff13fd2d7e82a82ffab9_76ec4113_3422fec7-78a4-4af9-a4b8-66ee941ee573

Analysis symbol: 
Rechecking for solution: 0
Report Id: abb8aaf2-edb1-49a6-965d-007adb0a4bbc
Report Status: 268435456
Hashed bucket: f7a4d1104eaf8d0f0191dd8fddf2c83c
Cab Guid: 0

bugreport.txt 69.87 kB · 0 downloads Report.txt 16.2 kB · 0 downloads

Upload the realtime log, assuming there is still no normal log / debug log. Also upload the attached files mentioned in the event log.

Is that event log entry the only one related to this around this timestamp?

There is still not much the program can do about being terminated without its crash handler being invoked.

In addtion to chkdsk run sfc /scannow as admin. Doublecheck BIOS (memory timing settings for example) and/or disable overclocking etc.

[IX_Flipyap]

2 hours ago, sheson said:

Upload the realtime log, assuming there is still no normal log / debug log. Also upload the attached files mentioned in the event log.

Is that event log entry the only one related to this around this timestamp?

There is still not much the program can do about being terminated without its crash handler being invoked.

In addtion to chkdsk run sfc /scannow as admin. Doublecheck BIOS (memory timing settings for example) and/or disable overclocking etc.

https://ufile.io/w4pkf8yx Heres the real time log Dyndolod still doesnt make any normal logs. and yes there are other logs from the event viewer around the same 1331 timestamp. The system scan did find some corrupt files and has repaired them, i am now going to check my memory XMP.

Report1.txt Report2.txt Report3.txt

Edited November 28, 2022 by IX_Flipyap

[sheson]

1 hour ago, IX_Flipyap said:

https://ufile.io/w4pkf8yx Heres the real time log Dyndolod still doesnt make any normal logs. and yes there are other logs from the event viewer around the same 1331 timestamp. The system scan did find some corrupt files and has repaired them, i am now going to check my memory XMP.

Report1.txt 16.17 kB · 1 download Report2.txt 16.1 kB · 1 download Report3.txt 16.1 kB · 1 download

As MO2 mentions there is still a (or more) TexConvx64.exe active when this happens. Can you check in Windows task manager it/they just linger around or eventually dissapear?

Add LockTexconv=1 below [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini and see if it makes a difference.

If not, use task manager to keep an eye on memory usage of DynDOLODx64.exe and any spawned TexConvx64.exe and LODGenx64.exe processes with task manager.

[IX_Flipyap]

1 hour ago, sheson said:

As MO2 mentions there is still a (or more) TexConvx64.exe active when this happens. Can you check in Windows task manager it/they just linger around or eventually dissapear?

Add LockTexconv=1 below [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini and see if it makes a difference.

If not, use task manager to keep an eye on memory usage of DynDOLODx64.exe and any spawned TexConvx64.exe and LODGenx64.exe processes with task manager.

It finally generated the LOD successfully. im not sure if LockTexconv, or changing my XMP profile from 1 to 2 fixed the issue. but tysm for all the help! this was an annoying two days.

[sheson]

10 minutes ago, IX_Flipyap said:

It finally generated the LOD successfully. im not sure if LockTexconv, or changing my XMP profile from 1 to 2 fixed the issue. but tysm for all the help! this was an annoying two days.

Great. When you inevetibly update LOD, revert one or the other and let us know if you can.

[z929669]

6 hours ago, Mousetick said:

About the "Moved large reference" warnings, thanks for adding them.

It looks like the warning is issued if any ESM plugin in the stack moves the LR to a different cell, even if the last, winning ESM plugin in the stack places it back into its original cell. Is this the expected warning behavior? If yes, why is that?

Hypothetical example (next plugin overrides previous):

• Skyrim.esm REFR XYZ places Object_1 in cell Cell_A (REFR is LR)
• Plugin1.esm REFR XYZ places Object_1 in cell Cell_B (LR is moved)
• Plugin2.esm REFR XYZ places Object_1 in cell Cell_A (winning override)

DynDOLOD (Alpha 106) issues a warning "Moved large reference from Cell_A to Cell_B Skyrim.esm [REFR:XYZ]..."

This looks like a false positive to me.

Thanks.

My guess is that it's expected behavior because it's still an issue with the offending plugin (false positive for LO but not for the plugin), regardless of whether or not another plugin resolves it. More errors probably will increase the number of reports to the MA and potentially invoke education/understanding/remediation.

[z929669]

On 11/24/2022 at 11:08 PM, MisterMorden said:

Ok sheson, I finally was able to get my latest logs (106 alpha, no bugreport generated).  This was with the none, none, none, none, far full, unchanged mesh rule for giant campfires.  The other reference dropdown options didn't resolve the issue of the no flaming lod.  I have also included a link to some screenshots I took of walking through the issue.  I'm also currently in talks with the author of embers xd to see if it may be a mod issue.  I hope this information redeems my speculative past posts somewhat, lol.

logs: https://ufile.io/f/8qbp2

pics: https://imgur.com/a/TSzVR6d

Thanks again for your help!

Expanding on what sheson said in his response to this, it may be the root block type for the NIF. You can try editing the NIF yourself to use the proper type:
 

Quote

 

Root Block
The root node block type of a NIF for object models should typically be a BSFadeNode.

Dynamically enabling models with a root node block type other than BSFadeNode, BSLeafAnimNode or BSTreeNode causes CTD, hence the NIF is ignored for dynamic LOD.

The root node block type can be converted or changed with NifSkope. Right click the [0] NiNode, select Block, Convert, Bethesda, BSFadeNode, then save the updates NIF.

Certain types of models like grasses for example may be reported (vanilla grass models use BSFadeNode, so well made mods should follow that convention as well) but are never used for dynamic LOD anyways.

 

 

[z929669]

On 11/25/2022 at 4:11 AM, 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.

I essentially do the same in this situation but incorporate a diff analysis (e.g., WinMerge) to see what is unexpected after generating a new preset using my typical DynDOLOD GUI selections and comparing to my previous. Otherwise, yes, this could be bad. I can further confirm that using an old DynDOLOD preset can occasionally prevent DynDOLOD from working (e.g., fails to load).

[koopastroopas]

The only tree mod I use is 'Happy Little Trees' and I am getting these black boxes around trees, they start disappearing as I get closer to them and the trees finally show up. HLT is only losing conflicts to SMIMM which includes the new 4K replacer by Xilamonster, Skyland AIO and Turn of the Seasons. This has never happend to me before.

[sheson]

27 minutes ago, koopastroopas said:

The only tree mod I use is 'Happy Little Trees' and I am getting these black boxes around trees, they start disappearing as I get closer to them and the trees finally show up. HLT is only losing conflicts to SMIMM which includes the new 4K replacer by Xilamonster, Skyland AIO and Turn of the Seasons. This has never happend to me before.

Moved to the DynDOLOD 3 Alpha thread, assuming you are using it because of Seasons etc.

Read the first post which logs and debug logs to upload when making posts.

Run TexGen before DynDOLOD. https://dyndolod.info/Generation-Instructions

[koopastroopas]

I clicked the link you sent and noticed that on the step pictures of MO Dyndolod Scripts is overwriting Dyndolod DLL. In my case I have Dyndolod DLL overwriting Dyndolod Scripts. I am using 'Gamerpoets' most recent guide on setting up DyndoLOD and that is how he says to set them up. So do I change it to how it is on the link? And if I do, do I have to run Dyndo and Texgen again?

[Mousetick]

13 hours ago, z929669 said:

My guess is that it's expected behavior because it's still an issue with the offending plugin (false positive for LO but not for the plugin), regardless of whether or not another plugin resolves it.

Perhaps. It'd be good to clarify the intended behavior, though.

Here's a practical example that should be easy to reproduce. Load order with USSEP and SLAWF (both latest versions):

• Skyrim.esm REFR:0007AE01 places RockPileL03 in cell 000092BD <EastEmpireTradingCompanyDocks>
• USSEP.esp REFR:0007AE01 places RockPileL03 in cell 0000929C <EastEmpireWarehouseExterior>
• SLAWF.esp REFR:0007AE01 places RockPileL03 in cell 000092BD <EastEmpireTradingCompanyDocks>

The warning emitted by DynDOLOD a106 in this case is:

<Warning: Moved large reference from [-17,23] to [-17,24] Skyrim.esm [REFR:0007AE01] (places RockPileL03 [STAT:000185BD] in GRUP Cell Temporary Children of EastEmpireTradingCompanyDocks [CELL:000092BD] (in Tamriel "Skyrim" [WRLD:0000003C] at -17,23))>

If the goal is to incriminate USSEP, the warning is not doing that.

13 hours ago, z929669 said:

More errors probably will increase the number of reports to the MA and potentially invoke education/understanding/remediation.

Great idea but wishful thinking, I'm afraid. Apart from mods maintained by STEP and a few MAs, the overall attitude seems to be ignorance or plain rejection. Following are some concrete examples:

Spoiler

• From the Beyond Reach MA, a pretty big and popular mod:

Quote

Stop posting bugs related to DYNDOLOD. Take it to the bugs section. I will be deleting any comments related to DYNDOLOD or TEXGEN in the comments section.

The bugs section is closed. There is bugs topic in the forum section, where a lot of DynDOLOD warnings are reported, completely ignored by the MA.

• Midwood Isle, another pretty popular mod, has a bugs section where DynDOLOD warnings are reported, and ignored.
• From the Changelog of Legacy of the Dragonborn, a very popular mod: (emphasis added)

Quote

Fixes #1313 - DyndoLOD will no longer moan about irrelevant meshes.

There are still warnings despite the fix, LOL.

I could find more examples, but you get the idea.

Not to mention issues with mods that are no longer maintained: reporting to the MA is pointless.

[sheson]

7 hours ago, koopastroopas said:

I clicked the link you sent and noticed that on the step pictures of MO Dyndolod Scripts is overwriting Dyndolod DLL. In my case I have Dyndolod DLL overwriting Dyndolod Scripts. I am using 'Gamerpoets' most recent guide on setting up DyndoLOD and that is how he says to set them up. So do I change it to how it is on the link? And if I do, do I have to run Dyndo and Texgen again?

DynDOLOD DLL and DynDOLOD DLL Scripts have no conflicting files. https://dyndolod.info/Help/DynDOLOD-DLL