sheson

Actually this already happens for water1024.nif for medium/high. However the water in the screenshot is not a reference with a baselement / mesh. It is water defined in the cell record, which uses WATR records directly. The LOD for this water generated in the terrain LOD *btr files. LOD water always just uses one WATR defined for a worldspace. Technically the LOD water planes in the *btr files can be disabled (or just removed from LOD4 only) and replaced by dynamic LOD water meshes with animation and everything. Somebody would have to create those meshes so they match the look and reflection of the WATR though. They need to ACTI records with a nif and a link to the WATR. It could be as simple as creating a 4096x4096 version. I have yet not looked into that. In theory they could be done in static LOD as well - but I think that would be worse to the existing LOD water. I find that between Skyrim.ini settings and ENB water settings I never have THAT problem shown in the screenshot. May have to do with the fact that currently I do not use a water mod. I might get to this problem some day - after trees and ice/glaciers - when I do more testing about the bad occlusion culling that turns off large patches of the ocean from terrain LOD.

Ha, will update the ini filenames. Thanks. Yes, the vanilla trees are covered. However the _Static LOD8 *_flat_2.nif are replaced by the newer and better 'Billboards" instead. I just left the flat nifs in there in case something goes wrong with the automatic Billboard creation and for fallback. Eventually I want to get rid of them. Current fallback for TreeFullFallBack=0 will use whatever billboard, lod.nif, lod_0.nif, lod_1.nif, lod_2.nif is found first. So use Static LOD4, Billboard, Billboard. It is the better option and makes sure that LOD 8/16 always use the installed billboards and already match non-vanilla trees. I am currently working on a process to createnew 3D statics with 2D trunks for non vanilla trees for Static LOD4 as much a possible automatically.

The papyrus log will not report missing nifs. They are reported to TES5Edit_log.txt when DynDOLOD Worls.pas is generating LOD. You can enable debugging in game for DynDLOD as explained in the readme.txt. It will list all used nifs in the location and if an invalid or missing nif is causing the CTD it will be one of the last lines in papyrus log. Test with a new game, coc whiterun.

Yeah, current versions of LODGen are 1.0 beta x 0.8 is quite old

You need to check SKSE.ini heap memory settings with Memory Blocks Log not in Papyrus. Check ../TES5Edit/TES5Edit_log.txt for messages like 'Missing model "meshes\..\*.nif" - ignoring * [sTAT:xxxxxxxx] for dynamic LOD'

One off spring per user is quite enough

LODGen_log.txt shows "Skyrim Object LOD Generator v0.9" You didn't update xEdit incuding latest LODGen.exe. Check requirements for DynDOLOD / update post. Consequently it did not generate a single static object LOD *.bto file in the output folder in Meshes\Terrain\Tamriel\Objects\*.bto Log started at 9:38 [...] Error reading block textures\terrain\lodgen\skyrim.esm\tundradriftwood01_000b8f53.dds Log ended at 9:38

Screens look like the new LOD sources files from the DynDOLOD archive data folder are not installed. It seems it only has the vanilla source files to work with. Check the ../TES5Edit/TES5EDit_log.txt for something like: [00:00:00.570] Looking for LOD nif files in BSA archives and in E:\SteamLibrary\steamapps\common\Skyrim\Data\ [...] [00:00:16.735] Found 5097 LOD files for 3928 unique LOD objects If only vanilla+DLC LOD source are available it looks more like [00:00:03.489] Found 1025 LOD files for 629 unique LOD objects If it actually detected the additional 4000 LOD source files then make sure the entire output folder containing meshes/skse/textures was copied to the game/mod folder correctly. If all that is true, check in ../TES5Edit/LODGen_log.txt that LODGen.exe didn't end prematurely. Each "Log started at" should have an "Log ended at". It should have created 680 or more files in the output folder Meshes\Terrain\Tamriel\Objects\*.bto DynDOLOD is about tree and object LOD. Terrain/Water LOD is a third type of LOD. Use something like High Quality LODs or Skyrim High Definition LODs to improve the terrain between objects or generate terrain meshes and/or textures with Oscape.

