Questions about DynDOLOD 3 large reference warnings

[Phoenix]

Hi all!

So I finally got around to reading up on the SSE large references with which the DynDOLOD documentation and this forum here helped quite a lot, so thanks to all the posters who explained aspects of the bug in various places! However, I still have some remaining warnings in my DynDOLOD log that I am stumped on and unfortunately the search function yielded no insights.

For one, I am getting the Base Record Type Not STAT or MSTT for Large Reference warning for a number of Dragonborn.esm references, i.e. 04033EC9. However, the base records for these are all STAT records. How does that work?

Secondly, I am getting warnings about Overwritten large reference in the SMIM-SE-Merged-All.esp for two references. For 02011CFD I can see in SSEEdit that the record is indeed a large reference as it shows the Tamriel worldspace record in the reference tab. This is not true for the second reference, 000AEDF5. Does that mean that only some, but not all large references are themselves referenced in the worldspace record? This is fixable by moving the two references from SMIM into an ESM or just ESM-ifying the entire plugin, correct?

Thanks in advance for any clarification! I do apologise if I am not being clear enough, I am still fairly confused about the whole large references matter. Please let me know if you need me to provide any further information or logs. 

[Mousetick]

1 hour ago, Phoenix said:

For one, I am getting the Base Record Type Not STAT or MSTT for Large Reference warning for a number of Dragonborn.esm references, i.e. 04033EC9. However, the base records for these are all STAT records. How does that work?

The base record may be changed to something else by another plugin. Check your entire load order.

1 hour ago, Phoenix said:

For 02011CFD I can see in SSEEdit that the record is indeed a large reference as it shows the Tamriel worldspace record in the reference tab. This is not true for the second reference, 000AEDF5.

000AEDF5 is definitely a large reference. It's referenced by Tamriel WRLD in Skyrim.esm. Double-check.

1 hour ago, Phoenix said:

This is fixable by moving the two references from SMIM into an ESM or just ESM-ifying the entire plugin, correct?

You can ESM-flag the entire SMIM plugin, yes. That's what I did. It's safe and works fine. No need to 'ESMify' it with third-party tools.

Alternatively you can try the experimental DynDOLOD 3.0 version with Large Reference Bugs Workarounds.

[sheson]

4 hours ago, Phoenix said:

Hi all!

So I finally got around to reading up on the SSE large references with which the DynDOLOD documentation and this forum here helped quite a lot, so thanks to all the posters who explained aspects of the bug in various places! However, I still have some remaining warnings in my DynDOLOD log that I am stumped on and unfortunately the search function yielded no insights.

For one, I am getting the Base Record Type Not STAT or MSTT for Large Reference warning for a number of Dragonborn.esm references, i.e. 04033EC9. However, the base records for these are all STAT records. How does that work?

https://dyndolod.info/Messages/Base-Record-Type-Not-STAT-or-MSTT-For-Large-Reference
The most likely cause is a plugin changing the reference to use a different base record. This can also be caused by base record swapping, maybe also for seasons.

[Phoenix]

Thank you very much for your responses!

22 hours ago, Mousetick said:

000AEDF5 is definitely a large reference. It's referenced by Tamriel WRLD in Skyrim.esm. Double-check.

For the reference originating in Dawnguard.esm, 02011CFD, I am seeing that it is referenced by the Tamriel worldspace record; however, I don't see it for the one originating in Skyrim.esm, 000AEDF5. Is there another way of recognising a large reference in xEdit?

22 hours ago, Mousetick said:

The base record may be changed to something else by another plugin. Check your entire load order.

Turns out that was BOS being sneaky. I am using an INI to replace the trees from Dragonborn - which, for whatever reason, are STATICS in vanilla - with TREE records. I had assumed TexGen + DynDOLOD would recognise the change and generate tree billboards + LOD. Am I wrong? Will this cause the large reference bug?

Edited January 25, 2023 by Phoenix

[Mousetick]

48 minutes ago, Phoenix said:

For the reference originating in Dawnguard.esm, 02011CFD, I am seeing that it is referenced by the Tamriel worldspace record; however, I don't see it for the one originating in Skyrim.esm, 000AEDF5. Is there another way of recognising a large reference in xEdit?

Is there a specific reason you need to verify that a reference is indeed a large reference? The DynDOLOD report tells you which ones can cause visual issues based on its analysis of your entire load order. It's doing all the hard work for you, you can trust it's giving you accurate information. No need to go and double-check that they're indeed large references.

If you want to find and identify large references by yourself, you can follow this procedure (Method 2).

57 minutes ago, Phoenix said:

I had assumed TexGen + DynDOLOD would recognise the change and generate tree billboards + LOD. Am I wrong? Will this cause the large reference bug?

