zilav

Good job as usual! I LOLed after the comment "move along - nothing to see here", surprise

Or just drag&drop that field with mouse from Provincial courier service into AI overhaul merged

Yes probably a bad DDS texture file from some texture replacer. Maybe you can add output for TexGen script what the current LOD texture is being created out of what source textures, then they could be troubleshooted with Assets Browser in TES5Edit.

This is a cloud layer #28, you can manually adjust it's texture (a solid one is used here), opacity and colors per day time. I agree that vanilla weathers have it way too dark, but you can mod it easily either with CK or Weather Editor script in TES5Edit.

FNVEdit is shipped with script to restore FULL and DESC names on all records from master records "Restore record names from master.pas". You can apply it to any localized plugin to have english names back.

Since the language of your Skyrim differs from the plugin, you can first try to copy localized names from master over to the plugin. Right click on plugin, apply script "Restore record names from master". Then try to clean.

LOOT database is filled with manual user reports, LOOT itself has no idea about the presense and amount of ITM or UDR records. Several things could happened here 1) the original report by someone was wrong but got included into LOOT database without any check by someone 2) new clean version of plugin has been released but LOOT database still contains report for an old version, which again should be removed manually by someone Anything that LOOT shows you is only a hint, not something you should blindly trust and take action. I don't know who exactly posts reports into LOOT database and is there any "quality" control at all. I admit I never read STEP, but this must be clealy stated there for sure.

And that's why you should never load mod combinations when cleaning, only a plugin to clean and it's masters. If injected records are indeed the same in all of those plugins, than xEdit is working fine cleaning them out when several are loaded at once. If you really want them to stay in any possible case, then assign unique Editor IDs per plugin.

xEdit should not clean injected records having changed data, please provide test plugin to replicate this. Such bugs should be fixed if they are really present.

Intentional ITM records work only for mods that load after the conflicting ones, not before, and even then it will interfere with them by having that forced identical records. Any so called "intentional" ITM records should be cleaned anyway and conflicts must be resolved with a proper load order, a compatibiity patch, or not using conflicting mods at all if nothing else works. ITMs won't cure conflicts and make mods play nice together if they conflict on critical data no matter how many ITM records a mod author is trying to leave in his/her plugin to preserve vanilla records.

Generating LOD is not a rocket science for a user, but creating new missing LOD meshes is

That actually can not happen when generating tree LOD from billboards, in the worst case there will be a wrong tree image or no image at all. "Cut" distant trees problem is ALWAYS an incompatibility between LST file that defines position of images on atlas and tree lod atlas DDS texture itself.

The full post copy: Blocks and SubBlocks are actual GRUP records stored in plugins, game uses them to quickly find temporary exterior cells when player travels around. Their numbers depend on cell's X,Y coordinates, actually cells are placed into those groups depending on their X,Y. Blocks and SubBlocks numbers for a cell record are calculated this way, assuming (CellX, CellY) are the cell's coordinates stored in XCLC subrecord. SubBlockX = (int) CellX / 8 if (CellX BlockX = (int) SubBlockX / 4 if (SubBlockX The same for Y. So each SubBlock holds a grid of 8x8 cells, and each Block 4x4 SubBlocks, or 32x32 cells. This is a WastelandNV map with overlayed blocks, subblocks and cell coordinates of bottom left corner of each subblock to give you the overview. You can view it yourself in FNVEdit pressing Alt+F3 for any worldspace, including your own (just select opacity to overlay grid). The only exception is a singe persistent CELL having 0,0 as coordinates which holds all persistent references of worldspace, it is a direct child of WRLD record and game loads all those references regardless the position of player, hence the name "persistent". Interior cells use groups too under top CELL group, but they are determined differently. Cells can be only temporary, they hold both temporary and persistent references. Hexadecimal FormID number of a CELL record is converted to the integer value excluding the leading byte which is load order and changes dynamically depending on the position of plugin. The last decimal number determines Block number, the previous one is SubBlock. Lets take this cell as an example NovacMotelRoomTwin2 "Motel Room" [CELL:000CD3E1] Hex value 0CD3E1 converted to integer is 840673, so the physical locaton of that cell inside a plugin file is FalloutNV.esm \ Cell \ Block 3 \ Sub-Block 7 \ 000CD3E1 (as FNVEdit shows you). You can read more about plugin file format, it is the same since Oblivion (except extra 4 bytes in record's header for Version Control information). p.s. Don't know why I'm writing all of this, was kind of surprised seeing this "The block/Sub-Block format for grouping/displaying cells is just that - a display method. Those numbers don't actually exist in the plugin/Geck/Game" while they do actually physically exist, though GECK doesn't show them. It is only an internal search optimization method for the game.

Almost forgot about that. Described how worldspace and cell blocks and subblocks work some time ago on nexus forum, can be useful to include in the guide if you wish https://forums.nexusmods.com/index.php?/topic/3079894-lod-generation-troubleshooting/page-2&do=findComment&comment=27434159

Seems to be an error caused by MO bug when creating a lot of files inside virtual Data folder, did you redirect lodgen output somewhere outside of it?

Nice! Batlespire still remains the only TES game to support cooperative mode and deathmatch with up to 8 players. So many memories of beating it with with friends over LAN, was the best TES experience for me.

Those are ordinary landscape LOD textures, nothing wrong with them. In vanilla skyrim a LOD texture tile covers 4x4 cells area and has 256x256 resolution, so the quality is not that good. Skyrim uses exactly the same landscape LOD system since Oblivion. It looked **** there, looked **** in both Fallouts, and now looks **** in Skyrim too. Oh and judging by trailer Fallout4 is still using the same LOD terrain system, so expect more "****" in future. You can try to use more defined terrain noise texture mods to improve the look though.

Navmesh is a huge PITA in Skyrim indeed, hope they will improve it in FO4.

NAVI record always contains all navmesh data because it is merged at runtime, no need to clean it. Removing it entirely will probably destroy NPCs pathing between cells.

You have a NAVM record in plugin which is not located inside temporary group of child group of CELL record. Unfortunately TES5Edit can't fix such errors. Also calling Sort Masters on the entire load order is dangerous to say the least.

It must be -o:"D:\TES5 Output", not -o "D:\TES5 Output"

There are several mos for Oblivion that edit shaders and OBMM installer handles that .sdp patching itself. However I don't see any point in editing shaders yourself when you can install Oblivion Reloaded and tweak almost eveything shader related.

Use this version I uploaded today, it'll show the mesh name https://www.afkmods.com/index.php?/topic/3750-wipz-tes5edit/

Report this to mod author.

TES5Edit loads BSA archives using these 3 rules: 1) archives listed in Skyrim.ini under sResourceArchiveList and sResourceArchiveList2 parameters 2) archives listed in INI files provided with loaded mods, they are located in the Data folder and have the same name as mods, for example ArmoredBikini.esp ArmoredBikini.ini 3) archives those names match loaded plugins, for example ArmoredBikini.esp ArmoredBikini.bsa Rule 3 explicitly adds *.BSA extension so it can't cause your error where Update.esm is treated like BSA archive. Check data for rules 1 and 2.