LF111

Sweet, thanks. I've just made a note to remind myself to make sure that I generate after No Grass is unchecked via DynDOLOD in the event I have to reinstall again at some point in the future or if something goes wrong, as I still want to only load from the generated cache.

"No Grass" was unchecked for DynDOLOD.esp, but was checked for Occlusion.esp. I edited Occlusion to uncheck the box, saved the changes in xEdit, and redeployed all files (getting the confirmation notification that DynDOLOD_Output.zip was modified), yet the grass is still missing in-game, so unchecking it did not seem to do anything. This was done with Resources Alpha 55 and DynDOLOD Alpha 190. Edit: Never mind, unchecking the box did in xEdit did fix the issue, I just had to regen or disable NGIO (this has happened in the past, where if you generate NGIO on a freshly installed/reinstalled game before generating DynDOLOD, exterior grass won't appear; I had reinstalled when the weird form ID error was happening). NGIO was not the cause of the original issue (as I'd already tested that), but rather it appears to be something not forcing Occlusion to uncheck the box.

Same thing happening on my end with that piece of CC content, Alpha 189 is the first time it's ever been an issue. Copying from a separate post in which I mentioned the issue: As a side note (I didn't want to make this its own thread because I resolved the issue, but nevertheless think it's worth bringing up): When generating a new output on Alpha 189 and the newest Resources mod (wanted to see the new rock wall LOD), I got a notification about an unresolved form ID in cctwbsse001-puzzledungeon.esm. I went through the steps to find the errors in xEdit (there were two such errors in that plugin) and deleted the relevant properties, as both errors were for VMAD script properties. I was able to generate with no problem after doing that, but I felt I'd bring it up here since I've never gotten that warning before on past DynDOLOD versions and because that plugin is one of the AE creations/DLCs. As a test, I reinstalled the base game + AE creations and the same two form ID errors returned, which means they've probably been there all along. Just found it strange that I'm only now getting warnings about it, and I just want to make sure that it's safe to delete those properties for CC content. (Note: I am using the Unofficial CC Patch, too, and have been for a while).

I'll take you up on that explanation offer. As a side note (I didn't want to make this its own thread because I resolved the issue, but nevertheless think it's worth bringing up): When generating a new output on Alpha 189 and the newest Resources mod (wanted to see the new rock wall LOD), I got a notification about an unresolved form ID in cctwbsse001-puzzledungeon.esm. I went through the steps to find the errors in xEdit (there were two such errors in that plugin) and deleted the relevant properties, as both errors were for VMAD script properties. I was able to generate with no problem after doing that, but I felt I'd bring it up here since I've never gotten that warning before on past DynDOLOD versions and because that plugin is one of the AE creations/DLCs. As a test, I reinstalled the base game + AE creations and the same two form ID errors returned, which means they've probably been there all along. Just found it strange that I'm only now getting warnings about it, and I just want to make sure that it's safe to delete those properties for CC content. (Note: I am using the Unofficial CC Patch, too, and have been for a while). Edit: I saw some other people in the main Alpha 189 thread having the same issue with that CC content out of nowhere, so I've copied that portion of my reply there as well.

Checked out the new version, everything matches now. Many thanks.

Sorry if this isn't the right subforum for Resources reports, but: As stated in the title, exterior grass is not showing up when inside Whiterun, despite ticking the check in the FOMOD. I've tried fresh generations (though that might not be necessary), a new NGIO cache generation, reinstalling Resources, and disabling NGIO and my grass mods to test on vanilla grass; all give the same result. Pre-Alpha 54 versions worked for me, and while I've done a few generations on the current version since it released, this is the first time I've been in Whiterun and noticed it. Logs (although I don't know how relevant they are for this).

Hello once more. Now that all the previous funkiness is out of the way, I can send over the rock wall LOD stuff. The combination of mods I am using is High Poly Project + Rock-Wall Texture Patches for High Poly Project at Skyrim Special Edition Nexus - Mods and Community, using the Majestic Mountains - Main file. Interestingly enough, though, the problem has changed since I first mentioned it. Before, the LOD models would appear like sort-of white amorphous blobs, which led to me turning off the retexture during generation so that the rock wall LODs looked like Skyland's (my base texture overhaul). The thinking was that the transition would be far less jarring since the colors would mostly line up. Well, after regenerating today, the LODs match Skyland's even with the retexture mod turned on. That is, no more white blobs. Pics. This current result doesn't bother me at all, but I figured it's still worth posting here, just in case there should be a proper LOD model/texture for what I have enabled (it's worth noting that there doesn't seem to be a LOD model for the HPP rock wall at all, regardless of the retexture, hence why it's reverting to Skyland's model even though I have HPP overwriting Skyland). This may be a non-issue now. Logs.

Test version has completely fixed the issue on my end. Do you still want me to start a new thread for the rock wall LOD texture issue, or should I just continue it here?

The file in the data folder has the same modified time as the TexGen output file and is the same size. Folder has been updated with the two files. Testing the test version now.

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.

I do not use MO2, unfortunately, so I cannot check it that way. How else can I go about troubleshooting?

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.

This is continuing on from my previous thread about the seams/Occlusion record forwarding issue. I was going to regenerate LODs so I could start a new thread on the rock wall meshes that you wanted me to report on with matching logs, and I noticed that Alpha 187 was uploaded to Nexus, so I grabbed that first. Generating on Alpha 187 is causing some... issues. There are purple LOD textures and strange terrain blocks everywhere. There is no difference in my load order between what I generated two days ago for the water seam tests (on Alpha 185); these issues appear to be tied to 187 (and I also noticed the version of TexGen that ships with Alpha 187 is still on Alpha 186, and it's giving me a "more recent version is available" line at the bottom of the window). Logs. I noticed the debug log is truncated, which is probably due to me booting up and then immediately cancelling DynDOLOD to verify that it was version 187 after I noticed that TexGen was still on 186. Let me know if you need me to do another generation in order to produce a fresh debug log. I've attempted a fresh TexGen and DynDOLOD generation twice on 187, and got the same issues both times. The second attempt was done as cleanly as possible, disabling DynDOLOD and creating a clean interior cell save. After I get this figured out, I'll start a new thread on the rock wall.

The new exe fixed the issue. The xEdit records match and the seams have been eliminated everywhere in the game that I was aware of them. Many thanks.

xEdit Results Occlusion.esp is not matching the preceding RW2 record in the cell at the Riften Docks, and is instead matching the records of the mods that precede RW2, which I believe is what's causing the seam. Every LOD generation has been done with RW2 enabled, so I don't know why DynDOLOD isn't matching it. I can confirm the three generations done over the last two days have all been on the exact same load order, with no mod being added or subtracted after enabling the TexGen and DynDOLOD outputs, other than an High Poly Project rock wall retexture I only enable after generation, as generating with it enabled results in white LOD textures for the walls (and just to be safe, I did a generation with it enabled the whole time, and predictably it had nothing to do with the water issue).