sheson

Well the memory blocks log well be clear cut. If you crash and the left column reached the exact same number as the max value report on top you need to increase heap. If it stays below the max, the heap settings is fine. You need to test at the time of crash to be certain. No problems with the new generation yet? There will be a new DynDOLOD version later today that will print lines about missing nifs (and not use them for LOD) which would just leave invalid nifs. But if it only happens later in the game and has to be an object that get enabled by a quest or something later.

We already have pinpointed to PapyrusUtil 3.1/3.2 differences and by the crash log there seems to be some relation when interacting with MCM. I think we will figure this out eventually. Based on that, can you download these Papyrus Scripts and see if by chance they change anything. There are two versions that are identical in function. The ones in the Scripts_Debug print lines to the papyrus log. So if these scripts do not change anything, post the papyrus log with the debug scripts from the game loading with the CTD. The linked discussion suggests the user not doing the clean routine properly - there simply should not be that much data left over after the clean save. Not that removing an esp form an existing save game is recommended at all, as you know. As the DynDOLOD manual and everybody else explains, there is no such thing as a save removal of mod from a save game. Removing DynDOLOD is relatively save because the scripts are only attached to and manipulate objects added by DynDOLOD itself. There should be only 1 version of each script or so left over in a clean save. Also, since it was discussed there, USLEEP Swap Masters Script should work without problem on any existing DynDOLOD.esp.

