Crash fron DynDOD "BGS water collision"

[MonolithK]

I'm absolutely sorry if this has been covered in FAQ or anywhere else for starters! 

 

I've spent two long nights generating LODs constantly trying to figure out what is wrong, even if it was fruitless by my own fault I have been trying! I also struggled more at first as during learning DynDLOD I actually was under the impression I was doing the steps wrong constantly and as a result lots of information wasn't sticking and instead I was bound to a lot of trial and error before realising I seemingly had been handling things at least decently. Anyhow, onto the actual problem!

I am currently using the Skyrim Seasons series of mods Seasonal Landscapes, turn of the seasons, seasons of bruma + unfrozen etc hence my main reasons for using DyndLOD. Anyway, During my experianfe everything is seemingly going perfectly until I get in game. Skyrim seems to work perfectly, but upon my arrival to Bruma things begin to turn a little confusing. Upon entering an interior and exiting approximately two times I replicate a consistent crash to desktop issue. Now  I dialed back my load order a lot and tried quite a few things but this problem never seemed to stop, it also seemingly popped up recently out of nowhere as on my initial tests I had gotten Bruma working just fine. Anyhow, at first I deduced that "Bruma Unfrozen" was the problem as when I removed it the crash disappeared. Then I decided to rebuild my Dyndlod assets and such so I wouldn't have the missing master for "Bruma Unfrozen". However once I completed the LOD generation and such... The crash came back! This led me to spend two consecutive nights troubleshooting and trying varities with no fruit until I at least noticed one small pattern in my circumstance. Whenever the Dyndlod.esp had a missing master (it could be any as long as one was missing) the crash would seemingly resolve itself although I haven't tested prolonged play sessions with this either That was the result I arrived at and what led me to mistakenly blame "Bruma Unfrozen" initially. 

Now among my antics, I actually didn't check the LOD gen console during generation for my most recent generations, but I do recall the earliest ones that did work initially seemingly not having any errors but either way, point is at this moment I can't comment on that aspect. Anyhow, this is where my current knowledge and troubleshooting had led me to. I was hoping someone could share some insight and advice?

I apologise if I am selfish and considered to be wasting people's time, I spent a lot of time at this and I will have to start picking up the pace IRL (I may be unavailable for around a day or two) and so I wanted to share my situation in advance in hopes that when I return I could either have answers as to if I need to do more diagnosis or if I stumbled upon something unusual. Yet again, I am very sorry for wasting anyone's time.

 

Below I will provide a crash log that should sample this issue (I am quite confident) it is not the most recent log but it seemed to entail and consistent error to what I've been getting throughout and triggered by the same causes. I can upon return produce another log if needed.

Log:

https://pastebin.com/A7JYM0Eq

 

I will be unavailable for approximately a day or two (away from my computer) but I'll still have phone access so hopefully I can answer some stuff sensibly if need be!

 

As another note, I am using DynDLOD 3 Alpha!

Edited May 5 by MonolithK
Added crash log, extra info

[sheson]

7 hours ago, MonolithK said:

So the good news is, this crash is incredibly easy for me to reproduce.
Go to Bruma, go indoors then outdoors about two times and then crash! Very easy to do.

I have briefly tested with this .ini you have provided and generated DynDOLOD again and I haven't crashed or been able to reproduce a similar one (I haven't crashed at all)
Whatever you provided here seems to have fixed the crash from happening! I'm not sure what you adjusted or how I can continue to replicate this (if I change my order). But as it is with what you have given me the crash seems to be gone!

That is great.

I added a rule that prevents the creation of the NIF, which shouldn't happen in the first place. It should not been created in the first place, so taht will be properly addressed in the next alpha version.

[sheson]

On 5/5/2024 at 12:13 PM, MonolithK said:

I'm absolutely sorry if this has been covered in FAQ or anywhere else for starters! 

 

