sheson

The service Nexus uses, there was always one scanner that flagged each beta versions until it suddenly stopped flagging for no apparent reason. Do not trust me (the development VM or libs I use could potentially be infected without me noticing), trust the multiscanner. For example, upcoming DynDOLOD.exe 2.14 - no flag from Kaspersky, but McAffee

LOL, nicht nur auf einen scanner vertrauen, einfach mal mit mehreren testen so wie es Nexus tut ;)

See if this helps DynDOLOD supports updating an existing esp as explained in the manual. Load the current load order with the current esp, then merge/overwrite the mod with the files from the output. Type tll in console. What you see now is loaded cells. the stuff that went missing is LOD. Whiterun uses the LOD of Tamriel worldspace and simply superimposes its own cells over the cells of Tamriel. If you see stuff that has LOD but is not in the loaded cells, it was deliberately not added by Bethesda for performance reasons. I created Whiterun Exterior on user request to add the most obvious missing buildings. Adding more and more of the missing objects like landscape features is possible but will affect performance more and more. uGridsToLoad affects LOD indirectly by defining the distance where LOD starts. fTreesMidLODSwitchDist, fMeshLODLevelXFadeDist, fMeshLODLevelXFadeTreeDistance, fLODFadeOutMultObjects, fLODFadeOutMultItems, fDecalLODX, fMeshLODFadePercentDefault, fMeshLODFadeBoundDefault are all settings affecting detail on or of full models in loaded cells.

Just leave it for now and skip the worldspace while I have a look at the mod. You can later update the existing esp once I have a fix for that. OK now we are on to something. Something must have gone weird when that patch was created. You used merge plugin that writes the map text files? It should be read by DynDOLOD.exe to know about the merge so it can apply rules intended for the single esp to the the merge esp. To generate LOD without the bridge just deselect that esp before loading DynDOLOD.exe and generating LOD and then things should be fine. This reportedly can happen with 2.x after save before exit, but I could not replicate this so far. Since everything is done successfully by that time we are not overly concerned about it.

Unfortunately nothing sticks out in the error check that would explain the problem. 2.13 just fixes the read error for the missing file so it should run through. But Solstheim will then have no tree/object LOD generated and fall back to vanilla LOD. This is most likely what happened with versions The first log you posted has a line that says Filtering 0 references in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] for LOD which obviously is wrong. It should rather log something like Filtering 17548 references in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] for LOD After you opened your load order in xEdit.exe, type the form ID 04000800 into the field top left and hit enter. This will open the Solstheim World record. Maybe you could screenshot the right window that will show a bunch of mods changing the worldspace records. I am especially interested of the mods to the most right In the left window, click the little [+] to the left of 04000800 | DLC2SolstheimWorld to unfold its children, you should see a Cell and a list of Blocks, Click [+] 040142EC Cell, [+] Persistent and it should show a long list of references in left window Do the same for a bunch of Blocks. Subblocks. I am wondering if it will throw some kind of an error message, though I think it should have done that when error checking already If you cleaned Dragonborn.esm, you could try to restore the original backup and see if DynDOLOD works with it. If that works, redo the cleaning.

Whatever you see in the distance is Tamriel LOD. The cities (excluding Markarth) are child worlds that use the parent world LOD, regardless if objects were added to child world cells. Looks like something is causing a problem with Solstheim World so it can not read any data /references from it. Open the load order in xEdit.exe and find the worldspace, usually form id 04000800 check if you can unfold it, including the block 0,0 and deeper. Check entire load order for error in xEdit.exe maybe something shows. See if it works if you only generate for Solstheim.

Nexus being Nexus I guess. Fixed - it now is called DynDOLOD Standalone 2.12

I doubt Bethesda left the area empty by accident but fully intentional for performance reasons. Every additional object affects performance. It is not clear what buildings you seem to be missing. All the missing vanilla buildings are added by Whiterun Exterior. If you use a mod that adds buildings to the exterior you should ask the mod author to make them visible from the inside.

It doesn't matter, since you are not going to generate the Tamriel worldspace or the city worldspaces in step 3. Realistically it will be very though to load the current load order with the existing DynDOLOD.esp from step 2 without OCS, though.

I've updated low/medium/high rules for Legacy of the Dragonborn. You need to overwrite the rules shipping with the mod in the Skyrim/data/DynDOLOD/*.ini folder (or Legacy mod folder of MO) Those files take precedence over any rule files in ..\DynDOLOD\Edit Scripts\DynDOLOD\rules\*.ini, which might be the reason why adding the door didn't work in your case. Both the door and the stairs are included now. I've also send the updated rules to icecreamassassin to include in the next update of Legcay, but I figured it may be a bit until that happens.

By default that bridge should not have any dynamic LOD, only static LOD. Check if a mod changes the reference (of the full bridge) or the base record. also bring up the DynDOLOD form id for the LOD version of the brdige and check its Editor ID which will tell us the original modname_formid. Maybe it is not Skyrim.esm anymore for some reason. Let me know if you need more detail explaining the steps.

Make sure to install all DynDOLOD Resource core files, including the papyrus scripts. Make sure to install SKSE, SkyUI and PapyrusUtil. Make sure to copy all files from the output folder into a mod/data folder after the generation, including the esp and the meshes/skse/texture folder. Most likely the clean save update went wrong. Test if it happens when starting a new game with coc whiterun from console in main menu. If the problem is gone then, make sure to do a clean save as explained in the update post/manual before introducing the new esp.

