sheson

DynDOLOD is packed the same since 5 years. The top level of the archive contains the DynDOLOD folder. The Installation instructions say Unpack the DynDOLOD Standalone archive into a new 'DynDOLOD' directory that is outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game or any mod manager folders. I figured people have enough common sense that they do not need the overly wordy older instructions from the 2.x version anymore. From the DynDOLOD Standalone archive copy the content of the 'DynDOLOD' folder, which contains the files DynDOLOD.exe, TexGen.exe, DynDOLOD_QuickStart.html and the sub folders 'Docs' and 'Edit Scripts' with all their content into a new 'DynDOLOD' folder outside of special OS folders like 'Programs Files' or 'Program Files (x86)', the SteamApps or game folders and Mod Organizers virtual file structure. Do not mix with old versions or xEdit/xLODGen installation.

Mesh rules take priority over the base record LOD assignments unless the "use original LOD assignment" is checked. It should fall back to the base record definitions if there is no matching rule (and no wrfarmhousewindmill2_lod*.nif). The (partial) path/filename.nif of the mesh rule needs to match the model assigned to MODL - Model Filename. In the screenshot the VWD flag is set. Right next to check box it says "apply rule only if matching LOD meshes exist", which means the rule is only applied if a wrfarmhousewindmill2_lod*.nif exists, which is most likely not the case. So do not set the VWD to make it use the full model in this case. In case the full model is used for LOD, DynDOLOD should also be using any replacement textures defined on the base record when generating LOD. If you still have trouble with this, upload the plugins/models/rules so I can have a look.

Tree LOD atlas should be fixed in Alpha-18 1) Do you mean the message "Found Bashed Patch, 0.esp. In case there are errors, test if removing the Bashed Patch allows generation without problems. If it does, it means the Bashed Patch is broken. Use a newer version of Wrye Bash to create a new patch"? That notice has been in TexGen/DynDOLOD for l years, because in the past there were several bugs in Wrye Bash creating broken bashed patches. 2) Either check Windows (can only be not "High") only in the first pass or only in the second pass (can only be "High"). I need to double check the second pass is working correctly. Seems it might still have something wrong. There is no need for users to "clean" the installation before publishing.

Thanks for the logs. Alpha-17 should fix this for good hopefully.

This should work now with Alpha-16 See if the problem still exists with Alpha-16. It it does upload new bugreport.txt and debug log.

Based on the complete lack of information I am guessing that you are probably not able to fix it. It is most likely something I need to fix. Read the first post. "If making posts..."

It should still work without error, I just needed to know so I can try to replicate.

The first entry of a list has an index of 0. Trying to retrieve an entry from the list with index -1 is not possible, so the index -1 is out of bounds.

Yes I do. Read the first post. "If making posts..."

Which version of Legacy of the Dragonborn are you using?

Delete the file. Then load the game, open console and type "cow Tamriel 7 0" without quote to load into the cell. No Objects In Grass should then generate the file anew, which hopefully can then be read. In case it still can not be read, upload it please.

The values are 0.0 to 1.0 = 0 to 100%. So 0.5 means the resulting color value is 50% of the input. The current values are based around the vanilla grass textures with a final tweaking for the billboards. Are you using an ENB or have weather mods?

From docs/DynDOLOD_Mod_Authors.html It is important to understand - by Bethesda's own basic file naming conventions - that each file name is unique and there never exist two different versions of an asset with the same file name twice or more in different folders. If variants - even if only changing textures - of the same mesh are created, they need to have different filenames. It is not enough to keep files in separate folders. Again, this is based on the principles how Bethesda names files and helps greatly with compatibility. Consequently if the scanning for files finds a file with the same name again in a different folder, that file will be used instead of the file found before it. The folders are scanned in a specific order defined in 'DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAMEMODE].ini' Folder1=meshes, Folder2=meshes\dlc01\lod, Folder3=meshes\dlc02\lod, Folder4=meshes\lod, Folder5=meshes\dyndolod. This ensures that files from DynDOLOD Resources always overwrite vanilla LOD files. From docs/trees.ultra/tools/DynDOLOD_CreateStaticTree.html If a 3D static model is created for a mod, take note of the DynDOLOD.exe output to the Messages window (..\TES5Edit\TES5Edit_log.txt). Look for lines like 'Tree replaced, looking for 3D LOD treepineforest01_8E204123 using full model instead'. Unlike crude replacer mods overwriting existing meshes, DynDOLOD.exe creates a CRC32 checksum from the full model to identify if the vanilla model has been replaced. With both the filename and the CRC32 checksum shared archives of 3D static LOD models for trees can be created without the need to worry about load order and overwriting as each version will have a unique LOD filename. Consequently the file name for a full model tree with the file name treepineforest01.nif and a CRC32 checksum of 8E204123 becomes treepineforest01_8E204123passthru_lod.nif. [...] As a last ditch effort before using the billboard as fallback, DynDOLOD checks if there is an object model with the typical filename convention of full model filename_LOD_[0|1|2].nif. The last ditch effort is the xLODGen way, which is probably what your modification is based upon.

The bugreport is enough that way. But instead of uploading the logs from TexGen you should upload the logs from DynDOLOD.

Read the first post. "If making posts..."

Alpha 15 uses -memory by default. Instead use -speed to save a a minute or two for large worldspaces. The peak memory usage while the Occlusion generation reads all the object LOD meshes in several threads seems normal, especially if the BTO are really large because of grass LOD. To counter this I added a limitation to the number of concurrent threads, which usually defaults to number of cores. If the peak usage is still too high while reading object LOD, lower OcclusionMaxThreadsObjectLOD in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini

Asserts mean there is a problem with the data in the plugin. Does the error repeat every time? Error check the load order with xEdit.

As the manual explains, billboards are textures and text files and work the same in all game versions. If you can see the billboards represented in the BTO the game has no other choice than to show them. If they do not show it might be because the BTO are the old format or because they are actually not the ones loaded by the game. In the end you need to generate the LOD properly with DynDOLOD -tes5vr for the game version anyways, so do that.

Generate LOD after changing LOD assets. Make sure the updated LOD assets are actually used for generating LOD. Check the log. Make sure the new output completely replaces the old output.

The error was probably caused by a race condition I fixed in beta 67

Test without Bashed Patch. If that works, the bashed Patch is broken. Delete the broken patch and generate a new one with the latest Wrye Bash version. If that is not it, check which plugins overwrite the mentioned GRAS record. Remove the highest overwriting plugin and test without it. If that works, fix whatever the error is in the plugin or remove it permanently.

If No Grass In Object is using the same grass cache files that were used for generating grass LOD, then each grass placement is represented by a billboard. However, a billboard has to exist for each grass type, too. Most likely the same as https://forum.step-project.com/topic/15348-dyndolod-300-alpha-14/page-14?do=findComment&comment=244170 If you check the LODGen command prompt windows they probably said something along the line like this https://pastebin.com/z9eCFtLM

Post or pastebin the log

It says x64, always has.

This typically means, that the tree LOD *.btt file for that area was not generated for the current load order of plugins. Make sure sure that none of the output from DynDOLOD is overwritten and that all *.btt files are from the same tree LOD generation and that the order of plugins and their content (tree placements) did not change after generating tree LOD.