Blackread

I have another LOD related (not necessarily DynDOLOD though) problem that I was hoping you might be able to help with. I have two different colours of dynamic snow on my map: From inspecting the .bto files in Nifskope it looks like the bright snow is on objects tagged with objSnow, and the dark snow is on objects tagged with objSnowHD. Ideally I would like to have snow that's somewhere between the two in terms of brightness, but I would take anything that has consistent colours. I am using Better Dynamic Snow 3.5.0 and the plugin is winning all conflicts for the snow materials so they should be consistent as far as I know. What's more this only happens on the map, i.e., LOD32. The other LOD levels have the right coloured dynamic snow. I generated the LOD with Level32 enabled, and I'm using A Clear Map of Skyrim with all the bells and whistles. I also tried changing uLockedObjectMapLOD to 16 in the INI file and it does fix the dynamic snow colours (while "downgrading" the map to LOD16 of course), so it would seem it's something specific to LOD32. Here are the logs for the output that the screenshot was taken from: https://mega.nz/file/dGsRXKwJ#_fpzVNJvzMed6VUtOwbSxemUmdG46hFONvZGk2ls6V0

With Tamriel+Solstheim only I saw the glow objects again. Here are the logs for the run with Alpha-128: https://mega.nz/file/8KUliL7K#KMpnilaom0i1mixB2dyeCEoZzy0vPM7hhdIV_mkTCXM And here are the logs for the run with the test version: https://mega.nz/file/BGMjSSTL#9ollcacv56J8TjpsGI4T0QetZl1n2gE9W2wCb242UOc

Here are the logs: https://mega.nz/file/kC8BiLpD#Sa6Me1XBwKPjuWPSlciYokVo5SE55OgmeU8yaFMqjZc By the way, out of interest I tried the output from this run and couldn't find any stuck glow LOD anywhere.

Done, here are the logs: https://mega.nz/file/RWVw3SwA#02sF3-_J7NUfePCXKRlbaZRb0EU_BXxu_kBIJE0orAk

I ran it twice, the program crashed pretty early on in both cases. Logs for the first run, no error message: https://mega.nz/file/5O0DzZaR#fL_dCdPRd4FlDb3bBOsPeKnXOmG_fJcn6HM38VHZNIY Logs for the second run which did produce an error message: https://mega.nz/file/tG8EWCTY#sHnJkFURMHLcq77BVz59eaT-2oyW_ckfPmXB7GrdZgQ I included the bugreport.txt too.

Alright, sounds awesome! Will it include mod added objects too? The ferry is from CFTO, but it happens with fast travel from the map too. Here are the files you requested: https://mega.nz/file/RCtVDSbZ#2P11jMrC-D8U-ZkmNYcWRhmi-jhzqUXs0VmTA0zRbp8 The Papyrus and DynDOLOD logs are from a session where I loaded a save inside the AP room, spawned to Retching Netch and fast travelled (from the map) to tel mithryn.

Just remembered there was one other thing I wanted to ask. With the same LOD generation the area around Riften looks like this viewed from inside the city: The first picture is from the Jarl's balcony, the other two from the canals. Is this the expected result? I just wanted to ask to make sure I haven't screwed something up again before trying to fix it.

No idea what happened there xD Here's the correct link: https://mega.nz/file/dGsRXKwJ#_fpzVNJvzMed6VUtOwbSxemUmdG46hFONvZGk2ls6V0

Hello Sheson, I am once again experiencing some issues with stuck glow LOD (I think). This time it's with the lanterns outside Better Tel Mithryn. Imgur Gallery When inspecting the LOD I started a new game with Alternate Perspective and spawned in the Retching Netch. Then I exited the bar, waited for DynDOLOD to initialize and took the ferry to Tel Mithryn. Here are the EditorIDs for the glow statics I could find: telmithrynesp_040FF0_DLC2SolstheimWorld_DynDOLOD_LOD telmithrynesp_040FED_DLC2SolstheimWorld_DynDOLOD_LOD telmithrynesp_03E10C_DLC2SolstheimWorld_DynDOLOD_LOD telmithrynesp_040FF2_DLC2SolstheimWorld_DynDOLOD_LOD telmithrynesp_078BF5_DLC2SolstheimWorld_DynDOLOD_LOD telmithrynesp_040FF3_DLC2SolstheimWorld_DynDOLOD_LOD telmithrynesp_040FF4_DLC2SolstheimWorld_DynDOLOD_LOD Logs for the LOD generation

How important are the cell editor IDs for DynDOLOD to function? I've been using this Synthesis patcher https://github.com/Deigue/CellEditorIDFixer and I recently noticed that it's also removing underscores from the editor IDs of some cells generated by DynDOLOD. I also have another unrelated question: is swapping large references with Base Object Swapper supported?

