Jump to content

DynDOLOD 3.00 Alpha 180


sheson

Recommended Posts

2 hours ago, Blackread said:

Putting all this together I would conclude that you were right in that it was a navmesh related issue. Not in terms of conflicts, but some undetermined latent issue with my edits to the deleted navmeshes that would only manifest if the plugin had ESM flag applied to it.

Thanks for following up with all the details and clarifications. At this point it's pretty clear the issue has nothing to do with DynDOLOD and is specific to your navmesh patch so I'll keep my comments short:

  • Editing navmeshes in CK is way beyond my knowledge so I can't help you there.
  • As far as I understand, if the Navigation Mesh Info Map links to door/portal/passage references, they need to be persistent. Not being explicitly defined as persistent in the ESP may not be a problem, but could become one once the plugin is ESMified,  as they would now be truly temporary.
2 hours ago, Blackread said:

It didn't make a big difference in the stability of my game as I had already resolved this issue in an alternative manner by separating the large ref edits into a plugin which I flagged as a master

That's good advice and is actually much easier and safer than ESMifying whole plugins if the goal is to fix a few large references bugs rather than limiting the number of references.

Link to comment
Share on other sites

1 hour ago, Mousetick said:

Thanks for following up with all the details and clarifications. At this point it's pretty clear the issue has nothing to do with DynDOLOD and is specific to your navmesh patch so I'll keep my comments short:

  • Editing navmeshes in CK is way beyond my knowledge so I can't help you there.
  • As far as I understand, if the Navigation Mesh Info Map links to door/portal/passage references, they need to be persistent. Not being explicitly defined as persistent in the ESP may not be a problem, but could become one once the plugin is ESMified,  as they would now be truly temporary.

That's good advice and is actually much easier and safer than ESMifying whole plugins if the goal is to fix a few large references bugs rather than limiting the number of references.

Yes, I actually never meant to imply that this was a DynDOLOD issue. I mainly made a post here because there was a similar looking crash report that seemed to have been somewhat unresolved.

I can't take credit for the separate large ref plugin trick, as it's actually from the DynDOLOD Large Ref guide. :D But it is likely the least error prone solution in many cases. I often just ESMify the whole plugin out of laziness. xD

Link to comment
Share on other sites

3 hours ago, sheson said:

No, for now just replace the files in the load order with the vanilla once which we assume should be fine.

I replaced all five texture files shown for the icebergsmall02.nif in Asset Browser with vanilla textures, checking to make sure the path was correct in the MO2 Data tab.  Stil CTD'd at Riften Gate.  See crash log.

As a test, I again disabled the Dyndolod Output and traveled to the same spot.  No CTD.

Crash_2022_6_28_15-38-18.txt

Link to comment
Share on other sites

46 minutes ago, Dez756 said:

I replaced all five texture files shown for the icebergsmall02.nif in Asset Browser with vanilla textures, checking to make sure the path was correct in the MO2 Data tab.  Stil CTD'd at Riften Gate.  See crash log.

As a test, I again disabled the Dyndolod Output and traveled to the same spot.  No CTD.

Crash_2022_6_28_15-38-18.txt 41.01 kB · 0 downloads

Seems we are not getting anywhere with this. Maybe time to do the steps explained under "Debug CTD caused by missing or invalid NIF" in the DynDOLOD-README.txt

First check/remove the object LOD mesh *.BTO file to rule them out.
If it still CTDs with all meshes removed, check if disabling DynDOLOD.esp and keeping DynDOLOD.esm makes a difference. In case it does, do the debug=true tests.

If it crashes with only DynDOLOD.esm, let me know for different suggestions.

Link to comment
Share on other sites

1 hour ago, sheson said:

If it still CTDs with all meshes removed, check if disabling DynDOLOD.esp and keeping DynDOLOD.esm makes a difference. In case it does, do the debug=true tests.

Still CTD with meshes removed.  No CTD with DynDOLOD.esp only disabled.

I'll try to get to the debug=true tests later.

Link to comment
Share on other sites

On 6/28/2022 at 5:17 PM, Dez756 said:

I'll try to get to the debug=true tests later.