Have you verified heap memory usage with Memory Blocks Log yet? Did you generate LOD again after adding any of the new mods? Then there could be an invalid/missing nif. Someone from the STEP team can answer these questions better than I. I can only give general hints - the details you are asking for is what things like the STEP guides are for. "Normal" modding is Skyrim can already be complex by itself if starting anew, because there so many different types of mods. 1) The STEP Guide is constantly updated with the lasted information. Follow recent (mid 2015 and newer) modding guides instead of using old forums posts. The recent ones should cover both ENBoost and Memory Patch (build into SKSE) and Memory Block Log to verify is works. 2) All these managers have pros and cons. If you never used any of these before I suggest to use MO - also for the fact that most up-to-date guides are for it. Not overwriting physical files is a great plus for modding users who constantly change things ;) 3) You use the tools that a guide requires you to use for whatever task it is you want to do. 4) Install order of assets like meshes/scripts/textures packed in *.BSA and loose files and the order of mods esm/esp (LOOT + manual sorting) order is crucial. There is no order for dll plugins, they just work. ENBs that come with meshes/textures/*.esp should be installed first like any other mods. Patchers like DynDOLOD need to be run when the load order is finalized (so typically after cleaning, merging, LOOT). Ini tweaks can be done at any time. 5) You only need to select the esps that actually add objects that have LOD or that you want LOD for. Typically landscape, town or house mods. Quests mods add buildings too sometimes. Check all and it will discover any suitable object. The only relationship between what mods are selected and ILS is that -> the more mods -> the more LOD data is generated -> the more memory is needed. Sorry to tell you, but 3 days is nothing... this will easily translate into weeks, months and years.

FAQ: Skyrim: ILS or CTD A: 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

Ops typo, that was meant to be 40MB... The mesh for that tree is 395kB and the tree is used a 110 times.

Please edit SKSE.ini and add or change [Debug] WriteMinidumps=1 Then produce the crash. Find minidump in c:\Users\[username]\Documents\My Games\Skyrim\SKSE\Crashdumps\*.dmp Go to https://www.osronline.com/page.cfm?name=analyze and upload it. Copy/paste the text of the result into spoiler tags here.

It rather shows how important it is to create optimized LOD versions. This one heavy snow tree full model is 400MB 40MB alone. Some pruning is needed...

So I have been working on LODGen.exe to better support full model trees static LOD SFO 2.3 full model trees as static LOD No problem loading and running around using SSD... it loads things Ok 8 GigaByte *.bto LOD files ... Loading this save requires more than 1024 heap - which is the limit of SKSE. Use your own patch or SSME I guess Also impressive display how 7.4m triangles is nothing as long as draw calls is low.

What happens if you just remove the MCM.pex and leave the others in place? That didn't work at all? When you say "corrupted" save do you mean it doesn't even load when esp and all .pex are removed again - maybe they work with PapyrusUtil 3.1? Use the latest papyrus scripts from the update post and if problem persists check the MCM Information page

Can you check with the newer scripts dated 22.11.2015 from the update post? I need to understand the exact steps. You are loading a clean save in interior which always works - then save while still in the interior or do you have to go outside first? Either way, the DynDOLOD MCM has registered. Then trying to load the last save it CTDs (or not depending on the scripts/Papyrus Util version)

I know (older?) PapyrusUtil can CTD if trying to access the json files to early the very first time at initialization - waiting a second or 2 fixed that. Maybe the large co-save contributes back to a similar problem and something doesn't have enough time anymore. To narrow it down could you remove all Papyrus SHSESON_DynDOLOD_*.pex scripts and see if it works? Then add one by one in the following order and test each time SHESON_DynDOLOD_MCM.pex SHESON_DynDOLOD_LODObject.pex SHESON_DynDOLOD_Firstborn.pex SHESON_DynDOLOD_Minion.pex SHESON_DynDOLOD_Master.pex If it crashes after adding one, remove it again and add the next. Let me know with which script it crashes and which seem fine.

Also try overwriting with 3.1 specifically. If a new generation changes anything I would assume it be something like nifs/textures changed in the meantime. We can try plenty of things over the next days/weeks no worries. You could also try to continue troubleshooting by disabling other mods using dlls. Correct

The new co-saves without DynDOLOD should be a couple 10kb smaller then. I am still wondering about PayrusUtil 3.1/3.2? SexLab includes the new version. Did you generate LOD with Windows High glow LOD? Is there a difference activating the esp again on an interior/exterior clean save?

The co-save contains a lot of data from nioverride/chargen from race menu - which judging from the logs is body morphs - probably by other mods utilizing racemenu. DynDOLOD data in the co-save seems fine and is not that much as expected. All its data in the co-save is saved/loaded via PapyrusUtil. If you are using 3.1, try 3.2 or vice versa. If you still have older saves, can you try to pinpoint when the co-save started getting larger and what mods you added/updated at that time? I believe the most recent dll updates seem to be CrashFixPlugin.dll and SexLabUtil.dll. The first seems like a good candidate that could cause weird issues. There is also quite some data in the co-save from the second. The skse.log is truncated just when it should get interesting. After the "dispatched message." it should continue with something like loading co-save Loading mod list: (0 -> 0) Skyrim.esm (1 -> 1) Update.esm (2 -> 2) Dawnguard.esm (3 -> 3) HearthFires.esm (4 -> 4) Dragonborn.esm (5 -> 5) Unofficial Skyrim Legendary Edition Patch.esp etc... I am not sure what happens between dispatched and loading co-save or if it just couldn't flush loglines while already reading co-save data. skse_nioverride.txt for example seems to indicate it loads data already unless I am interpreting that wrong. Compare log file times if they are indeed from the same load - maybe delete them all before trying again to not be confused by old ones. Did you try loading the game without the co-save (rename it)? It may be worth checking which of the other dll should write logs there and may be missing.

BTT files are not meshes. They store x, y, z and and an ID. The ID is used to look up more data in the lst file. Like width and height and the uv map for the texture atlas.

If those trees are not straight up but rather tilted or lying on the ground for example they are done a static LOD. That would mean there is only one problem of static LOD not unloading.

I assume the save you are loading already had those other mods active before? If it only happens the first time I guess we do not to be concerned really. I would still like to understand why. Do you mind uploading the esp and the json files from the skse output folder somewhere?

This is really weird why that should be a problem in your case only. Did you alter Skyim.ini [Papyrus] section? How big is the DynDOLOD.esp? Is that pause happening on subsequent loads as well?

Winterhold Rebuild works completely out of the box with LOD updating as the rebuild progresses. Tanners Ridge Treehouse will have LOD for the big tree and a few pieces of straw used for the roofing but miss walls and other elements used to puzzle the house itself. It would require custom rules depending how much of it is wanted for LOD. From a distance everything is behind lots of trees, so it might be just good enough as it is. Syerscote will need custom rules for the new buildings the mod comes with for sufficient LOD.

Is the world actually loading and working for a few seconds before it CTDs? I see MCM initializing. If so do the invalid nif check from the readme. If not please upload logfiles from c:\Users\[username]\Documents\My Games\Skyrim\SKSE\*.log

I only know this behavior from quest heavy mods like Interesting NPCs or Immersive Citizens - AI Overhaul. Never seen this with DynDOLOD and no reports about this so far. So you have this just with the updated esp, while meshes/skse/textures from output disabled? Could you try also to disable meshes/textures/script from the download archive and only have the esp active? My next step would be to try with default inis to see if that makes a difference. You can switch sides with nifskope to find the best angle and then use photoshop to edit the canvas of the billboard so that the trunk is in the middle. Billboards dds can have a txt file next to them (check the vanilla billboards) to set height/width/scale/z-shift However, those leaf less trees are prime targets to be done as 3D statics. There will be an updated LODGen.exe soonish that can deal with all types of full model trees, side effect from FO4..

Did you see my answer to that post? These vague reports of people having troubles loading save games just seem to have started to appear recently. I see such reports with DynDOLOD as well as without DynDOLOD in the load order. The current version of DynDOLOD is out since October. Common sense says if simple data in DynDOLOD somehow causes problems there should have been such reports since a long time already. So the question is, what else did you install, update or change more recently? Safe bloat is when the file size of a save keeps increasing forever or in a very short time without reason (like adding a new mod). If saving the current state of a game the save files need to contain all that current state data. Why do you think 4MB is bloated or a reason for concern? It seems large yes, but more and more mods make use of it. What is the load order (use https://www.modwat.ch/)? What are the versions of SKSE, StorageUtil.dll and nioverride.dll - any other dll plugins that you are using? Are there any stack dumps in papyrus log? What were the selected options when generating LOD with DynDOLOD Worlds.pas. Upload the TES5Edit_log.txt if you still have it. Upload a problematic save and co-save, I can decipher those.

Regarding stuck tree LOD: Does this happen in/around city worldspaces? Then you have a mod that adds those trees in the parent worldspace and an engine limitation does not unload them when in the child world. There is a workaround. If it happens in the wild, do you have a recent version of xEdit? Check the ..\TES5Edit\TES5Edit_log.txt for "Get xEdit 280715 or newer in case there are LOD trees in loaded cells" If you have a recent enough version check ..\TES5Edit\TES5Edit_log.txt for "Warning: x duplicate FormID numbers of trees references were detected, excluded from LOD" Truth is though if you see those messages there should be no stuck tree LOD in the wilderness. You would have to check the form ids of those trees (you can only get form ids from loaded full models, not LOD) and also post what mod they come from. If static LOD gets stuck after fast travel, enable save on travel. That is so far the only confirmed case. Make a screenshot, get full model form ids / mod if problem persists. Regarding the windmill buildings I wonder if you still have SkyMills? For all cases above, check if you still see the LOD model when using tll in console. Other than that, check with default inis and coc whiterun (new game) if any of the above problems happen as well.

I think you need to read this thread more thoroughly again and how I troubleshoot problems with people until they are solved before making claims of "lot of backslash". You are refusing my help since you obviously do not want to troubleshoot to get the game working with DynDOLOD. How am I supposed to help? It should be no problem to remove all the files installed to data from the download archive and copied to data from the output folder. A mod manager does this with one or two clicks. No other game related files in data are secretly created or changed by DynDOLOD World.pas. The manual has more detail in the uninstall section. If there are still problems after all the files have been removed the cause is obviously something else unrelated to DynDOLOD. If you wanted to troubleshoot with me, post what I asked for and try the things I suggested. Once the most likely cause for a problem is eliminated the next likely cause will be addressed. Except the esp data and papyrus scripting uses less memory than the static LOD meshes and textures and only starts working once the game has actually completely loaded :) I think we can assume that the esp was first amongst the files that were removed while the problem persisted.

You eliminated DynDOLOD as the cause by removing all copied/generated files. So obviously something else must be the problem. I can not help with problems caused by something else. Heap memory filling up is the only known cause for ILS. It has been so far every time. Memory blocks log is the only way to track heap memory usage. Everyone who claimed otherwise found out memory patch was not working. Try Safety Load maybe. If adding/removing a mod is such a big deal with the current setup I suggest to use a mod manager. Yes just remove it, the game will use the vanilla mesh again. You mean "Continue" from the main menu? DynDOLOD just adds LOD data to a world, it is not modifying menus or loadscreens. Of course the new additional LOD needs to be loaded when a game is loaded.