Medium Works, High = ILS/Not Responding

[SGP]

I feel like a simpleton.

 

I was comfortable modding and figuring out load orders, finally got the game where I want it, and then I discovered DYNDOLOD.

 

"Oh. This is much more difficult to learn. Uh oh"

 

It works absolutely fine in medium preset mode, but if I set high, and load into whiterun/tamriel, I get a not responding crash during the load screen. (Or ILS until I alt-tab, then not responding)

 

Papyrus log says this: https://pastebin.com/qdVP9xs3

 

Mod load order: https://pastebin.com/MT5YZZFg

 

DynDOLOD_SSE_log.txt : https://drive.google.com/file/d/1HQO0qI5w1g6XjceTzzKL5XuIJZXJv_fW/view?usp=sharing

 

I have read the DYNDOLOD advice, and it says to look at the logs for both papyrus (posted) and for DynDOLOD.

There's nothing to be found in papyrus, and I can't see any reference to 'Error when loading' or 'Root block of meshes' or 'Missing model' or 'clean'. If these have all failed, I have no idea at this point what I'm looking for.

If I had some kind of workflow for troubleshooting or a guide, I could just do it, but there seems to be no solutions or troubleshooting guides as far as I can google.

 

What have I done wrong?

[sheson]

FAQ: Game: ILS or CTD

A: Do not use the experimental TreeFullFallBack setting without understanding what it does and what it is for. 

A: If heap memory is not the cause of CTD see ..DynDOLOD\Docs\DynDOLOD-README.txt for checking if a missing or invalid nif model used for dynamic LOD is the cause. 

A: Large load orders with many plugins might surpass the reference handle cap. SSE Engine fixes prints a warning. See https://www.reddit.com/r/skyrimmods/comments/ag4wm7/psa_the_reference_handle_cap_or_diagnosing_one_of/ Setting Temporary=1 in ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GameMode].ini may help in these situations, however converting large new land plugins to ESM is the preferred solution. 

 

 

DynDOLOD-README.txt

Install crash fixes for Skyrim as it will report missing or invalid nifs. Install .NET Script Framework for Skyrim Special Edition and check its crash log for clues about NIFs or other causes. 

 

There are many posts about troubleshooting beyond that: The obvious first step is the hiding of output textures, then meshes, then disabling the plugins one by one as a first step to determine the source of the CTD. If it turns out to be any of the loose files in textures/meshes they can be hidden in groups in a binary search to narrow it down to a single file. If it turns out to be a plugin, then data can be removed from them in a binary search as well. We will discuss that in more detail once the source has been determined.

[SGP]

 

FAQ: Game: ILS or CTD

A: Do not use the experimental TreeFullFallBack setting without understanding what it does and what it is for. 

In the ini file this is disabled. 

 

 

 

A: If heap memory is not the cause of CTD see ..DynDOLOD\Docs\DynDOLOD-README.txt for checking if a missing or invalid nif model used for dynamic LOD is the cause. 

A: Large load orders with many plugins might surpass the reference handle cap. SSE Engine fixes prints a warning. See https://www.reddit.com/r/skyrimmods/comments/ag4wm7/psa_the_reference_handle_cap_or_diagnosing_one_of/ Setting Temporary=1 in ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GameMode].ini may help in these situations, however converting large new land plugins to ESM is the preferred solution. 

I am using SSE (with 32gb ram and a 20180ti (11gb vram)). So I can't use heapmemorylog or the SKSE.ini memory patch, but hopefully my hardware will be good enough when fixed. Will the 'large load order' problem still be a worry, if DynDOLOD still works in medium? Vortex says I am running 236 mods including DynDOLOD. 

 

 

 

 

DynDOLOD-README.txt

Install crash fixes for Skyrim as it will report missing or invalid nifs. Install .NET Script Framework for Skyrim Special Edition and check its crash log for clues about NIFs or other causes. 

 

I don't think this is available for SSE. I can only find 'FPS fix'

 

 

 

