sheson

Billboards are texture dds file. They do not have esp plugin files. Typically the installation order defines the overwrite order. Refer to the manual of the mod manager tool for how to change the overwrite order of loose texture files. The Gamerpoets video covers this for NMM If problem persists, post error report with contents of ..\DynDOLOD\logs\TES5Edit_log.txt of the last session from "[00:00:00.000] DynDOLOD based on xEdit starting session ..." to the end.

I am pretty sure you are following a video from Gamerpoets and not Gopher From the log all seems in order with the BSAs loading. The texture frozenmarshice01 is in Skyrim - Textures.bsa which is listed as being loaded. The file may be corrupted. You could try to delete it and then validate the game in steam to have it download a fresh copy.

The screenshot shows it copied the Form ID correctly. However something went wrong with the load order form id or the Master Files table in DynDOLOD.esp It almost looks like you or something else removed masters from the Master Files list after the data was copied and now the 0F of the form ID points to an empty or wrong entry. xEdit would complain right away about this error when it tries to add the record, so it might have happened afterwards. Position 0F hex of the Master Files list in DynDOLOD.esp needs to contain the filename for the BDS esp. I could imagine an error in a plugin causing this. Load all plugins in xEdit.exe and check for errors. Otherwise I have no idea yet how that error could even happen when records are copied without the process throwing error messages and stopping right the moment it copied/created data with that error. If you are certain no plugins have errors, that there are no errors in the log, e.g. the process completed successfully and you didn't edit DynDOLOD.esp in xEdit, you could try commenting out the lines 611 to 613 in ..\DynDOLOD\Edit Scripts\DynDOLOD Worlds.pas by inserting // in front of them // if not Settings.bUpdateDDOL then // CleanMasters(NEWFILE); // SortMasters(NEWFILE); Those commands update the Master Files list, right before the end of the process. Then generate from scratch again. It is the only think related to the problem I can think of right now.

LODGen.exe is started once for each worldspace. So the one that crashed did fully generate static LOD for one worldspace. Whatever parts it did not create will still have vanilla LOD. If you check the logfiles in ..\DynDOLOD\Logs\LODGen_*_log.txt you can find out which worldspace did not complete. Each successful one ends with "Log ended at [hh:mm:ss]". This line will be missing from the one. You can try running only LODGen.exe for this worldspace again and see if it runs through this time - or catch the error message at least. Set Expert=1 in '..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5.ini' Start DynDOLOD.exe. Select the world for which to generate for. This defines the export filename for LODGen.exe. Click the button "Execute LODGen.exe"

Are you saying that overwrites in DynDOLOD.esp for base records did not copy the DNAM \ Material from the last overwrite? Can you post a screenshot of such a record? Or any other where data from the last overwrite did not make it into DynDOLOD.esp. It would be very unusual for the native xEdit deepcopy function to ignore data. Are you sure there was no existing DynDOLOD.esp in the load order in which those records already existed? Check all plugins for errors in xEdit. What you are describing is not normal at all. There would be lots of posts from users seeing weird things happening in their game.

There may be a setting to make the radius larger when using larger uGrids, but I do not remember it. I haven't done higher uGrids in ages.

It affects how long the fading algorithm takes to blend terrain LOD to full texture when moving a row of cells ahead. To test its effects, turn off grass (set distance really low). Then use tcl and speedrun. Then set fLandLOFadeSeconds=1 and do it again. The blending now happens much quicker and should be much more obvious.

Install the required DynDLOD Resources - Core Files before generating LOD. It contains a fixed and better looking version of that tower. The screenshot shows the bugged vanilla version. Make sure no other mod is overwriting the LOD core files. This is the file ..\Meshes\lod\solitude\sbardscollegetower_lod.nif

