sheson

https://dyndolod.info/Help/xLODGen It is advised to always generate high quality terrain LOD meshes for the current load order with xLODGen to make sure that height changes made by mods are reflected by terrain LOD. It is advised to always generate high quality terrain LOD textures for the current load order with xLODGen to make sure that changes to the full landscape textures or their placement information made by mods are reflected by terrain LOD. Typically terrain only uses the textures in the ..\Textures\Landscape\ folder and none of subfolders. https://dyndolod.info/Help/Terrain-LOD-and-Water-LOD#Technical-Information

It is known that ENB settings affects grass LOD color/brightness. ENB typically does not change the visibility of LOD or transparency of textures. Use tfc to get close to LOD. No logs and no useful screenshots like a close up of LOD with tfc were provided.

This is the xLODGen and DynDOLOD support forum. If you have questions about third party mods and how they work, then you should ask their author or on its support comments. If "something" is not mentioned in the guides for a mod that exists since years, it typically means that "something" is not relevant. There is only type of grass cache. The same cache is used to place full grass and for grass LOD generation.

If a specfic type of full grass model has no LOD representation see https://dyndolod.info/Help/Grass-LOD#No-Grass-LOD-Check-List

No such feature ever existed. You used a mod that included special landscape textures for terrain LOD generation.

https://dyndolod.info/Help/Grass-LOD#Settings Change the Density dropdown to a lower value in the advanced mode of DynDOLOD under the Grass LOD checkbox to thin out grass LOD for better performance. https://dyndolod.info/Help/Advanced-Mode#Grass-LOD Density sets the percentage of grass LOD billboards that are being generated. 50 means only half of the grass placements are added for better performance but thinner grass LOD in the distance. Set it to 15 or lower to further reduce performance requirements.

Error check the load order in xEdit. In particular check all plugins that overwrite the mentioned CELL record and the LAND record contained within for unresolved form ID or other errors. If no errors are reported for the CELL or its LANDscape record, report that and which plugin is the one to overwrite those records last if any.

You seem to be using an older version. Delete the xLODGen folder and download the latest version from first post. Error check the load order in xEdit. In particular check all plugins that overwrite the mentioned CELL record and the LAND record contained within for unresolved form ID or other errors. Upload new logs and bugreport.txt if problem persists.

The answer depends on ... knowing which exact texture it is that is being replaced. Lets assume by mountain texture, this is about the textures in the ..\Textures\landscape\mountains\ folder, which are typically used by rocky the mountains meshes. Well made mods stick to that folder usually. ... knowing if the texture is being used by an LTEX Landscape Texture record (which are used by LANDscape records for the terrain layers). The vanilla game only uses textures from the ..\Textures\landscape\ folder and none of the subfolders. Well made mods do the same usually. So, generally the answer is, you have to run TexGen and DynDOLOD and not xLODGen if textures in ..\Textures\landscape\mountains\ are changed and you want (most) object LOD to reflect the changes.

I already posted the link to the explanations which log files to upload https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs The page also explains to use search https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-Search, searching for the error message finds this thread https://stepmodifications.org/forum/topic/19354-a-call-to-an-os-function-failed

Looking good. Thanks for testing and letting us know.

Let me know if this test version works - no unresolved form IDs and no crashes. https://mega.nz/file/BBAWlCwA#wn7-2iAs803THnasndswcCYH0wFWwV473creTLtoK8I Let me know if Alpha-171 fixes the issue properly for you. For speed DynDOLOD creates the large reference list on the worldspace record directly without using the usual xEdit functions that also take care of load order form IDs and the master list being in sync. This requires the master list to be final when DynDOLOD creates the list. A change somewhere else means if circumstances are right, the master list could change after, which is hopefully addressed in this test version.

Grass cache generation with NGIO does not require Grass Cache Helper NG. Object LOD uses 3 LOD level, 4, 8 and 16. Whatever the LOD meshes of level 4 depict, shows in the area between the edge of the active cells and the object LOD level 8 meshes and can not be made to stop rendering earlier. That would require changes to the engine and/or shaders. See https://dyndolod.info/How-LOD-Works and https://dyndolod.info/Help/Object-LOD

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts. Use the Copy Message to clipboard link to paste the text of messages instead of posting screenshots as explained on the first post and https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text. The message already explains the problem and the solution. The mentioned plugins contain deleted reference and need to be cleaned. Use the Click on this link for additional explanations and help for this message to open https://dyndolod.info/Help/DynDOLOD-DLL for further explanations and help as explained in the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages This message replaces https://stepmodifications.org/forum/topic/18984-large-reference-bugs-workarounds-requirements-not-met/ from earlier alpha versions. Same reason, same solution. Nothing really changed other than the message being more clear. https://dyndolod.info/Help/DynDOLOD-DLL DynDOLOD DLL NG Every plugin containing deleted references needs to be cleaned. Scrolling down to https://dyndolod.info/Help/DynDOLOD-DLL#Requirements In case of Skyrim SE, Skyrim AE, Enderal SE, Skyrim VR and Enderal VR every plugin that contains deleted references needs to be cleaned. That includes vanilla game plugins like Update.esm etc. See the Prerequisites section of the Generation Instructions for more. https://dyndolod.info Always use the latest versions. Newer versions fix bugs, contain updated/new assets and configuration files for the vanilla game and for existing, new or updated mods. Using the latest version and providing feedback or reporting problems is a requirement to participate in the alpha test. Do not waste time using older versions or reporting problems with older versions. Participating in the alpha test requires to report any problems to the official DynDOLOD support forum. The only sane and common sense modding and development method of free tools is to report bugs or problems, have them fixed in a new version and solved in the official DynDOLOD support forum. https://dyndolod.info/Generation-Instructions Clean and error check the load order with xEdit. Clean every plugin that LOOT suggests to clean ... Cleaning of plugins that contain deleted large references is mandatory for the large reference bugs workarounds. Cleaning dirty plugins containing deleted references is a soft requirement of DynDOLOD since its inception. Fixing deleted references is a requirement of DynDOLOD DLL NG and the large reference bugs workaround since its inception.

