sheson

Are you saying the game crashes the very moment you click "New Game / Yes" in main menu? Then you might have some very odd mod combination and data carried forward from another mod may be causing this or a corrupt plugin. Do you have EnableDiagnostics=1 in SKSE.INI? Try coc whiterun from main menu console. Have you checked all plugins for errors in xEdit and fixed them all? Have you changed the load order priority after generation? Try sorting masters with xEdit. Make sure the papyrus scripts are up-to-date. This could be related to PapyrusUtil. Which version? Upload generation log so I can look for mods and hints for what might be causing this.

If only textures changed, see Docs/DynDOLOD_TexGen.html 'Update Texture Atlas' section

You could try crash fix OSAllocators with pre-loader. If you already use that, I guess it is just to much to handle for the current engine.

Moss on objects typically has decal fade flag set in the fill model nif. So, first you need to disable detail fade through ini settings that the decals show all the way regardless of distance. [LightingShader] fDecalLODFadeEnd=1.0000 fDecalLODFadeStart=1.0000 So that moss and other decals show all the way on full models. Or you could set the no_fade flag in the nif. Then do the mesh rule setting as described. I think they should do what you want. If you only set LOD4 blank and leave LOD8/16 as they are, it should then use the full model for Far Grid but still have the static LOD model further away in LOD8/16. Though the switch between Far Grid / LOD8 is not exact like it would be between LOD4/LOD8, so there will be bit of overlap in the distance or gaps sometimes. You have to make sure to set the max Block0 distance roughly to match the 21 * 1/2 of the Far Grid. You can also try to set LOD4 to full model instead. It should keep the decals but without the fade. I programmed into the tools to set no_fade flag so they never fade regardless of INI settings. I have not fully tested this though. Note though, that regardless of full model or LOD model - decals that do not fade at some point, the decals will always win z-fight, which at large distances means they will be in front of things they really shouldn't be.

If the mods you are going to merge are not masters in the current DynDOLOD.esp and you haven't cleaned its masters since generation, it is save to merge those mods as no data from them was carried forward into DynDOLOD.esp. I can not answer questions if other mods are save to merge.

You could post the mod list to modwatch.

If it is a glow orb, it is the Torch. Now look up the Form ID 0010191B which is the full "model" source reference for the LOD object if it was changed by a mod. If it wasn't changed by a mod then then upload the load order. It should not be really possible for references using LIGH to be picked up when both Fake light child world and Fake light parent world are unticked in the advanced options. Unless a mesh rule overrules something. Any other custom settings? In any case the LOD should turn off when you are in that loaded cell. Any other dynamic LOD objects behaving strangely? Does this happen with a new game? Use coc MarkarthExterior01 from main menu, wait for initialization, walk into the city.

See this answer

That looks like the Editor ID of a base record. Look at the Editor ID of the Reference that is using that base record. It should look something like Skyrimesm_0A0D6E_DynDOLOD_LOD for example. If the mod actually is Skyrim.esm look up the mentioned form id to check if a mod updates it.

If both child/parent Fake Light checkboxes are off when generating and this still happens in a new game, then there is a compatibility issue with a mod. Find the real "source" of the object by looking up the form id in xEdit. The Editor ID of the DynDOLOD object will start with modname_formid of the object that the LOD was created for. Let me know which mod that is or if you need more detailed instructions.

You can update the existing DynDOLOD.esp (and static / tree LOD) by keeping the current DynDOLOD.esp last in the in the load order, generate static/tree/dynamic LOD. Then merge the new output folder with the old output data, overwriting all old files. When updating an existing DynDOLOD.esp still use an interior save, but it doesn't have to be "cleaned" - that is you can omit the steps of starting the game and saving without the esp. The "clean" save game update procedure has to be done when generating a new DynDOLOD.esp from scratch. See the "Updating" section in the manual for more info.

You should either make sure the papermap plugin is the last esp when generating with DynDOLOD from scratch so its world record edits are carried over, or generate without papermap plugin in the load order and then sort the plugin after DynDOLDO.esp

RTFM "Update Texture Atlas" in ..\Docs\DynDOLOD_TexGen.html for instruction how to just update the texture atlas for worldspaces that you already generated LOD for earlier.. Yes

There are special instructions in the manual under "Custom Settings For Specific Mods" for Open Cities. It also contains a link to the section for Open Cities of the step-by-step video. Follow those instructions, then the generated LOD should be fine.

Are you using Open Cities?

Great

Both DynDOLOD.exe and LODGen.exe have no network connectivity and so do not require Firewall settings. Do check AntiVirus though if you use any. Copy the entire command line starting with "L:\Steam\... to --skyblivionTexPath from the log into a command prompt window (cmd.exe) and see if starting it manually prints some kind of error message. It may not be able to read/write certain files. I wonder if restarting Windows might help clearing that up. If it starts directly at the command prompt but still refuses to start through MO, check MOs logfiles for "LODGen.exe" and potential error messages. To run DynDOLOD.exe without MO, you need to make sure that all config files exist at their native locations. Starting the Launcher once usually takes care of that.

I am not surprised doing all these unrelated things didn't help with the problem that it tries to start the external LODGen.exe :) Does the LODGen.exe process actually get started? Is DynDOLOD started through MO? What MO version? What happens when you start DynDOLOD directly? I could imagine some antivirus being problematic as well. Try setting "run as administrator" on all *.exe involved. The instructions say to install "outside of the game folders". Though in this case I do not believe it to be an issue.

Check overwrite folder. In MOs right window, Data tab, check what mod the TreeLod.dds and the *.lst and the *.btt files belong to. Then fix the error.

If you have problems with Nexus, contact them or post on the Nexus forum.

FAQ: Tree LOD: LOD trees textures cut off mid-way A: Verify that the tree texture atlas Textures\Terrain\Tamriel\Trees\TamrielTreeLod.dds and the tree LOD in Meshes\Terrain\Tamriel\Trees\*.* are the ones from the output folder and none of the files are overwritten by other mods. The tree texture atlas like Textures\Terrain\Tamriel\Trees\TamrielTreeLod.dds does not belong to the generated tree LOD in Meshes\Terrain\Tamriel\Trees\*.*. Keep generated files in sync. Replace Tamriel with Vyn obviously.

You could try running all tools as administrator. Do not install DynDOLOD into the protected Program Files (x86). Do not install DynDOLOD into game folders. I also suggest to move your SteamApps/Skyrim installation out of the Program Files (x86) folder

Select at least one worldspace or nothing will be generated. If using the advanced options and the box "Generate DynDOLOD" is unchecked there won't be a SKSE folder. Click the "Save & Exit" button at the end so it can save the DynDOLOD.esp to the output folder.

Billboards installations should not conflict with Hi-Res DLC at all so it should not even ask for overwrite permission. If it does, you should check the installation instructions for the billboards.

If that doesn't help I suggest to move your SteamApps/Skyrim installation out of the Program Files (x86) folder. You could also try running all tools as administrator.