sheson

None of the tools should crash, that is not normal. If something stops working it means it could not generate everything completely. Check TES5Edit\LODGen_log.txt for hints or messages or if it crashes and couldn't write anything useful to the logfile, post a screenshot of the white text on black background command prompt window and its message. If the system is overclocked or there are CPU temperature problems it might just close randomly. You can then try to uncheck some CPU core affinity in task manager. If the mod that is disabled only contains dds texture files it makes no sense and I have no idea - something else must be happening. But it doesn't make sense overall because DynDOLOD leaves NPCs alone anyways. TexGen only generates LOD textures with "lod" in the their filename which are only used by LOD models and to build the atlas. They either overwrite existing textures and add a few new ones for new LOD meshes. So if you disable them, it means the vanilla textures will be used by some LOD models if using the atlas version does not work. The only connection I could think of is running out of VRAM. The manual is up-to-date in regards to the mods that are listed and what needs to be done with them. I may add rules for them at one point, or better yet - if you create "Enable" rules for the tree references in question and post them I will happily add them.

No promises about if ever or when anything comes to light. Glow LOD. Static and dynamic LOD Windows and things that emit light (candles). Create new LOD models for a few more vanilla objects. Update existing vanilla LOD models. better texture replacer support esp. for LOD models that use merged textures (major city LODs) Eventually looking into a stand alone compiled version to speed things up. Testing and if successful try to implement or improve: - better water LOD, probably can only be done as dynamic LOD - static LOD with enviroment maps / specular - for ice and glaciers - Terrain LOD / meshes / textures I also have my eyes on Skyblivion/Skywind and other new lands as well as creating LOD meshes for 3rd party models / modders resources to better cover and support mods.

See https://wiki.step-project.com/Guide:Troubleshooting#INI_Issues and https://wiki.step-project.com/Guide:Skyrim_Configuration_Settings The order of entries doesn't matter.

In that case the minimum requirements to use DynDOLOD are not met.

Everything says to make sure the Skyrim.ini contains [Archive] sResourceArchiveList=Skyrim - Misc.bsa, Skyrim - Shaders.bsa, Skyrim - Textures.bsa, Skyrim - Interface.bsa, Skyrim - Animations.bsa, Skyrim - Meshes.bsa, Skyrim - Sounds.bsa You are reporting your Skyrim.ini does not contain that. Just add it and see what happens? This is not a DynDOLOD problem. You may want to search for how to recreate default inis.

Let LOOT sort it out. It should be OK them.

I know right :) Once you sorted out the hurdles the first time you are set. Then it just is a PITA because it runs forever when you update.

You should check with Skyrim Performance Monitor if you run into memory, main or VRAM/GPU troubles. Yes, copy the contents of the textures.128 overwriting the textures from the archive. You do not have to generate all LOD again. If you set Expert=1 in TES5Edit\Edit Scripts\DynDOLOD\DynDOLOD.ini and start TES5Edit and apply DynDOLOD Worlds.pas as normal. At the top left click the button "LODGen export" and find TES5Edit\Edit Scripts\LODGen_Tamriel.txt then at the bottom click the button "Rebuild atlas" It will be quicker and actually better if you just resize Textures\DynDOLOD\LOD\DynDOLOD_Atlas_Tamriel.dds Textures\DynDOLOD\LOD\DynDOLOD_Atlas_Tamriel_n.dds Textures\Terrain\Tamriel\Trees\TamrielTreeLod.dds with a dds tool of your choice. The texture.128 does not cover all textures that are used in the LOD atlas listed above.

I will add rules for those 2 trees with next update. Just to verify they are from JKs Whiterun exterior.esp right? Once AceeQ added a patch for Pinegrove Lodge and you generate LOD again everything should be fine.

Yes you will have to generate LOD again from scratch after removing the wild edits that got picked up into LOD. I guess if you do the same cleaning process first for Solstheim it will take care of the stuck tree LOD.

