sheson

I suggest to only use Skyrim SE version of mods and plugins or learn how to properly convert them. I advice against using it. It unsets vanilla LOD definitions and also doesn't carry forward some other data from DLC / unofficial patch. In any case it should be overwritten by as many mods as possible, including DynDOLOD.esp as it corrects the LOD mistakes in the esp. I can not replicate any CTD with that esp (either with the DynDOLOD.esp you uploaded earlier or with one create myself and just this mod) I suspect it has to do with the install combination of whatever meshes/textures are installed with it.

None of the 7 downloads has a plugin esp, but only textures. If you created a custom plugin, then make sure it does not contain errors. Make sure the load order is sorted correctly before generating LOD and the DynDOLOD.esp from scratch for that load order. Then there simply can be not be any conflicts in DynDOLOD.esp, because when the DynDOLOD.esp is created from scratch, the last overwrite record from the highest plugin is copied to create the overwrite in DynDOLOD.esp.

Great! Thanks for the help finding this obscure bug.

LOD 4, 8, 16 (and maybe 32) are static object LOD levels. The dynamic LOD of DynDOLOD has a Near Grid, Far Grid and Neverfade which is independed of the object LOD levels. Billboards are rendered textures. They usually are used by the tree LOD system, which only has one LOD Level 4. DynDOLOD can also use the billboard textures in object LOD by automatically creating the typical X model for them. I am assuming what you mean to say is, that the same LOD model for a 3D tree shows in LOD 4, 8 and 16, while you were hoping to have different 3D LOD models or even a billboard in the higher levels? You need to make sure the different nif files are named correctly with 4 = *_lod_0.nif, 8 = *_lod_1.nif, 16 = *_lod_2.nif A *_lod.nif applies to all levels, if no specific files for a level exists. If a specific file for a level exists *_lod.nif applies to all lower levels if possible. If a level is set to Billboard, it will create a billboard X for that LOD level if the billboard texture exists - regardless of any nif files. To set different 3D models for LOD level 4 and 8, I suggest to name the nif files specifically to *passthru_lod_0.nif and *passthru_lod_1.nif Then creating a mesh rule for that tree (or group pf trees) that sets Static LOD4 | Static LOD 8 | Billboard | Yes | Far LOD should work as intended. I suggest to remove all passthru_lod_flat_2.nif files. They are not needed anymore and also removed from latest DynDOLOD Resources. They were used before billboard textures could be used directly by setting Billboard for a LOD level, but now they are not needed anymore. They react wrong to lighting in the game because of their normals/tangents. "The only explanation I can think off is the actual LOD generation process is disconnected from what I do in the advanced rules panel." All settings done in the DynDOLOD option windows define directly how tree, object and dynamic LOD is generated in the current session. Make sure to save the mesh rules as well, so they can be loaded again later. Different folder locations for the standalone do not cause different LOD generation results. The recommendations are because of file and folder permission and to avoid accidentally overwriting existing files. The mesh rules, selections in the options windows and settings in the config files control how LOD is generated. So not sure what kind of problems you made yourself by installing things contrary to the manual and then by moving/renaming things. I suggest to simply install DynDOLOD into its own dedicated folder as recommended. Best to never use any special characters for files and folders. xEdit/DynDOLOD gets the games installation path from the registry. It may work to start the launcher once after renaming the games path to update that. In the long run you may want to consider to rename the folder structure.

You have a mod (DawnofSkyrim-AllMajorCities.esp) that defines a base record (Form ID xx0F1B87) that uses a 3D model meshes\stroti\treebench\benchpodest.nif. This nif file does not exist in the load order. This mod can red exclamation marks in the game or even CTD. I suggest to check the mods pages how to fix the broken mod. The fix is either to add the nif file to the load order or to remove the base record and all references that use it. DynDOLOD just reports the problem.

Which install option of Northfires Photoreal Mountains has a plugin? I only ever saw textures so far in any of the downloads? There really shouldn't be conflicts between plugins and DynDOLOD.esp. DynDOLOD.esp is created with the data from plugins in the load order to create overwrite records if needed. Problems can happen if plugins have invalid data or errors.

I found a bug that only manifested itself with one of the billboards. Please verify with this test version and FFO as it were to see if it works now.

