Blackread

Excellent, thank you.

I haven't managed to complete the troubleshooting for the on load crashes yet, still working on it. But I wanted to ask for some clarification about how texture transparency works with LODs. The dyndolod website states the following: If the full model texture uses alpha, will the parts of the texture below the threshold always be transparent, even if the LOD model in question doesn't have a NiAlphaProperty in the block that uses said texture? So if I don't want the texture to be transparent at all, is the only way to make a dedicated object LOD texture without alpha?

Hello sheson, I'm seeing crashes on loading a save with the latest DynDOLOD 3 Alpha. The basic sequence leading to the crash is: Make a save in an exterior location -> Go somewhere else -> After a while load the save -> Crash. Here's a video of a repeatable test I deviced. It looks a bit odd, but the crash does happen during normal gameplay too. It's uncut footage including all loading times, the main test starts around 2:25. Here's the top part of the crash log produced for quick examination: Full crash log along with DynDOLOD logs here: https://mega.nz/file/sPlDHADb#eP0vryOYQeVPwuYiHEDCT_DoPAFc02nXDmvKr3bPqUA Another user also gave similar reports about crashing on load with this crash log: https://pastebin.com/vgx3Kiz7 I've also seen this crash at 902691 but the one at C072DF is a lot more common for me. The other user said that after regenerating LODs without Large Ref Bug Workarounds they were no longer crashing, but I haven't verified this myself. I have however been unable to replicate the crash without a DynDOLOD output. Edit: I also noticed that while the link to the DLL NG download on dyndolod.info says Alpha-15, the downloaded file is actually Alpha-14.

One more related question, what are these h and l suffixes on the files? Do they stand for high and low, or something else?

Here: https://mega.nz/file/ZGlHnDYZ#8Yu6xGt9aEVE6di0UEedQJSv7Sz7qj9lpgAAilIixhs

This is what DynDOLOD is telling me: If I'm reading it right, it's trying to match xxx.nif with xxxsnow_lod_[0|1|2|3].nif even though xxx_lod_[0|1|2|3].nif is also present. Logs: https://mega.nz/file/sLNWAKSL#MkTheTPb1ywwjcndCPjcp4TwWiGrHTKXYn8FA2w-Y-w

Is there a guide on how the *snow_lod_x.nif files are matched to the full models? I read through the Mod Authors page but couldn't find mentions about them. Also, do the snow lod models support the same CRC system as the "normal" lod models? If I have, say, tundrastreamend01_1234ABCDsnow_lod_0.nif, will that be matched with a tundrastreamend01.nif with CRC32 1234ABCD whenever it's considered "snow", or with every use of tundrasteamend01.nif?

The test version fixed the stuck glow LODs.

The swap file generated by DynDOLOD is not working. Looks like Base Object Swapper is strict about the letter case: the _SWAP suffix needs to be all upper case, and the file generated by DynDOLOD has it in lower case. Pictures, in order: 1. Fence in WhiterunWorld as is 2. Fence in WhiterunWorld after renaming the file to DynDOLOD_SWAP.ini 3. Original fence in Tamriel. EDID of the fence copy is skyrimesm_0627B3_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD There's also this bit of road sticking through the Whiterun front gate: 1. Road in WhiterunWorld 2. Original road in Tamriel (the gatehouse was disabled when taking the screenshot) EDID of the road copy: skyrimesm_069818_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD Lastly the dark elf lantern glow LOD has made a return. I didn't see them with Alpha-134. EDIDs, respectively: telmithrynesp_078BF5_DLC2SolstheimWorld_DynDOLOD_OBJECT telmithrynesp_040FF2_DLC2SolstheimWorld_DynDOLOD_OBJECT Logs: https://mega.nz/file/YbU33bCS#orQb99fQmxXAdE3TPJ6BRRZRxtbBVdFkyMogM432rqg

Sounds like a good solution, thank you. I also have a suggestion of a few lines to be added to \DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_SSE_ChildworldMatches.txt to fix a few issues when copying SolitudeWorld with NoCellsWithNAVM=0: The details for the issues are at the bottom of my comment here: I generated Tamriel LOD with these additions and the end result looked good to me.

Here: https://mega.nz/file/NGtgRJDb#6_qQlqMbMp98j0O2zmDZJV_s844_1KJenJmBXxVccHA I only included the Tamriel.4.-44.0 and Tamriel.4.-44.-4 blocks, I assumed you didn't want the whole of Tamriel.

Thank you I got the terrain LOD to work now. However, the underside is still in the way. For some reason it looks like I'm getting a hole in the cell -43, -1 where I hid quads 3 and 4, but not in the cell -43, 0 where I hid quads 1,2,3 and 4. First picture is from inside the mine tunnel, looking towards Markarth. The last picture is from under the terrain. The black tube is the mine tunnel, which pierces the underside. The gap in the underside is visible above it. Logs and the plugin I used to hide the terrain. It was placed dead last in my load order while generating, so shouldn't be overwritten by anything. https://mega.nz/file/RG1mAbKC#4dlXjUlkrZkNXjB_JcCYHyl3sF8TO3-MkbMMJBKOvzE

I noticed that some dock corner pieces are rotated 90 degrees clockwise in the LOD, despite the lod and full model meshes being perfectly aligned. Here are pictures of one example: Caption for the pictures in their order of appearance: 1. The dock copy as seen in the child worldspace (SolitudeWorld) 2. The dock LOD as seen in the child worldspace 3. The original dock as seen in the parent worldspace (Tamriel) 4. The dock LOD as seen in the parent worldspace EDID of the dock copy: skyrimesm_01991F_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD Logs: https://mega.nz/file/8adAyAyb#MD_N7VeQYpMyLxIRf2nGm5IlU-2YVMgbRBro4r2kWY4 The full model dock is from Static Mesh Improvement Mod, and the LOD model is from DynDOLOD Resources SE.

Very true, and I have barely any mods modifying the exterior areas of cities, with Solitude being the exception, so my load order is fairly easy on that regard.

That is true, but I checked pretty much the whole of Riften and couldn't find any rogue objects anywhere.