DynDOLOD 3.00 Alpha 180

[sheson]

20 minutes ago, Blackread said:

I did several runs with this version without getting stuck, so likely the issue was fixed, thank you.

I found some large ref bugs in the area around the western watchtower. Here are a few examples:

https://i.imgur.com/aEHKPMU.png ref 1a482

https://i.imgur.com/PCxDWWF.png ref 6ea15

https://i.imgur.com/itAuhLY.png ref 1a370

https://i.imgur.com/3DyFU69.png ref 1a494

https://i.imgur.com/lG6zdhJ.png ref 3abbf

For some reason I couldn't find a debug log for the latest run, so here are the logs for the run before. The only difference is that I had realtimelogging active for the run these logs are from, the bugs were present in both. Papyrus logs didn't contain anything dyndolod related.

you made sure the go away with uLargeRefLODGridSize=5?

Provide a list of all plugins overwriting their cells 000095DE, 00009A8A  and 00009A6A. You will notice that those cells (coordinates) are not reported as having bugs right now.

[Blackread]

23 minutes ago, sheson said:

you made sure the go away with uLargeRefLODGridSize=5?

Provide a list of all plugins overwriting their cells 000095DE, 00009A8A  and 00009A6A. You will notice that those cells (coordinates) are not reported as having bugs right now.

Yes, with uLargeRefLODGridSize=5 there are only the LOD models visible (and only one model, no z-fighting). Here are the overwrites:

000095DE: Update.esm, Unofficial Skyrim Special Edition Patch.esp, Landscape and Water Fixes.esp, Landscape Fixes For Grass Mods.esp

00009A8A: Update.esm, Unofficial Skyrim Special Edition Patch.esp, MajesticMountains_Landscape.esm, DynDOLOD.esm, Lux Orbis.esp

00009A6A: Unofficial Skyrim Special Edition Patch.esp, MajesticMountains_Landscape.esm

 

[sheson]

1 hour ago, Blackread said:

Yes, with uLargeRefLODGridSize=5 there are only the LOD models visible (and only one model, no z-fighting). Here are the overwrites:

000095DE: Update.esm, Unofficial Skyrim Special Edition Patch.esp, Landscape and Water Fixes.esp, Landscape Fixes For Grass Mods.esp

00009A8A: Update.esm, Unofficial Skyrim Special Edition Patch.esp, MajesticMountains_Landscape.esm, DynDOLOD.esm, Lux Orbis.esp

00009A6A: Unofficial Skyrim Special Edition Patch.esp, MajesticMountains_Landscape.esm

Did you modify any of those plugins or use older version than what is currently available on Nexus?

[Blackread]

2 hours ago, sheson said:

Did you modify any of those plugins or use older version than what is currently available on Nexus?

Everything is up to date. Update.esm has been cleaned with xEdit QAC. USSEP, not sure, I may have done some small edits. LaWF should be as is except for generating large refs. LFfGM should be unchanged, as is MM Landscape. In Lux Orbis I have done some minor fixing, at least on the floating embers in Windhelm. I'll make sure all those plugins are in their original state and regenerate to be sure.

Edited October 10, 2022 by Blackread

[sheson]

10 minutes ago, Blackread said:

Everything is up to date. Update.esm has been cleaned with xEdit QuickAutoClean. USSEP, not sure, I may have done some small edits. LaWF should be as is except for generating large refs. LFfGM should be unchanged, as is MM Landscape. In Lux Orbis I have done some minor fixing, at least on the floating embers in Windhelm. I'll make sure all those plugins are in their original state and regenerate to be sure.

Here is why I ask. Just checking 00009A6A alone, since it only has 2 plugins overwriting.

Majestic Mountains only changes the LAND record, while the unofficial patch only overwrites TREEs. So neither cause the bugs, unless you have different versions doing something else.

If I checked correctly, Skyrim.esm adds 5 REFR that are large references, 0001A370, 0001A480, 0001A482, 0001A483, 000C8C06.

If nothing adds new large references and does not overwrite those, then check if anything overwrites the base records of those 5 references.

0003ACCD, 0003925C, 00042A88, 0003ABE3, 00077773

[Blackread]

2 hours ago, sheson said:

Here is why I ask. Just checking 00009A6A alone, since it only has 2 plugins overwriting.

Majestic Mountains only changes the LAND record, while the unofficial patch only overwrites TREEs. So neither cause the bugs, unless you have different versions doing something else.

If I checked correctly, Skyrim.esm adds 5 REFR that are large references, 0001A370, 0001A480, 0001A482, 0001A483, 000C8C06.

If nothing adds new large references and does not overwrite those, then check if anything overwrites the base records of those 5 references.

0003ACCD, 0003925C, 00042A88, 0003ABE3, 00077773

None of the references are overwritten.
0003ACCD and 0003ABE3 are overwritten by MajesticMountains_Moss.esp
0003ACCD, 0003925C, 00042A88 and 0003ABE3 are overwritten by DynDOLOD.esp.
No overwrites on 00077773.

I reinstalled USSEP to make sure the plugin is unchanged, and like you said, MM Landscape only edits landscape records. I checked that neither plugin adds new large references to Tamriel.

I'm using the test version you gave me a few posts before.

Edited October 10, 2022 by Blackread

[sheson]

2 minutes ago, Blackread said:

