sheson

The DynDOLOD and Occlusion plugins contain worldspace and cell records copied from the winning plugins at generation time and add plugins as master. A plugin that changes its name and is a master or if there are changes to worldspaces and cell records in one of the patches require the patches to be created anew or the conflicts should be resolved. If a plugin makes changes to terrain or references that affect their respective LOD types, LOD needs to be rebuild so it matches visually. TexGen creates object LOD textures from full textures. If a mod changes any of those full textures, then the object LOD textures should be updated and then the object LOD texture atlases should be updated.

Since no additional information was provided I will have to guess a couple things: fix any errors in plugin. Add some LAND records with height data to some of those cells. Uncheck specific chunk.

Make sure to get the latest Wrye Bash version to create valid Bashed Patch that isn't corrupt.

Unless Holds - Windhelm.esp is flagged as a master, things went wrong. There probably should be some kind of error message or warnings in the DynDOLOD log.

So what changed with the mod between generation? Load DynDOLOD.esp in xEdit. Unfold Worldspace, Tamriel, Persistent Worldspace Cell D74, Persistent. Sort by EditorID column. There should be references with EditorID starting with WhiteRiverFarmesp_* For example, for the initial destroyed shack there should be a WhiteRiverFarmesp_0A2268_DynDOLOD_LOD

Did the DynDOLOD version change? Did the DynDOLOD Resources change? What changed between the two generations? Does the log show that the plugin is loaded? Did you test with a new game?

Assuming you are using the same version of DynDOLOD and settings, then either the plugin changed or required LOD resources went missing from the load order. The message log lists each loaded plugin. Make sure it is enabled and listed in plugins.txt and shows up in the log. LOD models are assigned via full model filename matching as explained in DynDOLOD_Mod_Authors.html. If no LOD models exists a mesh rule should be added to use the full model for static object and/or dynamic LOD.

There is a problem with the required installation of Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019. All requirements of DynOLOD are listed in the included manual. For obvious reasons SSELODGen is not a requirement. From the manual: SSELODGen is a combined package of xEdit.exe and LODGen.exe. xEdit.exe is renamed to SSELODGen.exe so the built-in LODGen menu for object and tree LOD generation shows automatically. There are similar versions for other games. DynDOLOD.exe/DynDOLODx64.exe is a modified xEdit.exe

The obvious error message from the one line of the log you posted: Executing TexConv returned error C0000135 Searching the forum as suggested by the log message and in my post above finds this: https://forum.step-project.com/topic/14518-executing-texconv-returned-error-c0000135-vruntime140dll-or-vcruntime140-1dll-or-thatch03snowdds-was-not-found/

If all that wasn't a hint, the mod, its worldspaces and assets are very deliberately excluded.

Take a look at what? You did not post any useful information. "It seems to fail" is meaningless. I bet the log says exactly what is wrong. Read the log messages. In case there are instructions what to do, follow them. Check the FAQ for the message or search the forum. If problem persists post error report with entire contents (not just the last couple lines) of ..\DynDOLOD\bugreport.txt (if it exists) and ..DynDOLOD\Logs\DynDOLOD_[GAMEMODE]_log.txt

The obvious error message is Executing TexConv returned error C0000135 Searching the forum for it finds this https://forum.step-project.com/topic/14518-executing-texconv-returned-error-c0000135-vruntime140dll-or-vcruntime140-1dll-or-thatch03snowdds-was-not-found

Often caused by a broken Bashed Patch. Use a newer Wrye Bash version to create the patch. Simple search as suggested: https://forum.step-project.com/topic/14697-assertion-failure-wbimplementationpas-line-14062

If there are no references from DynDOLOD, then I am not sure what you expect to change in regards to DynDOLOD. Are the screenshots showing LOD? If all the glow is coming from another plugin, then you need to address the problem in that plugin or its used assets.

So the problem is too many glow effect NIFs overlapping in the same area? You can also just remove the references from the generated DynDOLOD plugin if dimming doesn't help.