I checked this tree issue in my game to see if it's happening, but it doesn't seem to be. When the cells load the LOD trees turn into full models as expected. However I did notice that when turning on large refs, the trees turn invisible in the large ref grid, like the ones I reported around Kynesgrove.

Yes, looks like the rules indeed do not resolve.

I found a fairly minimal reproducible example. Here are the mods I had active: If generating LODs with these mods the passthru for the tree (with the flat trunk) where xx06312f would be is added. Editor ID: unofficialskyrimspecialeditionpatchesp_06312F_unofficialskyrimspecialeditionpatchesp_06312F_DynDOLOD_REVERT_DynDOLOD_CHILD The TGC Solitude installation is stock from the Nexus, and doesn't edit any USSEP records. Here are the logs for this run.

Alright, thank you for the explanation. The only things I don't understand now are these: xx06312f doesn't have an equivalent object in the Tamriel worldspace. So there was never any tree that was removed in the Tamriel worldspace, and thus no need to remove xx06312f from the Solitude world space. But for some reason this tree was still transported in that mutilated form into the Tamriel worldspace. Disabling the tree xx063127, which is the Tamriel equivalent to xx063133, with USSEP Tree Disable.esp has no adverse side effects, but when done with TGC Solitude Fixes.esp, it does. Though I suspect it has nothing to do with either of these plugins, but something else entirely... But these things will likely remain a mystery. TGC Solitude Fixes.esp

