DynDOLOD 3.00 Alpha 190

[MitchBandito]

  On 6/5/2024 at 8:58 AM, sheson said:

DynDOLOD does not do anything to full grass. Set the appropriated settings in NGIO GrassControl.config.txt to control full grass and its max render distance.

https://dyndolod.info/Help/Grass-LOD
With No Grass In Objects full grass can be rendered past the active cells, so Grass LOD can either start right beyond the active exterior cells (uGridsToLoad), which has better for performance - or beyond the large reference distance (uLargeRefLODGridSize). The DynDOLODGrassMode/DynDOLOD-Grass-Mode 1 or 2 setting controls the distance of full grass respectively.
Set the same desired Mode in the advanced mode of DynDOLOD under the Grass LOD checkbox and for DynDOLODGrassMode/DynDOLOD-Grass-Mode in the settings file. While the DynDOLODGrassMode/DynDOLOD-Grass-Mode setting can be changed at any time, the Mode used to generate grass LOD is baked into the object LOD meshes.

If you have problems with full grass and NGIO, you need to ask on the NGIO forum or comments.

Expand  

Thank you so much for your answer 🙏

[KRZ]

  On 6/5/2024 at 10:12 AM, sheson said:

The mentioned records are parent > child copies. There should not be really anything different between the references/base records in Alpha 169 and 170.

Lets just look at one crash log: crash-2024-06-05-08-57-45.log
Base record WRHouseStables01 with form ID 0x000627AA
used by reference 0x130BAEC0 in DynDOLOD.esm

Since you have both outputs, do the following:

Lookup the reference in xEdit by its EditorID in DynDOLOD.esm in both outputs. Enter skyrimesm_099F21_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLO into the Editor ID field top left of xEdit and hit Enter key and wait for it to find it. Obviously it should find the reference 0x130BAEC0 for the output put from 170. The form ID will different in the DynDOLOD.esm for the output of 169.

Compare the references if there is anything different.
Both should use the same base record 0x000627AA in Skyrim.esm, which seems not to be overwritten by any plugin and define Architecture\WhiteRun\WRBuildings\WRHouseStables01.nif. It (and any textures it uses) should also be identical for both load orders. Let me know in case this is not the vanilla NIF and if it comes from a mod and which.

If so far you haven't found a difference compare, check the Cell 0x00071E94 the reference resides in and compare the overwrites in the DynDOLOD.esm and Occlussion.esp for both output if there is anything different.

Let me know if you can spot anything different or obvious errors or if everything looks the same.

Expand  

Sorry for taking so long, xEdit reported a patch causing errors, so I replaced it and ran Alpha 170 again to see whether that's been the culprit - it was not. I've included a comparison shot of both entries below (Alpha 169 on the left, Alpha 170 on the right). I can't really spot a difference, however it appears that in Alpha 170's output skyrimesm_099F21_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLO doesn't actually get referenced by anything opposed to Alpha 169's output, which has exactly one reference.

The WRHouseStables01.nif is from this mod https://www.nexusmods.com/skyrimspecialedition/mods/120159

Edited June 5, 2024 by KRZ

[sheson]

  On 6/5/2024 at 1:13 PM, KRZ said:

Sorry for taking so long, xEdit reported a patch causing errors, so I replaced it and ran Alpha 170 again to see whether that's been the culprit - it was not. I've included a comparison shot of both entries below (Alpha 169 on the left, Alpha 170 on the right). I can't really spot a difference, however it appears that in Alpha 170's output skyrimesm_099F21_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLO doesn't actually get referenced by anything opposed to Alpha 169's output, which has exactly one reference.

The WRHouseStables01.nif is from this mod https://www.nexusmods.com/skyrimspecialedition/mods/120159

Expand  

Error check the DynDOLOD and Occlusion plugins in xEdit.

To be sure, test without the mod / hide the model so that the vanilla model is used. I do not expect that to make a difference.

Report if anything overwrite the original reference 00099F21.

[KRZ]

  On 6/5/2024 at 2:52 PM, sheson said:

Error check the DynDOLOD and Occlusion plugins in xEdit.