Regarding tree LOD. Are you certain you completely overwrote existing Tamriel tree LOD (Meshes\Terrain\Tamriel\Trees\*.*) with the one generated by DynDOLOD? I see previous generations by TES5LODGen. Maybe files got mixed somehow. Also was the stuck tree LOD present then? I quickly tested a Small-Town Marchants version and did not have floating objects. From the description of the clutter objects I assume they are always there regardless of DynDOLOD. The LOD objects in static LOD are also done by mod number 2B - which is rorikstead_merchant.esp 2B00DAAB 2B00DAAC 2B00DAAD 2B00DAAE 2B00DAAF 2B00DAB0 2B00DAB1 The gate from Windstad mine is always there floating in the air in the middle of the world, regardless of DynDOLOD. I suggest to just remove those objects from the mods with TES5Edit. The authors should be notified and clean their mods from wild edits.

Using NMM makes things a bit trickier in terms of quick tests and mod separation. No worries. I tested with JK's Whiterun Outskirts v.1.1 (that is the one, right?) about the trees and by itself I could not replicate. If you still have TES5Edit\TES5Edit_log.txt and could upload it somewhere for me to check. It also lists all mods in the load order so that will help me as well. Also upload TES5Edit\Edit Scripts\LODGen_Tamriel.txt. Could you tell what the object in the middle of the world was? I can't really tell it from the screenshot.

Regarding the stuck tree LOD check if TES5Edit\TES5Edit_log.txt contains lines like "Get xEdit 280715 or newer in case there are LOD trees in loaded cells." If that is the case download the latest xEdit and generate tree LOD again. The floating static LOD object is probably a wild edit to a town child world. That is why it disappears when you are in the Tamriel parent world. The location is the center of the map so at cell 0,0 You could check TES5Edit\Edit Scripts\LODGen_Tamriel.txt for an object where x (column 3) and/or y (column 4) are 0 by chance. Trouble is it might not be exactly zero. It may be easier to just travel into Whiterun, Solitude, Riften or Windhelm (not Markarth) and tcl to the center of the map until the object stays and you can get the form id. Let me know the mod I can add a rule to ignore the object. Also notify mod author.

All I ever wanted to do was to "see my house from here". Look what happened...

Correct on all accounts. Consider lowering the Far and Near grid sizes. For example a grid size of 21 means 441 cells with potential dynamic objects are "on". With 19 it is 361. So potentially quite a few objects less. You can also move some objects from the Far grid to the Near grid so the objects only show when closer. To be like SkyFalls/SkyMills (but even better since things turn off when outside the grids) remove all rules that have a setting in the "Grid" column Keep "fxwaterfallbody" (that is the 3 types of of waterfalls skyfalls does) Keep "farmhousewindmillfan", "solituderotor", "sfarmhousemillfan" and "waterwheel" Now the last rule "/" also has a Grid setting which means, any object that has static LOD but is dynamic in some way (quest enabled) is automatically done as dynamic LOD. You need to keep the "/" in general with LOD4/8/16, but you can set the Grid empty, but I recommend keeping it. It should be OK to keep the _byoh rules (Hearthfire) as well. Most of those house objects are not active all the time and if you have a house you want to see it. :) After a world is scanned, the log writes a line like "Setting up xxxxx cells with xxx active cells for xxxx dynamic LOD objects for DynDOLOD" I think there typically is around 4000 dynamic objects in Tamriel for high. You can use that as an indicator how changing the rules changes the number of objects.

Not at all, because it addresses a different performance problem than reducing objects. Testing this can be done quicker by simple resizing the atlass textures in Textures\DynDOLOD\LOD\DynDOLOD_Atlas_Tamriel.dds and DynDOLOD_Atlas_Tamriel_n.dds check the LOD meshes filenames themselves in Meshes\lod\rocks\ Not all rocks have a LOD8 version, so setting LOD8 is a simple trick to not generate LOD for the smaller rocks. _0 = LOD4 _1 = LOD8 _2 = LOD16 if there is no _0 it automatically uses _1 for LOD4 if there is no _0 or _1 it automatically uses _2 for LOD4 and LOD8 You can also rename the LOD files yourself to your liking. But creating specific rules is more future proof since you can save the preset and reuse it later. Actually I don't. I really only test with only a few mods all the time and performance is fine then. The mesh_count.txt is still the best bet. You might also want to turn your attention to the dynamic LOD and check if dialing back some of the fires and smaller waterfalls features helps performance. The simple test to see if there is potential is to run the game without the esp and only use the static/tree LOD to see the impact of dynamic LOD. The rules are in TES5Edit\Edit Scripts\DynDOLOD\rules\ Each mod has a file. The manual has a section about merged mods. The best you can do is to also merge the rules into a new file with the merged filename. If the manual is not explanatory enough how to do that let me know. Actually your questions are perfect for this thread and will hopefully help other people also looking for more details about fine tuning.

