Jump to content

Recommended Posts

Posted (edited)

 

  On 7/11/2022 at 6:50 AM, sheson said:
Expand  

I got the same result with the latest version. However, I noticed that if I loaded only the plugin (and its masters) I wanted to generate RNAM for, I got the right form IDs. Is this how the script is intended to be used? Although this only worked for plugins that only had a single master editing the same worldspace. If there were more the same thing happened.

  On 7/11/2022 at 12:32 PM, sheson said:

Do you have an example plugin where the actual full model loads in a different position/cell other than the position/cell that the winning overwrite of the reference defines? With a new game of course.

Expand  

Sorry my initial post was a little light on details, I thought this was a known engine limitation. I'll give the full reproduction steps with COTN Falkreath here.

I did the same as you, took COTN Falkreath, flagged it as ESM without generating RNAM and generated LOD with DynDOLOD Alpha 95. Then this is how I can get the glitch to manifest:

1. From the main menu, coc whiterun.

2. After loading into the game I did the following console commands (to help with testing): tmm 1, tdetect, tgm.

3. Fast travel to Peak's Shade Tower, southeast from Falkreath.

4. Run to Falkreath. The route you take shouldn't matter, but I beelined over the cliffs.

5. Be greeted with this sight:

  Reveal hidden contents

6. Run up the hill to inspect the place where the object should be, to find a gaping hole:

  Reveal hidden contents

That's all of the steps. However, if you instead coc straight to falkreathexterior01 (be it from the main menu or after coc'ing to whiterun first), the object is in the right place.

  Reveal hidden contents

On both occasions this is what the record looked like in xEdit:

  Reveal hidden contents

On these tests I coc'd from the main menu, but the same bug occured on my full modlist when starting a new game via Alternate Perspective, so I don't think the manner of starting the game is relevant.

The LOD is generated and displayed correctly:

  Reveal hidden contents

If you situate yourself a suitable distance south of falkreath you can get a situation where both the LOD and the full model are displayed:

  Reveal hidden contents

CRC of the COTN - Falkreath.esp:

  Reveal hidden contents

When I took these screenshots I had uGridsToLoad = 5 and uLargeRefLODGridSize = 11. However, this time when I tested with uLargeRefLODGridSize = 5 the glitch still happened.

Active mods and plugins:

  Reveal hidden contents

The game version was 1.5.97. Here are the modlist and plugins in a text file format, along with my ini files: https://loadorderlibrary.com/lists/falkreath-test

I also did a quick test with the original COTN Falkreath plugin without the ESM flag, and the glitch did not happen.

If there's anything I forgot let me know.

Edited by Blackread
Posted
  On 7/11/2022 at 3:56 PM, Blackread said:

 

I got the same result with the latest version. However, I noticed that if I loaded only the plugin (and its masters) I wanted to generate RNAM for, I got the right form IDs. Is this how the script is intended to be used? Although this only worked for plugins that only had a single master editing the same worldspace. If there were more the same thing happened.

Sorry my initial post was a little light on details, I thought this was a known engine limitation. I'll give the full reproduction steps with COTN Falkreath here.

I did the same as you, took COTN Falkreath, flagged it as ESM without generating RNAM and generated LOD with DynDOLOD Alpha 95. Then this is how I can get the glitch to manifest:

1. From the main menu, coc whiterun.

2. After loading into the game I did the following console commands (to help with testing): tmm 1, tdetect, tgm.

3. Fast travel to Peak's Shade Tower, southeast from Falkreath.

4. Run to Falkreath. The route you take shouldn't matter, but I beelined over the cliffs.

5. Be greeted with this sight:

  Reveal hidden contents

6. Run up the hill to inspect the place where the object should be, to find a gaping hole:

  Reveal hidden contents

That's all of the steps. However, if you instead coc straight to falkreathexterior01 (be it from the main menu or after coc'ing to whiterun first), the object is in the right place.

  Reveal hidden contents

On both occasions this is what the record looked like in xEdit:

  Reveal hidden contents

On these tests I coc'd from the main menu, but the same bug occured on my full modlist when starting a new game via Alternate Perspective, so I don't think the manner of starting the game is relevant.

The LOD is generated and displayed correctly:

  Reveal hidden contents

If you situate yourself a suitable distance south of falkreath you can get a situation where both the LOD and the full model are displayed:

  Reveal hidden contents

