Jump to content
  • 0

SkyrimVR - DynDOLOD tree LOD no longer disappears when close


Question

Posted (edited)

Long-time fan, first time poster as they say.

 

I prepped for a new playthrough a few weeks back; installed mods, ran DynDOLOD, froze my modlist (no changes to mods during a playthrough, I'm paranoid) and started playing. All works fine, happy days.

 

I hit level 50 today after about 100 hours of play and out of nowhere the tree LODs are no longer disappearing when I get close, they overlay with the mesh as shown here:

weVJUvC.jpg

 

I verified in Wrye nothing changed in my load order (all good, green checkboxes everywhere); I tried resetting the INI files (despite not changing anything); I tried a rebuild of DynDOLOD following the upgrade instructions in the MCM menu (no change so I reverted to the save I made before I did that).

 

None of this fixed it.

 

Even more curious, I tried loading a save from several levels ago and I now see the same LOD behavior, all the way back to level 1 even (and I'm sure it's new behavior). I've never interacted with the DynDOLOD MCM menu but it tells me it's active when I'm outside.

 

It's only the trees (every tree), the rest of the LOD stuff works fine still. Using fallrimtools to look at my save, I don't see an excessive amount of active scripts, nor do I experience any other issues with the game. Savegame size is in line with expectations of 50 levels/100 hours/installed mods at ~12MB size.

 

I'm kind of stumped, any idea what could be the cause and more importantly, can it be fixed and how? 

 

Version info from the log:

DynDOLOD Worlds 2.82 (1) using TES5VRLODGen by Ehamloptiran, Sheson and Zilav, starting...
DynDOLODx64.exe 2.81.0.0 1/31/2020 (1346314240)
LODGenx64.exe 2.7.6.0 3/21/2020 (1349853184)
Edited by acidzebra

5 answers to this question

Recommended Posts

  • 0
Posted (edited)

Hi Sheson,

 

no changes were made to load order, and all plugins were cleaned before running DynDOLOD

I did a rebuild of DynDOLOD earlier just in case (following the howto in the MCM menu with saving/deactivating/removing/etc), no change.

 

Anything else which can cause this kind of behavior that you can think of?

Edited by acidzebra
  • 0
Posted (edited)

If this is tree LOD (goes away if setting fTreeLoadDistance to 0  in DynDOLOD SkyUI MCM Settings) and unless the "FAQ: Game: Tree LOD: LOD trees show in child worlds / towns" applies, then this is because the load order of tree references changed.

Unless something like SSE Engine Fixes or SSE Fixes recently changed how they fixed the tree LOD nested loop FPS bug, the there is no other known reasons for this to happen with tree LOD.

 

Generate tree LOD for this exact load order. Uncheck Generate static LOD and Generate DynDOLOD), check only Generate Tree LOD.

Only check the worldspace in question.

Generate.

Check the log for duplicate FormID numbers of trees ... or Tree reference [...] added by ESL ignored messages.

Only install the meshes|textures/terrain/[worldspace]/trees/ from the output as a new mod (so not to accidentally delete existing LOD files from earlier generation). Do not use the DynDOLD plugins and SKSE folder if they exist. No clean save needed then.

Make sure no old tree LOD files are used.

Then test in game, new or existing, does't matter.

Edited by sheson
  • 0
Posted (edited)

 

Unless something like SSE Engine Fixes or SSE Fixes recently changed how they fixed the tree LOD nested loop FPS bug, the there is no other known reasons for this to happen with tree LOD.

 

I'm glad you posted this because quite by accident you have helped me pinpoint the issue. This gentleman is porting SSE engine fixes to VR: https://github.com/rollingrock/EngineFixesVR/releases/

 

I just happened to install that fix the other day since it's an SKSE thing and as such not part of my ESP load order, nor does it alter landscape or trees (to my knowledge). So honestly, didn't think anything of it.

 

But I have just confirmed that with engine fixes VR installed, tree LOD does what I described in my first post, without, it works as intended. 

 

I pinged the dev and got

 

ahhhhh looks like i reintroduced a bug I had fixed previously.
 
I refactored a lot of the code to use CommonLib so must have found this bug again. Basically there's a long loop that decides whether or not the LOD should be present. It took me a long time before to get it right.
 
Let me go compare the old code to the latest code and try to figure out how to fix it. Hopefully won't take me long. In the meantime just disable the treeLOD caching in the ini file and the rest of the plugin should be working fine.

 

so I guess all good; thanks both of you for being so responsive :)

Edited by acidzebra

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
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

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