I've spent two long nights generating LODs constantly trying to figure out what is wrong, even if it was fruitless by my own fault I have been trying! I also struggled more at first as during learning DynDLOD I actually was under the impression I was doing the steps wrong constantly and as a result lots of information wasn't sticking and instead I was bound to a lot of trial and error before realising I seemingly had been handling things at least decently. Anyhow, onto the actual problem!

I am currently using the Skyrim Seasons series of mods Seasonal Landscapes, turn of the seasons, seasons of bruma + unfrozen etc hence my main reasons for using DyndLOD. Anyway, During my experianfe everything is seemingly going perfectly until I get in game. Skyrim seems to work perfectly, but upon my arrival to Bruma things begin to turn a little confusing. Upon entering an interior and exiting approximately two times I replicate a consistent crash to desktop issue. Now  I dialed back my load order a lot and tried quite a few things but this problem never seemed to stop, it also seemingly popped up recently out of nowhere as on my initial tests I had gotten Bruma working just fine. Anyhow, at first I deduced that "Bruma Unfrozen" was the problem as when I removed it the crash disappeared. Then I decided to rebuild my Dyndlod assets and such so I wouldn't have the missing master for "Bruma Unfrozen". However once I completed the LOD generation and such... The crash came back! This led me to spend two consecutive nights troubleshooting and trying varities with no fruit until I at least noticed one small pattern in my circumstance. Whenever the Dyndlod.esp had a missing master (it could be any as long as one was missing) the crash would seemingly resolve itself although I haven't tested prolonged play sessions with this either That was the result I arrived at and what led me to mistakenly blame "Bruma Unfrozen" initially. 

Now among my antics, I actually didn't check the LOD gen console during generation for my most recent generations, but I do recall the earliest ones that did work initially seemingly not having any errors but either way, point is at this moment I can't comment on that aspect. Anyhow, this is where my current knowledge and troubleshooting had led me to. I was hoping someone could share some insight and advice?

I apologise if I am selfish and considered to be wasting people's time, I spent a lot of time at this and I will have to start picking up the pace IRL (I may be unavailable for around a day or two) and so I wanted to share my situation in advance in hopes that when I return I could either have answers as to if I need to do more diagnosis or if I stumbled upon something unusual. Yet again, I am very sorry for wasting anyone's time.

 

Below I will provide a crash log that should sample this issue (I am quite confident) it is not the most recent log but it seemed to entail and consistent error to what I've been getting throughout and triggered by the same causes. I can upon return produce another log if needed.

Log:

https://pastebin.com/A7JYM0Eq

 

I will be unavailable for approximately a day or two (away from my computer) but I'll still have phone access so hopefully I can answer some stuff sensibly if need be!

 

As another note, I am using DynDLOD 3 Alpha!

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts.

The uploaded crash log seems truncated, the list of plugins appears incomplete. It also seems to have lost its formatting, try to keep that intact.

By default DynDOLOD does not generate any LOD for the Bruma/Cyrodiil worldspace.

The crash seems to be between the NPC and water. It may be not cell water.

This overwrite of 0x14 by ccbgssse018-shadowrend.esl seems suspicious:

Name: "Prisoner"
FormID: 0x00000014
FormType: ActorCharacter (62)
Object Reference: 
File: "ccbgssse018-shadowrend.esl"
Modified by: Skyrim.esm -> ccbgssse018-shadowrend.esl

DynDOLOD does not affect the NPC or cell water, or collision, but it might add references for water, however, typically the player can not reach (collide with ) those. However, we do not see any such references mentioned in the crash log.

DynDOLOD does copy cell records from the winning plugin the time when it adds references in those cells. The crash log shows a couple of those records being last overwritten by Occlusion.esp, which also just copies cell records from the winning plugin and then updates TVDT data - which is unrelated to water and unproblematic in itself.

