sheson

Run and upload the dmp files from this version https://mega.nz/file/0FxWQLTQ#tXQ5OQRwclahHfcrS2pMTq0mNQ856rMXrG6VpRv2FBI

You did not upload the entire log starting with the line TexGen ... starting session to the end. The log shows a message dialog was created and executed. Sometimes the OS hides new windows behind other ones despite the instruction to show it in front. As explained, the winning version of textures\landscape\grass\ewpshore07.dds is not a valid texture. Replace it with a valid texture as explained. For example, download and install the winning mod again.

Upload the entire log as explained in the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs. The log shows a message window was created to show the error. Clicking on the "Click on this link for additional explanations and help for this message" should open https://dyndolod.info/Help/Texconv: The texture is not a valid file format or corrupted and needs to be converted or replaced. Look up the texture path in MOs right window Data tab to find out which mod supplies it. Reinstall the textures from the mod, DynDOLOD Resources or TexGen output, whichever it is. If the mentioned texture is part of the DynDOLOD output, delete the entire output from former session before trying again. Only one mod can supply the wining texture for any given unique file path.

Those crashes are all over the place, meaning random - as expected unfortunately. See what happens if you do this: Find the corresponding export for the worldspace and seasons files like C:\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_Tamriel.txt C:\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_Tamriel_WIN.txt C:\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_Tamriel_SPR.txt etc. Open in notepad and find the line ThreadSplit= and change to ThreadSplit=1 and add a new line under it with Threads=1. Then Execute LODGen for one of the wordspace + season you edited to see if that makes a difference.

Great! Keep using that version then. It will be the base for the next alpha release. Thanks again for all the tests.

https://dyndolod.info/FAQ#Virus https://www.virustotal.com/gui/file/2a9ec9170c35f28b765d5f87f834c81d7ac722076f384ff40f4f01ed41748745

Leave LODGenx64Win.exe hidden. We will continue with the Framework 4.8 version. If you like you can try updating/uninstalling/reinstalling/repairing the latest Framework version. On a windows command prompt you can try running C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update /force You can also try a sfc /scannow https://support.microsoft.com/en-us/windows/using-system-file-checker-in-windows-365e0031-36b1-6031-f804-8fd86e0ef4ca Reboot after each. I doubt though that this is going to make a difference, since both Framework and .NET have the crash that is typically cause by CPU/memory issues. I have another test version. Replace the LODGenx64.exe with the one in this archive https://mega.nz/file/4RIzHSQZ#aTjH9RtZRcigS_RxmE3ZNbkglSvj6dIVmE1bhJRILPs Also put the same LODGenx64.pdb next to it. Delete old dmp files, and Execute LODGen in expert mode for a single worldspace and season so it only starts one processes. Upload dmp file(s).

Both debugs logs show that both RenderSingle=0 and RenderTexturesSingleThread=0 are set. You do not seem to be using the test version from https://stepmodifications.org/forum/topic/20153-error-opengl-framebuffer-objects-unsupported/?do=findComment&comment=282545 only it has the RenderBillboardsSingleThread setting, however in your case I believe RenderTexturesSingleThread=1 should work in case the test version still does not work with default settings.

Great! I have one more control to test if you don't mind: https://mega.nz/file/pNZQiIyD#kny76dS8lskjoWNgchrzOwSSqs1vFSaKVRhvjeDsiHY Thanks for the results.

No logs or screenshots were provided for the new generation. That is not really a satisfactory solution or seems logical. Didn't you report that you see the animated dynamic LOD reference added by DynDOLOD plugins beyond the large reference distance in the LOD area once you if you disabled all LOD with tll? Why would the static LOD model that should be a bit lower and smaller than the animated dynamic LOD model cover it? If anything either only uncheck Dynamic and leave everything else as is, or just set LOD Level 4 to None and leave everything else as is.

