sheson

No log files showing getting passed the initial error were provided. The message states a fact. The OS reported to the program that the file does not exist. Z:\home\chrysopoeia\Games\Skyrim\Stock Game\Data\meshes\architecture\whiterun\wrbuildings\wrhousewind01_dyndolod_child.nif Make sure that the file system is in case insensitive for all files and folders involved. If you can find meshes\architecture\whiterun\wrbuildings\wrhousewind01_dyndolod_child.nif in MO2 right window data tab with the same case, then make sure MO2 also uses the the shown data path Z:\home\chrysopoeia\Games\Skyrim\Stock Game\Data\ and if not, either update MO2 settings or the ones for DynDOLOD so that they use the exact same data path. See https://dyndolod.info/Messages/Windows-Registry-Key.

This is the DynDOLOD support forum section. I do not provide support for the STEP guide (that is a different section of this forum) or third party mods here. If you have questions or feedback about a modding guide you are following, you should direct those to the authors of the guide. As you noted my answer which INI needs editing is already personalized to your setup based on the log file provided.

I suggest to take the time to carefully read the description/instructions of the mod. Scroll down to the green "Installation Instructions". You should direct questions or feedback about mod(s) to their respective author(s) and/or comment sections.

Moved to the appropriate thread for the problem. See posts above. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-Search See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Check-the-FAQ. As the answers above, the answers to this FAQ most likely apply https://dyndolod.info/FAQ#Object-LOD-shows-in-active-exterior-cells You have a clear map overhaul installed. So this is the most likely solution: Make sure to read and follow the mods instructions which - depending on the mods install options - require setting Level32=1 in the C:\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini

The relevant libraries that need to be properly installed are dotnet48 for LODGenx64.exe, dotnet6 or dotnetdesktop6 for the alternative LODGenx64Win.exe, vcrun2022 for Texconv and DynDOLOD DLL NG. https://dyndolod.info/Downloads If LODGenx64.exe included in latest xLODGen works, so should be the LODGenx64.exe included in latest DynDOLOD.

Moved to the appropriate thread for the message. See posts above. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-Search Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD debug log to also upload when making posts. DynDOLOD seems to function fine. It is the command line tool LODGen that doers not work because a requirement for it is not working. Terrain LOD meshes generated fine with xLODGen in the same prefix? Neither .NET6 nor NET Framework 4.8 x64 versions seem to be properly installed in the prefix in which LODGenx64.exe is started. AFAIK the framework 4.8 version of LODGen also works with mono.

Great. Thanks for letting us know.

Moved to the appropriate thread for the message. See posts above. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-Search Use the Copy message to clipboard link of the message prompt to paste the message text instead of screenshots as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which entire DynDOLOD log and debug log to upload when making posts. When uploading logs from any tool, always upload the complete log from the entire session. Provide links to the used mods where they can be downloaded. Read the entire error message and additional explanation by clicking Click on this link for additional explanations and help for this message in the message window as explained https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages to open https://dyndolod.info/Messages/Unresolved-Form-ID: In case the message mentions that a plugin might be the wrong version, double check it is the correct version for the game version and for any other plugins using it as a master and vice versa. ... For example, patch plugins might need updating in case any of the plugins they are patching changed. For example, when compacting form IDs to convert a plugin to a light plugin (ESL), all other plugins using the converted plugin as a master need to be loaded/updated as well so they are also use the new form IDs. "Whiterun Has Walls - Blubbos Whiterun 2022 Patch.esp" was most likely made for a different version of "Blubbos_NewWhiterun_2022.esp" or one of the plugins was changed. If I had to guess, this looks like a botched conversion to light plugin, for example not all required plugins were loaded when compacting form IDs as already explained in the quote above. Do not rely on so called AI tools for anything where actual correct information is required. There is no "I" in these tools and they are "trained" indiscriminately on all the unqualified nonsense and BS found on the internet from clueless people and bots. They lie and gaslight unsuspecting users that do not have enough knowledge about a topic required to filter out the lies and BS from answers.

