sheson

Moved to a similar thread. The TexGen logs do not show an entire generation session. Make sure it rendered textures\dlc01\lod\DLC01IceSnow.dds. It seems the DynDOLOD Resources for Skyrim LE contain an outdated LOD model. Replace ..\Meshes\dlc01\lod\lakesnow01_lod.nif with the one attached, then Execute LODGen for DLC01FalmerValley again in Export mode to update the object LOD meshes. lakesnow01_lod.nif

Upload a useful screenshot of the full model with more informative console as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots

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. If you have the same problem, thennthe same sution applies. No link to a post with the "same problem" was provided. While DynDOLOD Plugins might be using a full model NIF and full textures provided by vanilla or mods, it typically does not change their appearance. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Rudimentary-Troubleshooting Make sure things look as expected without DynDOLOD output. If that changes anything, make sure to generate LOD for the current load order. See https://dyndolod.info/Help/Glow-LOD about the LightingShader INI settings.

Did you make any changes to C:\Modding\DynDOLOD SSE\DynDOLOD\Edit Scripts\DynDOLOD\Rules\DynDOLOD_SSE_legacyofthedragonbornv5esm_High.ini? Restore the default DynDOLOD_SSE_legacyofthedragonbornv5esm_high.ini from the DynDOLOD download archive. Probably best to unpack the DynDOLOD Standalone again into a new empty folder. Then start DynDOLOD as usual, select high to load the rules and generate just LOD for Tamriel, no need to Occlusion etc. for test.

Also upload the DynDOLOD debug log as explained in the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs

Get the new test version. Add LoadGLCompressed=0 under [TexGen] to the TexGen_SSE.INI. Upload new logs.

I uploaded a new test version to run and upload the new logs for.

The DynDOLOD log only contains a session that starts the tool without generating anything. Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload. Make sure they both contain the entire last LOD generation session. Explain in which worldspace the in-game screenshots were made. Outside or inside the city walls? Is the main museum building missing in Tamriel or in the SolitudeWorld? Parent->Child being checked is not supposed to have an affect the museum building being visible in both worldspaces in this case. The xEdit screenshot shows a new reference in a DynDOLOD plugin not overwriting any other record. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#xEdit-Screenshots

Data will just be copied from the json data found in the load order or the defaults baked into the DLL. Just the plugin name and id will be updated accordingly for the copied base record. If you need different values, make sure there is a json defining them for the original based record. In case of your screenshot that seems to be 0x00051577.

If the log and debug log are saved as usual you can disable the the realtime log. Delete old logs and bugreport, get the new test version and upload new logs, bugereport if it exists.

What the rules does is use the full model (in this case from EmbersXD) for LOD instead of the usual dynamic LOD model included in DynDOLOD Resources, since that is for the vanilla model and doesn't match well. Typically there is no need to switch from the full model to the same full model used for LOD, so that is why the rule uses "Replace", to use the "LOD" reference continuously. For now, change the rule from "Replace" to "Unchanged", so the original reference is used in the active cells and the LOD reference in the LOD area. See https://dyndolod.info/Help/Mesh-Mask-Reference-Rules. I will see if I can add support for FireHurts to automatically create a proper JSON file for it if a new base record added is added in the DynDOLOD plugins. Check the changelog of the next couple alpha release for support. Then you can use the EmbersXD rule with "Replace" again.

Upload new logs from latest test version I just uploaded.

Thanks for letting us know. The updates will be part of the next alpha version as usual.

I uploaded a new test version. Delete old logs, run, upload new logs.

The Please Wait means it is collecting data and writing creating the bugreport.txt. Add RealTimeLog=1 under [TexGen] in its INI and close TexGen with the X top right after a minute or so and try to let it shutdown on its own if possible. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs

https://dyndolod.info#Quickstart Click the Help buttons in the GUI or browse Help to open contextual help and explanations for a tool or topic. https://dyndolod.info/Official-DynDOLOD-Support-Forum Do not post screenshots of the tools, unless it is about visual issues with the user interface. Is there something I am supposed to look at in the screenshot other than verifying that the "Help" button is present? Clicking it should open https://dyndolod.info/Help/TexGen, which explains: Once the Start button is clicked, the current settings are saved as a preset to ..\DynDOLOD\Edit Scripts\DynDOLOD\Presets\DynDOLOD_[GAME MODE]_TexGen_Default.ini for the next time TexGen is started.

The DynDOLOD log reports deleted references. The reported plugins need to be cleaned. Read https://dyndolod.info/Messages/Deleted-Reference. The DynDOLOD log reports references attached to wrong cells. The plugins need to be fixed with an xEdit scripts. Read https://dyndolod.info/Messages/Reference-Attached-to-Wrong-Cell. As explained in https://dyndolod.info/Help/LODGen C0000005 can be a sign of hardware issues or high memory usage. High main memory usage and the memory usage of individual (sub) process can be checked with the Windows task manager for example. The -memory argument for TexGen/DynDOLOD only makes sense if the OS runs out of main memory because TexGenx64.exe or DynDOLODx64.exe use a lot. https://dyndolod.info/Help/LODGen#Out-of-Memory, especially: Let Windows handle virtual memory automatically. It seems you exited or stopped DynDOLOD manually. I suggest to do this: Do not check Occlusion, since it will fail if there are xLODGen errors. However, the DynDOLOD patch plugins, SKSE data and textures are typically generated fine if only xLODGen fails and Occlusion was not selected. Keep an eye on memory usage with Window task manager. If you notice lots of xLODGen process running at the same time, consider change the MaxLODGen as explained in https://dyndolod.info/Help/LODGen#Out-of-Memory. If there are still xLODGen errors next run, do this to try to generate each failed worldspace one by one or in small batches - from https://dyndolod.info/Help/LODGen: To restart LODGen generation for a worldspace in case there is no LODGen_[GAME MODE]_[WORLDSPACE]_log.txt or it does not contain a useful error message, start DynDOLOD in expert mode, select the desired worldspace and click Execute LODGen. Bring the LODGen command prompt window to the front to see if it prints more details to the console. If that does not give more detail, check the Windows Event Viewer for additional messages from the .Net Framework or the .NET Desktop Runtime. If xLODGen fails then, rename ..\DynDOLOD\Edit Scripts\LODGenx64Win.exe to LODGenx64Win.bak, so it will use LODGenx64.exe next start up, then try above steps again. If you can generate object LOD meshes for all failed worldspaces like this you will end up and have successfully generated the DynDOLOD plugins, SKSE and textures, you should have a complete LOD patch output that you can install and for which you can generate Occlusion separately by only checking the Occlusion checkbox in advance mode. https://dyndolod.info/Help/Occlusion-Data#Generation