So far so good. Delete all old dmp. Replace LODGenx64.exe in Edit Scripts with this version https://mega.nz/file/wMhQkbYK#txe4unb3FlDtjlAaaIoVuOUohMoGqUNNA6oH4AABulY Start DynDOLOD in expert mode and Execute LODGen for whatever worldspace and season with the problem. Upload new dmp file(s).

When making a "me too" post, it would be helpful to upload the entire TexGen log and debug log (and the bugreport.txt if it exists) from the last run that has the error, preferrable with the test version and GLDebug=1. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs

One more test, last one for now https://mega.nz/file/8MpjFIxI#v9Bz4wKrzbhYcKmqej1KCOlw0XWr8vrfwwi3XRQHl6w

Did you do change any settings about virtual memory/page file? Create a new registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps to enable minidumps. https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps No need to add any of the settings, the defaults should suffice. Then reproduce the crash and hopefully find the file to upload in %LOCALAPPDATA%\CrashDumps

Please test if this version also still works https://mega.nz/file/sQBxjA4a#F0VGH89c7sllMy5jFp-g4V6tid2Nm9syUBD8UZEASr4

Do not post screenshots of texts. Just copy and past the text. Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen log and debug log to upload when making posts. See https://dyndolod.info/Messages/Exceptions#Assertion-failure Try to search the forum for similar message/errors as explained in the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-Search https://stepmodifications.org/forum/search/?q=Assertion failure&quick=1&updated_after=any&sortby=newest The error happens while the xEdit background loader is loading plugins. Do you see a similar error with xEdit? Test if it loads after disabling TroublesOfHeroineUniqueVoices.esp. If it does, it means there is a problem with that plugin. You may want to redownload/reinstall it. Maybe loading and saving it with CK can fix that.

Can you check/upload whatever files you have in C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_LODGenx64.exe_3e45a4a6ec721ab9b0cf8eeec45b859ad46d875f_dccf8104_1e33ab8d-94fe-4a05-ba29-d611e7a20939 or here: C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_LODGenx64.exe_3e45a4a6ec721ab9b0cf8eeec45b859ad46d875f_dccf8104_d2f3d1fc-8356-4a4a-9082-6fc9c1dd1b74 Especially files ending in *.dmp Might be here: C:\ProgramData\Microsoft\Windows\WER\Temp\WER.f8f9708a-1428-4aa2-b32e-e61c619ff101.tmp.dmp or here: C:\ProgramData\Microsoft\Windows\WER\Temp\WER.b6d9ab25-2747-482b-8c01-2bd34348a1a1.tmp.dmp Did you do change any settings about virtual memory/page file?

If the test version only has the dll + pdb and no papyrus scripts, just use the ones from the latest version. Can you make sure you have the latest Redistributable installed? https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170 See what happens with this test version https://mega.nz/file/cMREELbQ#vcnwm7GwXN0B60zry4cAZ_NBYCXGtfI6d6Ba9Qbcv1E Delete the empty DynDOLOD.log so we if it created one. Start game. Upload the new SKSE64.log. Check if it created a new DynDOLOD.log in same folder and upload that as well if it is not empty.

Common sense would be to first troubleshoot if this crash is actually caused by DynDOLOD and not by another mod or DLL. Common sense of an alpha test is to troubleshoot the actual problem so it can be fixed. There are zero similar crash reports here in months while the DynDOLOD DLL is being used by tens of thousands of people. I suggested what to do test next, if a crash is rare, so what? It does even less prevent you from "just playing the game" while troubleshooting. I can not fix what is not reported and/or people refuse to follow through with the actual troubleshoot requests to narrow things down.