Here's my Papyrus log with debug=true.  I don't see entries in the Papyrus log exactly like the example in ReadMe.  I tried to search for the Form ID of the last entry referencing DynDOLOD ([06/29/2022 - 03:54:57PM] [SHESON_DynDOLOD_LODObject < (BE028E70)>] [SHESON_DynDOLOD_Firstborn < (BE028E5A)>] Enable #2 [Form < (20004052)>] using dyndolod\lod\effects\fxfirewithembers01_dyndolod_lod.nif TRUE False TRUE) but SSEEdit doesn't seem to find anything (although I'm not sure I'm looking in the right spot - I've used SSEEdit for some things like cleaning, adding keywords or heel sounds but never searched for Form IDs).  See screen shot for the results of filter for BE028E70.  

I note that the entries in the log in the last second all seem to concern Creature Framework.  To test whether that was somehow involved, I removed CF and all associated mods and traveled (on a new game) to the same Riften Gate.  Still CTD'd.  Again, though this mod and its associates have been in my load order for literally years!

It's so weird that this seems to be the only place it CTDs as I had traveled to most of the other cities before I ran across this problem at Riften.

I'm sure this is getting frustrating for you!  Should I start (dread) removing mods and running everything (Xlodgen, TexGen, DynDOLOD) again? 

 

Screenshot 2022-06-29 163134.png

Papyrus.0.log

Edited by Dez756
Link to comment
Share on other sites

7 hours ago, Dez756 said:

Here's my Papyrus log with debug=true.  I don't see entries in the Papyrus log exactly like the example in ReadMe.  I tried to search for the Form ID of the last entry referencing DynDOLOD ([06/29/2022 - 03:54:57PM] [SHESON_DynDOLOD_LODObject < (BE028E70)>] [SHESON_DynDOLOD_Firstborn < (BE028E5A)>] Enable #2 [Form < (20004052)>] using dyndolod\lod\effects\fxfirewithembers01_dyndolod_lod.nif TRUE False TRUE) but SSEEdit doesn't seem to find anything (although I'm not sure I'm looking in the right spot - I've used SSEEdit for some things like cleaning, adding keywords or heel sounds but never searched for Form IDs).  See screen shot for the results of filter for BE028E70.  

I note that the entries in the log in the last second all seem to concern Creature Framework.  To test whether that was somehow involved, I removed CF and all associated mods and traveled (on a new game) to the same Riften Gate.  Still CTD'd.  Again, though this mod and its associates have been in my load order for literally years!

It's so weird that this seems to be the only place it CTDs as I had traveled to most of the other cities before I ran across this problem at Riften.

I'm sure this is getting frustrating for you!  Should I start (dread) removing mods and running everything (Xlodgen, TexGen, DynDOLOD) again? 

 

Screenshot 2022-06-29 163134.png

Papyrus.0.log 383.58 kB · 0 downloads

Since the debug message from DynDOLOD is 9 seconds before the crash, it is not caused by any of the dynamic LOD objects.

When entering form IDs into the field top left you need to adjust the first two digits to the actual ID a plugin has in xEdit, e.g. 19 in case of the screenshot.

The next step would be to selective remove records from DynDOLOD.esp in a binary search in order to only keep record in the plugins that causes the problem.

1) Make a backup of DynDOLOD.esp
2) Load DynDOLOD.esp in xEdit and remove half records
3) Test if game still CTDs
4) if it crashes start from step 1) If it doesn't crash, restore backup and  continue with step 2) removing the other half of records which are not causing the crash.

Only remove records from [+] Worldspace
First time, remove all worldspaces that are not Tamriel as we expect the error to be in there only.
Second time, remove all Blocks and keepo the 0000D74 Cell persistent worldspace cell. If the crash is a record in the persistent cell, remove all overwrites first (they are listed at the top). If it is one of the overwrites, restore from back, remove all other records. Then do the loop by removing half the overwrites until only the problematic record remains. Otherwise , continue by removing about half the references that do not start with Tamriel_*, e.g remove the reference that start with a pluginname.
If the crash happens in the Blocks, do the loop removing about half the Blocks until only on Block remains, then Sub-Blocks until only one Sub-Block remains, then cells until only one cell remains, then references until only one reference remains. If you are down to the last reference, remove it too to see if it might be actually the cell record.

Link to comment
Share on other sites

7 hours ago, jimmywon34 said:

dyndolod doesn't finish for me when launched and keeps exiting out/crashing wihtout any warning

Read the first post which log, debug log and bugreport.txt to upload.

If none of those files were created check the Windows Event log.

Make sure to use a recent MO2 version and that OS, antivir does not interfere,

Link to comment
Share on other sites

18 hours ago, sheson said:

If the crash happens in the Blocks, do the loop removing about half the Blocks until only on Block remains, then Sub-Blocks until only one Sub-Block remains, then cells until only one cell remains, then references until only one reference remains.

Okay!  No crash if I remove two references at the following path in the DynDOLOD.esp.  

Worldspace>0000003C Tamriel> Block 1,-1> Sub-Block 5,-3>0000BCD0> Temporary

>1902677D Placed Object bluesskyrim_0121FA_DynDOLOD_CHILD IcebergSmall02_DynDOLOD_LOD[STAT:0D004028]

and

 >190266D6 Placed Object bluesskyrim_0121FB_DynDOLOD_CHILD  IcebergSmall02_DynDOLOD_LOD [STAT:0D004028]

I'm sure you recall that the .Net Script Framework crash logs also referred to IcebergSmall02.  BluesSkyrim.esp appears to be a patch I added back in 2020, but I can't find it on Nexus anymore.  The Mod is called Update by KorruptkSwades.

Should I remove that patch and do everything again?  Or can I just play with those references removed?

Edited by Dez756
Link to comment
Share on other sites

35 minutes ago, Dez756 said:

Sorry for the stupid question.  I just saw from that page that this patch should not be used for V1.5 of DOS.  Removing and then planning to rerun DynDOLOD to see if that cures the problem.  Wasn't planning on rerunning Xlodgen and TexGen since there are no textures in that mod but let me know if you recommend otherwise.  Thanks for your patient help.  You taught me a ton!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.