CRC of the COTN - Falkreath.esp:

  Reveal hidden contents

When I took these screenshots I had uGridsToLoad = 5 and uLargeRefLODGridSize = 11. However, this time when I tested with uLargeRefLODGridSize = 5 the glitch still happened.

Active mods and plugins:

  Reveal hidden contents

The game version was 1.5.97. Here are the modlist and plugins in a text file format, along with my ini files: https://loadorderlibrary.com/lists/falkreath-test

I also did a quick test with the original COTN Falkreath plugin without the ESM flag, and the glitch did not happen.

If there's anything I forgot let me know.

Expand  

Only load the plugin you want to update RNAMs for (xEdit should automatically load all required masters).
If it creates unresolved form IDs then, let me know a mod/plugin how to reproduce.

The problem with the wrong position/model does not happen after you generate RNAM for the plugin you flagged ESM?
E.g. the problem happens if a large reference is overwritten by an ESM without RNAM and the new cell / reference is not listed in any RNAM of any ESM plugin (OK that might be not trivial to test for your right now - I am just saying out loud the conditions)

Posted
  On 7/11/2022 at 2:55 PM, sheson said:

I would remove everything else from the plugin and only keep involved records and only test with the minimum number of plugins. That should at least quickly narrow it down to what records/changes are required to have the problem and others are more likely to be able to replicate it.

Expand  

Yes I know what you mean. So here is attached the simplest test cases I could come up with in a relatively short time. Using a tiny ESP plugin that moves one large reference from one cell to another. The test cases demonstrate the bugs and behavior I previously described, once the ESP is ESM-flagged, and should be quite easy to reproduce.

Requirements: USSEP + ASLAL + SKSE.

Please see steps to reproduce the issue and other details in the included Readme.

Edit: uploaded new version, much improved and more comprehensive.

LR Cell Move Test.7zFetching info...

 

Posted
  On 7/11/2022 at 6:19 PM, sheson said:

Only load the plugin you want to update RNAMs for (xEdit should automatically load all required masters).
If it creates unresolved form IDs then, let me know a mod/plugin how to reproduce.

The problem with the wrong position/model does not happen after you generate RNAM for the plugin you flagged ESM?
E.g. the problem happens if a large reference is overwritten by an ESM without RNAM and the new cell / reference is not listed in any RNAM of any ESM plugin (OK that might be not trivial to test for your right now - I am just saying out loud the conditions)

Expand  

I still have a couple plugins that get unresolved IDs even when loading alone, I'll attach them here. But it looks like, at least in the case of these plugins, it happens with disabled large refs.

I can't say what the exact conditions are for the wrong position glitch. What I can say though, is that running the RNAM script on COTN - Falkreath.esp after adding the ESM flag does not resolve the issue. Judging by the log output, in the case of this plugin, the script only adds new refs, and does not update the vanilla ones.

  Reveal hidden contents

There's also the issue of large ref occlusion planes, which will also be affected by this glitch. So even after fixing the longhouse, the occlusion planes would still be left behind, and they'd need to be fixed too.

I'll attach the modified COTN - Falkreath.esp here too.

There are other mods I have seen this happen with too, like the aforementioned Great City of Solitude moving the Red Wave and RedBag's Rorikstead moving some cliffs in the surrounding area (which I separated into their own plugin, still resulting in this glitch). When going through all the overwritten large references I saw that at least Quaint Raven Rock also had several of these references that were moved to different cells, but I didn't inspect what that place looked like ingame prior to fixing it.

One other mod suffering from this is eFPS. There it's not very apparent though, because the planes are always inside buildings anyway. But I wager that many of the large reference planes they moved to other cells aren't actually where they expect them to be.

Large Ref Plugins.7zFetching info... COTN - Falkreath.7zFetching info...

Posted
  On 7/11/2022 at 8:03 PM, Blackread said:

I still have a couple plugins that get unresolved IDs even when loading alone, I'll attach them here. But it looks like, at least in the case of these plugins, it happens with disabled large refs.

I can't say what the exact conditions are for the wrong position glitch. What I can say though, is that running the RNAM script on COTN - Falkreath.esp after adding the ESM flag does not resolve the issue. Judging by the log output, in the case of this plugin, the script only adds new refs, and does not update the vanilla ones.

  Reveal hidden contents

