sheson

Expert mode (Expert=1 in ini) only allows to select one world at a time. In wizard/advanced mode (Expert=0) right click and then use select all.

Get test version from this post and see if it works better.

Post the log

Hmm, wierd, but if LODGen.exe finishes without error you can safely ignore that error in DynDOLOD. Just wait for all LODGen.exe to finish and then close DynDOLOD.exe with X top right, it should still prompt to save the DynDOLOD.esp and everything should be fine.

This error in DynDOLOD happens because LODGen.exe crashed. See if using this version of LODGen.exe/LODGenx64.exe works better. Simply replace existing versions in ..\DynDOLOD\Edit Scripts\ If that does not help, see this similar troubleshooting thread. Post screenshot of LODGen.exe with crash error.

Happens to all of us. So how do I get the DynDOLODx64 to Recognize Skryim SE

FAQ: Tree LOD: LOD trees do not match close-up full model trees A: Doublecheck billboards and billboard load order. Open console, click on full model tree to get form id like 0006A9E6. Lookup this FormID top left in xEdit, bringing up the tree reference in the right pane. Find the form id of the 'NAME - Base', like TreeAspen01 [TREE:0006A9E6]. Search in Textures\Terrain\LODGen\ subfolders for files with that number, like TreeAspen01_0006A9E6.dds and TreeAspen01_0006A9E6.txt. Replace files with correct versions. You can also check the log. You will find a line for each tree and which billboard is used for LOD: TreeAspen01 [TREE:0006A9E6] using LOD Textures\Terrain\LODGen\Skyrim.esm\TreeAspen01_0006A9E6.dds it comes down to installing the correct billboards in the same overwrite order like the tree mods.

Use search top right for this error (just use search for "322") and check those discussions/threads to see if they match/help with your problem. Use the test version from this post and see if it works better. If that doesn't help, post the log.

You can control intensity of all light sources including the LODs with ENB. There are different types like fire, window, so they have different settings in ENB as welll. When you generate LOD you can set the FakeLightsIntensity=x in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5.ini This value just decides which Meshes\DynDOLOD\lod\effects\fxglowdefault[X=1-9]_dyndolod_lod.nif from DynDOLOD Resources they use. By default it is fxglowdefault6_dyndolod_lod.nif, you could either edit DynDOLOD.esp and find the base record that uses this model and change it to use any of the other files, rename any of the other files to replace fxglowdefault6_dyndolod_lod.nif, or edit it in nifskope and change shader settings yourself to change how bright they are. It is possible that ELFX and DynDOLOD both have glows in the LOD area on top of each other. You can find ou with console and clicking any of those glows, check form id, and use "disable" in console to find out if a second glow remains. You need to update DynDOLOD then, it has some rules to prevent that normally. Might as well not use any the fake light option from DynDOLOD in that case.

Beats me, that script functions all the same as the one in DynDOLOD Resources. It just has better a error message to include more information and to be printed to the papyrus log for better troubleshooting. Anyways, doesn't matter if it works fine now.

You could try to clean everything from the save with a save game cleaner - in case of DynDOLOD for example, after doing the clean save routine, clean out the handful of script that remain - before reintroducing a new or the same old DynDOLOD.esp to the save again. Though the problem suggests, that you probably need to do that to a number of mods/data to get rid of the cause of the problem - though that may created other problems - so that is all up to you at your own risk. What I suggest to do, generate a lightweight DynDOLOD on low without any of the extras from the advanced menu and see how that fares. You can keep the old static/tree LOD (meshes/textures folder) only use the esp and SKSE folder from the output. If there are still problems with that, generate low/medium/high with dynamic LOD not checked at all and use everything from output folder.

It seems all the data and json files are in order. Can you make sure that SKSE is installed correctly, especially its papyrus scripts. Specifically, check that ..\Skyrim\Data\scripts\stringutil.pex exists in the load order and is not missing or accidentally overwritten. It should have 1119 bytes and be dated 2015-05-24 If you are sure SKSE is installed correctly, download this ..\Skyrim\Data\scripts\SHESON_DynDOLOD_Firstborn.pex papyrus script and replace the one installed from DynDOLOD Resources. Then start a new test game (coc whiterun from main menu for example would suffice). It should then write a slightly modified error message telling us the worldspace name it is looking for - which for one reason or another seems not be Tamriel. I would not be surprised if it is empty. Best to set [Papyrus] bEnableLogging=1 bEnableTrace=1bLoadDebugInformation=1 in Skyrim.ini, before starting, so we can get some extra info. Then upload/post latest logfile from c:\Users\[username]\Documents\My Games\Skyrim\Logs\Script\*.log which has similar error message with hopefully some more details.

If your game is English you do not need to use the -l: command line parameter. Have you scrolled the xEdit window all the way to the right to check all overwrites? Make sure to load the entire load order.