The crash log shows that DynDOLOD.esp and Occlusion.esp are being overwritten by other plugins. Fix that mistake by first finalizing the load order and then generating LOD for it. Do not modify the load order after generating LOD.
Try to reproduce the crash with the same load order that LOD was being generated for.
If it still happens, disable only Occlusion.esp.
If it still happens, disable only DynDOLOD.esp. If that makes a difference, see https://dyndolod.info/FAQ#ILS-or-CTD answer about reading the DynDOLOD-Readme.txt to check for assets via enabling debugging and checking the papyrus. Upload the papyrus log. Upload the DynDOLOD log and debug for that last generation. Upload the new crash log.

[MonolithK]

Quote

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts.

The uploaded crash log seems truncated, the list of plugins appears incomplete. It also seems to have lost its formatting, try to keep that intact.

That's rather odd, I may have made a mistake (I shared that log via phone) I will be providing a new one in hopes that it wont have any problems, I didn't mean to intentionally muddle the log!
Hopefully this one will suffice (found at bottom of this post!
New DynDOLOD Log:
BugReport: Wasn't produced
TexGen SSE Log: https://ufile.io/0bjl38o1
TexGen SSE Debug Log: https://ufile.io/ti2d3jq7
DynDOLOD: https://ufile.io/tfvic3eh  (I believe these are the relevant logs, pardon if I've gotten this process wrong)

These logs are based on me reproducing the steps that lead to my crash (including the entire Dyndlod generation process done anew in order to ready up new logs)
 

Quote

 

The crash log shows that DynDOLOD.esp and Occlusion.esp are being overwritten by other plugins. Fix that mistake by first finalizing the load order and then generating LOD for it. Do not modify the load order after generating LOD.

 

This is correct, I've had my load order finalized before and such but its only one set of mods I have overwriting anything from DynDOLOD, though perhaps my approach is incorrect? Anyhow, the mods I have on top of DynDOLOD.esp and Occlusion.esp are mods to do with "Flat Map Framework". I recall reading around Nexus that the correct approach is load these after DynDOLOD. I assume this may be the incorrect incorrect approach? But otherwise, I have absolutely nothing else overwriting it.

Quote

If it still happens, disable only Occlusion.esp.
If it still happens, disable only DynDOLOD.esp. If that makes a difference, see https://dyndolod.info/FAQ#ILS-or-CTD answer about reading the DynDOLOD-Readme.txt to check for assets via enabling debugging and checking the papyrus. Upload the papyrus log. Upload the DynDOLOD log and debug for that last generation. Upload the new crash log.

 

Quote

If it still happens, disable only Occlusion.esp.
If it still happens, disable only DynDOLOD.esp

New Crash Log;
As Usual Crash Log (brand new and hopefully nothing is missing? Both .esp enabled): https://ufile.io/1lk12vix
Disabled Only Occlusion.esp crash log: https://ufile.io/27ppt7un
Disabled only DynDOLOD.esp:  (No crash seemingly)

Quote

 If that makes a difference, see https://dyndolod.info/FAQ#ILS-or-CTD answer about reading the DynDOLOD-Readme.txt to check for assets via enabling debugging and checking the papyrus. Upload the papyrus log. Upload the DynDOLOD log and debug for that last generation. Upload the new crash log.

I'll try to get on it now!

Edited May 6 by MonolithK

[MonolithK]

So Right so the log mentions no .exe errors from what I can tell

Seemingly hiding the terrain .bto files doesn't work/stop the crash? (Put them into sub folders assuming that works)
I do have some warnings of "root block is ninode" (thought I'm not sure how to follow the instructions for the advice offered on this point)

I seemingly have no "Error: when loading MESH" types of problems from what I can tell.
Also, when told to enable the DynDOLOD debug, I get no

"[05/16/2015 - 01:15:10PM] [SHESON_DynDOLOD_LODObject < (0D003F52)>] using base element [Form < (0D0010F3)>] using meshes\architecture\farmhouse\farmhousewindmill\farmhousewindmillfan.nif"

Type notes in the papyrus, the closest I get is:

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A8082251)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif

There's more of these but they're all "Enable" is what I mean.

I am providing my papyrus log too just as precaution in advance: https://ufile.io/qqyuvooq

UPDATE:

I slightly narrowed the crash cause (but I don't understand it or how to fix it)
DynDOLOD Output/Meshes/DynDOLOD/NoHavoc/

Inside this folder there are two files:
lux_lanternsolitudehanging02_nohavok.nif
water1024_nohavok.nif

One of these files is crashing my game, as when I entirely removed the mcrash seemed to stop? But I don't know what it means to remove these or if it will cause problems or even the reason why these problems are occurring.
I haven't narrowed which file is specifically the problem but considering the problem I am of the belief it is "water1024_nohavok.nif" 

UPDATE 2:

"water1024_nohavok.nif" appears to indeed be the problem, although I genuinely don't know what this file is or the context behind it if anyone could chime in and explain a bit more or is gaining an understanding of the situation. As far as I understand is that its a mesh that DynDOLOD generated and that's about it.

Edited May 7 by MonolithK

[sheson]

11 hours ago, MonolithK said:

This is correct, I've had my load order finalized before and such but its only one set of mods I have overwriting anything from DynDOLOD, though perhaps my approach is incorrect? Anyhow, the mods I have on top of DynDOLOD.esp and Occlusion.esp are mods to do with "Flat Map Framework". I recall reading around Nexus that the correct approach is load these after DynDOLOD. I assume this may be the incorrect incorrect approach? But otherwise, I have absolutely nothing else overwriting it.

As explained https://dyndolod.info/Generation-Instructions, the correct approach is to finalize the load order before generating LOD and to not temporality disable anything.
The patch plugins generated by DynDOLOD are made by copying the winning records for the plugins at the generation time.

You may need to overwrite generated output. See https://dyndolod.info/Mods/Maps-And-Map-Mods for more detail.

This is probably unrelated to the crash.

8 hours ago, MonolithK said:

Type notes in the papyrus, the closest I get is:

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A8082251)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif

This will probably be it. That will be the placeable water causing an issue. 

It shouldn't exist though. It should be using water1024_dyndolod_lod.nif instead.

I am not sure the DynDOLOD log and debug are from the same generation as the papyrus log as I can not seem to find the mentioned form IDs, so do this:

Load the DynDOLOD plugins into xEdit and look up one of the mentioned references like xx082251 in DynDOLOD.esp

The first two digits xx are the load order ID of the DynDOLOD.esp, so substitute those with the one show in front of the DynDOLOD.esp in the left tree view. Enter the entire form ID into the field top left and hit Enter.

Let me know the EDID - Editor ID of the reference shown in the right window.

[MonolithK]

Quote

 

As explained https://dyndolod.info/Generation-Instructions, the correct approach is to finalize the load order before generating LOD and to not temporality disable anything.
The patch plugins generated by DynDOLOD are made by copying the winning records for the plugins at the generation time.

You may need to overwrite generated output. See https://dyndolod.info/Mods/Maps-And-Map-Mods for more detail.

This is probably unrelated to the crash.

 

I have just made a new Load order and am pretty nothing changed between generation, but the crash still occurs so I do think its safe to say at least this part is unrelated to the crash? But I shall operate with this in mind from now on as further precaution!

Quote

I am not sure the DynDOLOD log and debug are from the same generation as the papyrus log as I can not seem to find the mentioned form ID

I am pretty certain I did everything correct. At "worst" I might have provided an old log in the event of a new one not being produced (whatever reason that may have been), but I checked each one and I am relatively certain the logs were newly generated and most recent.

Quote

 

Load the DynDOLOD plugins into xEdit and look up one of the mentioned references like xx082251 in DynDOLOD.esp

The first two digits xx are the load order ID of the DynDOLOD.esp, so substitute those with the one show in front of the DynDOLOD.esp in the left tree view. Enter the entire form ID into the field top left and hit Enter.

Let me know the EDID - Editor ID of the reference shown in the right window.

 

For the sake or clarity and continuity, whilst doing this I am not going to be using the DynDOLOD I generated today where I ensured the load order was correct, I'll be continuing where we left off with the newly generated logs so the circumstance makes as much sense as possible! But if request I can do it to the new generation too.
Also please bare with me, I am rather crude with Xedit so pardon any mistakes.

I will try going through as many of the "water1024_nohavok.nif" that were referenced in the logs that I sensibly can in XEdit.

Spoiler

1st three log errors

• [05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A80822EE)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
   
• [05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A8082252)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
   
• [05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A80821E1)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif

The editor ID is: Water1024RiverFlowSE_DynDOLOD_BASE

Spoiler

2nd log error

• [05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A808194A)>] Enable #3 [Form < (2700DEF2)>] using dyndolod\nohavok\water1024_nohavok.nif