Yes DynDOLOD handles BOS swaps as expected. See https://dyndolod.info/Mods/Base-Object-Swapper.

The large reference bug issue is orthogonal to base object swaps. It can be caused with or without BOS. If something is modifying the base object of a large reference to a type that is neither STAT nor MSTT, it can cause visual issues. It doesn't matter whether that modification originates from a plugin or a BOS swap.

[sheson]

1 hour ago, Phoenix said:

Thank you very much for your responses!

For the reference originating in Dawnguard.esm, 02011CFD, I am seeing that it is referenced by the Tamriel worldspace record; however, I don't see it for the one originating in Skyrim.esm, 000AEDF5. Is there another way of recognising a large reference in xEdit?

Turns out that was BOS being sneaky. I am using an INI to replace the trees from Dragonborn - which, for whatever reason, are STATICS in vanilla - with TREE records. I had assumed TexGen + DynDOLOD would recognise the change and generate tree billboards + LOD. Am I wrong? Will this cause the large reference bug?

The official xEdit ignores RNAM data for Skyrim.esm to avoid interface slowdowns. You need to use xLODGen trerrain LOD beta in edit mode to see the RNAM data for Skyrim.esm.

https://dyndolod.info/Help/TexGen-Configuration#Tree-Grass-LOD-Billboards
A tree is every base record of the types 'TREE' and 'STAT' with the 'Has Tree LOD' flag set. Grass is every base record of the type 'GRAS'.

If a plugin contains new TREE base records and they match the other requirements (object bounds etc.) tree LOD billboards are usually generated automatically for them by TexGen. The TexGen log and ..\textures\terrain\lodgen\TexGen_[GAME MODE]_[Tree|Grass]_Billboards.txt will tell you for which trees LOD billboards have been created.

The log typically will tell you, if something causes large reference bugs. If a large reference uses a base record that is not of the type STAT or MSTT, it will cause large reference bugs unless the experimental https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds are used. With the workarounds large references can use TREE and ACTI base records as well without triggering the bugs.

[Phoenix]

1 hour ago, Mousetick said:

Is there a specific reason you need to verify that a reference is indeed a large reference? The DynDOLOD report tells you which ones can cause visual issues based on its analysis of your entire load order. It's doing all the hard work for you, you can trust it's giving you accurate information. No need to go and double-check that they're indeed large references.

Yeah, there is. I am currently working on a new modding guide as successor to my old one (The Phoenix Flavour) and I need to be able to explain the issue as succinctly as possible, rather than going "well, that's just how it is". Memorising something and being able to recall and apply it later on is always easier with proper understanding. In other words, I want to be able to point at a record, say "this is a large reference because X", and this is the issue it can cause if overwritten by an ESP.

I appreciate the link! I had seen your other post before, but was wondering if there was not a more consistent way to distinguish large references in xEdit solely because it would have been easier for the purpose of my write-up. Since there is not, I'll likely just note that DynDOLOD will warn accurately and list large references which is sufficient.

1 hour ago, Mousetick said:

The large reference bug issue is orthogonal to base object swaps. It can be caused with or without BOS. If something is modifying the base object of a large reference to a type that is neither STAT nor MSTT, it can cause visual issues. It doesn't matter whether that modification originates from a plugin or a BOS swap.

I understand that this has nothing to do with BOS as such, and did not mean to imply otherwise. If I understand you correctly, there is no way to change the STAT trees from Dragonborn to, well, proper TREE records as they are large references.

This is only tangentially related, but I am curious now. Do either of you know why these two Dragonborn trees are STAT records and large references while other trees have their own record type which are not counted as large references?

Edited January 25, 2023 by Phoenix

[Mousetick]

1 hour ago, Phoenix said:

I had seen your other post before, but was wondering if there was not a more consistent way to distinguish large references in xEdit solely because it would have been easier for the purpose of my write-up.

If the object bounds of a STAT or MSTT reference in an exterior cell, defined in one of the vanilla masters, are larger or equal to the fLargeRefMinSize GMST (512 by default in Skyrim.esm), taking into account its scale, then it's very likely, but not necessarily, a large reference. So things like mountain cliffs/ridges, big rocks, waterfalls, other pieces of landscape, statues, buildings, ruins, etc. are typically large references. A large statue scaled down to 0.1 is (most likely) not a large reference. Trees (TREE base record) are never large references in vanilla. These are just empirical guesstimates... May be a good enough an explanation for your guide?

1 hour ago, Phoenix said:

If I understand you correctly, there is no way to change the STAT trees from Dragonborn to, well, proper TREE records as they are large references.

This is only tangentially related, but I am curious now. Do either of you know why these two Dragonborn trees are STAT records and large references while other trees have their own record type which are not counted as large references?

