DynDOLOD Beta for Skyrim Special Edition, Skyrim VR and Enderal SE 2.98

[sheson]

Hello!

 

So over the past few days I've been having an issue with DynDOLOD apparently causing a CTD whenever I try to pull up the map from within an interior cell. Removing DynDOLOD's plugins from my load order allows me to use the map as much as I want, but with the plugins if I'm inside of an interior cell I have to exit into a worldspace and re-enter before I can use the map. Using the map when starting a new game with ASLAL, using coc qasmoke from the menu, or loading a save made in an interior cell results in an instant CTD. Because of this, I think it might have something to do with DynDOLOD's initializing process?

 

I've attached my SKSE log and minidump, and here's a paste of my load order.

 

If there's anything else I should post to help diagnose this I'll do my best

Read the FAQ / readme how to troubleshoot common CTD caused by missing/invalid NIFs.

 

If that did not reveal anything, first hide the meshes/texture from out out to make sure the static object and tree LOD has nothing to do with the problem.

 

Then only disable DynDOLOD.esp and only enable DynDOLOD.esm to see if that works. If the problem still happens disable DynDOLOD.esm too - to make extra sure the issue related to DynDOLOD at all.

 

Once you are certain the problem is in DynDOLOD.esp you can start to remove batches of records from it until only the record causing the issue remains. I will explain that in more detail if any of the above did not help already.

[softboy_rodvt]

Read the FAQ / readme how to troubleshoot common CTD caused by missing/invalid NIFs.

 

If that did not reveal anything, first hide the meshes/texture from out out to make sure the static object and tree LOD has nothing to do with the problem.

 

Then only disable DynDOLOD.esp and only enable DynDOLOD.esm to see if that works. If the problem still happens disable DynDOLOD.esm too - to make extra sure the issue related to DynDOLOD at all.

 

Once you are certain the problem is in DynDOLOD.esp you can start to remove batches of records from it until only the record causing the issue remains. I will explain that in more detail if any of the above did not help already.

I suppose I should've mentioned I tried the steps of hiding the meshes and textures, and then hiding both the ESP and ESM. The issue did not persist with the meshes and without the plugin/master, so I'll try later tonight with only the ESM.

 

Sorry for leaving that detail out!

[softboy_rodvt]

Sorry for double posting(my account is too new for me to edit my last post)

I still get the map crash issue with only DynDOLOD.esm active, I can only avoid it if I have both disabled.

[sheson]

Sorry for double posting(my account is too new for me to edit my last post)

 

I still get the map crash issue with only DynDOLOD.esm active, I can only avoid it if I have both disabled.

Good. That narrows it down quite a bit.

 

You can now do a binary search type of thing where you make a backup of the plugin and use xEdit to remove batches of records from the ESM. If the problem is gone, go back to the backup and remove other records. That way you will eventually end up only with the record causing the problem.

 

Logically the issue should only be with records with the worldspace Tamriel. So start by removing all other worldspaces. You do this in xEdit by right clicking on the worldspace name and selecting remove.

 

If it still has the issue after removing them, remove the Tamriel persistent cell 00000D74. If the problem goes away go back to the update and remove all "Blocks" which are childs of 0000003C Tamriel. If the problem seems to be in one of the "Blocks", remove them one by one or in 50% batches. The continue with the subblocks etc. Once you are down to a cell, remove the content of the CELL first.

 

It is possible that the problem is with something on the worldspace record 3C itself. So you might want to do a quicktest with removing all childs first.

 

In any case you should be able to narrow it down to a single record and it will go pretty quickly if you remove half the records each time.

 

Let me know if anything is unclear or needs more explanation.

[softboy_rodvt]

So, having followed your instructions and stripping the DynDOLOD.esm's worldspace records to only 0000003C, I still get the interior cell map crash.

I feel I should clarify; I only get this crash when either starting or loading a save in an interior cell. If I open the map in an interior cell, having loaded into an exterior worldspace before that, the map shows up just fine with no crash. If I load the autosave made from the cell transition of entering a building and then pull up the map, it results in a crash when opening the map.

[sheson]

So, having followed your instructions and stripping the DynDOLOD.esm's worldspace records to only 0000003C, I still get the interior cell map crash.

 