FAQ: Game: Out of place objects / floating objects / flickering full models A: If LOD was generated for a different load order generate LOD for the current load order. A: Test with new game, wait in the exterior for the DynDOLOD initialized message before moving. If problem goes away, the updating of an existing save game with old DynDOLOD.esp went wrong. Follow instructions how to update save game with a new DynDOLOD.esp. RTFM, watch the video or check DynDOLOD SkyUI MCM. The clean save routine can also be redone with the same plugin to reset everything. A: If the load order had script lag and deactivating/activating from the DynDOLOD SkyUI MCM main page does not reset out of place objects, do the clean save routine where "old" and "new" plugin are the same. Consider generating less demanding dynamic LOD, see 'Performance' section in ..DynDOLOD\Docs\DynDOLOD_Manual.html A: Wild edit added by a plugin. Check the DynDOLOD log for messages about wild edits. Use console in the game and click on object to retrieve the form id. Look up the form id in xEdit and remove the reference, clean plugin afterwards. Notify mod author. If object is added by DynDOLOD.esp, follow the "pluginname_formid" information found in the Editor ID of the reference to find the plugin from which this object originates. A: Deleted record by a dirty plugin. Check the log for messages about deleted references by dirty plugins. Clean all UDRs and ITMs from dirty plugins. A: Sometimes LOD objects are placed on top of other objects without LOD and thus appear to float in the distance. Use mesh rules so that the object has no LOD or that the other object also has LOD. A: Game engine limitation. If the game enables objects that have static object LOD, the entire static object LOD for a cell may briefly show with the full models at the same time. Since now more objects have LOD this might be more obvious than before, especially while playing the intro. Consider installing the generated LOD mod after completing the intro. A: If the problems is stuck object LOD in Whiterun after fast travel, change Distant Object Detail on the View Distance tab of the Advanced options of the games launcher from Ultra to High. Alternatively try just slightly changing the value fBlockLevel0Distance=60000 in SkyrimPrefs.ini to 57000. A: Some mods are made with disregard to generating LOD or require updated rules and configs for best compatibility. This is especially true with mods modifying the walled cities. Users are asked and welcome to provide feedback to https://forum.step-project.com/forum/101-shesons-dyndolod-support in order to get everything working with as much compatibility as possible. Include a link to the mod and screenshots (with console / form id) about issues if possible. A: Flickering textures (full and LOD model showing at the same time) in Skyrim Special Edition and Skyrim VR are caused by plugins triggering the large reference bugs as explained in ..DynDOLOD\Docs\DynDOLOD_Manual_SSE.html. Verify if the problem goes away by setting uLargeRefLODGridSize=5 in SkyrimPrefs.ini. Open console and click the LOD glow when the fire is outside the loaded cells to get its reference form id.

There are no setting to control them separately at generation time. The same setting applies to all. After LOD generation, edit the base record in the DynDOLOD plugin. Make a new copy, edit it to use one of the other Meshes\DynDOLOD\lod\effects\fxglow*_dyndolod.nif and update the reference to use the new base record afterwards.

The DynDOLOD Resources SE archive is the same file regardless from where you downloaded it. I suggest to download it from https://www.nexusmods.com/skyrimspecialedition/mods/32382/

Read the included documentation Skyrim-Occlusion-Readme.txt in the xLODGen archive and the TVDT - Occlusion Data section in Docs/DynDOLOD_Manual.html to learn about TVDT data.

That's good for me and DynDOLOD :) You probably want to continue to disable mods at time, next ELFX until you find the one that changes the fire. Looking up the mentioned form ids in xEdit will help to know which plugins all overwrite the reference and base record. The issue might not be the records but the mesh and used textures. In xEdit, use the Asset Browser (start it with CTRL+F3) and enter Campfire01Burning.nif into the filter field to see the containers that supply the model. The first one mention wins. Disable the mod the first BSA belongs to etc. If the first container is Data, then it is a loose file and you can look up the mod in MO2 by finding the NIF in right window data tab. If you hightlight the NIF the status at the bottom will tell you the used textures. Enter the texture filenames into the filter field as above. At one point checking the involved mods you ought to find the culprit sooner or later.

That probably won't be necessary, as the terrain and object LOD didn't really change in terms of elevation, blocking view and the height of LOD objects. If you do not notice any square holes in the distant LOD then no need to worry about it.

As explained in DynDOLOD_Mod_Authors.html either there are LOD models defined on the base records, via automatic file matching or via mesh rules.

As explained in the manual, if you set Full model in LOD4/8/16 and Near LOD or Far LOD in Grid it will the full model to static object LOD if possible. It will only add LOD to dynamic LOD if technically required. Yes, you can edit rules on the advanced options settings and save/load them for later. Or you create a new rules file for the plugin as explained in DynDOLOD_Mod_Authors.html, so the rules are loaded automatically if the plugin is in the load order and low/medium/high is clicked .

Yes, those setting should work if no LOD model exists.

Setting the isFullLOD flag is what you do if you do not care about performance or potential visual issue with non fading decals. As explained in manual, DynDOLOD converts these to dynamic LOD so that they are only active within the Near/Far Grid distances to alleviate performance/resource issues. As explained in the manual, mesh rules can be used to automatically use full models or dedicated LOD models in static object LOD or dynamic LOD without having to edit references or base records in plugins.