sheson

Good to know and thanks. I'll have look. The used data from the plugin is just the NIF and the form id for the filename to create. OpenGL should only be affected by the NIF and texture directly.

Well, remember my mantra, removing something is just a troubleshooting step. We haven't found out the actual issue, yet. if the result works for you without visual issues it is OK to move on. If I am reading this right you removed the grass records with xEdit. I was initially thinking to only hide the texture being used, so it report it as file not find. Doesn't matter, if everything else ran through without a problem that narrowed it down close enough for now. If you could upload the winning textures\landscape\grass\IvyDrJ.dds and meshes\landscape\grass\IvyDrJ.nif you currently have so I can compare them to what I have. Maybe they are not the same that I have.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs wich DynDOLOD log and debug log to upload when making posts. Test if the issue stops happening with DynDOLOD output, its Resources, DLLs etc. disabled. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Rudimentary-Troubleshooting. I find it curious, that you claim the crash log "reported DynDOLOD as the source", when in fact all that the crash log reports is that there is a DynDOLOD.esm, a DynDOLOD.esp and a DynDLOD.DLL. 4 lines. None of the stacks seem to list or mention anything related to DynDOLOD. The crash log seems to indicate there might be a wrong or outdated DLL being used. Probably SkyClimb.dll. Use this version SkyClimb 1.6.1170 Fix Upload new crashlog if issue persists and crashes stop with everything DynDOLOD deactivated. Do not use CLA. https://dyndolod.info/FAQ#ILS-or-CTD Ignore nonsensical suggestions that autosaves need to be disabled because of papyrus scripts not completing or similar made up stories about plugins being "known to cause CTD" when fast traveling or changing locations because of scripting etc. This is not how anything works. If disabling autosaves would be required to prevent CTD, manual saves would have the same issue and it would actually be widely known, would have been reported, troubleshooted, analyzed, fixed, had known workarounds and/or be part of every modding guide since over a decade.

Did you install any mods replacing grass meshes or textures? If not this is probably caused by corrupt game files. Use a legal game version from Steam or GOG.

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. Try to search before posting to see if an issue or error message has already been discussed as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-Search As explained in this post, the initial purpose of this check was to make sure everything is fine when updating DynDOLOD. These are the relevant explantions in https://dyndolod.info/Help/Seasons: Do not swap records in DynDOLOD plugins. The form IDs of records is different for every load order and LOD generation process. Editor IDs are not guaranteed to stay consistent. The LOD generation process will automatically swap records directly or create a DynDOLOD_[SPR|SUM|AUT|WIN].INI if required. In case such swap definitions are detected, remove such lines from the reported *.INI files permanently so the LOD generation process works and the generated LOD patch works properly in the game. The INI line you provided shows that the record 0x233B2~DynDOLOD.esm should be swapped. In any case, whatever the mod is trying to do is simply wrong. Regardless of anything else, as explained above, form IDs in the DynDOLOD plugins are not consistent at all. They will be assigned to different records with every new generation, load order etc. Trying to swap a record like this might just not do not anything in the best case and or cause real issues in the game. It is unfortunate that there are mods containing such errors. This can happen if people do not report problems to have issues troubleshooted and fixed properly. You can just edit the INI file in notepad and remove the lines and then save the file. Make sure that Windows Explorer shows file suffixes so that the *.ini does not accidently get renamed to *.txt

Please see https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen log and debug log and most importantly which bugeport.txt to upload. When the "Please wait" message shows it writes the bugreport.txt to same folder where the TexGenx64.exe is. When you close TexGen, it saves the TexGen_SSE_log.txt and TexGen_SSE_Debug_log.txt to the log folder inside the DynDOLOD installation

Could you test what happens if you actually hide textures\landscape\grass\IvyDrJ.dds so it can not be found and is substituted with red default?

Try with this test version https://mega.nz/file/pIZmhRpb#qO0jMj47TsPqtu3NTWmFqFWI62j7Thk4Z3i5ctwL4iA Delete all old logs and bugreport first. Report results, upload new logs and bugreport if issue persists.

All links seem to require a login. You will need to provide links that we can access.

Does the error also happen with RenderSingle=1 and RenderBillboardsSingleThread=1? What Linux are you using? I am just not able to brute for the issue here in Windows and my Linux. The used version itself is probably not really relevant, just curious.

Also upload bugreport.txt as explained in the first post or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs Let me know in case does not ecist.

