sheson

https://dyndolod.info/Help/Grass-LOD#Updating To test different GrassBrightnessTop*/GrassBrightnessBottom* or GrassBrightnessBottom*/ComplexGrassBrightnessBottom* settings, change them in ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_[WORLDSPACE].txt, start DynDOLOD in expert mode, select the desired worldspace and click the Execute LODGen button. https://dyndolod.info/Help/Expert-Mode To start DynDOLOD in expert mode, use a text editor to set Expert=1 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini.

All base records and associated assets are scanned (before any worldspaces are processed). It only matters if a base record is reference by a reference (REFR) regardless of interior or exterior cells and if their worldspace is selected for LOD generation or not - since missing assets is an issue regardless of LOD generation. I can only repeat that missing assets is a problem regardless of LOD generation. To make a message about a problem go away, fix the actual problem. Ignoring a problem whatever way does not fix the problem. The last plugin to overwrite is typically blamed - typically DynDOLOD is supposed to just leave anything that cause bugs alone but with the large reference bugs workarounds things are in flux. The debug log tells us NoBrokenWhiterunTower.esp is probably the plugin causing it. With the large reference bugs If a diffuse texture for Shader/BSTextureSet is missing there is no point in reporting if other textures are missing, too. They typically do. It also should be easy to spot when checking the model and or the folder where the texture are expected. It is a common programming method to fail early/fast to be faster. The primary function is to know if something is usable or not and to only keep a list of usable assets while printing a log message why something wasn't used.

Is there any change after saving and immediately loading that save without restarting? Anything different when saving and actually restarting the game and loading?

1. The rules can/should be updated by clicking low, medium, high. All the other settings might change, removed or added and thus interfere, so you are on your own doing this. If you have custom rules for specific mods that you want to keep, put them into a rules file for the mod's plugin and make them available in games data folder. https://dyndolod.info/Mod-Authors#How-to-add-a-rule-file-for-a-plugin 2. Plugins should be cleaned. There should be no deleted references. How would you know about a plugin having unneeded/defunct records that all can/should be removed without DynDOLOD reporting them? As explained at https://dyndolod.info/Messages/File-Not-Found-Meshes, it is up to a human to verify/decide. 3. That statement ignores the error/problem you reported which exists regardless of generating LOD or not. The statement ignores that LOD is unique to the load order and user preferences and that DynDOLOD is the advanced and improved version of xLODGen to generate a patch - it does a many things more than "just" generate vanilla style LOD. The lodsettings file tells the engine that are LOD files to show beyond the active cells and contains information about the origin cell of the LOD (required to know the filenames) and the LOD levels. If you do not want to generate LOD for a specific worldspace, then simply do not check it in the worldspace selection box. If there is a problem or issue with LOD generation for a mod/worldspace, then it should be reported here, so it can be investigated, troubleshooted, fixed or addressed properly. See https://dyndolod.info/Mod-Authors. 4. No idea what/if the flag actually does anything in the game. If a worldspace has LOD or not is determined by the existence of the lodsettings file.

All further away fires look the same to me regardless of the original reference/base record in Skyrim.esm or the ones copied to DynDOLOD plugins. As I already said, it probably has to do with the how the NIF is made and corresponding INI settings. Particles count, decal fade maybe. Since just flying away with tlc from the fire just changed by the mod has the same effect, there is nothing any DynDOLOD setting can do about it.

I can replicate. Will be fixed next alpha version.

That is indeed confusing. "No vertex colors" should be checked. The object LOD meshes should not have any vertex colors.

Is this repeatable? If so, does adding TextureCache=100 below [DynDOLOD] to DynDOLOD_SSE.INI change anything?

Moved to the DynDOLOD 3 Alpha thread. Read the first post. See this existing answer https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-106/?do=findComment&comment=265482. It is unclear what warning or error message about problems in the load the order you need further help for in addition to the existing explanations. Always use the latest version. Do not install the game into special folders like Program Files x86 to avoid issues with Windows UAC, antivir etc.

Depends on the type of NIF and how it it used. You do not need to worry about any that are not reported. https://dyndolod.info/Messages/Root-Block

DynDOLOD is all compiled code, so no pas scripts. Just use the list from the summary.

"LOD associated ini" does tell us which INI setting you are talking about. I can only hope it doesn't mean INI settings for static object LOD under TerrainManager, since they are obviously irrelevant. We have no idea what the original base record looks like - since no logs, no screenshots or form id was provided - anything that might be different but the form ID and editor ID.

... and also show that the full model is being used. If there are no flames in that case, it could be because of some fade INI setting or in the NIF or because the base record in the DynDOLOD plugin is missing something. Compare to the original base record. If these troubleshooting hints do not get you anywhere, set the reference drop down to "Original" and test what happens then.

I can replicate, will be fixed next version.

DynDOLOD should be using the Theme setting. No logs or settings file was provided.

Just set FarFull and maybe Replace to avoid brief overlap of 2 full models.

Moved to the DynDOLOD 3 Alpha thread. As explained on the first post, Certain things may be incomplete, not work as expected or change considerably between versions. The reasons for the check are explained in the message and the linked documentation.

The 4 LOD levels for static object LOD need to be set to None. Doublecheck the LOD fire in the distance is dynamic LOD, it should show in More Informative Console as a reference and base record added by the DynDOLOD plugins and also show that the full model is being used. If there are no flames in that case, it could be because of some fade INI setting or in the NIF or because the base record in the DynDOLOD plugin is missing something. Compare to the original base record.

The setting to ignore entire worldspaces for LOD generation is set via a config file in the DynDOLOD installation only. The plugin specific config setting to tell DynDOLOD to ignore references a plugin adds to a worldspace for that plugin and worldspace only and is generally intended for the city child worldspaces only. https://dyndolod.info/Mod-Authors#How-to-ignore-all-references-of-a-child-worldspace-for-copying-to-parent-worldspace-and-LOD If there is an actual issue or problem, then it should be reported/discussed first, especially with DynDOLOD 3 Alpha. https://dyndolod.info/Mod-Authors Whenever coming across a problem and the initial reaction is to disable something - which is only a troubleshooting step - or to make elaborate workarounds to get something to work, it could mean the way LOD generation and DynDOLOD in particular works is not fully understood or that there is a bug or an unexpected situation that is not yet addressed - either in 3rd party mods or the tools or whatever else. Remember, DynDOLOD is a patcher to automatically generate a LOD patch. The LOD patch it generates is not supposed to require patching itself.

Do not set static LOD for animated models. Instead use the Full Model for dynamic LOD, e.g. Grid: FarFull. Consider setting Reference: Replace so that there is no switch.

Check that the texture has a supported compression format and is not corrupt.

Moved to the DynDOLOD 3 Alpha thread. The error message says that a texture is missing. This has nothing to do with the game version, the DynDOLOD DLL version or the grass cache. As explained on the first post, use search to find posts about the same/similar errors: See https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-106/?do=findComment&comment=250544 "cyrodiilfarmstucco02.dds is part of Beyond Reach and the texture is required because arnima.esm is in the load order." Install the latest version of Beyond Reach.

Really read the message prompt. It tells you what the problem is and gives a suggestion what to check: DynDOLOD Resources SE version information not found. Verify correct installation. The message tells you there is an issue with DynDOLOD Resources SE and to verify its correct installation. Click the "Click on this link for additional explanations and help for this message" to open further explanations and help as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages. It opens https://dyndolod.info/Help/DynDOLOD-Resources. Check the Troubleshooting section.

it means this is a rare race condition I'll have to fix. Thanks for reporting.

Is this error repeatable if you try again?