Test what happens with this version of DynDOLOD DLL NG https://mega.nz/file/JURRQYwR#DB0snkpgG_tMwU32B1e9BI2fH55cgSz-YH_ewUNp8F4 Just replace the files and use the already existing output.

The crashlog seems to show a navmesh/pathing related crash. The second crash is the usual one related to effects/NPCs. Since those crashes happen without any DynDOLOD files active I am not really able to help much further.

You are using PBR textures. Read https://dyndolod.info/Mods/Community-Shaders#PBR, especially these paragraphs: Since the shaders for LOD are still vanilla, they do not support parallax and/or PBR shaders or sRGB textures. A simple conversion of PBR sRGB diffuse textures to linear is done by xLODGen, TexGen and DynDOLOD on the fly. TexGen and DynDOLOD will both automatically create linear texture versions of the LOD textures for object and tree LOD in case the full model uses PBR textures. The gamma for the conversion can be adjusted by changing sRGBGamma=2.2 in ..\DynDOLOD\Edit Scripts\DynDOLOD\[TexGen|DynDOLOD]_[GAME MODE].INI. Use lower values to darken the LOD textures derived form the PBR textures. In case of any issues and for latest discussions see the PBR WiP thread on the official DynDOLOD support forum. Try with 1.9 maybe in both TexGen and DynDOLOD INIs. See https://dyndolod.info/Updating#New-or-Updated-Mods-or-Plugins how to only update textures: In case a new mod only updates textures or tree full models (and grass full models in case grass LOD is used) relevant to LOD, remove old TexGen output, then use TexGen to generate new output and install it as usual. Start DynDOLOD in expert mode, select all or only the affected worldspaces and click the Rebuild Atlas button to update the atlas textures. Then install the DynDOLOD output, overwriting the existing DynDOLOD output.

The outputs TexGen and DynDOLOD generate is a comprehensive LOD mod which patches the current load order to have better visuals in the distance. As explained, running TexGen and DynDOLOD will update the LOD texture to look like the currently installed full texture. The screenshots will look different. The LOD will match the full models better, the difference will be less obvious, especially when everything is viewed from the normal distances. The linked explanations about large references explain how changing the Large Object Distance slider in the games launcher to the very left turns them off. Then all full models switch to LOD at the same distance.

See https://dyndolod.info/How-LOD-Works and https://dyndolod.info/Help/Large-References. If you enable the large reference system then certain full models switch to LOD further away then others. The screenshots show that the full textures are replaced, while the LOD textures are still vanilla. Use TexGen and DynDOLOD to generate a LOD patch for the load order so the LOD textures are updated accordingly so difference isn't that obvious.

I can not troubleshoot a CTD without the files relevant to the CTD. The formIDs of references/base records change which each generation for example. If you have a crash with DynDOLOD output, then upload the crash log, the corresponding DynDOLOD log, debug log, DynDOLOD_NG_Tamriel.txt DynDOLOD_NG_RigmorCyrodiil.txt and also ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt Use the test versions of DynDOLOD and DynDOLOD DLL you already have. Report the result of this: Does it also crash if you temporarily rename or remove meshes\terrain\rigmor_cyrodiil\impcity\rigmor_brumacitydoorsanim.nif in the ParallaxGen output, so it uses the one shipping with Rigmor of Cyrodiil

This is off topic and irrelevant to DynDOLOD and deleted large references. https://dyndolod.info/Generation-Instructions#Prerequisites, https://dyndolod.info/Messages/Deleted-Reference Cleaning of plugins that contain deleted large references is mandatory for the DynDOLOD DLL NG that includes the large reference bugs workarounds. ITMs are irrelevant in this context, see There are no intentional ITMs. DynDOLOD does not care about ITMs, spells or enchantments, once the xEdit background loader successfully loaded all plugins. If you have questions or problems regarding to ITMs or cleaning, then you should post and ask about that on the xEdit discord or github.