Can you provide some specific examples? There are proper TREE base records in Dragonborn.esm such as DLC2TreePineForestAsh01, which are used to represent trees in the world. The STATs in Dragonborn.esm, such as DLC2TreePineForestBroken01, don't represent trees. They're landscape clutter basically.

If the BOS swap you're using replaces landscape clutter by actual trees, and this triggers large reference bugs warnings, you can either remove those specific swaps, or ignore the warnings. The large reference bugs warnings are there to inform about potential display issues, it does not imply that these issues are necessarily visible or noticeable in-game. You'd need to verify visually in-game whether LODs transitions happen smoothly or are bugged out (e.g. flickering, z-fighting), on a cell-by-cell basis.

Edit: clarification based on sheson's comment.

[sheson]

11 minutes ago, Mousetick said:

The large reference bugs warnings are there to inform about potential issues, it does not imply that these issues necessarily occur in-game. You'd need to verify in-game whether LODs transitions happen smoothly or are bugged out, on a cell-by-cell basis.

Every warning about a large reference means the object LOD for all large references for that cell is not disabled inside the uLargeRefLODGridSize. Otherwise I would be interested about warnings where you find that this is actually not the case.

[Mousetick]

7 minutes ago, sheson said:

Every warning about a large reference means the object LOD for large reference is not disabled inside the uLargeRefLODGridSize. Otherwise I would be interested about warnings where you find that this is actually not the case.

I didn't mean the issue doesn't exist, I meant it may not be visible or noticeable, and therefore is not an "issue" from a game player perspective.

As described on https://dyndolod.info/Help/Large-References:

Quote

In the "best" case scenario the full model and LOD do not occupy the same 3D space. If the LOD model is larger then LOD just seems to transition to the full model as close to the player as ever - the increased resource usage and performance requirements of these full models being loaded further are wasted for no visual gain. If the LOD model is smaller, then everything appears to be working normally (this is the case for a handful vanilla bugs) - LOD not unloading further away when it could just wastes a bit of performance.

Sorry for not being clear enough. I'll rectify my previous comment.

[Phoenix]

1 hour ago, Mousetick said:

Can you provide some specific examples? There are proper TREE base records in Dragonborn.esm such as DLC2TreePineForestAsh01, which are used to represent trees in the world. The STATs in Dragonborn.esm, such as DLC2TreePineForestBroken01, don't represent trees. They're landscape clutter basically.

Sure. So the BOS INI that I had was swapping two Dragonborn statics, 0403383D and 0403383C, to vanilla trees (which are actual TREE records), thus causing DynDOLOD to warn about large references being changed to non STAT or MSTT records. The two STAT records in question are "proper" trees in appearance (see here and here) but defined as STAT records and placed as large references. Of course, that means they will retain their vanilla appearance as opposed to being replaced by Happy Little Trees (or other tree overhauls). 

I do understand that the issue with flickering / invisible LOD is not guaranteed to appear for every overwritten large reference. 

1 hour ago, Mousetick said:

If the object bounds of a STAT or MSTT reference in an exterior cell, defined in one of the vanilla masters, are larger or equal to the fLargeRefMinSize GMST (512 by default in Skyrim.esm), taking into account its scale, then it's very likely, but not necessarily, a large reference. So things like mountain cliffs/ridges, big rocks, waterfalls, other pieces of landscape, statues, buildings, ruins, etc. are typically large references. A large statue scaled down to 0.1 is (most likely) not a large reference. Trees (TREE base record) are never large references in vanilla. These are just empirical guesstimates... May be a good enough an explanation for your guide?

That helps, thanks! 

2 hours ago, sheson said:

If a plugin contains new TREE base records and they match the other requirements (object bounds etc.) tree LOD billboards are usually generated automatically for them by TexGen. The TexGen log and ..\textures\terrain\lodgen\TexGen_[GAME MODE]_[Tree|Grass]_Billboards.txt will tell you for which trees LOD billboards have been created.

The log typically will tell you, if something causes large reference bugs. If a large reference uses a base record that is not of the type STAT or MSTT, it will cause large reference bugs unless the experimental https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds are used. With the workarounds large references can use TREE and ACTI base records as well without triggering the bugs.

Thank you for the clarification! Using the workaround would then be, I believe, the only way to change the two Dragonborn trees currently posing as STAT records into actual trees, right? While preventing any risk of the large reference bug, that is.

[sheson]

31 minutes ago, Phoenix said:

Thank you for the clarification! Using the workaround would then be, I believe, the only way to change the two Dragonborn trees currently posing as STAT records into actual trees, right? While preventing any risk of the large reference bug, that is.

Yes. 

The workarounds are still in a testing phase right now to make sure there are no ill side effects. If all goes well they will be the default.