And anybody else who has texture flicker with Glow LOD and ENB Sunrays. I could not verify the problem on my end so far - which could be as simple as not having a certain mod in the load order. Please download this version of ../TES5EDit/Edit Scripts/LODGen.exe to replace the existing version and generate static LOD again to test if the newer version solves the problem. You can update the existing static LOD *.bto files without having to worry about save game: Edit ../TES5EDIT/Edit Scripts/DynDOLOD/DynDOLOD_TES5.ini in notepad and change from Expert=0 to Expert=1 Then start TES5Edit and apply the script DynDOLOD World.pas as always. On the expert option window select the worldspace to update top left. This should automatically select the correct LODGen export file like ../TES5Edit/Edit Scripts/LODGen_Tamriel.txt - or select it manually with [...] button Once an existing export file has been selected, the "Execute LODGen.exe" button becomes enabled. Click the "Execute LODGen.exe" button to update the static LOD for the worldspace with the existing data. Plant a tree. Once it completed copy files from output path as before. Please let me know the outcome either way.

I suggest to use a mod manager to deal with the source files from the archive and the files generated to the output folder. Creating from scratch for a fresh install compared to creating from scratch for an existing install is the same so they require the same time!? You could open the existing DynDOLO.esp in xEdit and remove the entire worldspace added by a mod from it manually. If after "Clean Masters" that mod is still listed as a master, find and remove overwrite records from DynDOLOD.esp for this mod from Tree, Container, Door, Furniture, Light, Moveable Static and Static - then clean masters again. Do the clean save cycle. If certain type of records are removed from an esp there still needs to be a clean save to get rid of now orphaned persistent data in the save which will only happen if the belonging esp name is removed from load order. Generation from scratch is the safer course, because then you are certain no data from the removed mod is left in the esp. I am actually working/testing such an update functionality since a while now. However, as you can see, the whole story is a bit more complex. The only sane way to perform such updates is to disable things instead of removing if possible, only remove if absolutely necessary and update records that used the mods overwrite data to create a new overwrite for a 3rd mod. However, if the safest way for removing a mod is to disable its data instead of removing its data from DynDOLOD.esp, it also means there is unused data in the esp - which serves no purpose but just wasting space. If a clean save has to be performed anyways the whole exercise becomes futile.

The answer is still no

Let me guess: MO BSA management turned on... which means the BSA containing the mesh was not loaded by TES5Edit, because of the merge patch there was no esp of the same filename as the BSA to load it. Please let me know if that is the case, then I'll have to amend the FAQ answer with specific instructions for MO users...

I thought I fixed it all, but there is a report of this still happening. So I am looking into that.

A mod uses a model but is missing the nif. The mod is 17 hex or 23 decimal in your load order (0 = Skyrim.esm). It is a little bit weird that it didn't complain about the missing nif earlier. Can you tell me which mod it is? In xEdit right click in left pane, Other -> Build Reference Info. Wait for 'All done!' message. Load the record by entering the FormID 1700456F into the field top left, hit enter and check bottom for tab 'Referenced By'. If the tab is missing the nif is not used by any references and this error can be ignored. If it is used, you need to install the missing nif or else the game might CTD when the mod wants to use the nif. If it is not used by the mod try to fix my overly broad tree rule so DynDOLOD World.pas may hopefully skip over the nif: Click through to advanced, scroll down the mesh rule list to the bottom until you see the second to last "tree" rule Double click it and change "tree" to "\trees\", then OK to generate LOD. That *should* skip the object. Let me know the mod regardless so I can test myself.

Yes, Candles for sure, but it might also be FXGlow meshes - don't remember if LoS used those to light up the air around candles/lanterns. Window Glow is featured complete and works for all vanilla windows and whatever window from new LOD buildings included in DynDOLOD. Note that only "High" (= dynamic LOD) creates LOD windows that react correctly to weather/daylight. Not high adds them to static LOD - then they typically appear to be too white. Make sure to check the section DynDOLOD_Manual.html#11a and the ini setting because of decals.

Keep an eye on that co-save I guess.

Whatever lights/candles LoS switches on at night / off at dawn. This includes "Lights on Roads" and "Lights on Villages" (names from script so I hope this translates to some install option) If any of the lights/candles with timer from LoS are done as LOD the script patch will sync the LOD. You should be able to installed/remove the script at any time (be in interior) - like when a user see a light fro LoS in the distance that should be off at day -> install patch. A user asked me for this patch last year so i included it. Kinda wrong forum :) You seem to be confusing available DirectX9 memory with the memory patch and memory blocks log. Those are 2 different things. There is no need to use SSME when using SKSE.ini to do the memory patch. Uninstall SSME. If MemoryBlocksLog shows Block1 Block2 256MB 256MB then move the SKSE.ini from mod organizer/mods/skse scripts/skse/skse.ini to the real physical game folder .../skrim/data/skse/skse.ini. Maybe need to use forcesteamloader or execute as admin skse_loader.exe Do not change ScrapHeapSizeMB=256 Set DefaultHeapInitialAllocMB= to a number +256 slightly higher then the max number reached in MemoryBlocksLog.log. Change in memoryblockslog.ini the DefaultLogLocation=false, so log ends up in physical game folder and not in MOs overwrite. The 4064 VRAM limit happens because you are using a crippled Spyware OS called Windows 8 or Windows 10. DirectX9 can only use VRAM > 4GB under Windows 7.