Do not reenable anything if it did not to contribute to a problem so that in the end only the things remain that are required for the issue to happen. In fact I would disable the entire DynDOLOD output in one of the next steps, then the Resources and all scripts etc. Same with other mods, plugins. Since this crash seems related to effects, followers, I would also remove everything in one big step that most likely has nothing to do with it first to cut down the size of suspects. You do not need to post similar crash logs that show no change. The last crash log with "Teldryn Sero" is different to the ones with the "Steadfast Dwarven Sphere". That one is again about animations. It could be two different types of crashes. It could be same issue just looking different in what it affects. Effects, animations and related mods etc. are not my expertise.

Also upload ..\SKSE\plugins\DynDOLOD_Data\DynDOLOD_NG_Tamriel.txt Report result of this: Does it also crash if you temporarily rename or remove meshes\terrain\rigmor_cyrodiil\impcity\rigmor_brumacitydoorsanim.nif in the ParallaxGen output, so it uses the one shipping with Rigmor of Cyrodiil? If it also crashes with the original NIF, test if using this test version of DynDOLOD.DLL makes a difference. Just replace the DLL and use existing outputs. I assume the output when the crash happened originally was made with the test version and it stopped crashing when just the DLL was replaced. You then generated new output with the test version and the crash happened again. You then generated new output with the release version and the crash does not happen. Could it be that the crash is not 100% reproducibility?

While this time no call stack was recorded, it still is the same CTD as before. You can see a list of all SKSE DLL plugins in the crash log under SKSE PLUGINS. Something that could be related and easy enough to disable is stuff like ScriptEffectArchetypeCrashFix.dll or FootPrints.esp. Keep in mind though, while I can interpret the crash log information having probably to do effects and the virtual machine (script functions which can also be called by DLLs) I have really not much knowledge which mods to really look at in the load order.

Papyrus scripts issues should typically result in messages to the papyrus log and not in CTD under normal circumstances. I would first look at other DLL mods that have a hand in changing followers, magic, effects and plugins/scripts second. Of course there have been exceptions in the past. Just hide the DLL, leave everything else.

So what is it you did at the time? Again there is 10 seconds have past since DynDOLOD.DLL did anything. It seems to be related to a papyrus script function (probably GetTargetActor) and magic effects on or used by "Teldryn Sero". Continue testing with DynDOLOD.DLL being hidden/removed.

Does it alsocrash if you temporarily rename or remove meshes\terrain\rigmor_cyrodiil\impcity\rigmor_brumacitydoorsanim.nif in the ParallaxGen output, so it uses the one shipping with Rigmor of Cyrodiil? If it also crashes with the original NIF, test if using this test version of DynDOLOD.DLL makes a difference. https://mega.nz/file/0MYzjBYA#J_0-482cmXSeHh8a5dnlEdLFsU3xxEZKc3ov-WuSD2A Just replace the DLL and use existing outputs.

The best option is not to force their billboard generation with TexGen. You can also just delete all billboards files after the fact.

Both crash reference the same Steadfast Dwarven Sphere. The second crash especially, seems to indicate a problem with animations and/or skeleton again. Since I see FNIS in the list of plugins, that might be the next step to test, like regenerating it or test without it. What is interesting that both times the DynDOLOD.log indicates the DynDOLOD.DLL did not do anything for more than 10 seconds anymore, it completed all tasks for the current cell/location. Same for the papyrus log but even longer times. Are these death related crashes?

Also upload E:\Skyrim\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_Tamriel.txt According to the DynDOLOD_SSE_Object_Report.txt, the rules for FallForestShrub, PineShrub, TundraShrub, ReachBush, ReachShrub, VineMaple and YellowShrub are now applied and they LOD 16 set to none. Make sure to add a rule for all models you want to affect. For example DeadShrub seems to be missing. Make sure the generated files are installed and not overwritten. Otherwise properly identify what it is you are seeing in LOD level 16 and post a screenshot closeup of the LOD area and a useful screenshot of its full model.

You need to check the VWD flag for these rules to apply. Or set Grid to FarLOD.