Yup the full ground textures blend to the terrain LOD textures in a circle around the NPC. unlike the grass shader the circle does not move with the NPC, but just seems to center around the center cells of the 5x5 uGrid. There maybe a setting to make it larger, but I don't know/remeber one (most ini settings affecting terrain LOD need a restart of the game unlike other settings that can be changed live from console, so testing takes more time) I know from top of my head that you can change the fade time by changing in Skyrim.ini [Display] fLandLOFadeSeconds=15 the missing D of LOD is why I remeber that one :)

This looks like you are using the MO 2.x alpha version. I believe this error is already reported to the MO bugtracker. Use the current MO 1.3.11 instead.

That is great that it works and we figured out the cause. I am wondering what program/version do you use to extract the archive?

thanks for the log. It shows the two crucial files are not copied when they should be. Can you check the contents of the file C:\Games\Skyrim Apps\DynDOLOD-59721-2-18\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5_TexGen_copy_dawnguardesm.txt It should be // wbBuildAtlasFromAtlasMap expects _n.dds with same filename as dds, create the missig ones textures\dlc01\dungeons\castle\castlewallstone03_n.dds,textures\dlc01\dungeons\castle\castlewallstone05_n.dds textures\dlc01\soulcairn\bwallbase_n.dds,textures\dlc01\soulcairn\bwallbasegray_n.dds Or compare to download archive. Reinstall from archive and see if it fixes the issue.

Please replace ..\DynDOLOD\Edit Scripts\DynDOLOD TexGen.pas with this version and then post the end of the log it produces. It should look something like this [00:00:00.270] Processing C:\Skyrim\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5_TexGen_copy_dawnguardesm.txt [00:00:00.282] Copying textures\dlc01\dungeons\castle\castlewallstone03_n.dds to C:\Skyrim\DynDOLOD\TexGen_Output\DynDOLOD-temp\textures\dlc01\dungeons\castle\castlewallstone05_n.dds [00:00:00.296] Copying textures\dlc01\soulcairn\bwallbase_n.dds to C:\Skyrim\DynDOLOD\TexGen_Output\DynDOLOD-temp\textures\dlc01\soulcairn\bwallbasegray_n.dds but then probably write error messages that there were problems and then fail again and the same location later Could you then try a second run with a different/shorter ouput path just like c:\output for example.

Both castlewallstone05_n.dds and bwallbasegray_n.dds are created in the output path when the log writes "Creating some temporary files" and then "Processing C:\Games\Skyrim Apps\DynDOLOD-59721-2-18\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5_TexGen_copy_dawnguardesm.txt" Since it is not complaining about the source files textures\dlc01\dungeons\castle\castlewallstone03_n.dds and textures\dlc01\soulcairn\bwallbase_n.dds it needs to create them, it seems something goes wrong when it tries to write the new files. So, after TexGen.exe stops with the error, check if these files exist C:\Games\Skyrim Apps\DynDOLOD-59721-2-18\DynDOLOD\TexGen_Output\DynDOLOD-temp\textures\dlc01\dungeons\castle\castlewallstone05_n.dds C:\Games\Skyrim Apps\DynDOLOD-59721-2-18\DynDOLOD\TexGen_Output\DynDOLOD-temp\textures\dlc01\soulcairn\bwallbasegray_n.dds and let me know if they are, or if directories exists but are empty. Based on the outcome we continue the troubleshooting.

No workaround is needed if doing everything properly according to the manual. It would be better to fix the true cause.

Post the entire log from that TexGen run from start to end ..\DynDOLOD\Logs\TES5Edit_log.txt castlewallstone05_n.dds does not exist. A copy is made at run time from castlewallstone03_n.dds which exists in Dawnguard.bsa or one of the Hi-Res bsa.

You probably want to reinstall SolitudeExterior.esp from DynDOLOD Resources. I just double checked with xEdit. It has no such errors. Then load pre-merge load order into xEdit and check the reported cell records for which mod changes the XCLR records. Make sure Skyrim.esm is not the one from Enderal.

