sheson Posted February 17 Author Posted February 17 19 minutes ago, CarlWG2 said: Greetings! Looking for support with DynDOLOD Alpha 187. I have a 951 mod, quite stable Skyrim SSE/AE 1.6.1170 setup that I decided to try with DynDOLOD for the first time this week. I have tried using Alpha 185, 186, and 187 (I started trying to use DynDOLOD when 185 was current, then I tried 186, and then 187 as each was released...issue is generally the same with all three). With each new release, I recreated my Texgen and DynDOLOD output with the latest version and removed the old .zip / installed new .zip to Skyrim and then started a new character for testing. With DynDOLOD mod enabled and active in-game, I experience the following CTD and ILS issues: The automatic loading of the last save game after dying will almost always CTD. It was 100% of the time with 185, is slightly better with 186 and 187. Interestingly, it is better with Papyrus bEnableTrace=1 and DynDOLOD_NG_Worlds debug=true. I wonder if the problem is a timing issue and logging/debug is slowing some process down slightly. I do have an extremely fast computer (Intel i9-14900K, GeForce RTX 4090, 96 GB RAM). With a new character leaving Whiterun (starting in Whiterun using Alternate Start - Live Another Life), the first time I try to leave the city with the new character, I will almost always get an ILS (not 100%, but close to it). I started saving before leaving the city, and after restarting the game and reloading that save, I will no longer get an ILS leaving the city with that character. Very odd. I have tried the troubleshooting steps listed on this site and in the readme for DynDOLOD (in DynDOLOD\docs folder). Some troubleshooting results: If I uncheck "DynDOLOD is active" in the MCM and then make a save game and then die, that save game will auto load successfully after I die 100% of the time. I tried removing all of the *.bto files from the Meshes\Terrain\Tamriel\Objects folder. All save games will then load successfully after I die 100% of the time, even with DynDOLOD active in the MCM. If I add any of the *.bto files back to the Tamriel world Object folder, same issue with save games almost always causing CTD after the auto load after death. I can load any save game successfully, with DynDOLOD active, if I manually choose to load a save game when I'm not dead. It is the autoload after death that causes CTD. Skyrim seems less stable with DynDOLOD active (non-scientific observation). I have had more CTD with DynDOLOD active than before I installed it. I've been testing this mod list and load order extensively the last few weeks to prepare for a new run through Skyrim, and while I would have some crashes, the CTD since installing DynDOLOD are more frequent, and seem to go back to pre-DynDOLOD when I uncheck "DynDOLOD is active" in the MCM. I use Crash Logger SSE. It has not helped me to identify any consistent reason for the instability. The items in the stack are never the same from one crash to the next but are always "EXCEPTION_ACCESS_VIOLATION" unhandled exceptions at non-repeating addresses. I have attached the requested logs. I am happy to provide any additional data points. If I have missed something, am doing something wrong, etc., please let me know and I will upload additional logs, try recommended configuration changes, etc. DynDOLOD_SSE_log.txt: https://ufile.io/572l0cnk DynDOLOD_SSE_Debug_log.txt: https://ufile.io/ak4hpco6 Papyrus.0.log: https://ufile.io/0tgz2jvj Crash Logger log: https://ufile.io/4a8lesx1 My sincere thanks for any help. The visuals from DynDOLOD in my game are breathtakingly awesome...I so want to keep using them and am hoping I can figure out what is causing this instability. CarlWG2 The crash log indicates a problem with an NPC (and their hair physics?) probably related SKEE64.DLL (from Racemenu). The NPCs happen to be in a cell which DynDOLOD.esp and Occlusion.esp are the last plugins to overwrite. Troubleshoot and fix the CTDs that happen without DynDOLOD in the load order. No crash log without DynDOLOD in the load order was provided for comparison. Test without SKEE64.dll / Racemenu. Test with a new game. If it only happens while load existing saves. it might be related to racemenu data in the save and/or SKSE co-save. You can clean (most of) the data of mods from the save and co save by temporarily disabling the mod and making a new save. Make sure to check comments/forum related to Racemenu and hair physics mods for similar reports, updates etc. Check NPC 0x00013B9B in xEdit and the involved plugins overwriting/patching it. Skyrim.esm -> unofficial skyrim special edition patch.esp -> cutting room floor.esp -> AI Overhaul.esp -> PAN_NPCs.esp -> AI Overhaul - Cutting Room Floor Patch.esp -> Olfina replacer.esp -> Bashed Patch, 0.esp -> Synthesis.esp Once the CTD without DynDOLOD are fixed, generate LOD for that load order. In case there are CTDs with only DynDOLOD output activated, upload new logs and crash logs.
AngriusWindstorm Posted February 17 Posted February 17 On 2/16/2025 at 12:30 AM, sheson said: Use the "Copy message to clipboard" link and paste its content as text as explained in the first post and https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages If there is an error prompt, read the entire message carefully. Many of them describe the problem in detail and offer hints for for a solution. Read additional explanations and help for a message by clicking on the Click on this link for additional explanations and help for this message link of the message. That will open a corresponding page on this website with further explanations and help for the message. The message says to "enable all plugins as explained in the Generation Instructions." https://dyndolod.info/Generation-Instructions Finalize the load order as explained in the prerequisites above. ... Make sure all mods, plugins and patches (that affect exterior cells and worldspaces and base records used by references in exterior cells) are enabled and their overwrite order is sorted. Ignore wrong 3rd party misinformation to temporarily disable plugins, mods, meshes or textures. Such misleading guides are categorically wrong or outdated. In case of issues, solve the cause or use appropriate mesh mask rules or settings for desired results. Disabling plugins, mods, meshes or textures is a troubleshooting step and not a fix. In case of problems or questions, use the official DynDOLOD support forum for qualified help and advice. The additional explanations and help explain: Enable all corresponding plugins. Appropriate mesh mask rule files for all corresponding plugins are included in the DynDOLOD Standalone archive and are automatically applied when clicking the Low, Medium or High preset buttons. Finalize the load order. Generate LOD as usual. Install output as usual. Do you not want to use the mentioned interior plugin in the final load order when you start the game? If you indeed want to use it, enable it as explained and generate LOD as usual. In case there are unexpected issue with the generated LOD patch, then report that. If you do not want to use the interior plugin in the game, let us know. I aplogise, I must have missed that part in your reply. If possible, I would rather not use the interior plugin as per the mod author's recommendation. Others with this mod are having the same issue and were looking for a way to follow the mod authors instructions as well.
sheson Posted February 17 Author Posted February 17 43 minutes ago, LF111 said: I've updated the photos with additional pics that I believe cover what the site asks. Pics. Based on how broad the problem here is, I didn't quite know how many pictures to actually take. Note that it's hard to get an up-close view of the purple squares that bisect that certain tree model, as they disappear when getting too close to them with tfc. Requested files and proper logs (let me know if there's an issue accessing the .bto file this way). I can confirm there is no old output overwriting the new one. There's also something funky going on with generation times. TexGen is taking the same amount of time as usual (2-3 minutes), but DynDOLOD is varying a lot. The generation time for my current load order (backed up by the three generations I did for the seam testing) is ~18 minutes. The two Alpha 187 generations I did earlier today both were around 22 minutes, and the one that I just did (that these logs are coming from) was only 9 minutes total. I have never had a DynDOLOD generation go that fast. The BTO you uploaded and which should be the one used for the map, uses Data\textures\dyndolod\lod\dyndolod_tamriel.dds for the Whiterun Castle and walls. Does this texture exist in MO2 right Window data tab? Does it have about the same timestamp from the same session as the BTO you uploaded?
sheson Posted February 17 Author Posted February 17 36 minutes ago, AngriusWindstorm said: I aplogise, I must have missed that part in your reply. If possible, I would rather not use the interior plugin as per the mod author's recommendation. Others with this mod are having the same issue and were looking for a way to follow the mod authors instructions as well. Your intention is to not use the interior plugin in the game? Or is your intention to follow unnecessary 3rd party instructions that only make things more complicated and enable the plugin after generating LOD?
LF111 Posted February 17 Posted February 17 I do not use MO2, unfortunately, so I cannot check it that way. How else can I go about troubleshooting?
PRieST Posted February 17 Posted February 17 Just wanted to report a one time Access Violation with Alpha-187: [Window Title] DynDOLOD [Main Instruction] Access violation at address 0000000001DD2629 in module 'DynDOLODx64.exe' (offset FF2629). [Content] Read of address 0000000000000000 while processing HearthFires.esm BYOHHouse1Room08BPart157Roof [REFR:030090B4] (Places BYOHBYOHWRtowerKEXT01 [STAT:03003C78] in [CELL:00000D74] (in Tamriel "Himmelsrand" [WRLD:0000003C]) at -3,-17) Click on this link for additional explanations and help for this message For qualified help and advice or to report a problem make a post on the official DynDOLOD support forum. [OK] [Exit DynDOLOD] [Footer] Online Help | Support Forum | Copy message to clipboard Haven't made any crucial changes in loadorder in comparison to the last successfull run with Alpha-185. After clicking OK I had to force shutdown the program. Logs: https://www.mediafire.com/file/u9tj4jruk824k33/Logs.7z/file Only bugreport.txt (attached). After starting over no violation happened. Unrelated, but TexGen still reports as version Alpha-186 instead of 187. bugreport.txt
sheson Posted February 17 Author Posted February 17 39 minutes ago, LF111 said: I do not use MO2, unfortunately, so I cannot check it that way. How else can I go about troubleshooting? Refer to the manual or help of the mod manager you are using how to do everyday modding stuff. I suppose you can check the files (and their timestamps) directly in the actual data folder.
sheson Posted February 17 Author Posted February 17 27 minutes ago, PRieST said: Just wanted to report a one time Access Violation with Alpha-187: [Window Title] DynDOLOD [Main Instruction] Access violation at address 0000000001DD2629 in module 'DynDOLODx64.exe' (offset FF2629). [Content] Read of address 0000000000000000 while processing HearthFires.esm BYOHHouse1Room08BPart157Roof [REFR:030090B4] (Places BYOHBYOHWRtowerKEXT01 [STAT:03003C78] in [CELL:00000D74] (in Tamriel "Himmelsrand" [WRLD:0000003C]) at -3,-17) Click on this link for additional explanations and help for this message For qualified help and advice or to report a problem make a post on the official DynDOLOD support forum. [OK] [Exit DynDOLOD] [Footer] Online Help | Support Forum | Copy message to clipboard Haven't made any crucial changes in loadorder in comparison to the last successfull run with Alpha-185. After clicking OK I had to force shutdown the program. Logs: https://www.mediafire.com/file/u9tj4jruk824k33/Logs.7z/file Only bugreport.txt (attached). After starting over no violation happened. Unrelated, but TexGen still reports as version Alpha-186 instead of 187. bugreport.txt 223.73 kB · 0 downloads If the record 030090B4 overwritten by any plugin? I suppose it is not, which makes the error message odd, as it fails to get the "name" of the reference (in a critical section), but then has no issue to get the name when logging the VA to the log. Is this repeatable?
PRieST Posted February 17 Posted February 17 15 minutes ago, sheson said: If the record 030090B4 overwritten by any plugin? I suppose it is not, which makes the error message odd, as it fails to get the "name" of the reference (in a critical section), but then has no issue to get the name when logging the VA to the log. Is this repeatable? Started DynDOLOD second time without the error. 030090B4 is not overwritten. I know DynDOLOD is based on the most recent xEdit version - with that version I get the warnings regarding the FishingModsMerged.esp which wasn't the case with earlier xEdit/DynDOLOD versions. Do you know how harmful these are? I think they were from Simple Fishing Overhaul before I merged it with some other mods. Same goes for the mentioned navmesh error which is new - all mentioned FormID from the log are not overwritten, so is this a false positive? I could provide the new logs regarding these questions (from the successful run) if needed.
LF111 Posted February 17 Posted February 17 I don't think Vortex can do what MO2 does there, but I am able to just check the files. I downloaded a texture viewer (WTV) to be able to see the .dds files, and Data\textures\dyndolod\lod\dyndolod_tamriel.dds is blank. It's telling me that the DX10 format is unknown. I tried in GIMP as well and got a similar warning about an unsupported DXGI format. I can check the files in the actual folder, I just need to know what is meant by timestamp. If it's referring to date modified, they don't match (although it might be close enough, based on what you mean by "about the same"). The .bto has a date modified of 2/17/25 at 1:15 AM, while the texture has a date modified of 2/17/25 at 1:09 AM (though the "date created" is listed as 2/17/25 at 1:17 AM... after it was modified?) Sorry if this is not at all what you mean by timestamp. In case it helps, I've uploaded the texture .dds file to the folder.
sheson Posted February 17 Author Posted February 17 5 minutes ago, PRieST said: Started DynDOLOD second time without the error. 030090B4 is not overwritten. I know DynDOLOD is based on the most recent xEdit version - with that version I get the warnings regarding the FishingModsMerged.esp which wasn't the case with earlier xEdit/DynDOLOD versions. Do you know how harmful these are? I think they were from Simple Fishing Overhaul before I merged it with some other mods. Same goes for the mentioned navmesh error which is new - all mentioned FormID from the log are not overwritten, so is this a false positive? I could provide the new logs regarding these questions (from the successful run) if needed. I am not sure what warnings in FishingModsMerged.esp you are referring to. There aren't any in the uploaded logs I can find. The Navmesh error is unrelated and should be of no consequence to LOD generation. I believe the missing triangle #382 is added by the unofficial patch, you may have a plugin undoing that change.
PRieST Posted February 17 Posted February 17 17 minutes ago, sheson said: I believe the missing triangle #382 is added by the unofficial patch, you may have a plugin undoing that change. Haven't seen any conflicts in my whole loadorder. And es said before, wasn't mentioned with earliere versions of xEdit/DynDOLOD. 24 minutes ago, sheson said: I am not sure what warnings in FishingModsMerged.esp you are referring to. There aren't any in the uploaded logs I can find. Oh, thaught it was mentioned in that one, too. I'll take a look myself and if I need further guidance I'll ask again.
sheson Posted February 17 Author Posted February 17 1 hour ago, LF111 said: I don't think Vortex can do what MO2 does there, but I am able to just check the files. I downloaded a texture viewer (WTV) to be able to see the .dds files, and Data\textures\dyndolod\lod\dyndolod_tamriel.dds is blank. It's telling me that the DX10 format is unknown. I tried in GIMP as well and got a similar warning about an unsupported DXGI format. I can check the files in the actual folder, I just need to know what is meant by timestamp. If it's referring to date modified, they don't match (although it might be close enough, based on what you mean by "about the same"). The .bto has a date modified of 2/17/25 at 1:15 AM, while the texture has a date modified of 2/17/25 at 1:09 AM (though the "date created" is listed as 2/17/25 at 1:17 AM... after it was modified?) Sorry if this is not at all what you mean by timestamp. In case it helps, I've uploaded the texture .dds file to the folder. You need to use programs or plugins that support BC7 texture compression format. IrfanView has support for example. However, the problem seems to be missing textures, e.g. a file not found. Filemanagers like Windows Explorer typically show a filetime, which usually the last time a file has been modified. The creation time is when DynDOLOD saved it. The modified time is when Texconv converted it to BC7. According to the provided log, anything within 8 minutes is probably from the same generation: [01:31] [Tamriel] Executing "C:\Skyrim DynDOLOD\DynDOLOD\Edit Scripts\LODGenx64Win.exe" --inputfile "C:\Skyrim DynDOLOD\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_Tamriel.txt" --logfile "C:\Skyrim DynDOLOD\DynDOLOD\Logs\LODGen_SSE_Tamriel_log.txt" [01:42] Creating texture atlas C:\Skyrim DynDOLOD Output\textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds .. [07:17] Waiting for LODGenx64Win.exe generating object LOD for Tamriel. [08:25] [Tamriel] Generating Pre-Computed Occlusion TVDT Having all that explained, missing textures are not the issue it seems. The uploaded diffuse texture atlas has normal map textures included (the *_n.dds textures), which are usually blue and can look like missing texture color in the game. They should only be on the DynDOLOD_Tamriel_n.dds. Check the data folder for the textures\lod\wrbuildingslod01.dds. It should be from the TexGen output. Verify that the file in the data folder has the same filesize and modfied time as the file in the TexGen output mod, or better check their CRC32 to be equal (for example with the right 7zip CRC sha option if you have that installed for example. It should not be blue. Upload both textures\lod\wrbuildingslod01.dds and wrbuildingslod01_n.dds if you want me to check.
sheson Posted February 17 Author Posted February 17 10 minutes ago, PRieST said: Haven't seen any conflicts in my whole loadorder. And es said before, wasn't mentioned with earliere versions of xEdit/DynDOLOD. Oh, thaught it was mentioned in that one, too. I'll take a look myself and if I need further guidance I'll ask again. I suggest to ask about those on the xEdit discord.
PRieST Posted February 17 Posted February 17 31 minutes ago, sheson said: I suggest to ask about those on the xEdit discord. Thaught the same as you confirmed it will not cause any LOD related issues. Thanks.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now