Jump to content

DynDOLOD 3.00 Alpha 180

sheson

By sheson
in DynDOLOD & xLODGen

 Share

Recommended Posts

sheson Akatosh

sheson

Posted
  • Author
Posted
59 minutes ago, Mousetick said:

I agree. There is nothing special about Environs - Whiterun Watchtower, it's a red herring. It just so happens that it produces a bunch of dynamic LOD references that are enabled and then fail to disable after a specific sequence of events and under specific conditions that remain to be determined. The same issue could probably be reproduced with any other enabled dynamic LOD reference, using the same sequence of events under the same conditions.

This made no difference at all.

Yes. Annotated DynDOLOD.log:

  Reveal hidden contents

 

No. Repeating the same travel again after "fixing" the reference by manually disabling it in the console, results in the same failure. Annotated DynDOLOD.log:

  Reveal hidden contents

 

Other points to consider:

  • I chose Windhelm for my test, but I confirmed that the same failure occurred when travelling from Whiterun to the Solitude terminal. I suspect other destinations would fail in the same way.
  • Once the dynamic LOD reference is in the 'failed disable' state, it remains that way forever (unless manually disabled in console) and its failed state persists in the (co)save files across sessions.
  • If you can't reproduce there is probably another factor/mod/component involved. TBD.

Thanks.

 

Update: I just reproduced the issue by simply taking the carriage from Whiterun to Windhelm. Duh.

I should have tried the simplest way to fast travel first instead of seeking the most convoluted one. My apologies for making you install Clockwork and wasting your time with it.

Test/confirm that fast travel back and forth via the map or via console does not have the same problem as taking the carriage.

Link to comment
Share on other sites
  • Replies 9.9k
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

sheson
sheson

Will be fixed next version. The mipmap generation is wrapping the texture instead of clamping it.

sheson
sheson

This should be fixed next Alpha version.

Posted Images

Mousetick Emperor

Mousetick

Posted
Posted
44 minutes ago, sheson said:

Test/confirm that fast travel back and forth via the map or via console does not have the same problem as taking the carriage.

  • Fast travel from Whiterun with 7D3022EC enabled to Windhelm stables using the map: disable fails on arrival.
  • Fast travel from Whiterun with 7D3022EC enabled to WindhelmBridge01 using the console: disable fails on arrival.

Also, if I reload a save during the same session and the reference is already in 'failed state', it remains in failed state. For example, if it previously failed to disable so is still enabled, but the loaded save reset it to disabled, it fails to enable when it should.

Is there some kind of handle/proxy/wrapper in memory that keeps track of the reference or some kind of locking mechanism that could get out of whack?

Thanks.

Link to comment
Share on other sites
sheson Akatosh

sheson

Posted
  • Author
Posted
36 minutes ago, Mousetick said:
  • Fast travel from Whiterun with 7D3022EC enabled to Windhelm stables using the map: disable fails on arrival.
  • Fast travel from Whiterun with 7D3022EC enabled to WindhelmBridge01 using the console: disable fails on arrival.

Also, if I reload a save during the same session and the reference is already in 'failed state', it remains in failed state. For example, if it previously failed to disable so is still enabled, but the loaded save reset it to disabled, it fails to enable when it should.

Is there some kind of handle/proxy/wrapper in memory that keeps track of the reference or some kind of locking mechanism that could get out of whack?

Thanks.

If you start a new game from console or via a start mod there is no issue?

Link to comment
Share on other sites
Mousetick Emperor

Mousetick

Posted
Posted
3 hours ago, sheson said:

If you start a new game from console or via a start mod there is no issue?

I started a new game with ASLAL in Breezehome.

Initially all the stuff from Environs - Whiterun Watchtower Doesn't Stay Broken (what a mouthful, let's abbreviate into EWWDSB) is all OFF. In its place, there is all the stuff from Whiterun Watchtower Doesn't Start Broken (WWDSB), which does the same thing in reverse for the early game (before the dragon attack and the tower is destroyed). The WWDSB stuff is initially all enabled and then gets disabled during/after the dragon attack on the watchtower (Dragon Rising main quest).

  • The dynamic LOD of WWDSB is successfully disabled when fast travelling.
  • I then manually enabled the Enable Parent of the EWWDSB stuff in the console.
  • The dynamic LOD of EWWDSB fails to disable when fast travelling.

I'm completely confused. This doesn't make any sense.

Link to comment
Share on other sites
sheson Akatosh

sheson

Posted
  • Author
Posted
18 minutes ago, Mousetick said:

I started a new game with ASLAL in Breezehome.

Initially all the stuff from Environs - Whiterun Watchtower Doesn't Stay Broken (what a mouthful, let's abbreviate into EWWDSB) is all OFF. In its place, there is all the stuff from Whiterun Watchtower Doesn't Start Broken (WWDSB), which does the same thing in reverse for the early game (before the dragon attack and the tower is destroyed). The WWDSB stuff is initially all enabled and then gets disabled during/after the dragon attack on the watchtower (Dragon Rising main quest).

  • The dynamic LOD of WWDSB is successfully disabled when fast travelling.
  • I then manually enabled the Enable Parent of the EWWDSB stuff in the console.
  • The dynamic LOD of EWWDSB fails to disable when fast travelling.

I'm completely confused. This doesn't make any sense.

Technically there should be no difference between those dynamic LOD reference and how they are enabled/disabled.

Run this version https://mega.nz/file/xFpQTRAb#Lg5o8SRMDU0lnj4JY9DBG7H2b_oXSjwE4uTu1o0xZTQ
Check if the DynDOLOD log has "Disabled success? ..." and/or "Disabled failed? ..." messages.

Maybe try this: generate dynamic LOD only for the vanilla game and EWWDSB. Check if the problem still happens. If it does, test with vanilla INIs etc. If not, enable the rest of the load order to verify the problem still happens. If it does you can then start removing all other mods in to see what else might contribute to the problem.

Link to comment
Share on other sites
Mousetick Emperor

Mousetick

Posted
Posted
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.

Link to comment
Share on other sites
sheson Akatosh

sheson

Posted
  • Author
Posted
17 hours ago, Mousetick said:

Annotated DynDOLOD.log:

  Reveal hidden contents

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.

Link to comment
Share on other sites
Mousetick Emperor

Mousetick

Posted
Posted
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
Link to comment
Share on other sites
Mousetick Emperor

Mousetick

Posted
Posted

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.

Link to comment
Share on other sites
sheson Akatosh

sheson

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
Mousetick Emperor

Mousetick

Posted
Posted (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 by Mousetick
Link to comment
Share on other sites
Jonado Noble

Jonado

Posted
Posted

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:

20231031191713_1.thumb.jpg.9a42097d46455ac6c31832c92ca5788f.jpg

Looks as you would expect. However, looking towards Fort Snowhawk from a distance, forcing the LOD meshes to load, it will look like this:

20231031192221_1.thumb.jpg.62db579b1fa62fb63e8f4719edd0221b.jpg

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

Link to comment
Share on other sites
sheson Akatosh

sheson

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
sheson Akatosh

sheson

Posted
  • Author
Posted
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:

20231031191713_1.thumb.jpg.9a42097d46455ac6c31832c92ca5788f.jpg

Looks as you would expect. However, looking towards Fort Snowhawk from a distance, forcing the LOD meshes to load, it will look like this:

20231031192221_1.thumb.jpg.62db579b1fa62fb63e8f4719edd0221b.jpg

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.

Link to comment
Share on other sites
Mousetick Emperor

Mousetick

Posted
Posted
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.

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.

  I accept