zilav

Ctrl+C to copy text of focused node from the right pane.

It tries to convert "Object Bounds\NAM0\X" from worldspace into numbers. Internally those are stored as floats, but xEdit converts them into integer cell values when displaying. There is a known bug in CK that sometimes it saves invalid float values here, probably meaning "infinity" when it can't calculate bounds for some reason. This is actually should be fixed by mod author. And DyDoLOD should just catch exception here and skip such mods silently. Warning - such invalid numbers in worldspace records are known to cause stuttering in game, Arthmoor reported it some time ago.

Never tried it myself, but I believe it would be enough to adjust LOD Water record set in WRLD to match the color of ordinary water. Vanilla Skyrim Tamriel worldspace record uses the same WATR for both LOD and non LOD water, so new water record for LOD need to be created and set in WRLD, and that plugin must be loaded dead last.

Nope, it is a faulty nif mesh from one of your mods. I asked Sheson to show mesh name when exception occures, but looks like he forgot to add that. You can try disabling mods to find out the source of issue.

Use OScape to regenerate terrain LOD for your load order.

Because DynDoLOD doesn't generate terrain LOD, only objects and trees.

The best confirmation is vanilla LOD itself, or rather it's absense I'd say

Big Town doesn't have LOD models. You can quickly check vanilla LOD yourself by renaming meshes\landscape\lod folder to "_lod" for example.

This looks like infinite uGridsToLoad now

Actually LOD generated by FNVLODGen is more performant and demands less memory compared to vanilla one because it removes unseen mesh parts hidden under landscape LOD (GECK doesn't do that).

Short draw distance is dreaded uGridsToLoad in Bethesda games, nothing we can do about it. The only way to make seemless transitions between LOD and full models is to create high quality LOD models that look very close. The current kind of "hub" for new LOD models is this mod https://www.nexusmods.com/newvegas/mods/61206/ Try to contact it's author since he stated intention to make trees at some point.

There is a bug in Fallout engine that crashes the game if a reference of tree that has LOD is marked as initially disabled (that's what cleaning process does). The latest version handles that correctly.

You must rerun DynDoLOD after any merging because it changes FormIDs and tree LOD relies on them.

As mentioned before, tree LOD looks good only with symmetrical billboards. Why do you think there are mostly straight pines in vanilla Skyrim and aspens are quite small? One of Bethesda tricks so you won't notice how bad LOD is in Skyrim, not because they love pines and tiny trees. Your billboard is not symmetrical at all, you need to rotate mesh and choose better angle before grabbing the image. Size of LOD in game is defined in .txt file having the same name as billboard.

Yes WastelandObjectsLOD is dynamically created atlas from LOD textures used in a worldspace, mipmaps are generated on the fly for it so mipmaps in source LOD textures aren't used.

If nothing works for you, then you can always switch off generating dynamic patch of DynDoLOD and use only static LOD generation. This way no papyrus scripts will be running and you can remove/update generated LOD files any moment without special steps. Some features will be lost (animated meshes, light FX), but generated LOD would still be way more detailed than the vanilla one. Like "TES5LODGen on steroids".

LODGen is a built-in script in TES5Edit for basic LOD generation, you are not supposed to run it if following guide.

The textures are just bad, that's all. As I said need real 3D LOD meshes like Jacobstown trees in NV.

I grabbed images for all trees LOD from NifScope without any processing in Photoshop or GIMP, that's why they look so bad. If you can make better ones yourself, I'll gladly replace them on FO3LODGen page. The ideal solution is to make low poly real 3D meshes instead of flat billboards, but that requires modeling.

There is no difference between esm and esp except for a single bit in the file header flags.

It tells you the name of plugin file it tries to open C:\Users\fabio\AppData\Local\Skyrim\Plugins.txt Either that file doesn't exist or TES5Edit can not access it due to permissions.

You need to create modgroups for that.

Except for the "height data" all of you mentioned is not false positive.

XLRL is treated as ITM when added and not overwriting a previous value because CK likes to add them to records in game master file for no reason. This feature was requested by Arthmoor since it caused a lot of "dirt" in USKP. You can change something else too to prevent cleaning, like EditorID, or slightly altered position/rotation by 0.0001, etc.

"Script" tag should handle that, but all WB versions other than Oblivion one never supported all the possibe tags completely. I guess this is something to be reported to WB devs, but I doubt it'll be fixed any time soon. Noone is working on FO3/FNV version code right now afaik.