see ..DynDOLOD\Docs\DynDOLOD-README.txt for checking if a missing or invalid nif model used for dynamic LOD is the cause. 

 

As I said in my first post, I have read the DYNDOLOD readme, and it says to look at the logs for both papyrus and for DynDOLOD.

 

There's nothing to be found in papyrus referencing DynDOLOD, and when ctrl+F'ing the DynDOLOD log, I can't see any reference to 'Error' or 'Root'(block of meshes) or 'Missing model' or 'clean'(plugins).

 

If there a specific line of text I should be looking for?  It's 13323 lines of text and I have no idea what I'm looking for specifically.

 

 

 

 

The next step, removing things from the output, I can do. I'll try this now. 

 

If I'm clearly missing something in the quoted steps, please let me know. I apologise for my ignorance, but I'm eager to learn. 

[sheson]

I am using SSE (with 32gb ram and a 20180ti (11gb vram)). So I can't use heapmemorylog or the SKSE.ini memory patch, but hopefully my hardware will be good enough when fixed. Will the 'large load order' problem still be a worry, if DynDOLOD still works in medium? Vortex says I am running 236 mods including DynDOLOD.

I did not post the answer for Skyrim and the SKSE memory patch / Crash Fixes / Enboost as it obviously does not apply for Skyrim Special Edition.

 

The reference cap applies to all Skyrim versions and it has nothing to do with memory or number of plugins. Read the linked post for its explanation and how to troubleshoot or it.

 

I don't think this is available for SSE.

 

Yes, obviously "Skryim" is not the same as "Skyrim Special Edition". I simply copy and pasted a line from the readme that you have overlooked. Read and follow the second sentence that applies to Skyrim Special Edition.

 

Install .NET Script Framework for Skyrim Special Edition and check its crash log for clues about NIFs or other causes.

 

Check its comments for newer versions if needed

Edited September 27, 2019 by sheson

[SGP]

I have around 250000 references out of the reference cap of 1048576, so I think I'm OK there. I removed 'tPoS' and ICoW' as I felt they were using a lot of references, but perhaps at my low count, I could probably re-enable them safely?

 

Unfortunately, the .NET framework doesn't seem to be logging the problem, as the game simply hangs on a loading screen, and can only be closed with task manager, and I assume this doesn't count as a 'crash' so it doesn't make a log?

 

The Textures folder and then the Models folder being deleted makes no difference. the hang remains with just the plugins enabled.

 

I'm re-building the textures and re-running Dynolod every time I change any plugins or mods. 

[sheson]

Does the hang go away when disabling only the DynDOLOD.esp but leave the DynDOLOD.esm active?

[SGP]

Sorry, I'm totally mistaken. The game works when the meshes/tamriel/objects folder is removed. There must have been a mod interaction issue that is now cleared up. 

 

I'm assuming I can't just remove random files from /objects to clear the problem, and that this is a .NIF problem?

If this is correct, what's the best way to discover the 'problem NIF' without using the .net framework crash logs?

Edited October 3, 2019 by SGP

[sheson]

Sorry, I'm totally mistaken. The game works when the meshes/tamriel/objects folder is removed. There must have been a mod interaction issue that is now cleared up. 

 

I'm assuming I can't just remove random files from /objects to clear the problem, and that this is a .NIF problem?

If this is correct, what's the best way to discover the 'problem NIF' without using the .net framework crash logs?

You can remove any of meshes *.bto in a binary search to test which one is the problematic one.

 

But first you might want to double check DynDOLOD\Logs\LODGen_SSE_Tamriel_log.txt that the *.bto meshes generation went without errors. The last line should be "Code: 0".

 

Consider running LODGen.exe again to just generate all *.bto meshes again. Set in Expert=1 in DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini, start DynDOLOD as usual, change world drop down  to Tamriel, click the Execute LODGene.exe button.

 

Then if problem persists do the binary search. Remove half the files, test if problem still exists. If problem went away, restore removed files and remove the other half. Continue until only one file (or a few) is left so we can look at it.

Edited October 3, 2019 by sheson