DynDOLOD DLL

[TheShadow208]

9 hours ago, sheson said:

Test if it works with this version https://mega.nz/file/odZl0aRT#jMVtY6xEl7A4DqsoUFxe7Dl9Baiw0X5CkUYdBnJTyWQ

Upload new crash log if it doesn't.

I am testing it out now on a new save (I was able to finally initialize DynDOLOD and get past the start of the game successfully)

Out of curiosity, can I ask what changed in this version you supplied me and the public release version of NG? Everything seems to work perfect now

[sheson]

5 minutes ago, TheShadow208 said:

I am testing it out now on a new save (I was able to finally initialize DynDOLOD and get past the start of the game successfully)

Out of curiosity, can I ask what changed in this version you supplied me and the public release version of NG? Everything seems to work perfect now

Good to know. I made sure the function I wrote about earlier is properly implemented.

[TheShadow208]

3 hours ago, sheson said:

Good to know. I made sure the function I wrote about earlier is properly implemented.

Awesome! Thank you so much Sheson. I would have given up without your help the last couple days!

[Chaplit]

I'm sad that this thread has stopped as it has, with @Sheson claiming that the previous poster's issue was due to a version mismatch. I had to make an account and chime in on this, as I've had the very same issue and was definitely using the correct version for my Skyrim runtime. Since I removed the .dll and ran Dyndolod without the large references workaround, I've had no ctd. My last DynDOLOD.log before I removed the plugin:

Spoiler

DynDOLOD NG plugin version: 3.0.13.0 | SKSE version: 2.2.3.0 | Game version: 1-6-640-0
DynDOLOD save/load handler installed.
DynDOLOD Papyrus functions installed.
Default Trampoline => 0B / 28B (00.00%)
Trampoline initialized.
Default Trampoline => 14B / 28B (50.00%)
Default Trampoline => 28B / 28B (100.00%)
DynDOLOD Patch installed.
DynDOLOD Cell Events installed.
DynDOLOD Menu Events installed.
DynDOLOD Player Events installed.
Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Worlds.txt
Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Tamriel.txt

 

[sheson]

34 minutes ago, Chaplit said:

I'm sad that this thread has stopped as it has, with @Sheson claiming that the previous poster's issue was due to a version mismatch. I had to make an account and chime in on this, as I've had the very same issue and was definitely using the correct version for my Skyrim runtime. Since I removed the .dll and ran Dyndolod without the large references workaround, I've had no ctd. My last DynDOLOD.log before I removed the plugin:

  Hide contents

DynDOLOD NG plugin version: 3.0.13.0 | SKSE version: 2.2.3.0 | Game version: 1-6-640-0
DynDOLOD save/load handler installed.
DynDOLOD Papyrus functions installed.
Default Trampoline => 0B / 28B (00.00%)
Trampoline initialized.
Default Trampoline => 14B / 28B (50.00%)
Default Trampoline => 28B / 28B (100.00%)
DynDOLOD Patch installed.
DynDOLOD Cell Events installed.
DynDOLOD Menu Events installed.
DynDOLOD Player Events installed.
Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Worlds.txt
Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Tamriel.txt

 

Despite you mentioning my answer to a post with insufficient information, I have to beg for common sense information yet again:
Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts.
Obviously upload the entire crash log if you have a CTD in the game.

As explained in my signature, replies are based on the provided information or lack thereof. 
So, since I do not have a crystal ball, I speculated a likely reason for the crash. Then never hearing from the user again, typically means the speculation helped.

Update to the the latest version of DynDOLOD DLL NG and Scripts.

[Chaplit]

18 hours ago, sheson said:

Update to the the latest version of DynDOLOD DLL NG and Scripts.

Thanks, I'll try that. I'll post a crash log if it happens again and, like you say, if I don't reply again you can assume the updated DLL fixed it!

[Ylikollikas]

Hello,

I have had this issue with new DynDOLOD version where the game frequently crashes from loading save or just generally running around (more rarely). The crash does not happen without DynDOLOD output. I use latest version DynDOLOD Alpha 3 and DynDOLOD NG. From my observation, it seems disabling bSpeedUpNativeCalls in Papyrus Tweaks NG reduces the rate/chance that this crash occurs but does not eliminate it completely, only disabling DynDOLOD outputs does. Worth noting that two other people I know are also getting crashes with similar logs and same situations (with even the same code, 902691, usually), and disabling DynDOLOD outputs stops the crash for them as well. I can try to get their relevant lod generation logs as well if you want them.

Seems like there also has been discussion about the same crash here and here.

Regardless, here are my textgen and DynDOLOD logs. I also attached crash logs after my last DynDOLOD run, however this is not the first run that has had this crash. Unfortunately no bugreport.txt was generated.

Logs

Please let me know if there is other relevant information I can provide.

[sheson]

1 hour ago, Ylikollikas said:

Hello,