The editor ID is: Water1024ClearAnkleStill_DynDOLOD_BASE

Spoiler

Then the, the first one comes back up again in the log three more times:

• [05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A8082308)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
   
• [05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A8082251)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
   
• [05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A80821DF)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif

The editor ID is: Water1024RiverFlowSE_DynDOLOD_BASE

In total 7 errors related to "water1024_nohavok.nif".
Please tell me if I've done anything wrong, hopefully this is the correct information.

I copied the forms from each error and searched them up within the DynDOLOD.esp! Pardon if that isn't quite what you asked, if not I may need further instruction.

 

 

 

Edited May 7 by MonolithK

[sheson]

5 minutes ago, MonolithK said:

I have just made a new Load order am pretty nothing changed between generation, but the crash still occurs so I do think its safe to say at least this part is unrelated to the crash? But I shall operate with this in mind from now on as further precaution!

I am pretty certain I did everything correct. At "worst" I might have provided an old log in the event of a new one not being produced (whatever reason that may have been), but I checked each one and I am relatively certain the logs were newly generated and most recent.

For the sake or clarity and continuity, whilst doing this I am not going to be using the DynDOLOD I generated today where I ensured the load order was correct, I'll be continuing where we left off with the newly generated logs so the circumstance makes as much sense as possible!
Also please bare with me, I am rather crude with Xedit so pardon any mistakes.

