sheson

There is nothing wrong with a reviewer being compensated for his work of creating a review for whatever it is he is reviewing.

1.14 Added no particles version for many of the full models used for dynamic LOD. Should generally mean better performance. Specifically disables objects when leaving their world space to further reduce resource usage more quickly. Both updates address and fix the particle fire problem report by Neovalen Ignore mods authored by "BASHED PATCH" Technially not required but grab the latest xEdit svn 1943 from https://www.afkmods.com/index.php?/topic/3750-wipz-tes5edit/ to get the the newest version of LODGen.exe I updated it as well. I rewrote the "remove unseen faces" routines which removes all data below water/land. The effect is that static LOD files will be a bit smaller than before. It will remove an additional 10% to 20% compared to the old routines. Removing unseen faces is active by default when generating through DynDOLOD. So if generated static LOD so far was around 900MB with older versions of LODGen.exe you can expect it to be around 750MB now. Most importantly it means loading less data while moving around. While I didn't check default LOD for Skyrim, generating LOD for FNV is now 25%-30% less than its default :)

I require blood sacrifice

Not cool dude, I am pretty sure you owe him to me. Keep the wife.

Start TES5Edit and apply script It should then find all required source dds and _n.dds in bsa and as loose files from load order It then copies the found textures to a temp folder in -:output to avoid any trouble with MO It needs to do this step because it has to rename a few _n.dds because the image tool in TES5Edit auto expects _n.dds names to be the same as the .dds name Then the content of the temp folder in -: output is copied to game path, because the image tool in TES5Edit only accepts relative paths in game path. It then builds mini atlases to -o: output folder It then removes all temp files and folders. Does the script fail at any point with an error? Just post the log.

If LODGen.exe does not complete successfully it means the static LOD wont be complete. You maybe have OK static LOD from earlier runs though. See if ..\TES5Edit\LODGen_log.txt has more info, but if it crashes chances are slim it could write to the log. Next time try to copy/screenshot the messages from the cmd window The most common reason for a crash is writing to a directory that is part of MO VFS, like the overwrite folder.

No worries, it wont be *just* for you. Its general thing :) I don't know if you should but you sure can. It would help to discover problems if there are any. Since all other worlds are a magnitude quicker there is technical reason not to. Visually, I really only test with Tamriel, Solstheim. Sometimes with Hunterworld, Vale, Falskaar and Wyrmstooth

1) It only shows now that you generated tree LOD. My bet is on TAVE - Whiterun Remove it from load order when generating tree LOD. You can enable it again for the game later. I will add that mod to my list of mods to check. It this one https://www.nexusmods.com/skyrim/mods/19799/, correct? 2) that's really advanced stuff, leave that for later it is not throughly documented yet I need a to create a list of cells that are walled town LOD area, then I can automate tree LOD for that. It will happen eventually :)

Interesting observation. Try one more time with new game. These changes never work reliable for me when loading save games... Not to worry though, using non particle versions for LOD fixes that issue for me. Also I do have success specifically disabling LOD objects after leaving the world - which seems redundant to me, but hey whatever works. Both updates will be in the next update.

The json files need to be the ones matching to the generated DynDOLOD.esp. They need to be copied into from the output path to the game folder, just as meshes and textures. This is a simple file reading error or the json data is not formatted right or the data in the json doesn't match the data in the DynDOLOD.esp. If you are sure you coped the right files and they were generated at the same time as the DynDOLOD.esp you are using, I can have a look. upload all json filres and the esp somewhere for me to check. This is an engine limitation. A mod added trees into the walled LOD city in the Tamriel worldspace. What Zilav said :) Edit: I believe this happens because the engine first starts processing the interior objects before removing the exterior objects from memory. If you disable/enable the interior fire it works all right for me. If raising particles is not an option change mesh rules for small fire 01burning and/or large 01landburning to "Near LOD" or remove completely. I will see if I can create dynamic LOD versions of these and some other objects with less particles. Just like I did for waterfalls.

1) If the esp is active when generating LOD it will be needed in game later as well. So disable the esp or unselect it in TES5Edit at start up but keep the meshes active in the load order. 2) DLC billbords are included in the Skyrim billboards. Sorry that wasn't clear. I updated the byline of the download. You should be all covered. 3) The quickstart.html in the root of the DynDOLOD archive is a step-by-step instruction. Down to the bare minimum and so they are hopefully not confusing instructions :) Don't worry about asking. These are all valid questions :)

I will update the note next to SMIM

To get your head around it more easily consider that this whole thing is a combined process of 3 different tools for 3 different LODs now. Tree LOD, static LOD, dynamic LOD The good news is, that you do not need to split tree LOD atlas into billboards if there exist billboard downloads for your setup at https://www.nexusmods.com/skyrim/mods/62698/ Which is the case for SFO 1.87. I suggest to start with the quickstart.html and wizard mode video to get the gist of it. If you do not intend to use SkyFalls/Mills anymore remove it from load order before starting TES5Edit and generating any LOD.