I have had this issue with new DynDOLOD version where the game frequently crashes from loading save or just generally running around (more rarely). The crash does not happen without DynDOLOD output. I use latest version DynDOLOD Alpha 3 and DynDOLOD NG. From my observation, it seems disabling bSpeedUpNativeCalls in Papyrus Tweaks NG reduces the rate/chance that this crash occurs but does not eliminate it completely, only disabling DynDOLOD outputs does. Worth noting that two other people I know are also getting crashes with similar logs and same situations (with even the same code, 902691, usually), and disabling DynDOLOD outputs stops the crash for them as well. I can try to get their relevant lod generation logs as well if you want them.

Seems like there also has been discussion about the same crash here and here.

Regardless, here are my textgen and DynDOLOD logs. I also attached crash logs after my last DynDOLOD run, however this is not the first run that has had this crash. Unfortunately no bugreport.txt was generated.

Logs

Please let me know if there is other relevant information I can provide.

Unless TexGen or DynDOLOD have an exception there won't be a bugreport.txt.

It seems newer a DynDOLOD Standalone version has been installed over older versions. Try a clean install as explained in the https://dyndolod.info/Installation-Instructions

What is more problematic is that there are plugins and patches loading after DynDOLOD.esp and Occlusion.esp. Finalize the load order, in particular other patches before generating the LOD and Occlusion patch. https://dyndolod.info/Generation-Instructions#Prerequisites

The crashes seem cell water related and/or point to a temp ACTI base record FF00FCAF, which is not from DynDOLOD.

There is only one script in DynDOLOD DLL NG that use the mentioned OnCellAttach event. If the problem persists after generating for the entire current load order and DynDOLOD.esp and Occlusion.esp are truly the last plugins to overwrite everything, you could test if there is a difference hiding SHESON_DynDOLOD_ObjectActivator.pex

[Ylikollikas]

Latest DynDOLOD version was clean installed before generating LOD, I just didn't bother to rename the base folder, because I'd have to setup the paths again in MO2.

The plugins loaded after DynDOLOD include

- Empty dummy plugins that were used for BSAs. These have no data and do nothing, I just forgot to remove them. My current DynDOLOD output is not BSA packed.

- The "DynDOLOD dupe trees fix.esp" was used because cities had some duplicate reference trees that had ref refined in DynDOLOD.esp so I just used this patch to disable the duplicates. I'm sure this is issue with how Rogue Unicorn's City Trees mod is built (and how that interacts with dyndolod child/parent worldspace settings) and not fault of DynDOLOD.

- Synthesis patchers, everything between water_patcher0 -> load screen remover are Synthesis patches that are patches generated with Synthesis that forward DynDOLOD changes when needed.

- Cell Settings Patches is just conflict resolution for cell water types with Water for ENB - shades of skyrim, that were missed from DynDOLOD.esp and Occlusion.esp.

- Load screen plugins, I double checked and these ones just add load screens. The reason these are loaded low is because I run load screen remover synthesis patcher to remove load screens from all other mods, then load the load screen mods after the patcher to only get load screens I want.

- Flat map framework plugins, these just touch the wordlspace records. According to modpage for FMFW, these should be loaded after DynDOLOD.

Regardless, I will disable all plugins loaded under DynDOLOD.esp and Occlusion.esp and test if this issue is reproducible on a new game.

I will also test what happens with hiding the script you mentioned, thank you for help.

[sheson]

1 hour ago, Ylikollikas said:

Latest DynDOLOD version was clean installed before generating LOD, I just didn't bother to rename the base folder, because I'd have to setup the paths again in MO2.

The plugins loaded after DynDOLOD include

- Empty dummy plugins that were used for BSAs. These have no data and do nothing, I just forgot to remove them. My current DynDOLOD output is not BSA packed.

- The "DynDOLOD dupe trees fix.esp" was used because cities had some duplicate reference trees that had ref refined in DynDOLOD.esp so I just used this patch to disable the duplicates. I'm sure this is issue with how Rogue Unicorn's City Trees mod is built (and how that interacts with dyndolod child/parent worldspace settings) and not fault of DynDOLOD.

- Synthesis patchers, everything between water_patcher0 -> load screen remover are Synthesis patches that are patches generated with Synthesis that forward DynDOLOD changes when needed.

- Cell Settings Patches is just conflict resolution for cell water types with Water for ENB - shades of skyrim, that were missed from DynDOLOD.esp and Occlusion.esp.

- Load screen plugins, I double checked and these ones just add load screens. The reason these are loaded low is because I run load screen remover synthesis patcher to remove load screens from all other mods, then load the load screen mods after the patcher to only get load screens I want.

- Flat map framework plugins, these just touch the wordlspace records. According to modpage for FMFW, these should be loaded after DynDOLOD.

Regardless, I will disable all plugins loaded under DynDOLOD.esp and Occlusion.esp and test if this issue is reproducible on a new game.

I will also test what happens with hiding the script you mentioned, thank you for help.

You are doing things in the wrong order if you patch anything affected by DynDOLOD and Occlusion.esp afterwards. They are not supposed to be masters in other plugins or any of their records being patched. Conflicts should preferable be solved before records are copied into the DynDOLOD/Occlusion plugins.

Also see https://dyndolod.info/Mods/Maps-And-Map-Mods