Can you replicate the problem when starting a new game? You starting form the save 302 you sent me right? Applies to trying to run the script with FO4Edit.exe instead of TE5Edit.exe... I used DynDOLOD Words.pas to create an esp with updated base records with additional LOD objects (LOD source files shipped with game, unused in the static LOD) for FO4LODGen... experimental and thus disabled

Correct. Sounds all good on your end. No worries i am just making extra sure.

Thx, I probably missed a mesh that needs updating or could also be a 3rd party mesh being used. Please double check all source meshes were replaced with the new ones - just want to make sure...

If using MO I would install the data folder from the 1.47 archive into a new mod. Call it DynDOLOD Source 1.47 for example. Sort it after the current DynDOLOD source files. If you have both old and new source file mods activated, the result is like merging or overwriting. Use MOs "hide" function to hide the esp/meshes/texture folder of the new DynDLOD Source 1.47 mod and the result is only the papyrus scripts are updated. When the day comes to generate from scratch you can just disable the old source and unhide the new files/folders and it will only use the new source files. The current generated output with the generated DynDOLOD.esp always needs to be after both DynDOLOD source mods. Does it also go away when you disable sun rays in ENB? I will try to replicate and see what I find, maybe I missed a source file that needs fixing. For it to be fixed in existing games one needs to replace (if from scratch) or overwrite (if updating) the source meshes with the new ones from the archive and generate static LOD again. Just saying this for other people since you did that. PapyrusUtils 3.1 or 3.2 both work. I am a bit reluctant to write "or higher" because a new version might deprecate things and I am still a bit unsure about 3.2s general stability. No of course not. xEdit is used to create the patch. It is not used for normal game operation. There is a space between : and ", you need to remove that. -o:"C:\output"

Yes, very satisfying to see the immediate effect of adding that feature to the process. One more PITA gone because of the valuable user feedback like yours giving me ideas how to improve the process.

Yes of course, they are very simple mods with only a handful of records. Its best to do after creating LOD. Only add/merge the WhiterunExterior afterwards.

The instructions are different because of different types of update scenarios. The first steps are always the same: deactivate DynDOLOD in the MCM (only possible if outside), go into an interior, check MCM is still deactivated, save, exit game. a) If you only want to update the papyrus scripts, overwrite them now. You can update the existing DynDLOD.esp with DynDLOD World.pas at this point in case you added new mods. There is no need to update the DynDOLOD.esp just because of this update. Once done, start the game and load the last save, go outside, activate from MCM. b) If you want to generate a new DynDLOD.esp from scratch, you first deactivate the old esp, start the game without esp, load the save, wait, save, exit. This is now the clean save. Now generate LOD from scratch. Once done, start the game with the new esp and load the last save, go outside, activate from MCM. As you can see the extra step of starting the game without the esp and saving are only needed when creating a new DynDOLOD from scratch. BTW the manual even mentions the difference to the video: "While the tutorial video explains the safest way to update an existing game, there may be no need to redo the whole DynDOLOD.esp from scratch. You can try the following option first and only in case of undesired results start from scratch." The processes and consequently the manual have been updated and refined since the videos were created. At any time can static and tree LOD be generated without having to worry about existing save games. Backup the existing esp and skse folder with json files to a save location. Then do a generation from scratch to create static and tree LOD, disable "Generate DynDOLOD" form the advance menu to save time and not create json files. Once the process is completed do not save the esp. Delete the skse folder in output folder if there is one and only copy the new meshes/texture back to the game. Restore esp and skse from save location. Enjoy updated static / tree LOD. Result should be visually fine 99% of the time.

STEP includes all the updated correct LOD and billboard textures already. However, do not confuse billboards with LOD textures. Generally they are the same thing... dds files, but billboards are for tree LOD - which is different from static 3D LOD. TexGen generates texture for 3D static LOD but not billboards for tree LOD. Billboards are created by splitting existing tree LOD atlas textures or create them from scratch by taking a screenshot from a render view for example. You most likely do not have to worry about the textures at all for you changes - unless you deviate from the STEP setup and install additional tree mods.