I will try going through as many of the "water1024_nohavok.nif" that were referenced in the logs that I sensibly can in XEdit.

  Hide contents

1st three log errors

• [05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A80822EE)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
   
• [05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A8082252)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
   
• [05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A80821E1)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif

The editor ID is: Water1024RiverFlowSE_DynDOLOD_BASE

  Hide contents

2nd log error

• [05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A808194A)>] Enable #3 [Form < (2700DEF2)>] using dyndolod\nohavok\water1024_nohavok.nif

The editor ID is: Water1024ClearAnkleStill_DynDOLOD_BASE

  Hide contents

Then the, the first one comes back up again in the log three more times:

• [05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A8082308)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
   
• [05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A8082251)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
   
• [05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A80821DF)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif

The editor ID is: Water1024RiverFlowSE_DynDOLOD_BASE

In total 7 errors related to "water1024_nohavok.nif".
Please tell me if I've done anything, hopefully this is the correct information.

"Water1024RiverFlowSE_DynDOLOD_BASE" looks like an editor ID of base record, like you looked up xx00DEFA?

Look up the references, like the from IDs xx0821DF, xx082251, xx082308 for example. They use that base record, but will have a different Editor ID, but they probably all mention the same plugin as source.

[MonolithK]

53 minutes ago, sheson said:

"Water1024RiverFlowSE_DynDOLOD_BASE" looks like an editor ID of base record, like you looked up xx00DEFA?

Look up the references, like the from IDs xx0821DF, xx082251, xx082308 for example. They use that base record, but will have a different Editor ID, but they probably all mention the same plugin as source.

Sorry I'm not following properly perhaps.
My DynDOLOD.esp first two characters are "A8". so I suppose "A800DEFA" is what to look up.
I may need an explanation on "look up" aspect for this.
 

EDIT:
Ah okay I believe I was being a little silly sorry. I think I figured it out.
I will provide now.

Is this an example you are looking for:
 A80822EE <bsheartlandesm_049587_BSHeartland_DynDOLOD_OBJECT