Just note, that there are always tree base records that typically nobody ever creates billboards for, like shrubs and bushes. To verify exactly which trees you are missing billboards for, install Mfg console, then in the game go close to a tree with missing LOD, open console and click the tree. Then check the "baseID" (the base record form ID) and "mod" (the plugin name) info on the right site. Together with the generation log you should be able to identify exactly which billboards are missing. With that info you should be able to follow up on the forum/thread for the tree mod.

DynDOLOD uses TES5LODGen to generate tree LOD. It requires that each base record of a tree that you want tree LOD for needs a billboard installed at the correct path/filename. If a type of tree doesn't get tree LOD it is a file not found problem. The ..\DynDOLOD\Logs\TES5Edit_log.txt prints a list of billboards it seeks/finds when generating tree LOD for a worldspace. For example: No billboard found at the path/filename for this tree (which is normal for this example) A billboard was found at path/fiename for this tree TreeAspen01 [TREE:0006A9E6] using LOD Textures\Terrain\LODGen\Skyrim.esm\TreeAspen01_0006A9E6.dds As you can see the plugin, form ID and full model nif filename minus the extension of the tree base record are part of the path/filename. If any of it changes for a tree base record, copy/rename the billboard to the correct path/filename. If a billboard does not exist at all, it needs to be created.

Read the FAQ Skyrim: ILS or CTD. So, for all the rest, to put it nicely, I suggest to stop messing around doing random and unrelated things and rather follow installation guides like STEP that teach how to setup the game with SKSE, Memory Patch or crash fixes OSAllocators, ENBoost, correct INIs and how to install mods while learning about RAM/VRAM limits. For example, the ini settings you quoted have nothing, really absolutely nothing to do with the type of LOD DynDOLOD is doing. Follow proper modding and troubleshooting procedures, always do these tests with new games until everything works. DynDOLOD in the game is a very simple mod. It needs RAM/VRAM and it needs valid nifs that exist. It needs all the files and data that was generated by DynDOLOD.exe in the correct location and intact. Whatever other problems you have with NPCs, dark textures, missing files or problems with armor textures are unrelated to DynDOLOD and are most likely mod installation/uninstallation/load order errors.

What is the issue?

From the manual Updating There is no need to generate LOD just because a new mod was added. New objects may be missing LOD, but that is only a visual problem. Generating LOD Tip: If the load order changes often, consider generating LOD only for the base install of Skyrim Legendary and only the mods which are considered essential. There is no technical requirement to update LOD just because a mod was added. The worst that can happen is that LOD is missing for new objects. This will make it easier to remove non essential mods from the load order without having to generate LOD from scratch.

Are you using MO? Which version? What is the installation path of DynDOLOD.exe. What is the games installation path? Is there a ..\SteamLibrary\SteamApps\common\skyrim\Data\TES5Edit Backups\ folder?

I just tested high + ultra tree generations with vanilla trees and then two EVT setups, one with and one without the included RAT trees. All three generations worked without a problem in 2.18. All generations have hybrids for all trees in LOD4 and use the installed billboards for LOD 8/16 as expected. As expected the TES5Edit_log.txt showed no tree fallback messages when scanning base records since all trees have hybrids, so the fix doesn't matter. The generation of the flat texture atlas showed the usual suspects for tree billboards normal maps, which is an indicator billboards have been installed correctly and are being used. The log LODGen_Tamriel_log.txt for LODGen.exe shows static LOD was generated without error. Everything appears to be working fine on my end. Make sure to install the tree LOD resources from EVT correctly, exactly matching the full model setup.

2.18 is a minor update that creates the same LOD and data. Test with a new game and if that works correctly, make sure to follow the save game update routine. If you fast traveled and have such LOD issue, turn on autosave on fast travel. If you use crash fixes MSAllocators with the custom memory verify in console that it is not filling 100%. I also read reports that fast travel into cities can sometimes put the player outside the walls in the child worldspace.