Ok thanks. I will post here again if I find anything.

Double check the billboards / reinstall them, Maybe something happened to the files. I will download those billboards myself and test generation with them and see what I can learn. Which ones did you use? The Fall Forest edition or the Original version?

Looks like I was quicker :) Please test with this version, it also replaces one file in the "Edit Scripts" folder. Check if you have success generating both static and tree LOD. If tree LOD has error, do the two step like before. If this version also stops after checking large references, edit DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini in notepad and set Debug=1 and try again. This will add a few debug messages to the log which I am interested in.

Either a mod or maybe hardware instabilities? Are you overclocking? There is still a couple things I can change/test in the exe - that will take some time. In the meantime you could check if you remove batches of mods from the load order will make it go through eventually. Maybe you can narrow it down to a mod.

I am not yet sure what to make of that scanning problem, especially now that it can the files without problem. It may be related, but it seems strange that it would now read the generated tree LOD data - at least you can use that as a workaround for now. It will be same result as if you run tree and static LOD at the same time. I believe 00104395 is just the last reference from that report and has no special meaning. Edit DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini with notepad and change FasterBase=0 (maybe also FasterCreate=0 but that shouldn't make a difference) then do the same generation without tree LOD again, see if it goes through.

The log is probably the same for both, just there was no time left to write the last few lines for the other instance. Can you tell me how many *.btt files are in the folder it is scanning? There should be about 388 *.btt and one Tamriel.lst With those files still in place - after you killed DynDOLOD.exe - what happens when you start DynDOLOD again, go to Aadvanced, uncheck Generate tree LOD and click OK. Does it also stop at the scanning... ?

There are no other reports and I also have no problem with the original file meshes\architecture\whiterun\wrbuildings\wrhouseshack01.nif from Skyrim Meshes0.bsa. Double check the bsa/file maybe it has no errors. Otherwise just remove the reference.

Please test with this test version that will hopefully tell us in what part of the tree LOD generation process it fails.

Please check all plugins in the load order for errors with xEdit. Fix or remove plugins with errors. Then test with normal or test version.

Can you try running with this test version of DynDOLOD.exe. My hope is it produces a better error message that helps us to identify the problem. Edit: Also check if the problem is the same with either x86/x64 version. Just to make sure.

Are you using MO? Which version? What is the output folder? Is it empty? Does it exist (it should be automatically created, but that may fail). You have rebooted in the meantime I assume, which would clear up other processes locking folders/files. Please post new screenshot.

The installation instructions really really mean it when they say to install DynDOLOD "... outside of special OS folders like 'Programs Files' or 'Program Files (x86)', the SteamApps or game folders and Mod Organizers virtual file structure. Do not mix with old versions or xEdit installation." The errors is most probably caused because the program can not write the files. Also, it is best to not install the game to special folders like Program Files x86, as is mentioned by any installation guide. Then do not install DynDOLOD to the game folder and not to Program Files x86. You may get it to work by running "as administrator", but also check any anti virus interfering. Let me know if it still fails after fixing that.

The esp is required so LOD works correctly, adds copies of object from child city worlds that now have LOD to the parent world and adds a couple neverfades. This is all explained in the included documentation. It is in the right click window Other / Localization of xEdit. I doubt it will change anything. Yes, that should create a correctly localized plugin. G:\The Elder Scrolls V SE unpacked\ is not a valid installation path for the game. xEdit/DynDOLOD do not support invalid paths/setups. The problem is probably a corrupt nif (which most likely is from one of the other mods) which is used for neverfade LOD. The next troubleshooting step would be to methodically remove parts of data from the esp with xEdit, while at the same time keep a copy of a version with that data which still causes problems. It goes like this: remove half the data. If it works then go back to the earlier copy and remove the other half. The resulting esp should still cause problems. You continue this until you have narrowed down to the data causing the problem, always keeping a copy of the previous step. In this case we only need to looks at worldspace data. So, remove all worldspaces from the esp, to see if it works. If that is the case, use backup file and remove one worldspace at the time to narrow it down to a single worldspace. Once you know which worldspace it is, remove groups, then sub-groups until you have a single sub-group. Then remove batches of cells until you narrowed down to single cell. Then remove single references until you narrowed it down to a single reference. Then check the base record for the nif it uses. Replace that nif with its vanilla version / fix the nif. Or remove the base record and references using it in case the nif can not be fixed. If removing worldspaces does not work, then you are out of luck with that current setup.

First get a legal copy of the game. Then do some more selective troubleshooting. Only disable *.esp. Only disable all textures Only disable tree LOD. Only disable static LOD In case of the esp is causing trouble, I suggest to run DynDOLOD.exe (which is a modified xEdit.exe) with the -l:Russian language switch, so it matches the installed language of the game. And/Or maybe try the Delocalize plugin function of xEdit on the esp

This is the message: ERROR: Worldspace object bounds added by Holds.esp for [0000003C] Tamriel outside +- 128 cells. See the log or FAQ for more details.This is from the DynDOLOD FAQ Q: ERROR: Worldspace object bounds added by mod name.esp for [xxxxxxxx] Worldspace outside +- 128 cells. A: A mod changes the size of a worldspace beyond useful values. Either do not select this worldspace when generating LOD or fix the object bounds to useful values if they seem to be wild edits. To fix worldspace bounds error, in xEdit, open the worldspace record by entering the FormID of the worldspace into the field top left. Hit Enter key. Scroll right to the column of the mod. Scroll down to the rows for Objects Bounds. Right click a value and select edit and enter a number <= +- 128. In case it is a overwrite record use numbers from master mod as a guideline. Click OK or hit Enter. Save changed esp. Post from April 2016 where I explain the steps to fix the plugin, this can also be found in a issue posted to Holds Bug Reports In case anyone is interested why Object Bounds, NAM0, NAM9 values are sanity checked, check this thread. Technically, there is no use of using cells for game play beyond +-64 because of a engine bug with activators. It is a bit surprising that the mod has not been fixed in all this time and 3 versions later. I suggest to check all plugins for errors with xEdit and fix them (See this video for help) or to remove mods with errors from the load order.

Check the load order for errors in xEdit.exe before generating LOD. Fix all errors. See this for help. If problem persists, open ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5.ini in notepad and set FasterBase=0 and/or FasterCreate=0, see if that helps.

Well, as it is right now with the broken Skyrim SE engine, lots of mod cause large reference flicker as you can see from the log. So when you turn large references completely off, then SkyFalls may make sense until we can use SKSE and papyrustil (or something similar). From your post I could imagine that there could have been meshes with SBT that were used by LODGen, which are now gone or updated.

SkyFalls/Mills in SSE? You setting yourself up for lots of hurt and incompatibilities. Make sure none of the mods report errors when checking with xEdit. What happens when you run DynDOLOD directly without MO. Any exceptions? The log you posted shows no errors in LODGen or DynDOLOD? If the exception in DynDOLOD happens after [00:11:22.191] [00:00] Saving: DynDOLOD.esp [00:11:22.255] [00:00] Done saving. [00:11:22.255] Saving: Settings [00:11:22.270] Saving: Logs Then it doesn't matter, the esp has been written and the logs closed and the program is done shutting down. That exception is most likely caused by MO2 but it is not relevant to anything anymore. AFAIK UAC can not be disabled for certain folders. It is either on/off no? If you run everything as admin it should not matter. Anyhow check for anti virus causing trouble. Well the error causing Shreds problems has been fixed. Yours may be similar in nature though. If you run LODGen outside MO (I know that is hard to do ...) we could see the error message. You can start LODgen by copy pasting the execution line from the DYnDOLOD log into the a command prompt, however you would have to make sure all assets/meshes/bsa are available... So, if you can not do that, the next best method would be to eliminate as many mods from the load order as possible to narrow down the list of potential mods/meshes causing trouble. That would help me in order to replicate. If the game crashes, then invalid BTO might have been created. Narrow this down by first only disabling the DynDOLOD.esp, but keep meshes/texture. Then hide textures. Then hide bto meshes in groups. I tend to first hide all LOD levels but the largest. Then groups of files until you have one file left. If that is the cause, send me that bto file.. 2.24 has the newest LODGen version, it has been released after I posted the beta version. Use whatever billboards match your tree mods best. Billboards should not be able to make LODGen hang at all, since it does not read *.dds files. LODGen reads nif, btr and the text files from export and cache folder. Check MO log for errors.