sheson

ILS is always that heap memory block 1 is full. I have never seen/read about any other cause. Double check with memory blocks. If you are certain this is not the cause check VRAM usage. If it truly peaks around 256 you should not set more than maybe 300 for block1. The reserved memory can not be used by other things, so that would mean wasting 512 for no reason.

The screenshots indicate that the data/meshes folder from the archive with the 1000s of new/updated LOD meshes was not installed correctly before LOD was generated.

That is still not fixed? If it is static LOD you only have to generate for Tamriel again. On advanced, check Tamriel, check "Generate static LOD", you can uncheck everything else, click OK.

Doh!? Enable those masters again.

Default inis? Test with/without esp, with/without static LOD, with/without tree LOD? Does it matter where on the map you are? DynDOLOD alone does not cause CTD in map, because all the object LOD the default map shows is already loaded usually.

Yes it is, was already answered a week ago :)

Are you using the mod VIGILANT? Disable it including its loose files/BSA while generating LOD or wait for next DynDOLOD version. The mod is incompatible and yes we just discussed this couple days ago, because one other user had this too.

FAQ: Skyrim: ILS or CTD More LOD uses more memory and this can cause ILS or CTD. Double check heap memory usage (block 1) with Memory Blocks Log from https://www.nexusmods.com/skyrim/mods/50471/ and adjust SKSE or SSME memory settings. Remove satefy-load if it is used. Set ExpandSystemMemoryX64=false in enblocal.ini If heap memory is not the cause of CTD see Docs\ DynDOLOD-README.txt for checking if a nif model used for dynamic LOD is the cause.

Please upload TES5Edit\TES5Edit_log.txt DynDOLOD.esp skse\plugins\StorageUtilData\DynDOLOD_Worlds.json skse\plugins\StorageUtilData\DynDOLOD_Tamriel_Objects.json skse\plugins\StorageUtilData\DynDOLOD_Tamriel.json

Yes that is the message. Output folder seems to be OK and not virtual MO Data folder judging from the logfiles posted earlier. Are you overclocking CPU/memory or maybe cooling isn't working? Check CPU temps.

You using xEdit 170815 or newer? Post screenshot of the error message from LODGen.exe if problem persists

The screenshots are not showing that error. I am not sure what causes the error in the screenshot, but it could be that the system is overloaded and can not catch up. I see similar behavior when speed running, or when FPS is really low which then also results in script lag. If the engine does not catch eventually when you stop moving around, I have no idea what else can cause this. You should clean those mods. Make sure inis are default. Remove those incompatible mods. All of them. The total list contains like 6 mods. I would be surprised if you have more than 3.

OK, so no change with other LODGen.exe, that is good to know. One thing I would love to know is how you get to Falskaar/Solstheim when you test. Do you coc, cow or load an existing save game perhaps? When you load Falskaar do you also have Dragonborn active? I mean, by any chance what happens with Falskaar if Dragonborn is not active? I really wish we could figure it out, but I guess we need to wait for more people to have this problem until we discover the cause. I am still interested in the BTO files from either Falskaar or Solstheim, if you could upload them somewhere.

You reported yourself the problem goes away when you disable other mods while the BTO generated by LODGen are still in the load order. This is a clear hint to spend some more time investigating those other mods. So I do not see any reason not to do so. In a clear, orderly and repeatable fashion. But do the tests. Trouble Shooting is about ruling out - for certain - any possible cause. There are no other reports about stuttering in Solstheim. I am not going to speculate about other users having imaginary problems that are not reported. However it seems safe to assume if there are any more users having this problem there would be more reports. As I already wrote a couple weeks ago, the one other user that had problems in Falskaar - with TES5LODGen - sent me his bto files. They were the same as the bto generated by my setup. I used his files, no stutter. Send me the bto you generated. I will happily test them. Generate static LOD with TES5LODGen, with old and new LODGen.exe see what happens - it will be even less LOD objects than low for DynDOLOD. Other things to check: Default inis? Turn off MO BSA management.

You understand you are the only one that ever reported this behavior right? I totally agree that Tamriel should be the first worldspace to have problems - IF the reason is running out of resources of any kind or IF anything is up with the BTO files. Since that is not the case we simply suggest to look at other things as well. LOOK or TEST them though - do not just say it is impossible. See if using this LODGen.exe makes any difference

Hmm if disabling the Hires texture pack helps, this would indicate running out of texture memory. You are using ENBoost right? ENB can also show the GPU memory usage in the "Profile". Optimize all textures or get the prepared optimized versions - the details are out of my scope but I believe STEP instructions have a mod to download them. Regarding DynDOLOD you can try reducing LOD texture size as well: Either copy content from DynDOLOD download archive Options\textures.128\dlc01\ over DynDOLOD Or if you use DynDOLOD TexGen.pas open it in notepad and change the line iAtlasSize = 256; to iAtlasSize = 128; Then generate texture again with the new setting.

Test with new game/coc. If it works then it means you didn't follow the update procedure for an existing save game.

Start with the SSD, it is the best overall performance upgrade you can do. Loading all the data quicker into the game will improve it the most in terms of loading times and hitching/stutter when walking around in the world and things need to load.

I think the images do not really show snowdrifts but distant terrain LOD textures. Snow drifts are actual 3D models that have object LOD with DynDOLOD, like the dirtcliffs or rocks. There are mods for better distant terrain LOD meshes (High Quality LODs) and better distant terrain LOD textures (HD Detailed Terrain or The Ruffled Feather - Mod Collection)

if you remove DynDOLOD.esp meshes/textures/skse and still CTD aftwarrds starting a new game or coc to a location for testing, then anything from DynDOLOD is not part of the reason you CTD. If you load an existing save game then left over data should be removed. It would be quite something if ENB mist anchors conflict with anything in the game. That is very unlikely if not impossible.

Are you saying neither 000BAC72 or 000BAC8F have any mod changing the data (which you can check in TES5Edit obviously) and yet one of them shifted its position? Then have a look at either mesh being changed by a mod.

Compatibility issue between an ENB preset and what exactly? There sure is many ways to make ENB CTD with *.fx files and settings and whatnot. I see it comes with an esp as well that changes weathers and things. Actually, that is beyond my scope and knowledge of things.

open console, click on object, use disable/enable to mke sure you got the right one. What the form id and mod? If it is DynDOLOD.esp, open it in TES5Edit, and check its Editor ID. FAQ: Skyrim: ILS or CTD More LOD uses more memory and this can cause ILS or CTD. Double check heap memory usage (block 1) with Memory Blocks Log from https://www.nexusmods.com/skyrim/mods/50471/ and adjust SKSE or SSME memory settings. Remove satefy-load if it is used. Set ExpandSystemMemoryX64=false in enblocal.ini If heap memory is not the cause of CTD see Docs\ DynDOLOD-README.txt for checking if a nif model used for dynamic LOD is the cause. However, if you crash with everything DynDOLOD turned off the cause may be something else. You just got lucky. If you truely turned off all the mods and files in MO they are not loaded, it is just a random CTD - most likely memory related. You still loading the old save that never saw the new LOD files, right?

Yeah that mod uses the wrong way using modified meshes in different folders without renaming the mesh files themselves. Bethesda always renames meshes in different folder so there is never a duplicate file name. Few mod authors are aware of that convention creating all kinds of problems for people like me :) DynDOLDO picks some of them up based on file name alone and uses them. I will add a workaround for next version.

That is correct and by design.