Mousetick Posted October 30, 2023 Posted October 30, 2023 18 hours ago, sheson said: Check if the DynDOLOD log has "Disabled success? ..." and/or "Disabled failed? ..." messages. Annotated DynDOLOD.log: Spoiler Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Worlds.txt Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Tamriel.txt Enable - Reference 7D3022EC Base 5A231849 Flags 40010C08 lod\clutter\stockade\stockadegate01_lod_0.nif # Approach watchtower by foot (dynamic LOD is effectively disabled) Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled success? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif # Move away Enable - Reference 7D3022EC Base 5A231849 Flags 40010C0A lod\clutter\stockade\stockadegate01_lod_0.nif # Fast travel to Windhelm (after which point it's actually never disabled) Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled failed? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled success? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled success? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled success? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif # At some point in this sequence, fast travel back to Whiterun # Approach watchtower by foot Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled success? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled success? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled success? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Note there is one occurrence of 'Disabled failed?' 18 hours ago, sheson said: Maybe try this: ... Yeah, that's a good idea, but I'm going to pass. Unless you'd like to try to keep troubleshooting with more debug versions of DynDOLOD.dll, I'm going to put this whole issue aside for now. It appears to be isolated to EWWDSB, and may be specific to my load order or configuration, so I don't think it's worth spending that much time into it. Aside from the dynamic LOD references remaining always enabled and the resulting visual glitches, there are no game-impacting side-effects. Perhaps I'll tackle your suggestions later when I have more time and nothing more important. I have to say it's really strange and puzzling though. These references are defined in DynDOLOD.esp. I'm pretty sure absolutely nothing else touches or uses them. And they're no different in how they're defined in the plugin, compared to other dynamic LOD references. I even tried disabling some big engine-level SKSE plugins (NetScript Framework, Bug Fixes SSE, Papyrus Tweaks NG, powerofthree's Tweaks, Scrambled Bugs, ...) which made no difference. Thanks for your assistance. Dynamic LOD failing to disable on fast travel (Continued) I edited DynDOLOD_NG_Tamriel.txt and removed all 'Environs - Whiterun Watchtower.esp' entries, except the one for 3154668 (hex 3022EC). Now 7D3022EC disables and enables successfully on fast travel and DynDOLOD.log shows all 'Disabled success?'. I'm going to add them back in batches until it breaks again. I don't understand why everything seemingly works fine when changing cells while moving by foot but doesn't when fast traveling. Is there a difference in how DynDOLOD.dll handles these 2 cases? Are dynamic LOD references disabled/enabled serially or all in parallel? If they're processed serially, is the order in which they are disabled/enabled always the same or random? If the order is constant, is it the order in which they are listed in DynDOLOD_NG_Tamriel.txt? Thanks.
sheson Posted October 31, 2023 Author Posted October 31, 2023 17 hours ago, Mousetick said: Annotated DynDOLOD.log: Reveal hidden contents Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Worlds.txt Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Tamriel.txt Enable - Reference 7D3022EC Base 5A231849 Flags 40010C08 lod\clutter\stockade\stockadegate01_lod_0.nif # Approach watchtower by foot (dynamic LOD is effectively disabled) Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled success? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif # Move away Enable - Reference 7D3022EC Base 5A231849 Flags 40010C0A lod\clutter\stockade\stockadegate01_lod_0.nif # Fast travel to Windhelm (after which point it's actually never disabled) Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled failed? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled success? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled success? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled success? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif # At some point in this sequence, fast travel back to Whiterun # Approach watchtower by foot Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled success? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled success? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disable - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Disabled success? - Reference 7D3022EC Base 5A231849 Flags 4001040A lod\clutter\stockade\stockadegate01_lod_0.nif Note there is one occurrence of 'Disabled failed?' Yeah, that's a good idea, but I'm going to pass. Unless you'd like to try to keep troubleshooting with more debug versions of DynDOLOD.dll, I'm going to put this whole issue aside for now. It appears to be isolated to EWWDSB, and may be specific to my load order or configuration, so I don't think it's worth spending that much time into it. Aside from the dynamic LOD references remaining always enabled and the resulting visual glitches, there are no game-impacting side-effects. Perhaps I'll tackle your suggestions later when I have more time and nothing more important. I have to say it's really strange and puzzling though. These references are defined in DynDOLOD.esp. I'm pretty sure absolutely nothing else touches or uses them. And they're no different in how they're defined in the plugin, compared to other dynamic LOD references. I even tried disabling some big engine-level SKSE plugins (NetScript Framework, Bug Fixes SSE, Papyrus Tweaks NG, powerofthree's Tweaks, Scrambled Bugs, ...) which made no difference. Thanks for your assistance. Dynamic LOD failing to disable on fast travel (Continued) I edited DynDOLOD_NG_Tamriel.txt and removed all 'Environs - Whiterun Watchtower.esp' entries, except the one for 3154668 (hex 3022EC). Now 7D3022EC disables and enables successfully on fast travel and DynDOLOD.log shows all 'Disabled success?'. I'm going to add them back in batches until it breaks again. I don't understand why everything seemingly works fine when changing cells while moving by foot but doesn't when fast traveling. Is there a difference in how DynDOLOD.dll handles these 2 cases? Are dynamic LOD references disabled/enabled serially or all in parallel? If they're processed serially, is the order in which they are disabled/enabled always the same or random? If the order is constant, is it the order in which they are listed in DynDOLOD_NG_Tamriel.txt? Thanks. Test with this version https://mega.nz/file/sFIAQD4Y#OvGeausKp63By1g43zcYLks585xW0yh7KNxz7X5hJ2c and check/upload DynDOLOD.log.
Mousetick Posted October 31, 2023 Posted October 31, 2023 27 minutes ago, sheson said: Test with this version https://mega.nz/file/sFIAQD4Y#OvGeausKp63By1g43zcYLks585xW0yh7KNxz7X5hJ2c and check/upload DynDOLOD.log. Disables are not logged anymore: Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Worlds.txt Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Tamriel.txt Enable - Reference 7D3022EC Base 5A231849 Flags 40010C08/00000040 lod\clutter\stockade\stockadegate01_lod_0.nif Enable - Reference 7D3022EC Base 5A231849 Flags 48010C08/00000040 lod\clutter\stockade\stockadegate01_lod_0.nif # There should be one Disable here Enable - Reference 7D3022EC Base 5A231849 Flags 40010C0A/00000040 lod\clutter\stockade\stockadegate01_lod_0.nif # There should be at least one Disable here
Mousetick Posted October 31, 2023 Posted October 31, 2023 I made another test. I edited DynDOLOD_NG_Tamriel.txt and removed all [Object] entries except those associated with 'Environs - Whiterun Watchtower.esp'. 7D3022EC was successfully disabled and re-enabled on fast-travel. Upon coming back from the fast-travel roundtrip and looking at the watchtower with its cell(s) attached, all the dynamic LOD associated with EWWDSB was correctly disabled. I don't know what happened to it while fast-travelling back and forth since DynDOLOD.log only logs one ref at a time, but I'm assuming it was disabled and re-enabled successfully like 7D3022EC. My DynDOLOD_NG_Tamriel.txt is fairly large. There are 6237 [Objects] entries in total. EWWDSB alone has 142 entries. That's quite a few references to keep track of. Is it possible we're hitting some kind of limit, or a performance bottleneck? My PC is a potato by today's standards. Also, is it possible that DynDOLOD.log is not telling the truth when it says "Disable XYZ" or "Enable XYZ", and internally DynDOLOD.dll actually tries to disable/enable some bogus non-existent reference for whatever reason? Thanks.
sheson Posted October 31, 2023 Author Posted October 31, 2023 3 hours ago, Mousetick said: Disables are not logged anymore: Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Worlds.txt Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Tamriel.txt Enable - Reference 7D3022EC Base 5A231849 Flags 40010C08/00000040 lod\clutter\stockade\stockadegate01_lod_0.nif Enable - Reference 7D3022EC Base 5A231849 Flags 48010C08/00000040 lod\clutter\stockade\stockadegate01_lod_0.nif # There should be one Disable here Enable - Reference 7D3022EC Base 5A231849 Flags 40010C0A/00000040 lod\clutter\stockade\stockadegate01_lod_0.nif # There should be at least one Disable here Despite there not being a log message, is the dynamic reference disabled? 1 hour ago, Mousetick said: I made another test. I edited DynDOLOD_NG_Tamriel.txt and removed all [Object] entries except those associated with 'Environs - Whiterun Watchtower.esp'. 7D3022EC was successfully disabled and re-enabled on fast-travel. Upon coming back from the fast-travel roundtrip and looking at the watchtower with its cell(s) attached, all the dynamic LOD associated with EWWDSB was correctly disabled. I don't know what happened to it while fast-travelling back and forth since DynDOLOD.log only logs one ref at a time, but I'm assuming it was disabled and re-enabled successfully like 7D3022EC. My DynDOLOD_NG_Tamriel.txt is fairly large. There are 6237 [Objects] entries in total. EWWDSB alone has 142 entries. That's quite a few references to keep track of. Is it possible we're hitting some kind of limit, or a performance bottleneck? My PC is a potato by today's standards. Also, is it possible that DynDOLOD.log is not telling the truth when it says "Disable XYZ" or "Enable XYZ", and internally DynDOLOD.dll actually tries to disable/enable some bogus non-existent reference for whatever reason? Thanks. Set debug=true to show log messages for all dynamic references. Use this version https://mega.nz/file/ZBZ23LyY#mch6Mk67b0l2RwRbf4qaT9FQ3At7B2Pm61uClGCtLnw which should log the intent to disable dynamic references again. The test would be to see if there is any change with specific references not being disabled.
Mousetick Posted October 31, 2023 Posted October 31, 2023 (edited) 8 hours ago, sheson said: Despite there not being a log message, is the dynamic reference disabled? Not in the second instance (after fast travel). So no change from previous. But you can ignore that, because the results from the latest test version are much more interesting. 8 hours ago, sheson said: Use this version https://mega.nz/file/ZBZ23LyY#mch6Mk67b0l2RwRbf4qaT9FQ3At7B2Pm61uClGCtLnw which should log the intent to disable dynamic references again. The test would be to see if there is any change with specific references not being disabled. I switched to debug=true which produces much bigger logs so I'm attaching them rather than copying them inline here: DynDOLOD TEST1.7zDynDOLOD TEST2.7zDynDOLOD TEST3.7z Test 1: Load clean save. Exit Whiterun meadery. Fast travel to Windhelm stables. Test 2: Load clean save. Exit Whiterun meadery. Run in a large circle around Whiterun. Stop in front of the meadery. Test 3: Use DynDOLOD_NG_Tamriel.txt edited to contain only EWWDSB entries. Load clean save. Exit Whiterun meadery. Fast travel to Windhelm stables. My comments/observations on the logs: In Test 1, after landing at Windhelm stables, all the enables/disables initially succeed. Then one disable fails (7D30226D, which happens to be associated with EWWDSB). Then all the following disables fail, affecting dynamic LOD references from multiple sources, but mostly from EWWDSB. The last one in the first failure sequence (7D3022F7) is associated with a vanilla reference from Skyrim.esm (0D3F85). Then everything works again, until it doesn't. This repeats a few times. At one point the failure sequence affects both enables and disables equally, again from multiple sources, including vanilla references. For example, 7D3020C6 is the dynamic LOD of 0E94A9 and it fails to enable. In Test 2, everything looks good mostly. Except at one point there is a string of continuous enable failures. Some or all, I didn't check, of these references were already enabled earlier. In Test 3, the log is clean. The failures followed by successes followed by failures and so on, each happening in continuous "bursts", make me think the issue could be DynDOLOD.dll might be trying to enable/disable references when the engine is busy or in a state incompatible with manipulating references "behind its back" so to speak (e.g. Papyrus VM running). I had "Autosave on travel" enabled. I disabled it but it made no difference. I don't think another mod could be interfering. It can't be a plugin. Nothing overwrites DynDOLOD.esp. It can't be a Papyrus script, as if it were, it would fall into the "Papyrus VM running" category. It could very well be another SKSE plugin that's interfering. I have a boat load of them. So my next test is going to disable all of them. Although I don't think I can disable Engine Fixes. The game probably can't even start without it (too many open files). Suggestions for DynDOLOD.log in debug mode, if possible: Print the cell FormID or X,Y coordinates of the current cell on each cell change to make it easier to understand the flow. Or print the cell FormID or X,Y coordinates of the cells that attach and detach. Or both Whichever is easier / you prefer. Print the type of event received. Print the EditorID of each enabled/disabled dynamic LOD reference. This would be mostly useful for you to read the logs since you don't have my load order to look up the reference IDs in xEdit: without the EditorID you can't tell what the reference ID corresponds to. Thanks. Edited October 31, 2023 by Mousetick
Jonado Posted November 1, 2023 Posted November 1, 2023 It seems like Seasonal LOD does not work correctly for objects swapped with Base Object Swapper (tested on Alpha-152, but nothing in the changelog suggests that this has been fixed). BOS will swap the base objects, so seasonal form swaps act on the swapped objects, which works perfectly fine. However, as far as I can tell, the LOD objects for these meshes do not get updated with seasons. Specifically, I am using the mods Simple Snow Improvements - Skyrim Fixes and Simple Snow Improvements - Snow Forts (and the rest too, but that doesn't matter for the report), which swap Vanilla non-snowy objects in snowy areas with snowy objects. I am also using Seasonal Landscapes - Unfrozen, so for this I have created a patch. I am attaching both the relevant SWAP file for snow forts and the seasonal swap file for summer. As you can see, the SWAP file swaps all Imperial fort assets at Fort Snowhawk with snowy variants, whereas the SUM file swaps them back to the regular variants during summer. Here is a screenshot close-up: Looks as you would expect. However, looking towards Fort Snowhawk from a distance, forcing the LOD meshes to load, it will look like this: Not so nice - the fort is covered with snow. I have experienced this for a couple of other BOS swapped objects as well. What I suspect is that the swaps have been executed in the wrong order. For Seasons of Skyrim, BOS swaps are are applied first, whereas seasonal form swaps are applied afterwards. If doing it the other way round, the seasonal form swaps will start by doing nothing, because the base objects are already snow free. Then BOS will swap the object with a snowy variant, yielding the observed result. This should be all information you need, really. If you want me to attach a log file, I want to know exactly which information from them that you actually need. If you want to try to reproduce this yourself, you have the links to the mods and the attached ini files to play with. If you want the full Unfrozen patch (but you won't need the esp for testing), it is available here: Seasonal Landscapes - Unfrozen - More Patches. Simple Snow Improvements - Snow Forts_SWAP.ini Unfrozen - Simple Snow Improvements_SUM.ini
sheson Posted November 1, 2023 Author Posted November 1, 2023 8 hours ago, Mousetick said: Not in the second instance (after fast travel). So no change from previous. But you can ignore that, because the results from the latest test version are much more interesting. I switched to debug=true which produces much bigger logs so I'm attaching them rather than copying them inline here: DynDOLOD TEST1.7zDynDOLOD TEST2.7zDynDOLOD TEST3.7z Test 1: Load clean save. Exit Whiterun meadery. Fast travel to Windhelm stables. Test 2: Load clean save. Exit Whiterun meadery. Run in a large circle around Whiterun. Stop in front of the meadery. Test 3: Use DynDOLOD_NG_Tamriel.txt edited to contain only EWWDSB entries. Load clean save. Exit Whiterun meadery. Fast travel to Windhelm stables. My comments/observations on the logs: In Test 1, after landing at Windhelm stables, all the enables/disables initially succeed. Then one disable fails (7D30226D, which happens to be associated with EWWDSB). Then all the following disables fail, affecting dynamic LOD references from multiple sources, but mostly from EWWDSB. The last one in the first failure sequence (7D3022F7) is associated with a vanilla reference from Skyrim.esm (0D3F85). Then everything works again, until it doesn't. This repeats a few times. At one point the failure sequence affects both enables and disables equally, again from multiple sources, including vanilla references. For example, 7D3020C6 is the dynamic LOD of 0E94A9 and it fails to enable. In Test 2, everything looks good mostly. Except at one point there is a string of continuous enable failures. Some or all, I didn't check, of these references were already enabled earlier. In Test 3, the log is clean. The failures followed by successes followed by failures and so on, each happening in continuous "bursts", make me think the issue could be DynDOLOD.dll might be trying to enable/disable references when the engine is busy or in a state incompatible with manipulating references "behind its back" so to speak (e.g. Papyrus VM running). I had "Autosave on travel" enabled. I disabled it but it made no difference. I don't think another mod could be interfering. It can't be a plugin. Nothing overwrites DynDOLOD.esp. It can't be a Papyrus script, as if it were, it would fall into the "Papyrus VM running" category. It could very well be another SKSE plugin that's interfering. I have a boat load of them. So my next test is going to disable all of them. Although I don't think I can disable Engine Fixes. The game probably can't even start without it (too many open files). Suggestions for DynDOLOD.log in debug mode, if possible: Print the cell FormID or X,Y coordinates of the current cell on each cell change to make it easier to understand the flow. Or print the cell FormID or X,Y coordinates of the cells that attach and detach. Or both Whichever is easier / you prefer. Print the type of event received. Print the EditorID of each enabled/disabled dynamic LOD reference. This would be mostly useful for you to read the logs since you don't have my load order to look up the reference IDs in xEdit: without the EditorID you can't tell what the reference ID corresponds to. Thanks. In test 1, what does "Then everything works again" mean? Do the affected references disable/enable properly again? In test 2, do the affected reference disable/enable properly? In case they are not, does using console command resetreference has any effect on them? Add debuglevel=1 to the DynDOLOD_NG_Worlds.txt if you want log messages about cells etc. Test with this version https://mega.nz/file/gQ50RbCC#jpW0MPs6riX0JKUigX9vazVVIi93nLXWgfKUJS2rPWg There won't be any failed messages in any case regardless of what is happening.
sheson Posted November 1, 2023 Author Posted November 1, 2023 10 hours ago, Jonado said: It seems like Seasonal LOD does not work correctly for objects swapped with Base Object Swapper (tested on Alpha-152, but nothing in the changelog suggests that this has been fixed). BOS will swap the base objects, so seasonal form swaps act on the swapped objects, which works perfectly fine. However, as far as I can tell, the LOD objects for these meshes do not get updated with seasons. Specifically, I am using the mods Simple Snow Improvements - Skyrim Fixes and Simple Snow Improvements - Snow Forts (and the rest too, but that doesn't matter for the report), which swap Vanilla non-snowy objects in snowy areas with snowy objects. I am also using Seasonal Landscapes - Unfrozen, so for this I have created a patch. I am attaching both the relevant SWAP file for snow forts and the seasonal swap file for summer. As you can see, the SWAP file swaps all Imperial fort assets at Fort Snowhawk with snowy variants, whereas the SUM file swaps them back to the regular variants during summer. Here is a screenshot close-up: Looks as you would expect. However, looking towards Fort Snowhawk from a distance, forcing the LOD meshes to load, it will look like this: Not so nice - the fort is covered with snow. I have experienced this for a couple of other BOS swapped objects as well. What I suspect is that the swaps have been executed in the wrong order. For Seasons of Skyrim, BOS swaps are are applied first, whereas seasonal form swaps are applied afterwards. If doing it the other way round, the seasonal form swaps will start by doing nothing, because the base objects are already snow free. Then BOS will swap the object with a snowy variant, yielding the observed result. This should be all information you need, really. If you want me to attach a log file, I want to know exactly which information from them that you actually need. If you want to try to reproduce this yourself, you have the links to the mods and the attached ini files to play with. If you want the full Unfrozen patch (but you won't need the esp for testing), it is available here: Seasonal Landscapes - Unfrozen - More Patches. Simple Snow Improvements - Snow Forts_SWAP.ini 2.84 kB · 0 downloads Unfrozen - Simple Snow Improvements_SUM.ini 12.46 kB · 0 downloads As explained on the first post and https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-the-Latest-Versions, always use the latest version. Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which entire DynDOLOD log and debug to upload. Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make useful screenshots with more informative console for at least one affected full model.
Mousetick Posted November 1, 2023 Posted November 1, 2023 1 hour ago, sheson said: In test 1, what does "Then everything works again" mean? Do the affected references disable/enable properly again? Sorry for being vague. In TEST1.log, starting at line # 1004, disables are all reported as failed, until line # 1155, when enables and disables of other references are not reported as failed anymore. At line # 1668, disables are all reported as failed again. But it looks like those are retries of the same previously failed ones starting at line # 1004. The affected references that fail to disable never work properly again. Ever since we started this troubleshooting, and in all my tests, I always check the state of 7D3022EC (which is one of the references that fails to disable, but not the only one) in the console at each step. It has never been disabled after fast travelling, as shown in the console, with any test version of DynDOLOD.dll so far. Except in the cases where I "hacked" DynDOLOD_NG_Tamriel.txt to change the list of [Objects], as I reported before. If 7D3022EC is successfully disabled after fast travel to Windhelm in one future test, you can be sure this will be the first thing I'll tell you. I have a small human brain so I can only keep track of 7D3022EC in the console. There are dozens of dynamic LOD references that are enabled and disabled after fast travel. I look at DynDOLOD.log to get an idea of what happens to the other references. 2 hours ago, sheson said: In test 2, do the affected reference disable/enable properly? Yes. 2 hours ago, sheson said: Add debuglevel=1 to the DynDOLOD_NG_Worlds.txt if you want log messages about cells etc. Test with this version https://mega.nz/file/gQ50RbCC#jpW0MPs6riX0JKUigX9vazVVIi93nLXWgfKUJS2rPWg There won't be any failed messages in any case regardless of what is happening. Ok, thanks. Let me give it a try, I'll keep you posted. I'll also try resetreference if needed, as you suggested.
Mousetick Posted November 1, 2023 Posted November 1, 2023 3 hours ago, sheson said: Test with this version https://mega.nz/file/gQ50RbCC#jpW0MPs6riX0JKUigX9vazVVIi93nLXWgfKUJS2rPWg SUCCESS! Whatever was changed in this version, has fixed it. I fast travelled back and forth between Whiterun and Windhelm a couple times, approached the watchtower by foot in between fast travels, and fast travelled from Whiterun to Markarth. 7D3022EC was disabled at the fast travel destination, when coming back to Whiterun, it was enabled again, it disabled properly when approaching the watchtower and re-enabled when moving away. The other dynamic LOD references that were failing before along with 7D3022EC all appeared to work properly (just visually looking at the EWWDSB objects at the watchtower, I can tell the dynamic LODs are properly fading when the watchtower cells attach). I didn't check them exhaustively but there is no reason to believe they all wouldn't be fixed as well. Log for info: DynDOLOD.7z Thanks. Glad you were able to nail it. 1
Jonado Posted November 1, 2023 Posted November 1, 2023 12 hours ago, sheson said: As explained on the first post and https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-the-Latest-Versions, always use the latest version. Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which entire DynDOLOD log and debug to upload. Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make useful screenshots with more informative console for at least one affected full model. I did read those, but I still don't understand why you want a full debug log with almost entirely unrelated information, when I have a quite good idea of what could be causing this. I can confirm myself that the object IDs of the affected models are all listed in the SWAP file I attached, no need to use More Informative Console for that. As an example, the centre tower has the model ImpExtTower01 (this is clearly affected, and on the list). In any case, I would have to regenerated all LOD to be able to produce meaningful log files, since last time I used DynDOLOD, I had to repeat the process for a smaller, unrelated worldspace. I always find it a hassle to generate LOD, so this is something I would rather avoid doing too frequently (also the reason why I would rather not update DynDOLOD just to get three versions ahead). If it is of any use for you, the limited debug file I have gives the following entries when searching for ImpExtTower01, but honestly, I think the interesting things would happen further ahead: [00:35] [ProcessSeasonFile] <Debug: Season SUM, swapping record Simple Snow Improvements - Snow Forts.esp ImpExtTower01snow [STAT:FE2BE804] to Skyrim.esm ImpExtTower01 [STAT:0003F1F9]> (loaded twice) ... [01:19] [BuildBaseRecords] <Debug: Looking for impexttower01 for Skyrim.esm ImpExtTower01 [STAT:0003F1F9]> ... [01:19] [AddModel] <Debug: Meshes\dungeons\imperial\exterior\impexttower01.nif L1_Windows Shader Flags 1: Specular | Environment_Mapping | Recieve_Shadows | Cast_Shadows | Own_Emit | Remappable_Textures | External_Emittance | ZBuffer_Test Skyrim.esm ImpExtTower01 [STAT:0003F1F9]> [01:19] [AddModel] <Debug: Meshes\dungeons\imperial\exterior\impexttower01.nif L1_Windows Shader Flags 2: ZBuffer_Write | Vertex_Colors | EnvMap_Light_Fade Skyrim.esm ImpExtTower01 [STAT:0003F1F9]> (a bunch of other similar entries) ... [02:45] [BuildBaseRecords] <Debug: Looking for impexttower01 for Simple Snow Improvements - Snow Forts.esp ImpExtTower01snow [STAT:FE2BE804]> ... [03:07] [AddModel] <Debug: Meshes\lod\imperial\impexttower01glow_lod_1.nif L1_Windows Shader Flags 1: Specular | Recieve_Shadows | Cast_Shadows | Own_Emit | Remappable_Textures | Decal | Dynamic_Decal | External_Emittance | ZBuffer_Test Skyrim.esm ImpExtTower01 [STAT:0003F1F9]> [03:07] [AddModel] <Debug: Meshes\lod\imperial\impexttower01glow_lod_1.nif L1_Windows Shader Flags 2: ZBuffer_Write | No_Fade | EnvMap_Light_Fade Skyrim.esm ImpExtTower01 [STAT:0003F1F9]> ... [03:21] [LoadSwaps] <Debug: Location record FortSnowhawkLocation "Fort Snowhawk" [LCTN:00019184]: Swapping Skyrim.esm ImpExtTower01 [STAT:0003F1F9] to ImpExtTower01snow Simple Snow Improvements - Snow Forts.esp ImpExtTower01snow [STAT:FE2BE804]> So it may take a while until I am able to produce all the logs you want, but the report should be clear enough anyway for you to be able to investigate this (and even reproduce it if you have time). If this would have been fixed already, I would expect it to be listed in the changelog, or at least that you would be aware of the issue.
ButchDiavolo Posted November 2, 2023 Posted November 2, 2023 (edited) Hi Sheson, I am having an odd situation with TexGen for which I can't find any information forums. I downloaded a 3d LOD mod for Nature of The Wild Lands yesterday. I have been trying to run TexGen and DynDOLOD. For the most part it works fine, except for 2 billboards. TexGen does not give errors after the run, so it just gives the option to close. When I run DynDOLOD with the TexGen output activated, I get a "Texture not Found" report for 2 nifs. The DynDOLOD reports have no information about it, besides that the textures are missing. Checking the TexGen_SSE_Debug_log.txt, I eventually found two notices concerning the missing textures: [00:10] [TwbRender.SetRenderMax] <Notice: Skipping billboard C:\Games\Tools\DynDOLOD\TexGen_Output\Textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\alnus_forest_shrub02_91ed5863_trunk_1. Not enough opaque pixels 0.01 < 0.01> [00:10] [TwbRender.SetRenderMax] <Notice: Skipping billboard C:\Games\Tools\DynDOLOD\TexGen_Output\Textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\alnus_forest_shrub06_b0fc1baa_trunk_1. Not enough opaque pixels 0.00 < 0.01> I have never seen that message before and have no idea what that means/ causes it. Apparently I am (so far) the only one with this error and the mod author has been very helpful in trying to solve it, but he can't replicate it. So I am hoping you can give me some insight in what could cause it and how I can correct it. I have attached only the zipped TexGen logs, since DynDOLOD has no further mention about it beside the textures missing. Thanks in advance for you help! TexGen Logs.7z Edited November 2, 2023 by ButchDiavolo
sheson Posted November 2, 2023 Author Posted November 2, 2023 47 minutes ago, ButchDiavolo said: Hi Sheson, I am having an odd situation with TexGen for which I can't find any information forums. I downloaded a 3d LOD mod for Nature of The Wild Lands yesterday. I have been trying to run TexGen and DynDOLOD. For the most part it works fine, except for 2 billboards. TexGen does not give errors after the run, so it just gives the option to close. When I run DynDOLOD with the TexGen output activated, I get a "Texture not Found" report for 2 nifs. The DynDOLOD reports have no information about it, besides that the textures are missing. Checking the TexGen_SSE_Debug_log.txt, I eventually found two notices concerning the missing textures: [00:10] [TwbRender.SetRenderMax] <Notice: Skipping billboard C:\Games\Tools\DynDOLOD\TexGen_Output\Textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\alnus_forest_shrub02_91ed5863_trunk_1. Not enough opaque pixels 0.01 < 0.01> [00:10] [TwbRender.SetRenderMax] <Notice: Skipping billboard C:\Games\Tools\DynDOLOD\TexGen_Output\Textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\alnus_forest_shrub06_b0fc1baa_trunk_1. Not enough opaque pixels 0.00 < 0.01> I have never seen that message before and have no idea what that means/ causes it. Apparently I am (so far) the only one with this error and the mod author has been very helpful in trying to solve it, but he can't replicate it. So I am hoping you can give me some insight in what could cause it and how I can correct it. I have attached only the zipped TexGen logs, since DynDOLOD has no further mention about it beside the textures missing. Thanks in advance for you help! TexGen Logs.7z 661.29 kB · 0 downloads It means the ratio of transparent to opaque pixels is higher than the BillboardDiscardRatio set in TexGen_SSE.INI. The billboard is mostly just transparent. It could be a result of the full textures. You should check the preview. In my quick test with the current version of the mods and default settings (with units per pixel 11 or 5.5) there is no such message or problem.
ButchDiavolo Posted November 2, 2023 Posted November 2, 2023 3 hours ago, sheson said: It means the ratio of transparent to opaque pixels is higher than the BillboardDiscardRatio set in TexGen_SSE.INI. The billboard is mostly just transparent. It could be a result of the full textures. You should check the preview. In my quick test with the current version of the mods and default settings (with units per pixel 11 or 5.5) there is no such message or problem. Thank you for your reply. Since you also didn't have this issue, I figured something in my set up was wrong. So I decided to reinstall the mods involved and DynDOLOD. I ran TexGen again and had no warnings! Then I remembered that I had forgotten to change the ini's to what STEP advises and re-ran TexGen, which promptly brought the errors back... Figuring the issue concerns trees, opaque pixels/ transparency (=alpha right?) and STEP advising to set "TreeMSAlphaThreshold=144", I changed that back to the original 96 and it works again. Still no idea why just those two billboards were affected though. I then ran DynDOLOD and again no errors this time. Thank you for pointing me in the right direction!
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