Since the last plugin the xEdit background loader is crashing at seems to be different each time, this could be the PC/OS being unstable, like hardware issue, bad BIOS settings like wrong memory timing etc. Test system stability with prime95 and OCCT. Remove -memory command line argument. Get latest xEdit 4.1.5o from the xEdit Discord and check if its background loader loads the load order OK like 3 or 4 times. Report and upload the xEdit log or check if you can find out if a specific plugin is problematic. Report issues with xEdit to its Discord for troubleshooting help.

TexGen requests an opengl version 3.0 context despite the version string reporting 2.1 and that is what fails in the test version. I uploaded a new test version, get that and upload new logs. Delete old logs and bugreport first.

I asked to "post .. an xEdit screenshot of the cell record" - so the first screenshot is that, just for another cell. https://dyndolod.info/Official-DynDOLOD-Support-Forum#xEdit-Screenshots When investigating records in xEdit, make sure to scroll to the far right to show the last winning plugin to overwrite the record. If not everything of interested fits into a single screenshot, do several to show the whole record, scrolling to the bottom, too. Do not trim anything. Do not filter anything, keep the entire window of xEdit is shown. Unfold elements (in particular when they link to other records) in case their content is not entirely shown in the folded view. While the screenshot does not show the most right winning plugin, we can see that the XLCN entry has a string ID error. If the problem also exists in the winning plugin this might be related to the issue. You should check the linked location record 00018A56 in xEdit and find out the last plugin to overwrite it. The log still reports deleted references. Really read https://dyndolod.info/Messages/Deleted-Reference and fix the error in all reported plugins. The log still reports references attached to wrong cells. Really read https://dyndolod.info/Messages/Reference-Attached-to-Wrong-Cell and fix the problem in all reported plugins. If no bugreport.txt is created in the same folder as the exe, try rebooting and make sure the PC/OS is stable. For example test with prime95 and OCCT. The log still reports deleted references. Really read https://dyndolod.info/Messages/Deleted-Reference and fix the error in all reported plugins. The log still reports references attached to wrong cells. Really read https://dyndolod.info/Messages/Reference-Attached-to-Wrong-Cell and fix the problem in all reported plugins. I also suggest to really pay attention to all log messages and read their explanations at https://dyndolod.info/Messages and how to solve them if applicable. Generate updated TexGen output for the load order.

Pay attention to all log messages. Errors and warnings are reported for a reason. Really read these explantions https://dyndolod.info/Messages/Can-Not-Resolve-Cell and https://dyndolod.info/Generation-Instructions#Prerequisites. Really fix these errors in the load order: https://dyndolod.info/Messages/Reference-Attached-to-Wrong-Cell Run the "Put worldspace references in the right cell" script on the worldspaces of the reported plugins. https://dyndolod.info/Messages/Deleted-Reference Clean the reported plugins. If an issue with cell 4, -2 persists after fixing the broken plugins, post new logs and an xEdit screenshot of the cell record 0x000095FC. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#xEdit-Screenshots

Moved to the appropriate thread for the error 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 log and debug log to upload when making posts. Read https://dyndolod.info/Messages/Can-Not-Resolve-Cell and https://dyndolod.info/Generation-Instructions#Prerequisites

Check if the test version of DynDOLOD from https://dyndolod.info/Downloads/Test-Versions runs through. Upload new logs if issue persists.

Get the latest test version of DynDOLOD from https://dyndolod.info/Downloads/Test-Versions Generate underside as usual for the first time and add the base records, form lists and references to your master plugin. This necessary because the EditorIDs of those records changed going forward to include the term _DynDOLOD_ to properly identify these records. Then it should be possible to generate a LOD patch with DynDOLOD as usual. If the Underside option is checked, the records will be overwritten only if there are any changes to them. There should be no new duplicate records created. The mesh will always be generated.

https://dyndolod.info/Official-DynDOLOD-Support-Forum#Rudimentary-Troubleshooting https://dyndolod.info/Official-DynDOLOD-Support-Forum Report the actual problem or error message without making unverified assumptions or asking leading questions. Read the explanations and tips below, especially about what information and logs to provide and how. DynDOLOD DLL NG requires considerably less helper (non LOD) references than using PapyrusUtil/DynDOLOD DLL SSE. Skyrim INI settings do not affect the number of dynamic LOD references being generated. uGridsToLoad defines the area of cells around child worldspaces that require parent->child copies. Increasing uGridsToLoads means LOD starts further away - that means there is less LOD and more full models being shown. Decreasing uGridsToLoads means LOD starts closer - that means there is more LOD and less full models being shown.