To be sure, test without the mod / hide the model so that the vanilla model is used. I do not expect that to make a difference.

Report if anything overwrite the original reference 00099F21.

Expand  

I'm getting a couple of errors with both Alpha 169 and Alpha 170, but it's hard to tell whether that isn't caused by me replacing that one patch and adding 3 more patches which had been chosen by the FOMOD. Should I create a new Output for Alpha 169 as well to maintain consistency or does it not matter? I had to replace the patch or xEdit would have thrown a fit and I couldn't check for errors etc.

I've attached the findings anyways, but if I have to do another round let me know.

 

Launching without the mod/model did nothing.

Nothing touches the original reference 00099F21.

Error check.txtFetching info...

[sheson]

  On 6/5/2024 at 3:51 PM, KRZ said:

I'm getting a couple of errors with both Alpha 169 and Alpha 170, but it's hard to tell whether that isn't caused by me replacing that one patch and adding 3 more patches which had been chosen by the FOMOD. Should I create a new Output for Alpha 169 as well to maintain consistency or does it not matter? I had to replace the patch or xEdit would have thrown a fit and I couldn't check for errors etc.

I've attached the findings anyways, but if I have to do another round let me know.

 

Launching without the mod/model did nothing.

Nothing touches the original reference 00099F21.

Error check.txt 638.44 kB · 1 download

Expand  

The Unknown 2 are expected.

The unresolved Form ID are a problem. This should not happen right after patch generation. So if you generate again with 170, check it right after. For troubleshooting I do not need a new 169 for now.

[KRZ]

  On 6/5/2024 at 4:12 PM, sheson said:

The Unknown 2 are expected.

The unresolved Form ID are a problem. This should not happen right after patch generation. So if you generate again with 170, check it right after. For troubleshooting I do not need a new 169 for now.

Expand  

Once again everything's brand new, including TerrainLOD this time, but the crashes persist.

DynDOLOD_SSE_Debug: https://mega.nz/file/FDlAwDTa#pI9vxOzqgJoBPAB8x5lMWILKdnqLzjxsXwmVdZ6QzQU

 

Fwiw, I've noticed there are a ton of 0D and FE005 FormIDs in xEdit's error report, which are

evgSirenroot.esm https://www.nexusmods.com/skyrimspecialedition/mods/70917 and

Landscape and Water Fixes.esp https://www.nexusmods.com/skyrimspecialedition/mods/26138 in my LO.
I wonder whether that's related somehow.

 

Peculiar, I've done another Alpha 170 output without Sirenroot and Landscape and Water Fixes, but while all the 0D errors are gone, the FE005 have changed. Everything related to this is in Logs 2 & DynDOLOD_SSE_Debug 2.

DynDOLOD_SSE_Debug 2: https://mega.nz/file/9XsBEADa#mMWBomfMs2suBL9rzJLxHOQwFrVpbDRO3ifMmHFhaBs

 

Logs.zipFetching info...

Logs 2.zipFetching info...

[Jonado]

  On 6/5/2024 at 5:27 AM, sheson said:

Yes you are correct, both BOS and DynDOLOD also sort the BOS INIs alphabetical. Same issue with the case sensitivity though - that I double checked with the logs. So that will be fixed as well.

Expand  

I thought as much. Just want to make sure you get it right this time, though. Intuitively I think the order should be _AaBbCc..., not ABC...XYZ_abc... as you claimed it is. At least I think that is the sorting that is used on Windows.

[sheson]

  On 6/5/2024 at 10:36 PM, Jonado said:

I thought as much. Just want to make sure you get it right this time, though. Intuitively I think the order should be _AaBbCc..., not ABC...XYZ_abc... as you claimed it is. At least I think that is the sorting that is used on Windows.

Expand  

xEdit  ignores the case filenames of assets by default, so I'll change that for when reading these INIs. Windows Explorer sorts case insensitive, too since by default filenames are case insensitive. Sorting is usually based on the ASCII order in programming context. The logs report this:

INI : Data\AB_SWAP.ini
INI : Data\Aa_SWAP.ini
INI : Data\B_SWAP.ini
INI : Data\a_SWAP.ini