Use latest Alpha-184 for now. That TexGen is what the last test version was. Potential new test version will be based on that release.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug lot to upload when making posts. Copy and paste messages with the Copy message to clipboard link instead of a screenshot as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text The message should have a link Click on this link for additional explanations and help for this message as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages and opens https://dyndolod.info/Help/Seasons which explains: Do not swap records in DynDOLOD plugins. The form IDs of records is different for every load order and LOD generation process. Editor IDs are not guaranteed to stay consistent. The LOD generation process will automatically swap records directly or create a DynDOLOD_[SPR|SUM|AUT|WIN].INI if required. In case such swap definitions are detected, remove such lines from the reported *.INI files permanently so the LOD generation process works and the generated LOD patch works properly in the game. A bit further down under https://dyndolod.info/Help/Seasons#Technical-Information it explains: The feature requires season swap files in ..\Data\Seasons\*[SPR|SUM|AUT|WIN].ini. All relative paths in the game, CK, xEdit and tools based typically relate to the Data folder. Which means the reported file will be in the ..\Data\Seasons\ folder. The used data folder is reported at the top of the log messages. Provide a list of all files and mods they are from. As explained in a recent post about a similar message, the check exists to make sure there is nothing bad happening when updating existing DynDOLOD output. Without further information like the requested logs I do not know if there is an old out of date file or if this is caused by mods. That would determine the next steps. I happen to share DynDOLOD with the public to help test and report bugs with the specific requirement to use the latest version and to report any problems including logs and other requested information to this official DynDOLOD support forum as explained on https://dyndolod.info. If users report issues, we troubleshoot them together no matter the cause or how long it takes and try to fix them for everybody.

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. The message should have a link Click on this link for additional explanations and help for this message as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages and opens https://dyndolod.info/Messages/Plugin-Limit which exlpains: Remember that there also needs to be room for adding one or two DynDOLOD plugins and maybe the Occlusion.esp. The Occlusion.esp is flagged as light plugin (ESL) automatically if possible. So with a full plugin limit of 254, there can only be a max of 252 to leave the required room for the DynDOLOD.esm and DynDOLOD.eso

Thank you for verifying the alternative method works as it should. The DynDOLOD 3 Alpha-184 does not add the superfluous Activate Parent. If you like you can right click and remove it (from all underside references). It shouldn't matter either way.

Follow up request if things actually worked out as they should: Open DynDOLOD.esp in xEdit (it is OK to only load the plugins that are required for it) Enter "Tamriel_Underside_DynDOLOD_NOLOD" without quotes into the Editor ID field top left and hit the Enter key. It might take a while searching but should eventual;y show the record in the right window. Check if the record has a VMAD - Virutal Machine Adapter element that sets the "SHESON_DynDOLOD_ObjectEnabler" ScriptName and links to a FLST FormList "DynDOLOD_Tamriel_UndersideWorldspaces". if unsure about this, just post a screenshot.

@S-Matrix @WinterishClover @Yomi Try new test version from https://stepmodifications.org/forum/topic/20141-dyndolod-300-alpha-183/page/689/#findComment-284419 Delete old logs first. Upload new logs if issue persists.

Same on VR error as the other guys on SE. Follow the posts about the test version. Whoever reports results first whenever I upload a new test version "wins"

Get new test version from https://stepmodifications.org/forum/topic/20141-dyndolod-300-alpha-183/page/688/#findComment-284419 Test if there is anything different. Probably not. If same error message, just report that. No need for logs.

The upload logs are the TexGen logs. You want to upload the DynDOLOD logs instead.

Can you load the entire load order into xEdit and check if you can find a record with form ID 0x902? Typically there shouldn't be one. In case there is one, report plugin / mod.

Logs are text files. They can be opened in notepad and their content posted to pastebin for example. Or the files can be attached when posting (there is field to drag and drop) or uploaded to a free file service. Zip first them if they are large. Also see my signature or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs

See posts above. https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-Search Delete old logs, get and run the mentioned test version from https://stepmodifications.org/forum/topic/20141-dyndolod-300-alpha-183/page/689/#findComment-284419, upload new logs.

For future reference, attach logs as files, paste to pastebin or upload them to a file service. This is a packaging error of the DynDOLOD Standalone archive affecting non MO2 users that will be fixed in the next alpha version ASAP. This should be fixed in DynDOLOD 3 Alpha-184

I updated the test version in this post https://stepmodifications.org/forum/topic/20141-dyndolod-300-alpha-183/page/689/#findComment-284419 Same as before, delete old logs, bugreport.txt, upload new ones.