There's also the issue of large ref occlusion planes, which will also be affected by this glitch. So even after fixing the longhouse, the occlusion planes would still be left behind, and they'd need to be fixed too.

I'll attach the modified COTN - Falkreath.esp here too.

There are other mods I have seen this happen with too, like the aforementioned Great City of Solitude moving the Red Wave and RedBag's Rorikstead moving some cliffs in the surrounding area (which I separated into their own plugin, still resulting in this glitch). When going through all the overwritten large references I saw that at least Quaint Raven Rock also had several of these references that were moved to different cells, but I didn't inspect what that place looked like ingame prior to fixing it.

One other mod suffering from this is eFPS. There it's not very apparent though, because the planes are always inside buildings anyway. But I wager that many of the large reference planes they moved to other cells aren't actually where they expect them to be.

Large Ref Plugins.7z 7.07 kB · 1 download COTN - Falkreath.7z 596.12 kB · 1 download

Expand  

Find line #161 in the Skyrim SE - Generate Large References.pas and change it to
SetElementEditValues(rnam, 'Ref', Name(e));

That should fix the unresolved form IDs.

To both @Blackread and @Mousetick, I am going to test some stuff around those large reference bugs over the next days. Thanks for all the information.

Posted
  On 7/12/2022 at 6:34 PM, sheson said:

Find line #161 in the Skyrim SE - Generate Large References.pas and change it to
SetElementEditValues(rnam, 'Ref', Name(e));

That should fix the unresolved form IDs.

Expand  

That did the trick, thank you. ^^

Posted
  On 7/12/2022 at 6:34 PM, sheson said:

I am going to test some stuff around those large reference bugs over the next days.

Expand  

If you're going to try out my simple test plugin and accompanying test cases, I forgot to mention that I was using a vanilla configuration generated by Skyrim SE Launcher, particularly uLargeRefLODGridSize=9, which might be important to reproduce the bugs exactly as the tests intend to.

I've been doing some more tests on my side and I've given up on finding a pattern, trying to define a general rule. With some old/new cells combinations, I can't seem to be able to trigger the bug. There are too many factors involved, many unknown, so, short of reverse-engineering the whole caboodle, it seems impossible to predict the behavior. The position of old and new cells relative to each other, the position of the cells on the worldspace grid, the position of the cells in the RNAM table, the algorithm used to scan cells to load, the algorithm to load near references around the player, the algorithm to load large references around the player, the phase of the moon, etc. each may be a factor.

What's really interesting though about this bug is it shows the engine remembers the original position/scale/other properties of the large reference, as defined in its parent ESM (the one with the RNAM table). It must be keeping it around in memory somehow, otherwise it wouldn't be able to (incorrectly) load the reference at its original position/scale in the old cell.

  On 7/12/2022 at 6:34 PM, sheson said:

Thanks for all the information.

Expand  

No problem. Glad to help a bit and return the favor, for once :)

Posted (edited)

This is a suggestion/question as I am surprised this feature doesn't already exist (to me it is a fairly obvious feature).  I am curious if there is a reason why a "Select All" option doesn't exist on the "Select Worldspaces" page.  Is there a reason why we shouldn't do all world spaces?

 

EDIT:  I have used dyndolod a few times in the past with mixed results.  Last time the trees didn't turn out well but with the new version I hope things go better.

Edited by primem0ver
Posted

I spotted toxic water lods sometimes like this.

KazitSh.jpeg

qYITt2A.jpeg

If i save and restart game lods are fine.

aLKrZmX.jpeg

VfothQV.jpeg

 

Any suggestions?

Posted
  On 7/15/2022 at 11:46 AM, had said:

I spotted toxic water lods sometimes like this.

KazitSh.jpeg

qYITt2A.jpeg

If i save and restart game lods are fine.

aLKrZmX.jpeg

VfothQV.jpeg

 

Any suggestions?

Expand  

https://dyndolod.info/How-LOD-Works
In this distant LOD area the game shows terrain LOD (includes LOD for cell sized water), object LOD and tree LOD.

https://dyndolod.info/Help/Terrain-LOD
At the moment DynDOLOD does not create, update or otherwise change terrain LOD or water LOD. How the LOD water looks is defined by the LOD water record defined on the worldspace record of the highest plugin at generation time, which is copied to create the DynDOLOD and Occlusion plugins.

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
×
×
  • Create New...

Important Information

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