There are two ways to tell LOOT where to put a plugin: load after rules and groups. If you tell LOOT to load WfE after Lux.esp, it only ensures that WfE loads after the main Lux.esp. You would have to specify a load after rule for each Lux patch you need WfE to load after. So in this case it's probably better to use groups instead. The LOOT masterlist assigns Lux.esp into the Interior Lighting group I think. Because all the Lux patches have Lux.esp as a master, this ensures that all the Lux patches are effectively placed in that same group, even if they haven't been assigned to it. So in order to load WfE after Lux and all its patches, it should be assigned in a group that loads later than Lux. You can see the groups and their order through Game -> Edit Groups (this can't be opened if you have metadata for a plugin open). For example in my setup WfE is assigned to the group Late Loaders.

Out of interest I also tried generating LOD with just USSEP, Happy Little Trees, the DynDOLOD 3 Addon for HLT and a custom plugin that disables xx063127 from USSEP. Nothing weird happened, and the tree was gone as expected, no passthru models were put in its place, or on the spot of xx06312f. Not sure what's going on in my main modlist that prompts it to happen. Here are the logs and the plugin if you're interested. USSEP Tree Disable.esp

I don't think I have edited any of the ini files except for DynDOLOD_SSE.ini, here's what's in the list: Ignore=treereach, treepine, treeaspen, treeclover, treegourd, treekelp, treethicket, treevine, gkbtree, jungletree, cedartree, shrub, fern, flora, wrtreecircle, windmill, mountain, rock, fxwater, water1024, rapids, dirtcliff, drift, road, hay, wrpondwall, fence, stonewall, shackroof, impstoneblock, whprisonwallcap, whouterwallstatue, mrkmillroof01, crafting, fxglow, whgate, whdoorfrontgate, slightpost, signrtpost, mrkkeepcollonadecolm, mrkbrazierhangingdeco, mrkwarrensarch, mrkarch, candlehorn, candlel, candles, candle0, rtcanals, rtlamppost, fxmist, door I disabled those two trees in the Solitude worldspace, regenerated LODs and now the problem trees in Tamriel are gone, thank you. I don't quite understand how these trees work though. I was checking them in game with just USSEP enabled, and I could see the same refs in both the Tamriel and Solitude worldspace. And even though the ref is placed in the Solitude worldspace, player.moveto xx06312f teleports me into the Tamriel worldspace. Same with that other tree, xx063133. xx063133 has an equivalent tree with the same position in the Tamriel worldspace, xx063127, and these trees appear on top of each other in the Tamriel worldspace (like duplicated objects). But I can't seem to find a tree in the Tamriel worldspace with the same position as xx06312f.

Here are the Editor IDs for the trees outside Solitude: Tree1: unofficialskyrimspecialeditionpatchesp_063133_unofficialskyrimspecialeditionpatchesp_063133_DynDOLOD_REVERT_DynDOLOD_CHILD Tree2: unofficialskyrimspecialeditionpatchesp_06312F_unofficialskyrimspecialeditionpatchesp_06312F_DynDOLOD_REVERT_DynDOLOD_CHILD Editor ID for the Solitude windmill rotor: DynDOLOD_SSE_skyrimesm_tamrielpatch_000004_DynDOLOD_PATCH_SolitudeWindMillFan_Tamriel_DynDOLOD_LOD Editor ID for the windmill rotor outside Whiterun: skyrimesm_096272_Tamriel_DynDOLOD_LOD

Lol I'm an idiot. No they are not LOD, they are regular objects that just look a bit like LOD with the billboard trunks. Can even click on them with console. I'll post the pictures with full details, but basically they are placed by DynDOLOD.esm. Edit: Took the pics accidentally with the wrong LOD, posting real pics soon. Edit2: Console pics:

Yes, that is the full path of the windmill fan mesh. Here are the CRC 32s for the meshes: CRC32 Size Name -------- ------------- ------------ 84C846CE 349922 farmhousewindmillfan.nif 26C45CC6 349922 farmhousewindmillfan02.nif 23C240AD 349922 smfarmhousewindmillfan.nif I wasn't able to find any of the form IDs related to that particular tree outside Solitude in that txt file. All three of the Kynesgrove trees screenshotted were moved to another cell by The Great Village of Kynesgrove.esp, as you suspected. Just realised something related to the lod-looking tree models outside Solitude: I used Billboard4 for LOD4 and LOD8, Billboard1 for LOD16 and Billboard6 for LOD32, so I shouldn't even have any of the hybrid tree models with 3D branches in my game.

Moving the conversation here, as it is starting to look like this might indeed be a bug. I reran DynDOLOD with the latest version, and this time the solitude windmill is using the swindmillrotor.nif model as it should. However, the farmhouse windmills are using Farmhousewindmillfan.nif, despite smfarmhousewindmillfan.nif being present during LOD generation. I also have some problems with trees. Outside Solitude there are some tree LOD models in a loaded cell. I don't think these trees have an associated full model in that location. In the place of one of these there used to be a tree added by USSEP. I made it into an UDR, and now there's just the LOD model instead. If I disable TGC Solitude Fixes.esp, I get this tree on top of the LOD model on the right. Then there's a bunch of trees near Kynesgrove that behave erratically. In LOD4 they can be seen in the distance. Then when I go closer and the trees enter the large ref grid they disappear. When the cell loads properly they appear again. I am using large trees as large refs - which btw is a fantastic feature, thank you very much for adding it. Here are the logs as usual. I also checked Papyrus logs, but there were no DynDOLOD related errors or warnings. Edit: My uGridsToLoad is 5 and uLargeRefLODGridSize is 9. If disabling large refs by setting uLargeRefLODGridSize to 5 the trees at Kynesgrove no longer disappear. I'm using the DynDOLOD DLL NG and Scripts large ref workarounds.

The spot where the glitch happens is indeed where the cell changes. I did three tests, two of the logs had dyndolod errors. I checked the activators and they were both empty. The activators were present in Helgen prior to teleporting, but as soon as I arrived to theshire they were emptied and never filled again. However, afterwards I did two tests where I waited considerably longer, a minute or two past getting the initialization message. Those times when I teleported to theshire the activators were there, and there were no LOD glitches. Maybe it just needs a bit more time for things to settle? Or maybe there's some other initialisation going on that messes things up.

Sorry about the sloppy report. I can't reproduce it elsewhere so I'll focus on The Shire, as it seems to be easily reproducible at least on my setup. Here's a new video that shows the whole process: And here are the logs for this LOD generation: https://mega.nz/file/IGsFDa7Z#kcMgWwnAkBc6lj3TcJEYq-Y4BBNbv1r8D75QFWed2AU Written steps of how to reproduce: 1. Start a new game 2. Exit character creation and wait a few seconds in the starting cell 3. Leave the starting cell. Once in an exterior, wait until the message DynDOLOD successfully initialized is displayed 4. cow theshire 0 0 5. You should see some hobbit holes and a path in front of them. Follow the path to the west up a hill 6. Roughly atop the hill should be a spot where some parts of the LOD flash as you pass over it. It's not possible to stop in a spot and have the LOD disappear for an extended period of time, or at least I can't do it. I'm using the Alpha-4 version of DynDOLOD DLL NG downloaded from this link

No, couldn't find any bugged glow LODs with that one. This also sometimes happens with the LODs: I haven't yet figured out what causes it. The footage was recorded in The Shire, but I have also seen it in the Tamriel worldspace, near Solitude and Whiterun.

Problem does happen with a new game. Data files for the NG generation. Logs and data files for the Tamriel test generation. I used the default scripts in DynDOLOD resources SE 3, so PapyrusUtil I believe. Trace and DebugInformation were turned off. Two Papyrus logs with them turned on.