I feel I should clarify; I only get this crash when either starting or loading a save in an interior cell. If I open the map in an interior cell, having loaded into an exterior worldspace before that, the map shows up just fine with no crash. If I load the autosave made from the cell transition of entering a building and then pull up the map, it results in a crash when opening the map.

 

And if you remove the worldspace 3C from the plugin the problem is gone?

Edited April 24, 2019 by sheson

[softboy_rodvt]

And if you remove the worldspace 3C from the plugin the problem is gone?

Just tried that now; the problem still persists, even with every single worldspace record removed from DynDOLOD.esm.

 

Maybe it's time to just redo my load order, maybe 280 plugins isn't all that healthy to begin with, even if they're half ESL/ESPFE

Edited April 24, 2019 by softboy_rodvt

[jmarceno]

Well typically works fine with multiple cores (and HT) on with one CPU.

 

The multi-threading is a bit brittle with Delphi and me not giving it all the required (if this was paid software) attention to potential deadlocks, resource or memory contention issues. Eventually xEdit and DynDOLOD will switch to the newer Delphi version - which seems to be much more picky in this regard as well. That means some time in the future that might just solve that issue for you.

 

The x86 version most likely just runs out of memory. The next version will use less memory when doing the atlas, so it should be able to create the atlas as well. It might run through require the same treatment as the x64 in your case.

 

The LODGen.exe process is started only once the atlas has been created so it should have no influence on this issue.

Thank you for the reply. Will continue to use with the 1 core affinity them. regards.

[sheson]

Just tried that now; the problem still persists, even with every single worldspace record removed from DynDOLOD.esm.

 

Maybe it's time to just redo my load order, maybe 280 plugins isn't all that healthy to begin with, even if they're half ESL/ESPFE

Interesting. If that is the case, remove the remaining records in batches as well.

 

You have SSE Engine Fixes installed?

[softboy_rodvt]

Interesting. If that is the case, remove the remaining records in batches as well.

 

You have SSE Engine Fixes installed?

I do, although removing Engine Fixes didn't solve my issue either

 

I ended up just reinstalling, hoping that a less bloated load order won't have this issue. My Skyrim VR install with DynDOLOD also doesn't have this problem either lol

 

Another thing I noticed is, when running the .dmp through WinDBG, the crash seemed to be due to an Acces Violation(ExceptionCode: c0000005). I have to wonder why it'd be reading as a memory issue on my end, all 32gb of my RAM is pretty fine last I checked. Maybe this reinstall will work it out either way

Edited April 25, 2019 by softboy_rodvt

[sheson]

I do, although removing Engine Fixes didn't solve my issue either

 

I ended up just reinstalling, hoping that a less bloated load order won't have this issue. My Skyrim VR install with DynDOLOD also doesn't have this problem either lol

 

Another thing I noticed is, when running the .dmp through WinDBG, the crash seemed to be due to an Acces Violation(ExceptionCode: c0000005). I have to wonder why it'd be reading as a memory issue on my end, all 32gb of my RAM is pretty fine last I checked. Maybe this reinstall will work it out either way

My question about Engine Fixes was about the persistent reference cap, since it would notify you.

 

The x5 Access Violation is such a generic error message, it seems it could mean anything.

[softboy_rodvt]

My question about Engine Fixes was about the persistent reference cap, since it would notify you.

 

The x5 Access Violation is such a generic error message, it seems it could mean anything.

Hmm, would it have notified me in the EngineFixes.log? I'm willing to bet it might be the persistent reference cap being the issue, but I'm not seeing anything relating to that in that log.

Edited April 25, 2019 by softboy_rodvt

[sheson]

Hmm, would it have notified me in the EngineFixes.log? I'm willing to bet it might be the persistent reference cap being the issue, but I'm not seeing anything relating to that in that log.

There is a pop-up message when the count is over a certain number, so you can't miss it.

[softboy_rodvt]

There is a pop-up message when the count is over a certain number, so you can't miss it.

I had no pop-up message, just a clean instant CTD whenever I'd press M or pull up the map from an interior.

[softboy_rodvt]

Update; One new install and 230 plugins later, my map screen doesn't crash anymore!