Check in xEdit if a mod changes the base records 000487e7 and 000487e8 or the references 0004e7be and 000ce81d If that is not the case, check ..\DynDOLOD\Edit Scripts\Export\LODGen_Blackreach.txt for lines like MountainPeak01 or MountainPeak02 that should look like 0004E7BE 04008000 8118.145508 16921.089844 9796.507812 180.0000 0.0000 70.0381 1.0 MountainPeak02_Blackreach 00038800 meshes\landscape\mountains\mountainpeak02.nif meshes\lod\mountains\mountainpeak02_lod_0l.nif meshes\lod\mountains\mountainpeak02_lod_1.nif meshes\lod\mountains\mountainpeak02_lod_2.nif 000CE81D 00008000 6246.502441 20009.597656 5755.744629 182.0536 358.5899 177.0209 1.0 MountainPeak01_Blackreach 00038800 meshes\landscape\mountains\mountainpeak01.nif meshes\lod\mountains\mountainpeak01_lod_0l.nif meshes\lod\mountains\mountainpeak01_lod_1.nif meshes\lod\mountains\mountainpeak01_lod_2.nif

Setting doors for Full Model static LOD can be problematic because they can be open or closed... and typically they are opened by default. Or LODGen.exe just fails to read the correct data from the animated nif. I just added something to upcoming 2.12 that will ensure doors are closed/open properly when they are done as dynamic LOD. I am afraid though that won't help for the first screenshot as you may be too far away for the default 21 Far Grid distance. You could try setting all the static LOD entries to empty and use Never Fade Full. But with 2.11 the door might always be in open state. The best solution would be to create a simple true static LOD model of that door. I am currently finishing testing a couple new functions to LODGen.exe and will include Legacy in the testing to see what can be done about this particular case.

This is how updating and merging works. Merging means overwriting all existing files.

Do it like this for now 1. Generate static/tree LOD for Tamriel without Open Cities, move output to mod 2. Generate dynamic LOD for Tamriel with Open Cities, merge output to mod 3. Generate static/tree/dynamic for all other worldspaces but not for Tamriel, merge output to mod

As always I will answer this generally because DynDOLOD uses the TES5LODGen for trees LOD generation and relies on the user to choose and install 3rd party billboards for the load order. DynDOLOD uses the billboards which are currently installed in the load order. If the billboards do not match the full tree very well then... ... if the difference is just too dark/too bright use the tree LOD brightness drop down in the advanced menu ... the billboards might be just that bad/good. Find better matching ones for the mod or create your own ... the billboards might be out of order if you use several different tree mods Open the full tree model.nif in nifskope and compare to the billboard.dds - the ..\DynDOLOD\Logs\TES5Edit_log.txt prints lines like TreeAspen01 [TREE:0006A9E6] using LOD Textures\Terrain\LODGen\Skyrim.esm\TreeAspen01_0006A9E6.dds which tells you exactly which files to check. Especially for older mods the available 3rd party billboards are usually just made by splitting the existing tree LOD texture atlas from that mod. The quality varies a lot. Only recently have mod authors created much better looking/matching billboards now that better tools and knowledge is available. Keep in mind that billboards are always a one-sided/flat representation of a 3D tree. Only one specific viewing angle will truly match the full model. However due to the flat nature of tree LOD, lighting is always different.

LODGen_Blackreach_log.txt ends with a line "Log ended at xx:xx:xx"? Check the file ..\DynDOLOD\Edit Scripts\Export\LODGen_Blackreach.txt with 'low' options it should have over 1000 lines with 'medium' options it should have over 1200 lines with 'high' options it should have over 1600 lines Though it could be one single missing LOD mesh so that will be harder to spot. Upload your LODGen_Blackreach.txt if you like, I can try to compare. There should be 13 files in ..\Data\Meshes\Terrain\blackreach\Objects\*.bto What generation options did you use? Can you also double check that this is missing LOD. Go to a location and looks at missing ceiling. Open console. Type sw 15e. Wait for fog to clear. Take 1st screenshot, Save the game. Exit game. Hide \Data\Meshes\Terrain\blackreach\Objects\ folder so it falls back to vanilla. Start game. Load save. Take 2nd screenshot.

Do the third pass with loading the existing DynDOLO.esp after you installed everything from the output folder to a mod. Then load existing esp and generate all types of LODs just for these two worlds. Then merge output folder with mod again. The worst that can happen is that textures of LOD do not match. If the textures TexGen uses between profiles are the same then it should be no problem. Most LOD uses the texture atlas created by DynDOLOD.exe from the from the single texture TexGen generates. However, there may be few LOD objects here or there that use the single LOD textures as well. If you do not see any obvious texture mismatch then all is fine. Verify DynDOLOD Resources core files are completely installed Verify ..\DynDOLOD\Logs\TES5Edit_log.txt contains a line Background Loader: [skyrim - Meshes.bsa] Loading Resources Check ..\DynDOLOD\Logs\TES5Edit_log.txt for missing nif messages or other error messages Check ..\DynDOLOD\Logs\LODGen_Blackreach_log.txt for error messages

Ha!

Looks like you have a messed up ini/game/save where static object LOD does not unload in loaded cells. Does it go away when you tll in console? Does it happen when you coc whiterun from main menu?

You found it while I was writing my answer. Nice ninja :) No worries.

I put spoilers around that log. The log does not mention any of the .bsa from the archive lines. Most likely reason is that the tag in the default ini is [Archive] without the "s"

You shouldn't. On a general note, the manual explains how to split existing tree LOD atlas into billboards.

Will be fixed next version, see this post