I will include all 7 errors that feature "water1024_nohavok.nif", A8 is the first two characters for DynDOLOD.esp in xedit.

Spoiler

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A80822EE)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
Editor ID: bsheartlandesm_049587_BSHeartland_DynDOLOD_OBJECT
From looking up: A80822EE 

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A8082252)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
Editor ID: bsheartlandesm_049531_BSHeartland_DynDOLOD_OBJECT
From looking up: A8082252

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A80821E1)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
Editor ID: bsheartlandesm_0494FB_BSHeartland_DynDOLOD_OBJECT
From looking up: A80821E1

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A808194A)>] Enable #3 [Form < (2700DEF2)>] using dyndolod\nohavok\water1024_nohavok.nif
Editor ID: bsheartlandesm_04931B_BSHeartland_DynDOLOD_OBJECT
From looking up: A808194A

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A8082308)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
Editor ID: bsheartlandesm_04958C_BSHeartland_DynDOLOD_OBJECT
From looking up: A8082308

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A8082251)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
Editor ID: bsheartlandesm_049548_BSHeartland_DynDOLOD_OBJECT
From looking up: A8082251

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A80821DF)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
Editor ID: bsheartlandesm_049503_BSHeartland_DynDOLOD_OBJECT
From looking up: A80821DF

Have I done it correctly?

Quote

Look up the references, like the from IDs xx0821DF, xx082251, xx082308 for example. They use that base record, but will have a different Editor ID, but they probably all mention the same plugin as source.

As I am understanding it so far, I believe all the water havoc errors and IDs do indeed mention DynDOLOD.esp and they all match up with A8 where my DynDOLOD stands.
Looking at the rest of the errors in the papyrus log we generated from yesterday too, I appear to also be seeing "A8" across the logs errors, in XEdit A8 is the DynDOLOD.esp so I assume that would mean these errors affiliated plugin will be DynDOLOD.esp?

Also pardon me, I am trying my hardest to keep up, I'm just not totally knowledgeable on everything, genuinely trying and I appreciate the support very much.

Edited May 7 by MonolithK

[sheson]

44 minutes ago, MonolithK said:

Sorry I'm not following properly perhaps.
My DynDOLOD.esp first two characters are "A8". so I suppose "A800DEFA" is what to look up.
I may need an explanation on "look up" aspect for this.
 

EDIT:
Ah okay I believe I was being a little silly sorry. I think I figured it out.
I will provide now.

Is this an example you are looking for:
 A80822EE <bsheartlandesm_049587_BSHeartland_DynDOLOD_OBJECT

I will include all 7 errors, A8 is the for DynDOLOD.esp

  Hide contents

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A80822EE)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
Editor ID: bsheartlandesm_049587_BSHeartland_DynDOLOD_OBJECT
From looking up: A80822EE 

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A8082252)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
Editor ID: bsheartlandesm_049531_BSHeartland_DynDOLOD_OBJECT
From looking up: A8082252

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A80821E1)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
Editor ID: bsheartlandesm_0494FB_BSHeartland_DynDOLOD_OBJECT
From looking up: A80821E1

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A808194A)>] Enable #3 [Form < (2700DEF2)>] using dyndolod\nohavok\water1024_nohavok.nif
Editor ID: bsheartlandesm_04931B_BSHeartland_DynDOLOD_OBJECT
From looking up: A808194A

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A8082308)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
Editor ID: bsheartlandesm_04958C_BSHeartland_DynDOLOD_OBJECT
From looking up: A8082308

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A8082251)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
Editor ID: bsheartlandesm_049548_BSHeartland_DynDOLOD_OBJECT
From looking up: A8082251

[05/06/2024 - 09:25:49PM] [SHESON_DynDOLOD_LODObject < (A80821DF)>] Enable #3 [Form < (2700DEFA)>] using dyndolod\nohavok\water1024_nohavok.nif
Editor ID: bsheartlandesm_049503_BSHeartland_DynDOLOD_OBJECT
From looking up: A80821DF