None of the references are overwritten. 0003ACCD and 0003ABE3 are overwritten by MajesticMountains_Moss.esp, 0003ACCD, 0003925C, 00042A88 and 0003ABE3 are overwritten by DynDOLOD.esp. No overwrites on 00077773.

I reinstalled USSEP to make sure the plugin is unchanged, and like you said, MM Landscape only edits landscape records. I checked that neither plugin adds new large references to Tamriel.

Look up the form id of the references in ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_Tamriel.txt (this mist won't be listed obviously)

Check if their lines contain "-LargeRef"

[Blackread]

1 hour ago, sheson said:

Look up the form id of the references in ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_Tamriel.txt (this mist won't be listed obviously)

Check if their lines contain "-LargeRef"

Yes, all the refs are tagged with -LargeRef.

But, it looks like MajesticMountains_Moss.esp is the culprit. I disabled it in my load order, regenerated the LODs and all the bugs were gone. I don't know if it makes any sense from a technical standpoint, but it is logical looking at it from a troubleshooting standpoint. All the affected cells had at least one rock object with the new dirt shader (the moss plugin was changed from moss to dirt in the latest MM update). It is also one of the mods I updated before this latest LOD refresh I did.

I'll do a few more tests to see if I can get more info out of this.

[sheson]

16 minutes ago, Blackread said:

Yes, all the refs are tagged with -LargeRef.

But, it looks like MajesticMountains_Moss.esp is the culprit. I disabled it in my load order, regenerated the LODs and all the bugs were gone. I don't know if it makes any sense from a technical standpoint, but it is logical looking at it from a troubleshooting standpoint. All the affected cells had at least one rock object with the new dirt shader (the moss plugin was changed from moss to dirt in the latest MM update). It is also one of the mods I updated before this latest LOD refresh I did.

I'll do a few more tests to see if I can get more info out of this.

I am not able to reproduce this so far.

Double check object bounds are not weird (the 4.01 ESL moss plugin I have seem fine) and that DynDOLOD.esm sets game setting 0xf92 to 1. Make sure no other plugin overwrites it or adds a new record with Editor ID "fLargeRefMinSize.

They are also still STAT base records, so object bounds is really the only thing that matters for large refs. MSTTs also need that flag.

[Blackread]

1 hour ago, sheson said:

I am not able to reproduce this so far.

Double check object bounds are not weird and that DynDOLOD.esm sets game setting 0xf92 to 1. Make sure no other plugin overwrites it or adds a new record with Editor ID "fLargeRefMinSize"

Okay I think I found it! I thought I checked I had the latest version of Majestic Mountains but turns out I didn't. From the changelog of 4.01:

Quote

fixed object bounds in moss.esp

Edit: Just to be clear, some objects in the moss esp had their object bounds set to all 0, including one of the ones that were present in the cell we were checking.

Edited October 10, 2022 by Blackread

[sheson]

1 minute ago, Blackread said:

Okay I think I found it! I thought I checked I had the latest version of Majestic Mountains but turns out I didn't. From the changelog of 4.01:

Hmm I might add a message for that... and/or create an overwrite with the vanilla objects bounds.

[PRieST]

On 10/10/2022 at 9:10 PM, Blackread said:

Okay I think I found it! I thought I checked I had the latest version of Majestic Mountains but turns out I didn't. From the changelog of 4.01:

Edit: Just to be clear, some objects in the moss esp had their object bounds set to all 0, including one of the ones that were present in the cell we were checking.

Believe it or not, but I think this resulted in my strange behaviour earlier as well. I just came back to found out at still using version 4 of the moss plugin. After I updated to 4.01 and updated DynDOLOD I don't have anymore issues like the vanishing windmill and also the honning brew meadery buildings are either LOD or full model, no more overlapping - I used the exact same method as before where the problems were, nothing. Everything is normal now.
Also I did the regen with alpha 102 if it matters, but so far...no LOD related issues anymore.

I know this seems not related, but updating the moss esp from MM is the only difference and the change from alpha 101 to 102 (but as I read in the changelog this couldn't be it).

Edited October 12, 2022 by PRieST

[mansai]

After updating to Alpha 102, I get a CTD on Falkreath Hold.

TreeAspen03 and DynDOLOD.esm in NetScriptFramework logs.

Crash logs have been uploaded.
https://ufile.io/uv7uwaao

[sheson]

25 minutes ago, mansai said:

After updating to Alpha 102, I get a CTD on Falkreath Hold.

TreeAspen03 and DynDOLOD.esm in NetScriptFramework logs.

Crash logs have been uploaded.
https://ufile.io/uv7uwaao

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

The third party LOD model used by base record xx00A65E in DynDOLOD.esm needs to be fixed in order to be usable with dynamic LOD.

[mansai]

1 hour ago, sheson said:

投稿時にDynDOLODログとデバッグログをアップロードする 最初の投稿を読んでください 。

DynDOLOD .esm のベース レコード xx00A65E で使用されるサード パーティの LOD モデルは 、動的 LOD で使用できるように修正する必要があります。

Thank you for your response.
I had missed your first post.

bugreport
https://ufile.io/1c33k226

DynDOLOD_SSE_log
https://ufile.io/j2a7okn1

DynDOLOD_SSE_Debug_log
https://ufile.io/4cn0fabp