sheson

Uhm yes, that should not happen at all. Lets see if DynDOLOD trips over itself because of a mod: Open the reference 00099374 in xEdit and see if it is changed by a mod, if so which one? The reference 00099374 usually uses 000F58C0 as a base record, see if that is changed by a mod, if so which one?

Look up 7C019008 in xEdit and let me know which nif model 7C019008 uses - it may be not from DynDOLOD but something else that got picked up. If it is from DynDOLOD Resources, you could try to delete and reinstall DynDOLOD Resources, maybe a mesh got corrupted. Build the reference info in xEdit and look up which references use this model. I would also be interested in the editor IDs of the references, as that would show me additional mod info. If you do not know how to do the above, let me know and I will give you more detailed instructions.

FAQ: Missing model "meshes\..\*.nif" - ignoring * [sTAT:xxxxxxxx] for dynamic LOD Answer: 1) Verify that all required BSA files are loaded. MO archive management is incompatible with many 3rd party tools like xEdit. Check startup log of xEdit, make sure BSA files are loaded via a matching esp filename. 2) Mods often have left over base elements referencing non existing nifs. Look up the form id [sTAT:xxxxxxxx] in xEdit, right click in left pane, Other -> Build Reference Info. Wait for 'All done!' message. Reload the record and check bottom for tab 'Referenced By'. If the tab is missing the base element is not used by any references and this error can be ignored. Otherwise install the missing nif and generate LOD again if LOD for this object is desired. Missing nifs can cause CTD if a reference tries to use them. Notify mod author.

There are two engine limitations regarding tree LOD: The first is tree LOD in a parent world can not be disabled in a child world. So if the trees in questions are placed in Tamriel inside the town walls of Whiterun, their LOD will stick when you enter the childworld Whiterun. The workaround is to give those trees enable parents, with mesh rules for example, or give them to static LOD with setting their references to "Billboard" in LOD4/8/16. The second is that two trees in different plugins can not have the same form id (minus the first byte for load order). When generating tree LOD, there will be messages about duplicate form ids. The first tree with the form id will get tree LOD and any subsequent tree with the same form id will be ignored for tree LOD and in case of DynDOLOD will get static LOD instead. For this to keep working correctly, the load order between those mods with conflicting form ids should not change or the stuck tree LOD problem can occur in conjunction with tree LOD turning off for some trees at the wrong time. Check the ..\DynDOLOD\Logs\TES5Edit_log.txt for "duplicate FormID numbers of trees references were detected, excluded from LOD" to see if it is the second case. Let me know if this made sense and helps.

[LOD] settings are all about details in loaded cells, exception is the fLODFadeOutMultSkyCell, which multiplies the neverfade distance set with [MAIN] fSkyCellRefFadeDistance - I did not find any difference changing one or the other provided the total distance is the same. Anything with "MeshLOD" in its name applies to full models - in the loaded cells or neverfades. The LOD I care about is the one beyond the loaded cells, and there is nothing really much to be done about it: Beyond loaded cells is ... ... when tree LOD starts. All you can do is change how far it goes with [TerrainManager] fTreeLoadDistance ... when object and terrain LOD start, all you can change is how far the static object LOD levels go with the 3 settings in [TerrainManager]. The fSplitDistanceMult multiplies the object LOD distances for terrain LOD levels. So all in all, there is 1 value for tree LOD distance. 3 for static object LOD distances, and the multiplier for terrain LOD. All of them exposed in the MCM settings so you can test them in real time. The shorter the distances the better for performance and memory use. All in all, it is really coarse and simple. BTW nothing of this changed in FO4 - the only differences are that is use no tree LOD (trees are poorly done static object LOD) and that you can have static object LOD in LOD level 32 as well.

These things change every once in a while. This is just now, because of 4 tree billboards included in DynDOLOD atm, that Indistinguishable Vanilla Tree Billboards (and only that mod has them) should overwrite. Nobody will spot the difference if you do not know what to look for. Eventually I will move them to the vanilla billboard download from TES5LODGen, so DynDOLOD Resources once again does not contain billboards to worry about.

See 'Overwrite Orders' in the included Manual. Indistinguishable Vanilla Tree Billboards should overwrite the billboards included in DynDOLOD

I am downloading polish version right to see if I can replicate. May take a bit though. In the meantime, test if it loads with latest xEdit As a work around, you could rename the last mentioned BSA so DynDOLOD/TexGen will ignore it and probably start. Missing Voice should be no problem.

W Does DynDOLOD.exe start without problem with the same load order? If it has the same error upload complete log.

Remove the reference from the mod before generating LOD. Notify the mod author about the wild edit.

Yes that is very likely. I will test those two together and adjust if possible.

You only need to install DynDOLOD once. If you remove mods from the load order that are masters in DynDOLOD.esp generate LOD from scratch. See Uninstallation / Updating in the included manual.

Those lights are "Fake lights select world" and as the manual explains, they "might not work very well and look off when approaching the light source. Typically, leave this unchecked." The patch is to sync the LOD to Lanterns of Skyrim lights - candle flames as well. If specific LOD was not generated the patch will not change that and only switch the LOD that was generated.

Do not start the DynDOLOD Beta scripts through xEdit.exe. Follow the instructions in the included quickstart, manual or videos from the Beta post

Sounds like a save game update issue or an older version of Legcay. 15.x ships with DynDOLOD rules files (like data\DynDOLOD\DynDOLOD_TES5_legacyofthedragonbornesp_medium.ini). Make sure to update rules with low, medium, high so they are added. The log should print a line about rules for legacy being loaded.

Everything should be normal once out of the cave.

Can you pm the file so I can use it to make it work as we think it should.

Whatever I do for consoles will just either brick them or hack the account login data. Which terrain LOD meshes/textures to use depends on load order and your preference. If I had to recommend something I would suggest to generate terrain meshes and textures with Oscape, but that is not as simple as pushing a button. Enhanced Landscape does not change terrain LOD either.

Just wait for paid modding for FO4 and when I release versions for consoles once a week for 2.99. Season pass 10% off. Resources not included.

Oh you must be using the buggy modular version? I stopped testing them after seeing all the errors reported by xEdit - somehow I expected an update for that right away back in April. I need to add those esp names to some ignore list, next version.

I need to retest, there should be no stuck LOD outside the city limits with the current default support. It should create the same LOD all by itself equivalent to the LOD shipping with the mod plus the extra LOD from DynDOLOD.

1. Signed integer per section, so 2,147,483,647 2. Both will be applied. If they are the same it doesn't matter. If they are different they are cumulative - which may or may not make sense. If first rules creates a neverfade and the second says delete the result will be that the reference is "deleted" (technically disabled and moved below ground) and so the created neverfade LOD will never show. 3. Certain Form ID rules (Original, Copy, Enable, Delete) will be applied regardless of ignore so you can delete objects and later ignore everything else the mods for LOD. Anyway, that is how it is supposed to work. Let me know in case unexpected things happen.

Asked many times before: Objects that now have static LOD can flicker if sitting on cell borders and the esp is not enabled. So keep it if you notice that.

That shouln That doesn't matter as it can only create the overwrite once, the first time. If running an update later - after saving and loading - it will not update already existing overwrites. It probably should I guess.

I would run the patching again from scratch and make sure the last overwrite of the cell contains the data you want to end up in DynDOLOD.esp, to reproduce the result. That is, if you want DynDOLOD.esp to be the last in the load order once patching is done. It doesn't have to be. The code that creates the overwrite basically looks like this Element := WinningOverride(Element); wbCopyElementToFile(Element, File, False, True);