You only have to rerun/update DynDOLOD if you add a mod that actually adds objects that should have LOD, and only if you really want LOD for them. Vice versa, if you know the mods of your load order very well, only enable the ones that add objects that should have LOD when generating for the first time. This will minimize required masters. LODGen exe is a multi threaded application that makes good use of the CPU, so it gets hotter. If you rerun/update DynDOLOD and the rules (low, medium, hi) and LOD meshes did not change since last time you can check "Use cached base elements" on the advanced screen to shave off a couple minutes. We had this problem a couple times before and I am happy that the error message now is descriptive enough for someone to figure it out :)

If there is a list to fix that for low, medium I happily add it to the defaults. Can't be *that* many.

Uhm not my problem actually :) LOD is always working the same. It doesn't randomly change x, y, z position of things. Those reach trees were not planted with LOD in mind. I would assume a couple possibilities - the tree is growing on an object that has no LOD - either because of low, medium settings or actually no LOD model at all (easy to test when moving close) See discussion with EssArrBee - the vanilla LOD mountains often do not fill the exact volume perfectly, because of triangle reduction they are smaller. Form ID of the tree would be nice, though

If you are sure the esp and the json files are from the same generation process and you copied everything from output to game or mod folder correctly ... then most likely the LOD generation process for Tamriel didn't complete successfully. The end of TES5Edit\TES5Edit_log.txt should look like this [00:21:31.766] Saved c:\Output\skse\plugins\StorageUtilData\DynDOLOD_Tamriel.json [00:21:31.778] Adding world index with 9 entries [00:21:31.787] Saved c:\Output\skse\plugins\StorageUtilData\DynDOLOD_Worlds.json [00:21:31.796] Disabling 5 REFRs [00:21:31.811] Write next object id 1BE9F0 [00:21:31.828] DynDOLOD Worlds completed successfully. [Apply Script done] Processed Records: 0, Elapsed Time: 21:38

you can enable those mods afterwards again, no problem. Use LOOT to sort DynDOLOD in the load order then. LOD not found is probably bushes and ferns, it will only do trees, so this is normal. Already has an entry :) First, check memory patch and memory blocks for sure, extra LOD requires some more memory. If VRAM is full, you might want to use the smaller LOD textures from download archive options/textures.128 Or simple use ddsopt to resize the atlas textures from the output folder. Otherwise the hires texture pack comes to mind. It is easy enough to disable the 3 esp/bsa and test if you have better results. There are optimized vanilla and hires texture packs on nexus https://www.nexusmods.com/skyrim/mods/57353/

Which xEdit version are you using? Can you try with the latest? It looks like it barfs on something in Naruto - Overhaul.esp, there are unresolvable form ids in the 2 activators, but it works here. Can you try what happens when you remove / uncheck Naruto - Overhaul.esp from load order. I will check more of the other mods from your load order in the meantime

If problem persists post error report with contents of TES5Edit\TES5Edit_log.txt

FAQ: TES5Edit / TES5Edit\TES5Edit_log.txt: Any other script error while running DynDOLOD Worlds.pas Is DynDOLOD.esp last in load order? Try again with default DynDOLOD.esp? Delete all old files in TES5Edit\Edit Scripts\ DynDOLOD\ and install only new files from latest DynDOLOD archive. If problem persists post error report with contents of TES5Edit\TES5Edit_log.txt to https://forum.step-project.com/topic/5011-dynamic-distant-objects-lod-dyndolod

I just have to assume you are certain memory patch works and block 1 is fine. You used DynDOLOD before and all those meshes haven't changed since 1.27 (check time stamp of the files). They didn't cause CTD before, why should they now? Why only for you? Log one shows a line 3 seconds after the meshes were activated. So none of them can be the cause of CTD. Check Effects\FXrapidsFallsTop.nif it is not from DynDOLOD archive. However I doubt any of them is the cause of CTD. If you can't find it, it is in a BSA. Usually the vanilla Skyrim Meshes.bsa, then it is fine. Follow the instructions of the readme, that tell you to remove/disable the meshes. But if that is the complete list of meshes I doubt invalid mesh is the cause of CTD.