If SkyFalls esp is still active its distant waterfalls will be used. Which have z problems. If SkyMills windmill fan meshes are in the load order, DynDOLOD Worlds.pas will find them and use them. Regardless of SkyFalls esp still active or not. It will do it all automatically. The only manual thing to do is copy results from output folder. If using MO then the temp in overwrite folder needs to be deleted manually. Use the interior save. Load it without any DynDOLOD esp. Wait a bit. Then save it. Then load this second new save with new DynDOLOD.esp active. If that doesn't work, clean all DynDOLOD scripts from the second interior save with a save game cleaner before using it with new DynDOLOD.esp Thanks, will update manual

Yeah the hands on approach still works best of course :) Doing the red sail for the non SkyMills SMIM is not as simple. By default the rotor is part of the whole building. And SMIM vanilla keeps the 2 together as well. No idea why Bethesda did it this way, while all other windmill fans use separate meshes for the building and fans. SkyMills splits the Solitude rotor into its own that mesh, so it is easier to tie into the SMIM update for SkyMills and keep the red version. The way I see it, almost everyone uses the larger SkyMills fans anyways. I think there is a sentence in the manual that mentions that, but is most likely not very specific about the correct path and filenames. If you remember what you did maybe you can write couple sentence update for me to include :)

mod files names are everything because they are usually the only way to uniquely determine the source of records. It only matters for the few cases when having to address knowns things directly. That includes NOT doing certain things sometimes. Merge lists usually do not interfere with potential LOD objects in the world. It most likely only happens when having to copy world cell records that hold said objects. The normal operations just looks at mesh names and typical settings. All _lod*.nif that are found anywhere in the loaded resources *.bsa and meshes directory are used, including the default ones that I haven't updated.

Good idea, I will use that for some "logic" for some messages or something anything is better than some obscure error from TES5Edit :)

DynDOLOD does not support SMIM small sails Solitude option. I never said it would :) Nobody installs the small sails option, right? All your other troubles sound like updating a save game went wrong. Did you test with new game? Please only report problems regarding latest version. Hmm, DynDOLOD Worlds.pas tries to ignore mods with the name containing "Bashed Patch". However, if something uses it as master things will do god knows what. You think it should warn to remove "Bashed Patch" esp from load order instead of silently trying to hope it works? On second thought, I might be able to throw a warning if something uses a "ignored" master mod.

1.10 fixes the h LOD Mesh problem from steveowashere, hopefully print out a nice info message without further interruption fixes the empty master from hallowieners uses the red sails version for the Solitude windmill from SMIM when installing SMIM with the SkyMills option, so Ilkob is happy :) @EssArrBee and anybody else who wants to dive into LOD textures, check out DynDOLOD TexGen.pas. It has a lot of info at the top of script that should get you started. give it a minute to settle, was just updating :)

That mod is fine. It is actually not directly defining the h mesh, but rather adding a new combination with heavy snow settings that make DynDOLOD World pas believe there should be the h version of that LOD Mesh. It should look OK falling back to the l version - which the next DynDOLOD version will do. Once it is is out, see if you you can spot a message about it in the log with a MOD name.

There must be a mod that defines that LOD mesh to a base element without providing the LOD mesh. I will add a fail check to the next DynDOLOD version. It should be able to report the esp that adds it.

But back before you used the same profile when running TES5LODGen and TES5Edit? Maybe you can compare the old profile files to the new ones and spot the difference. They are in ..\ModOrganizer\profiles\[profile name]

We If the same LODGen.exe version once works and once doesn't, while the both DataPath= and Resource= are the same same the problem must be something else. Since TES5LODGen.exe is just a renamed TES5Edit.exe try that next. Copy 1937 TES5Edit.exe to TES5LODGen.exe and see if it then still works. If it does, double check the start options inside MO of TES5LODGen.exe and TES5Edit.exe are the same. Also search ..\ModOrganizer\logs\ logs for the name of the reported nif and Skyrim - Meshes.bsa

This is really odd :) Try using the slightly older LODGen.exe from TES5LODGen. Just copy D:\Skyrim\TES5LODGen 3.1.1 r1915-62698-3-1-1\Edit Scripts\LODGen.exe to D:\Skyrim\TES5Edit_r1937\Edit Scripts\LODGen.exe Backup D:\Skyrim\TES5Edit_r1937\Edit Scripts\LODGen.exe first (or just get it out of the 1937 download again later) Next try the opposite, copy the 1937 LODGen.exe to the TES5LOdGen Edit scripts, see if it still works. If this also makes no difference make sure to check MOs logs for the reported missing file. Maybe it provides clues.

Assuming you are are trying to generate LOD for Tamriel. If other world look up export file from TES5Edit_log.txt log file line starting with "Saving objects LOD data ..." Find LODGen export file from DynDOLOD World.pas TES5Edit\Edit Scripts\LODGen_Tamriel.txt and compare with LODGen export file from TES5LODGen - which is always the same regardless of world TES5Edit\Edit Scripts\LODGen.txt Compare values for PathData= path to game folder, something like ..\steamapps\common\Skyrim\Data\ Resource= several of theses listing all bsa files, needs to have one ..\steamapps\common\Skyrim\Data\Skyrim - Meshes.bsa Let me know if they are different