The entire setup has a problem and causes the script engine to overload. These scripts only run when the player crosses a cell border. I suggest to make sure to have proper INIs, check memory settings, not only heap (or just crash fixes), but of the script engine, double check truly script intensive mods. Make sure the game can sustain a decent frame rate closer to 60 than 30. Generate less intensive LOD. Do not use candle/glow/high windows for example. Test with a new game.

DynDOLOD generates tree and object LOD. It does not generate terrain/water LOD, which would be the thing that relates to "ground". So there is really nothing I could suggest in that regard. In any case, the problem you are describing seems to be happening in the loaded cells, which is where typically all LOD is disabled. FAQ: Tree LOD: LOD trees show in child worlds / towns Answer: This is a game engine limitation. A mod added trees into the same area in the parent world. Either disable that mod when generating tree LOD, or add a XESP - Enable Parent to the player reference 0x00000014 to each tree in question. Tree LOD generation skips all trees with enable parents leaving them to be done as static or dynamic LOD which don't have the limitation.

Hmm that all looks completely fine. Is your game using a different language setting? If that is the case, start DynDOLOD.exe with -l:language, where language is like German, Russian etc, the same value like it would be in the Skyrim.ini If that is not the case, make sure that the load order does not change after generating and that DynDOLOD.esp is the last mod. It could be that another mod overwrites the worldspace record and it may change the name Tamriel to something else instead so it doesn't match with the name in DynDOLOD_Worlds.json anymore. To check, load the entire load order into xEdit.exe and type form id 3C into the field top left and hit enter. It should have EDID - Editor ID Tamriel for all plugins

DynDOLOD_.json and None.json do not exist. Those "invalid" names are the result of it not being able to read DynDOLOD_Worlds.json properly. It sounds like DynDOLOD_Worlds.json does not contain the entries for "tamriel", while DynDOLOD.esp has data for that worldspace. This sounds like you generated LOD for different world spaces separately and somehow managed to end up with json that does not fully match DynDOLOD.esp. Post the contents of DynDOLOD_Worlds.json and upload DynDOLOD\Logs\DynDOLOD_TES5_log.txt to pastebin or a file service

That happens because the save game remembers position/rotation of references, but not the model. If the new plugin uses the same form id for a reference, it will use the model data from the plugin with the position/rotation from the save. It only purges the position/rotation for references if the associated plugin is not in the load order when loading. Ergo "clean" save. So, it is fully expected to see the wrong models at dynamic LOD locations when save is not cleaned of that data.

FAQ: Skyrim: DynDOLOD can not read data from *.json / DynDOLOD can not find master data in *.json A: Copy Meshes, Textures and SKSE (which includes the *.json files) from the output directory to the game directory. Make sure these files and DynDOLOD.esp are in sync from the same generation process. Can also be a save game update gone wrong. Test with new game. The file may be missing (not installed to Skryim\Data\skse\plugins\StorageUtilData\DynDOLOD_Worlds.json or whatever equivalent in the mod manager you are using) or can not be read because of permission reasons. Make sure it exists. Reboot to clear up file access problems. The content of the json file may be corrupt. You can open DynDOLOD_Worlds.json in notepad and copy/paste it into an online validator like https://jsonlint.com/ If it reports an error in the file, then post its content.

That's OK. If everything works now don't worry about it. "Ghost" LOD happens when not cleaning a save before introducing a new DynDOLOD.esp

If it has problems at different points, please posts (parts) of the log as well. The last few dozen couple lines like you already posted are enough for now. When you say you deleted earlier output, does that also mean you delete the earler DynDOLOD.esp or just the meshes/textures/skse folder? Instead of deleting I would rather recommend just hiding the folders/files or make a backup of the generated files for such test, so you can go back to before like nothing happened. Edit: See if updating to the test version from this post works better, in case you still have obscure problems.

RTFM Updating [..] There is no need to generate LOD just because a new mod was added. New objects may be missing LOD, but that is only a visual problem. Typically it should be enough to start DynDOLOD.exe with the current DynDOLOD.esp and generate (in this case update) LOD for the worldspace(s) the new mod changes. Then merge (overwrite) the files from the output path with existing files from the former generation. A clean save game cycle is not needed, however use an interior save between updates. Check the DynDOLOD SkyUI MCM for the message 'No DynDOLOD for this world' to be sure to not be in a world with any DynDOLOD data.

I support DynDOLOD, not other mods. You should not not update or change DLCs besides cleaning them. Use unofficial patches, which is loaded after DLC and has the correct data. After that I suggest to make sure to only use mods that properly forward unofficial patches and do not have errors reported by xEdit. I suggest to either check a mods pages for issues or remove such mods from your load order if they cause so many problems.

You should ask questions about particular mods unrelated to DynDOLOD on the mods pages. I suggest to copy (drag and drop) the MHDT - Max Height Data as well. A good indicator is that it is also in the Unofficial Patch. As a side note, the Holds patch for USLEEP also misses that data for no obvious reason. Unlike the world object bounds however, MHDT data from the last mod in the overwrite order is used, so if there are other mods loading after Holds its other problems with the world record may not matter. That file has nothing to do with DynDOLOD.

Keep using the latest one.