INI : Data\Seasons\AB_WIN.ini
INI : Data\Seasons\Aa_WIN.ini
INI : Data\Seasons\B_WIN.ini
INI : Data\Seasons\a_WIN.ini

[sheson]

  On 6/5/2024 at 8:05 PM, KRZ said:

Once again everything's brand new, including TerrainLOD this time, but the crashes persist.

DynDOLOD_SSE_Debug: https://mega.nz/file/FDlAwDTa#pI9vxOzqgJoBPAB8x5lMWILKdnqLzjxsXwmVdZ6QzQU

Fwiw, I've noticed there are a ton of 0D and FE005 FormIDs in xEdit's error report, which are

evgSirenroot.esm https://www.nexusmods.com/skyrimspecialedition/mods/70917 and

Landscape and Water Fixes.esp https://www.nexusmods.com/skyrimspecialedition/mods/26138 in my LO.
I wonder whether that's related somehow.

Peculiar, I've done another Alpha 170 output without Sirenroot and Landscape and Water Fixes, but while all the 0D errors are gone, the FE005 have changed. Everything related to this is in Logs 2 & DynDOLOD_SSE_Debug 2.

DynDOLOD_SSE_Debug 2: https://mega.nz/file/9XsBEADa#mMWBomfMs2suBL9rzJLxHOQwFrVpbDRO3ifMmHFhaBs

Logs.zip 1.21 MB · 1 download

Logs 2.zip 1.15 MB · 1 download

Expand  

Lets continue with the generation without Sirenroot and Landscape and Water Fixes. Upload that DynDOLOD.esm

In the meantime, if you are so inclined, could you doublecheck no such errors exist after generation with 169?

[KRZ]

  On 6/6/2024 at 8:05 AM, sheson said:

Lets continue with the generation without Sirenroot and Landscape and Water Fixes. Upload that DynDOLOD.esm

In the meantime, if you are so inclined, could you doublecheck no such errors exist after generation with 169?

Expand  

I'll get back to you once 169 output is generated

DynDOLOD.esm

[KRZ]

  On 6/6/2024 at 8:05 AM, sheson said:

Lets continue with the generation without Sirenroot and Landscape and Water Fixes. Upload that DynDOLOD.esm

In the meantime, if you are so inclined, could you doublecheck no such errors exist after generation with 169?

Expand  

To keep it short, there's no errors besides the Unknown: 2, which are expected. For sake of completion I've included it regardless.

DynDOLOD_SSE_Debug: https://mega.nz/file/gX1RXL6C#uZKEtw9HJCBm72IbmBkq5LNln1E1j6PDS5Hb675C5EE

 

Edit: It's probably a reach, but I wanna try it anyways: I've deleted a ton of entries from Fabled Forests cause I only wanted the additional tree placement, but never actually cleaned the plugin. I just did and it removed 2000 something identical to master records. I'll try another Alpha 170 and see what's going to happen. Nevermind, nothing's changed
 

Logs Alpha 169 (new 2).zipFetching info... DynDOLOD.esm

Edited June 6, 2024 by KRZ

[sheson]

  On 6/6/2024 at 9:24 AM, KRZ said:

To keep it short, there's no errors besides the Unknown: 2, which are expected. For sake of completion I've included it regardless.

DynDOLOD_SSE_Debug: https://mega.nz/file/gX1RXL6C#uZKEtw9HJCBm72IbmBkq5LNln1E1j6PDS5Hb675C5EE

 

Edit: It's probably a reach, but I wanna try it anyways: I've deleted a ton of entries from Fabled Forests cause I only wanted the additional tree placement, but never actually cleaned the plugin. I just did and it removed 2000 something identical to master records. I'll try another Alpha 170 and see what's going to happen. Nevermind, nothing's changed
 

Logs Alpha 169 (new 2).zip 1.15 MB · 2 downloads DynDOLOD.esm

Expand  

Let me know if this test version makes a difference https://mega.nz/file/JMhCEbhI#7lnJ2qwh-K00Uk1zIflcQEEEBQNqHHiLXy9V2y78Xf0

[KRZ]

  On 6/6/2024 at 6:09 PM, sheson said:

