Jump to content
  • 0

Question

Recommended Posts

  • 0
Posted (edited)

What is the problem supposed to be?

 

This is a full model in a loaded cell. DynDOLOD does not change the reference in a loaded cell as you can see by the information listed on the right.

Edited by sheson
  • 0
Posted

See the screenshot.  Semi-transparent lamp posts.

 

One more update.  If I load ML AFTER DynDOLOD, the error goes away.  But obviously this is not the preferred solution.

  • 0
Posted (edited)

Are you saying a particular full model just stops fading into full view?

 

If you believe DynDOLOD has anything to do with it, then the first obvious troubleshooting step would be to remove the overwrite of the base record, which typically is only setting the Visble When Distant flag.

 

If it still happens then, this is probably a resource issue.

 

If the ML plugin was  the last to before the DynDOLOD plugin at generation time, then you can have it load after. Otherwise, it will probably revert cell changes made by other plugins.

Edited by sheson
  • 0
Posted (edited)

Yes.  That is exactly what happens.  The screenshot does say "Base Last Changed by: DynDOLO.esp".  Thanks.

Edited by Zanderat
  • 0
Posted (edited)
  On 8/6/2019 at 3:45 PM, Zanderat said:

Yes.  That is exactly what happens.  The screenshot does say "Base Last Changed by: DynDOLO.esp".  Thanks.

 

FYI that flag is set by DynDOLOD on the base record of every object that gets LOD. Since years. So far without issues.

 

I can not replicate any issue with that particular reference or any other. You see it anywhere else? Does it happen every time the cell/model is loaded?

Edited by sheson
  • 0
Posted

The issue seems specific to ML.  Could also be specific to my load order.  But I don't see any obvious conflicts. I will do some more testing.  Thanks for the help.

 

Active Mod Files:

  Reveal hidden contents


 

  • 0
Posted (edited)
If this is with a new game, wait 12 or 24 hours (inside maybe) to let the ML script settle on the time of day.

 

Otherwise, if removing the base record overwrite with the Visible When Distant flag does not change anything, test with default INIs. Then next maybe with a reduced load order - when I say I can't replicate the issue I typically only have a dozen of plugins at a time.

Edited by sheson
  • 0
Posted

So I regenerated DynDOLOD without ML and then added back ML to my LO. Works fine now. If I can figure why ML doesn't play nice with DynDOLOD, I will let you know.

  • 0
Posted

Update: I loaded a profile with only ML, DynDOLOD, and LAL (so I can skip Helgen) installed. Unfortunately the fading issued remained. So, I feel that I am on fairly solid ground in saying that right now DynDOLOD and ML does need some sort of patch/fix. My temp solution is to run DynDOLOD without ML installed and to install ML afterwards.

  • 0
Posted (edited)
  On 8/12/2019 at 1:45 PM, Zanderat said:

Update: I loaded a profile with only ML, DynDOLOD, and LAL (so I can skip Helgen) installed. Unfortunately the fading issued remained. So, I feel that I am on fairly solid ground in saying that right now DynDOLOD and ML does need some sort of patch/fix. My temp solution is to run DynDOLOD without ML installed and to install ML afterwards.

I suggest to do some actual troubleshooting. Remember, I do not see any such issue with the reference you reported. Generally, the dynamic LOD works fine for everyone and everything else since years.

 

Do you have any of your own (LOD) models created earlier still in the load order? Is anything overwriting the models from ML or DynDOLOD Resources?

 

Use default INIs. Disable anything else in the setup from ENB to all SKSE plugins that are not required.

 

As already suggested before, remove the overwrite with the visible distant flag from the base record of the full model with the problem.

If nothing from DynDOLOD modifies the reference, its base record and the model it uses then the real troubleshooting starts.

 

Without knowing the actual cause for a fade-in to not complete there can't be a fix.

 

From the reporting I am not even sure if its only that one lantern reference you reported, or if it is all lanterns using the same base record, if it always happens to same lanterns no matter what or if it is random or maybe only specific locations.

 

Found any other DynDOLOD users with the same problem?

Edited by sheson
  • 0
Posted

Hey Sheson, I'm also getting this problem and I'm attempting to follow your troubleshooting steps, but I'm not certain what you mean by this -->"remove the overwrite with the visible distant flag from the base record of the full model". Is that a record I edit in SSEEdit?

 

 

I am using default INIs and have disabled everything else except ML and all the texture and landscape mods I use with DynDOLOD. Also I've tested ML without DynDOLOD and there is no fading. I also thought maybe it had something to do with the mod's script checking time to turn the lanterns on and off, but the mod says that script checks every 30 seconds and I get the fading way more frequently than that, like every 5-10 seconds.

 

Hm, I just did another test and the fading does not happen if I run DynDOLOD with candles and FX Glow unchecked. I'm not sure if it's one or both of those, I can test again later and reply with the results if that would be helpful!

  • 0
Posted
  On 8/25/2019 at 10:26 PM, aproco said:

Hey Sheson, I'm also getting this problem and I'm attempting to follow your troubleshooting steps, but I'm not certain what you mean by this -->"remove the overwrite with the visible distant flag from the base record of the full model". Is that a record I edit in SSEEdit?

 

 

I am using default INIs and have disabled everything else except ML and all the texture and landscape mods I use with DynDOLOD. Also I've tested ML without DynDOLOD and there is no fading. I also thought maybe it had something to do with the mod's script checking time to turn the lanterns on and off, but the mod says that script checks every 30 seconds and I get the fading way more frequently than that, like every 5-10 seconds.

 

Hm, I just did another test and the fading does not happen if I run DynDOLOD with candles and FX Glow unchecked. I'm not sure if it's one or both of those, I can test again later and reply with the results if that would be helpful!

 

Edit: Tested some more, the fading does only happen for me when the candles option is checked

  • 0
Posted (edited)

Yes, use xEdit to remove the overwrite record from the DynDOLOD plugin or just unset the Has Distant LOD flag.

You get the base form id in the game from console while clicking the object (with More Informative Console). Enter it into the form id field top left of xEdit.
In the right window where it shows the record and overwrite, you can right click on the column title where it shows [xx] DynDOLOD.esp to remove it.
 

  On 8/25/2019 at 10:26 PM, aproco said:

I also thought maybe it had something to do with the mod's script checking time to turn the lanterns on and off, but the mod says that script checks every 30 seconds and I get the fading way more frequently than that, like every 5-10 seconds.


Never assume. Test anyways if not using the scripts stops it from happening.
 

  On 8/25/2019 at 10:26 PM, aproco said:

Tested some more, the fading does only happen for me when the candles option is checked


Then no LOD is added for the lanterns and consequently no overwrite with the Has Distant LOD flag. Which seems to indicate that for some reason the flag together with something else is trigger the issues.

There also must something else at play, since we have not seen this issue in the past years before.

Edited by sheson

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.