[Ylikollikas]

I got the crash a few times after disabling the plugins / mods loaded after DynDOLOD.esp / occlusion.esp. I also tried with hiding the script you mentioned, but the crash still hapened in exactly the same way, which is loading a save after dying. Obviously started a new save after hiding the script. Seems like the code from crash log changed from SkyrimSE.exe+902691 to  SkyrimSE.exe+C072DF when the script you mentioned was disable. For good measure, I again went try to produce the crash without DynDOLOD output and wasn't able to.

Crash_2024_2_27_18-11-51.txt Crash_2024_2_27_18-28-40.txt Crash_2024_2_27_18-40-33.txt Crash_2024_2_27_18-49-52.txt Crash_2024_2_27_19-2-31.txt

Edited February 27 by Ylikollikas

[sheson]

14 hours ago, Ylikollikas said:

I got the crash a few times after disabling the plugins / mods loaded after DynDOLOD.esp / occlusion.esp. I also tried with hiding the script you mentioned, but the crash still hapened in exactly the same way, which is loading a save after dying. Obviously started a new save after hiding the script. Seems like the code from crash log changed from SkyrimSE.exe+902691 to  SkyrimSE.exe+C072DF when the script you mentioned was disable. For good measure, I again went try to produce the crash without DynDOLOD output and wasn't able to.

Crash_2024_2_27_18-11-51.txt 224.41 kB · 2 downloads Crash_2024_2_27_18-28-40.txt 224.16 kB · 2 downloads Crash_2024_2_27_18-40-33.txt 225.06 kB · 2 downloads Crash_2024_2_27_18-49-52.txt 224.55 kB · 2 downloads Crash_2024_2_27_19-2-31.txt 224.63 kB · 2 downloads

All these crashes seem NPC

If you believe the data in DynDOLOD/Occlusion plugins has something to do with them, make sure that DynDOLOD was generated for this load order. Check the plugins for errors with the latest xEdit experimental version from the xEdit discord. https://dyndolod.info/FAQ#Checking-DynDOLOD-plugins-for-errors-with-xEdit

If all that seems OK, test without Occlusion.esp. Then test without DynDOLOD.esp so that only DynDOLOD.esm remains. Once you determined which plugin might be containing problematic data, do a binary search where you make a backup, remove half the data and if problem goes away restore the back and remove the other half and repeat that until only stuff the causes a problem remains.

Start with the records in the Worldspace tree. Remove all worldspaces that are not Tamriel first. Once the worldspace is determined, remove only the persistent woldspace cell first. If it is not in the persistent cell, remove half the blocks, then half teh sub blocks etc. until you are down to a specific temp cell. Once you are down to a temporay or the persistent cell the remove the new records first to see if it is the overwrites or vice versa. Then half the remaining references. Once a single remains, also test with no refererence in a cell, then without the cell overwrite, then with just the worldspace record remaining.

In case it still happens with all worldspaces removed, continue the binary search in the Activator, Door, Furniture, Moveable Static, Static and Tree base record trees. In the end it should be possible to find a record/overwrite pretty quickly that is required for the issue to happen.

[Ylikollikas]

I cheked dyndolod.esm, dyndolod.esp and occlusion.esp for errors with the latest experiemental verion of xEdit downloaded from Discord (4.1.5b), there were no errors except the underslide stuff <Unknown: 2 $2>, which your documentation says doesn't matter. Deleting all blocks from tamriel worldspace in dyndolod.esp fixes the crash, but the problem is removing either half of the blocks keeps the crash. Removing blocks <0,0>, <0,-1>, <1,0>, <1,-1>, <-2,0>, <-2,1> doesn't fix it and neither does removing blocks <-2,-1>, <-1,0>, <-1,1>, <-1,-2>, <-1,-1>. Dyndolod.esm and occlusion.esp don't seem to be involved with the crash. But from this investigation its probably likely that cause of crash is something that appears in multiple blocks of tamriel in dyndolod.esp?

Edited February 28 by Ylikollikas

[Ylikollikas]

When doing the binary search method, I forgot to account for persistent worldspace cell. It indeed seems to be something contained in the persistent worldspace cell. The crash doesn't happen if I just delete persistent worldspace cell and nothing else. I'm going to find it with binary search.

Edited February 28 by Ylikollikas

[Ylikollikas]

Alright, so my binary search lead me to "Tamriel_ShesonObject" cause. First I suspected it is not actually cause, rather removing the master activator would have prevented the real culprit from presenting itself.  However, this was verified by removing all references in worldspace / cell records in dyndolod.esp except the "Tamriel_ShesonObject", which caused the crash to still remain. So it seems Tamriel_ShesonObject is the reference causing the crash.

Basically the situation is:

Only "Tamriel_ShesonObject" -> crash

Everything but "Tamriel_ShesonObject" -> no crash

nvm was too hasty, did few more rounds of death -> reload and the crash did happen

I will investigate more. Also since if someone else who is getting similar crashes could also do similar binary search that'd be great.

Edited February 28 by Ylikollikas