Let me know if this test version makes a difference https://mega.nz/file/JMhCEbhI#7lnJ2qwh-K00Uk1zIflcQEEEBQNqHHiLXy9V2y78Xf0

Expand  

Sadly no success. The FormIDs have changed, but xEdit still reports errors. 08 is USSEP.

Fwiw, the crashes in Whiterun and Riften are gone. I'm assuming that with the unintended errors in xEdit the crashes only have changed location though. maybe.

Just to throw in more ideas what could be causing it: I'm using best of both worlds downgrade to 1.5.97 from 1.6.640, perhaps that's causing a missmatch? Latest available downgrade is from 1.6.1130. Also I'm relying on BEES https://www.nexusmods.com/skyrimspecialedition/mods/106441. And I haven't created new Terrain LOD for the non Sirenroot/SLaWF LO. If that needs updating as well, my bad, I didn't know, please tell.

DynDOLOD_SSE_Debug: https://mega.nz/file/4OchDY6S#8eaQcckzsctwFHnhWFHPlCm8NvMY86uFFVX9SAzSlFU

Logs 171.zipFetching info... DynDOLOD.esm

Edited June 6, 2024 by KRZ

[sheson]

  On 6/6/2024 at 7:43 PM, KRZ said:

Sadly no success. The FormIDs have changed, but xEdit still reports errors. 08 is USSEP.

Fwiw, the crashes in Whiterun and Riften are gone. I'm assuming that with the unintended errors in xEdit the crashes only have changed location though. maybe.

Just to throw in more ideas what could be causing it: I'm using best of both worlds downgrade to 1.5.97 from 1.6.640, perhaps that's causing a missmatch? Latest available downgrade is from 1.6.1130. Also I'm relying on BEES https://www.nexusmods.com/skyrimspecialedition/mods/106441. And I haven't created new Terrain LOD for the non Sirenroot/SLaWF LO. If that needs updating as well, my bad, I didn't know, please tell.

DynDOLOD_SSE_Debug: https://mega.nz/file/4OchDY6S#8eaQcckzsctwFHnhWFHPlCm8NvMY86uFFVX9SAzSlFU

Logs 171.zip 232.39 kB · 0 downloads DynDOLOD.esm

Expand  

Do not worry about plugins, versions etc. This is about the internal form IDs not matching the saved master list.

Let me know how are things with this control version https://mega.nz/file/dRZiVTBQ#jcNj-wwdpC8J4rMDrrtfpS8zPYBJ8eRSkSYljOEBQ5M

[KRZ]

  On 6/6/2024 at 8:48 PM, sheson said:

Do not worry about plugins, versions etc. This is about the internal form IDs not matching the saved master list.

Let me know how are things with this control version https://mega.nz/file/dRZiVTBQ#jcNj-wwdpC8J4rMDrrtfpS8zPYBJ8eRSkSYljOEBQ5M

Expand  

This one's looking good in xEdit. Unknown 2 only. No crashes in game either. I've attached DynDOLOD logs, just in case.

DynDOLOD_SSE_Debug: https://mega.nz/file/1OVi3ATa#WQN_Iquyedx69e_4LHhKnCn8BMfQCy4DbkwtNf9cHfw

 

I'll start another run with Sirenroot and SLaWF and share the results once I got them.

Great success. Unknown 2 only.

DynDOLOD_SSE_Debug: https://mega.nz/file/0GdmWY6B#PuPZGFUWPAUm1a1rM7S0YbUGebjXv7GjKfrk2mmc_TU This one's with Sirenroot + SLaWF.

The text-files containing 'Complete' in their title are including Sirenroot + SLaWF.

May I ask how the mismatch came to happen? It sounds like something more people should encounter so I'm still sceptical I messed up somewhere.

Thank you for all the troubleshooting help!

Error Check 170C.txtFetching info... DynDOLOD_SSE_log.txtFetching info...

Error Check 170C Complete.txtFetching info... DynDOLOD_SSE_log Complete.txtFetching info...

DynDOLOD.esm Complete.zipFetching info...

Edited June 7, 2024 by KRZ