As explained in the first post, my signature or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs, zip large log files and use a file service to upload them. You do not seem to use seasons, so it is unclear why you are using Grass Cache Helper NG. If you want to compare performance requirements of full grass to grass LOD, make sure to extend it to the same distance as LOD Level 4 as explained in https://dyndolod.info/Help/Grass-LOD#Performance If you want to decrease performance requirements of grass LOD, reduce the density and/or shorten the LOD Level 4 distance as explained in https://dyndolod.info/Help/Grass-LOD#Performance https://dyndolod.info/FAQ#Long-running-time-or-output-several-GB-in-file-size

No logs were provided. The performance requirement depends on the load order, hardware and settings. Choose mods, settings and generate the LOD patch according to your needs. iMaxGrassTypesPerTexure means there can be more grass per landscape. A setting of 15 is 7.5 times higher than the default of 2, though how much grasses are there per texture depends on records in plugins and grass mods. iMinGrassSize of 20 is the default density. Increasing the value means less dense grass. If grass LOD does not match the full grass, then likely reasons are that a different grass cache was used for LOD generation, the game not using the grass to place full grass or the load order changed after generating LOD. See https://dyndolod.info/Help/Grass-LOD#Performance

Do not worry about plugins, versions etc. This is about the internal form IDs not matching the saved master list. Let me know how are things with this control version https://mega.nz/file/dRZiVTBQ#jcNj-wwdpC8J4rMDrrtfpS8zPYBJ8eRSkSYljOEBQ5M

Let me know if this test version makes a difference https://mega.nz/file/JMhCEbhI#7lnJ2qwh-K00Uk1zIflcQEEEBQNqHHiLXy9V2y78Xf0

Lets continue with the generation without Sirenroot and Landscape and Water Fixes. Upload that DynDOLOD.esm In the meantime, if you are so inclined, could you doublecheck no such errors exist after generation with 169?

xEdit ignores the case filenames of assets by default, so I'll change that for when reading these INIs. Windows Explorer sorts case insensitive, too since by default filenames are case insensitive. Sorting is usually based on the ASCII order in programming context. The logs report this: INI : Data\AB_SWAP.ini INI : Data\Aa_SWAP.ini INI : Data\B_SWAP.ini INI : Data\a_SWAP.ini INI : Data\Seasons\AB_WIN.ini INI : Data\Seasons\Aa_WIN.ini INI : Data\Seasons\B_WIN.ini INI : Data\Seasons\a_WIN.ini

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD debug log to also upload when making posts. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make useful screenshots of the full model with more informative console and of its LOD representation. See https://dyndolod.info/Messages and read the already existing explanations for a messages. If further help with a specific message is required, paste the actual message and ask specific question about it. Also see https://dyndolod.info/FAQ#Something-does-not-have-LOD.

The Unknown 2 are expected. The unresolved Form ID are a problem. This should not happen right after patch generation. So if you generate again with 170, check it right after. For troubleshooting I do not need a new 169 for now.

Error check the DynDOLOD and Occlusion plugins in xEdit. To be sure, test without the mod / hide the model so that the vanilla model is used. I do not expect that to make a difference. Report if anything overwrite the original reference 00099F21.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts. Messages report facts. https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages Replicate the actual message when asking about them. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text Proton/Wine means Windows program still work and run exactly the same as they do under "Windows". There should be no need for workarounds. MO2 still works the same, too. If you have problems with using MO2, then you should read its documentation and ask on its forum or Discord for help. Neither the game nor any tool needs to know or recognize how MO2 works. That would make using MO2 pointless. https://dyndolod.info/Installation-Instructions

The mentioned records are parent > child copies. There should not be really anything different between the references/base records in Alpha 169 and 170. Lets just look at one crash log: crash-2024-06-05-08-57-45.log Base record WRHouseStables01 with form ID 0x000627AA used by reference 0x130BAEC0 in DynDOLOD.esm Since you have both outputs, do the following: Lookup the reference in xEdit by its EditorID in DynDOLOD.esm in both outputs. Enter skyrimesm_099F21_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLO into the Editor ID field top left of xEdit and hit Enter key and wait for it to find it. Obviously it should find the reference 0x130BAEC0 for the output put from 170. The form ID will different in the DynDOLOD.esm for the output of 169. Compare the references if there is anything different. Both should use the same base record 0x000627AA in Skyrim.esm, which seems not to be overwritten by any plugin and define Architecture\WhiteRun\WRBuildings\WRHouseStables01.nif. It (and any textures it uses) should also be identical for both load orders. Let me know in case this is not the vanilla NIF and if it comes from a mod and which. If so far you haven't found a difference compare, check the Cell 0x00071E94 the reference resides in and compare the overwrites in the DynDOLOD.esm and Occlussion.esp for both output if there is anything different. Let me know if you can spot anything different or obvious errors or if everything looks the same.