mrudat

I can confirm that copying MNAM and WBDT from CraftingSmelterMarker1 -> CraftingSmelterMarker1_DynDOLOD_NOFLAG also allows for using the smelter. So, I guess the next question is, is MNAM intended to be have been removed from the NOFLAG record when compared to the vanilla record?

I was having an error when attempting to use a Smelter (the constructible one at Goldenhills Plantation, though it looks like the outdoor HF smelters should have similar behaviour, though I haven't tested those), "Someone else is using this"; I finally got around to investigating why this particular smelter wasn't working. In DynDOLOD.esm, built with alpha 92, a reference to `CraftingSmelterMarker1 "Smelter" [FURN:0009C6CE]` is replaced with 'CraftingSmelterMarker01_DynDOLOG_NOFLAG "Smelter" [FURN:190017E4]'. CraftingSmelterMarker1 has three things that CraftingSmelterMarker1_DynDOLOG_NOFLAG does not: the 'Has Distant LOD' flag MNAM - Active Markers is present with the values Sit 0 and Unknown 31 WBDT - Workbench Data/Uses Skill has the value Smithing while the DynDOLOD_NOFLAG has the value None Reverting the edit to the reference, so that it points to CraftingSmelterMarker1 again, allows use of the smelter once more; it also allows NPCs to use the idle marker at the smelter. I expect that this has other effects that are undesirable, otherwise the reference wouldn't have been replaced. WBDT - Workbench Data/Uses Skill - Smithing on CraftingSmelterMarker1 comes from Complete Crafting Overhaul_Remastered.esp, and is faithfully copied into DynDOLOD.esp, which is where the 'Has Distant LOD' flag is added as well. MNAM - Active Markers comes from Skyrim.esm, and I'm uncertain what benefit removing it has; ...do markers work even if the reference is disabled? I'm going to try copying MNAM and WBDT from CraftingSmelterMarker1 -> CraftingSmelterMarker1_DynDOLOD_NOFLAG to see if that also allows using the Smelter.

I don't suppose that it would be possible to change xLodGen to write output by default into <installation path>\xLodGen Output, similar to what DynDOLOD currently does? I was surprised to find that, by default, it writes into the game path; I had expected similar behaviour to the other tools that are under active development. Happily since I use MO2, fixing things shouldn't be terribly difficult, now that I've read the relevant section of the fine manual, and output isn't being written into the game directory.