Unfortunately the DynDOLOD debug log does not show a generation session anymore since the tool was started again and then closed. https://dyndolod.info/ The tools are shared for free with the specific requirement to use the latest version, to provide feedback and to report any problems including logs and other requested information to the official DynDOLOD support forum in order to advance their improve and advance their development for all users. You are not entitled to my work or time. On the contrary, if you participate in the alpha test you are required to use the latest version and to help troubleshoot problems. If you have no intention to help troubleshoot the issue in your load order for everyones benefit, then you do not meet the requirements to particpate in the DynDOLOD 3 alpha test and should use it. In case you actually want to help troubleshoot the problem for everyone's benefit, report if there is any difference using any of the older versions of DynDOLOD DLL NG and Scripts available at https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds. Also test without any DynDOLOD DLL (while ignoring any error messages in game from DynDOLOD about it missing etc.) Upload all crash logs collected while testing the 2 older versions. Report the steps required to reproduce the CTD.

Install this test version https://mega.nz/file/IcJRVTJa#bn4SnZ9suS_1cAK5Jj50xlLzu158IdXWH9af8uEoXeA Start game. Upload the new SKSE64.log. Check if it created a new DynDOLOD.log in same folder and upload that as well.

Install this test version https://mega.nz/file/5dYHzQpa#bkwmqPrj8843NtreuE5hzCmCRtMm5eUxAMd_WCk3jpk Start game. Upload the new SKSE64.log. Check if it created a new DynDOLOD.log in same folder and upload that as well. If it starts use it with the papyrus scripts from the latest Alpha version.

That is what the hover hints are for. The Help button is supposed to open https://dyndolod.info/Help/Advanced-Mode but nobody ever reports it not properly working, so nobody uses it anyways.

https://dyndolod.info/Help/Advanced-Mode#Tree-Lod Check Large to make the full model trees large references - if they are added by ESM flagged plugins. Requires DynDOLOD DLL NG and Scripts, which includes the large reference bugs workarounds. The TreeLargeRefSize setting in the ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini controls the size threshold, e.g. if smaller trees should be large references, lower the value. Also, references that are overwritten by non ESM flagged plugins, have enable parents or are initially disabled are skipped. In case the tree base records have locational swaps, like cells, locations or regions, they are skipped. https://dyndolod.info/Help/Advanced-Mode#Upgrade-NearGrid-Large-References-to-FarGrid Unchecked - large references that would have dynamic LOD in the NearGrid are ignored. They will not have LOD beyond the large reference distance setting. Better performance. Checked - large references that would have dynamic LOD in the NearGrid are added to the FarGrid. They will have LOD beyond the large reference distance setting. Better visuals. As a rule of thumb, check the box "Upgrade NearGrid Large Refs" in case the large reference system is not used - uLargeRefLODGridSize = uGridsToLoad (default 5) - to make sure all references receive dynamic LOD as intended. The result would be LOD working the same as it did in Skyrim. Vice versa, do not check this option in case the large referene system is used - uLargeRefLODGridSize > uGridsToLoad >= 5. Upgrading large references that were intended for NearGrid means more resource usage in case the large reference system is used. References that are intended for NearGrid are typically smaller and it generally makes not much sense to show them beyond the large reference grid. https://dyndolod.info/Help/Advanced-Mode#Downgrade-FarGrid-References-to-NearGrid Unchecked - non large references are added to the NearGrid or the FarGrid accordingly to their mesh rules. Better visuals. Checked - non large references are always added to the NearGrid even if the of their mesh rules set FarGrid. Better performance. If you want to know the visual and performance difference for your setup and load order generate 2 outputs and compare them. Typically making trees large references will have the biggest performance impact depending on the amount of trees, their complexity and the large reference distance setting.

By hiding I mean something like moving it out of the folder or renaming it to LODGenx64Win.bak for example. Make sure antivir is not interfering by temporality disabling or adding exceptions. Reinstall or repair .NET6 If neither works, upload the files mentioned from the last event log entry, e.g. C:\ProgramData\Microsoft\Windows\WER\Temp\WER.b742fef1-151c-4b46-8353-6e3f9a08266a.tmp.dmp C:\ProgramData\Microsoft\Windows\WER\Temp\WER.0820b4dd-3d78-4c5a-b818-0e6721cbf5f0.tmp.WERInternalMetadata.xml etc.