Have I done it correctly?

As I am understanding it so far, I believe all the water havoc errors and IDs do indeed mention DynDOLOD.esp and they all match up with A8 where my DynDOLOD stands

Check in xEdit if any plugin is overwriting the base record with the form id 0010CAC1 in Skyrim.esm. The name of the last plugin to the very right.

Also upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt

 

[MonolithK]

10 minutes ago, sheson said:

Check in xEdit if any plugin is overwriting the base record with the form id 0010CAC1 in Skyrim.esm. The name of the last plugin to the very right.

 

Uploaded an image to show, as far as I can tell/understand I don't see any overwriting, hopefully with this picture you can also verify it for me?

Quote

Also upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt

Slight problem, the log generated for this from yesterday has been replaced from when I used DynDOLOD today when you were mentioning not altering the load order at all. So this log isn't 100% representative of the the current scenario but the generation resulting from this log still produced the same in game crash. If this isn't satisfactory I can follow further steps. (the differences in load order are fairly minimal to my memory)

Log: https://ufile.io/jaogmjq7

[sheson]

45 minutes ago, MonolithK said:

Uploaded an image to show, as far as I can tell/understand I don't see any overwriting, hopefully with this picture you can also verify it for me?

Slight problem, the log generated for this from yesterday has been replaced from when I used DynDOLOD today when you were mentioning not altering the load order at all. So this log isn't 100% representative of the the current scenario but the generation resulting from this log still produced the same in game crash. If this isn't satisfactory I can follow further steps. (the differences in load order are fairly minimal to my memory)

Log: https://ufile.io/jaogmjq7

Replace ..\DynDOLOD\Edit Scripts\DynDOLOD\Rules\DynDOLOD_SSE_low.ini

Then generate LOD again from scratch. If you use the advanced options, make sure to click 'low' top right to load the update rules.

Let me know if that changes anything.

[MonolithK]

1 hour ago, sheson said:

Replace ..\DynDOLOD\Edit Scripts\DynDOLOD\Rules\DynDOLOD_SSE_low.ini

Then generate LOD again from scratch. If you use the advanced options, make sure to click 'low' top right to load the update rules.

Let me know if that changes anything.

So the good news is, this crash is incredibly easy for me to reproduce.
Go to Bruma, go indoors then outdoors about two times and then crash! Very easy to do.

I have briefly tested with this .ini you have provided and generated DynDOLOD again and I haven't crashed or been able to reproduce a similar one (I haven't crashed at all)
Whatever you provided here seems to have fixed the crash from happening! I'm not sure what you adjusted or how I can continue to replicate this (if I change my order). But as it is with what you have given me the crash seems to be gone!

Edited May 7 by MonolithK

[Ibsen23]

I've been experiencing an almost identical crash for a few weeks. Thank you for this great conversation. I'm going to try the DynDOLOD_SSE_low fix as soon as I can. In the meantime, Sheson, are those DLL settings specific to what you found in Monolith's logs? Also curious as to what was adjusted and why. Good luck MonolithK, and thanks sheson.

edit: ok duh, so looks like you added water1024 & 2048 to unchanged status. Basically just excluding them from lod generation?

Edited May 7 by Ibsen23

[MonolithK]

1 hour ago, Ibsen23 said:

I've been experiencing an almost identical crash for a few weeks. Thank you for this great conversation. I'm going to try the DynDOLOD_SSE_low fix as soon as I can. In the meantime, Sheson, are those DLL settings specific to what you found in Monolith's logs? Also curious as to what was adjusted and why. Good luck MonolithK, and thanks sheson.

edit: ok duh, so looks like you added water1024 & 2048 to unchanged status. Basically just excluding them from lod generation?

I'm also curious as to where the problem stems from cause/reason if possible so I can try to avoid it in the future, this crash has been on my mind nonstop since it started I'd like to learn what I can about it!
Hopefully Sheson will have more to say.

[Ibsen23]

Can confirm absolutely worked for me. Thanks again, both of you.