DynDOLOD 3.00 Alpha 182

[DoubleYou]

4 hours ago, sheson said:

I will need to generally enable the game mode FO4 and do some other updates in the code.

Send me one FO4 config file that contains at least one LOD texture, then I could see about implementing that.

I added several. 

• BeachPineBark01_d                    simple 1 to 1 texture, no alpha on either
• ElmAtlas_D.dds                            0.5 to 1 (might have the config wrong) needing alpha
• DriedGrass01_D.DDS                  1 to 1 texture, source has alpha, destination needs to have no alpha.

https://mega.nz/file/UIBmTbbQ#47AkdAcPCZdJjRpy4m9NnWc4noUloE08OgCOh2XQOBI

[LordIceWolf]

23 hours ago, sheson said:

There is no extra step.

Anything that would have object LOD in Tamriel (e.g. LOD assets or mesh mask match) and does not match the ignore lists and does seem to exist already in the parent world near the same position gets a facsimile copy.

Check ..\Logs\DynDOLOD_SSE_ChildworldCopies_Tamriel.txt for the list of objects that made the cut.

Make sure to edit the right INI.

The better method would be that whatever mods adds trees to the child world, should also add them to the parent world.

I found the source of the issue and just wanted to post it here in case someone else encounter the same issue. I had flagged the Whiterun Tree Plugin as esl and it appears to be the source of the problem. I reinstalled it as a regular esp and reran DynDOLOD and everything now works as it should.

[sheson]

51 minutes ago, LordIceWolf said:

I found the source of the issue and just wanted to post it here in case someone else encounter the same issue. I had flagged the Whiterun Tree Plugin as esl and it appears to be the source of the problem. I reinstalled it as a regular esp and reran DynDOLOD and everything now works as it should.

And what would the name of the mod(s) and plugin(s) be?

[LordIceWolf]

1 hour ago, sheson said:

And what would the name of the mod(s) and plugin(s) be?

It's the optional file on this mod
https://www.nexusmods.com/skyrimspecialedition/mods/20396

The plugin is named Timber for Whiterun MystiriousDawn.esp

[Blackread]

I was wondering, since DynDOLOD already warns about overwritten large references and large references with the Initially Disabled flag, would it also be possible to add a warning about large references that have been moved outside their original cell? At least on my setup these kind of edits seem to fairly consistently trigger an issue where the data of the last plugin that places it in the origin cell is used instead of the override which moved it to another cell. This is especially true whenever the large ref system is enabled (uLargeRefLODGridSize > uGridsToLoad).

As an example, COTN Falkreath swaps the model of the Jarl's Longhouse and moves it up the hill (which is to say, into another exterior cell). If I have uLargeRefLODGridSize = uGridsToLoad it works fine, but if I enable large refs the longhouse ends up in its old position and using its old model. I can work around this with the disable & duplicate trick, but finding these issues would be a lot easier (and faster) if I had a list of all the records that need to be addressed, instead of having to manually check every overwritten large reference.

[Blackread]

Another question related to large references... I tried running the Skyrim SE - Generate Large References script on some plugins, and it sometimes results in non-existent form IDs ending up in the RNAM table. This seems to happen when there is an overwrite swapping the base object of a reference. The resulting form ID has the plugin index from the overwriting plugin, but the rest of the ID is from the plugin where the reference was introduced, resulting in a mismatched ID. Here's the log output when running the script on Water for ENB.esm and DLC2SolstheimWorld:

[00.00] Start: Applying script "Skyrim SE - Generate Large References"
Gathering large references added by Water for ENB.esm
Overwrite: [REFR:04021003] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDC6] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 15,16))
Overwrite: [REFR:04024528] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDAD] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 7,17))
Overwrite: [REFR:0402452C] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDCF] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 6,16))
Overwrite: [REFR:04024534] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of DLC2StoneWater02 [CELL:0400EDD0] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 5,16))
Overwrite: [REFR:04026BDC] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDA7] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 13,17))
Overwrite: [REFR:04026D14] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDAD] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 7,17))
Overwrite: [REFR:040274AE] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400ED85] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 14,18))
Overwrite: [REFR:0402868C] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of DLC2POIChest01 [CELL:0400ED48] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 9,20))
Overwrite: [REFR:04031957] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400ED83] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 16,18))
Overwrite: [REFR:04033EEF] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDA7] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 13,17))
Adding 10 large references to DLC2SolstheimWorld
[00.10] Done: Applying script "Skyrim SE - Generate Large References", Elapsed Time: 00.10

And here are some of the resulting entries in the RNAM table:

I was using the version of the script that comes bundled with xEdit 4.0.4

Edited July 11, 2022 by Blackread

[sheson]

5 hours ago, Blackread said:

I was wondering, since DynDOLOD already warns about overwritten large references and large references with the Initially Disabled flag, would it also be possible to add a warning about large references that have been moved outside their original cell? At least on my setup these kind of edits seem to fairly consistently trigger an issue where the data of the last plugin that places it in the origin cell is used instead of the override which moved it to another cell. This is especially true whenever the large ref system is enabled (uLargeRefLODGridSize > uGridsToLoad).

As an example, COTN Falkreath swaps the model of the Jarl's Longhouse and moves it up the hill (which is to say, into another exterior cell). If I have uLargeRefLODGridSize = uGridsToLoad it works fine, but if I enable large refs the longhouse ends up in its old position and using its old model. I can work around this with the disable & duplicate trick, but finding these issues would be a lot easier (and faster) if I had a list of all the records that need to be addressed, instead of having to manually check every overwritten large reference.

The reference is already reported as being overwritten, no?

What you describe is not really possible AFAIK I know. Check with More Informative Console which are the last plugins reported to change the reference / base record.

The engine enforces its own load order of plugins which can be different to plugins.txt.

1 hour ago, Blackread said:

Another question related to large references... I tried running the Skyrim SE - Generate Large References script on some plugins, and it sometimes results in non-existent form IDs ending up in the RNAM table. This seems to happen when there is an overwrite swapping the base object of a reference. The resulting form ID has the plugin index from the overwriting plugin, but the rest of the ID is from the plugin where the reference was introduced, resulting in a mismatched ID. Here's the log output when running the script on Water for ENB.esm and DLC2SolstheimWorld:

[00.00] Start: Applying script "Skyrim SE - Generate Large References"
Gathering large references added by Water for ENB.esm
Overwrite: [REFR:04021003] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDC6] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 15,16))
Overwrite: [REFR:04024528] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDAD] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 7,17))
Overwrite: [REFR:0402452C] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDCF] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 6,16))
Overwrite: [REFR:04024534] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of DLC2StoneWater02 [CELL:0400EDD0] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 5,16))
Overwrite: [REFR:04026BDC] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDA7] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 13,17))
Overwrite: [REFR:04026D14] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDAD] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 7,17))
Overwrite: [REFR:040274AE] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400ED85] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 14,18))
Overwrite: [REFR:0402868C] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of DLC2POIChest01 [CELL:0400ED48] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 9,20))
Overwrite: [REFR:04031957] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400ED83] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 16,18))
Overwrite: [REFR:04033EEF] (places MXCreekFlatLarge [STAT:FE005882] in GRUP Cell Temporary Children of [CELL:0400EDA7] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800] at 13,17))
Adding 10 large references to DLC2SolstheimWorld
[00.10] Done: Applying script "Skyrim SE - Generate Large References", Elapsed Time: 00.10

And here are some of the resulting entries in the RNAM table:

I was using the version of the script that comes bundled with xEdit 4.0.4

Test with latest version from https://github.com/TES5Edit/TES5Edit/blob/dev-4.1.5/Build/Edit Scripts/Skyrim SE - Generate Large References.pas

[Mousetick]

1 hour ago, sheson said:

The reference is already reported as being overwritten, no?

Not if the plugin(s) overwriting the reference are ESM or ESM-flagged ESP. In that case, DynDOLOD doesn't consider the overwrite buggy and doesn't warn about it.

An ESM moving a large reference to a different cell than where it is initially defined appears to trigger a different kind of bug than those described in https://dyndolod.info/Help/Large-References.

Consider for example:

• Skyrim.esm: adds REFR abc to Cell x1,y1 in Tamriel worldspace, includes it in Tamriel's RNAM table, so it's a large reference.
• Plugin.esm: overwrites REFR abc and moves it to Cell x2,y2.

From DynDOLOD's validation point of view, it's all good. What happens in-game however is something like this:

• Player approaches Cell x2,y2 by entering one of the near cells inside the uGrid encompassing Cell x2,y2: full model is loaded in Cell x2,y2, as expected.
• Player approaches Cell x2,y2 by entering one of the far cells inside the uLargeRefLODGridSize encompassing Cell x1,y1: full model is loaded in Cell x1,y1, which is the wrong one.

Basically the engine is given inconsistent information about the location of the large reference, the RNAM table being out of sync with the actual cell location of the REFR.

Hope my description is relatively clear and makes sense.

Thanks.

Addendum:

I should add that this 'RNAM out-of-sync with moved large reference issue' seems to arise from ESMifying ESP plugins, which don't have their own RNAM tables, or by creating an ESM plugin entirely in xEdit without manually generating the RNAM tables. If I'm not mistaken, such a situation would never normally arise in an ESM 'natively' constructed by CK, because CK is supposed to automatically generate the RNAM table? In that case, the CK-generated RNAM table for that ESM would reflect the move of the large reference to a different cell.

Edited July 11, 2022 by Mousetick
Added stuff I forgot

[sheson]

1 hour ago, Mousetick said:

Not if the plugin(s) overwriting the reference are ESM or ESM-flagged ESP. In that case, DynDOLOD doesn't consider the overwrite buggy and doesn't warn about it.

An ESM moving a large reference to a different cell than where it is initially defined appears to trigger a different kind of bug than those described in https://dyndolod.info/Help/Large-References.

Consider for example:

• Skyrim.esm: adds REFR abc to Cell x1,y1 in Tamriel worldspace, includes it in Tamriel's RNAM table, so it's a large reference.
• Plugin.esm: overwrites REFR abc and moves it to Cell x2,y2.

From DynDOLOD's validation point of view, it's all good. What happens in-game however is something like this:

• Player approaches Cell x2,y2 by entering one of the near cells inside the uGrid encompassing Cell x2,y2: full model is loaded in Cell x2,y2, as expected.
• Player approaches Cell x2,y2 by entering one of the far cells inside the uLargeRefLODGridSize encompassing Cell x1,y1: full model is loaded in Cell x1,y1, which is the wrong one.

Basically the engine is given inconsistent information about the location of the large reference, the RNAM table being out of sync with the actual cell location of the large REFR.

Hope my description is relatively clear and makes sense.

Thanks.

Addendum:

I should add that this 'RNAM out-of-sync with moved large reference issue' seems to arise from ESMifying ESP plugins, which don't have their own RNAM tables, or by creating an ESM plugin entirely in xEdit without manually generating the RNAM tables. If I'm not mistaken, such a situation would never normally arise in an ESM 'natively' constructed by CK, because CK is supposed to automatically generate the RNAM table? In that case, the CK-generated RNAM table for that ESM would reflect the move of the large reference to a different cell.

There is no mention in the post that the plugin has been ESM flagged, it seems to be an normal ESP based on the information provided.
Seems to me the plugin triggers lots of large reference bugs already.

The CK often adds all surrounding cells to the  RNAM table, not only the one the large reference is in. This is used for pre-loading references one cell ahead (Skyrim LE or if large references are off).

Be that as it may, the last plugin to overwrite anything is typically not ignored (unless the Ignore flag is set), so whatever base record  / model is used is typically defined by the last overwrite. 

[Mousetick]

29 minutes ago, sheson said:

There is no mention in the post that the plugin has been ESM flagged, it seems to be an normal ESP based on the information provided.

I'm pretty sure that's the case, based on my conversation with the OP elsewhere, and this information was omitted. The OP is attempting to fix the large reference bugs by ESMifying plugins. But of course it's not for me to say. I'll let the OP confirm whether they've ESM-flagged the plugin or not.

[sheson]

12 hours ago, LordIceWolf said:

It's the optional file on this mod
https://www.nexusmods.com/skyrimspecialedition/mods/20396

The plugin is named Timber for Whiterun MystiriousDawn.esp

I compacted the FormIDs and ESL flagged the plugin Timber for Whiterun MystiriousDawn.esp and removed "treereach, treepine, treeaspen," from the Ignore= line in DynDOLOD_SSE.ini and then generated LOD. The trees were copied from the child world to the parent word and LOD was generated for them as expected.

DynDOLOD_SSE_ChildworldCopies_Tamriel.txt contains the expected lines for the trees as well. For example:

[REFR:FE001D8F] (places TreePineForest02 [TREE:00018A02] in GRUP Cell Temporary Children of WhiterunPlainsDistrict04 [CELL:0001A276] (in WhiterunWorld "Whiterun" [WRLD:0001A26F] at 6,-2)) -> timberforwhiterunmystiriousdawnesp_000D8F_DynDOLOD_CHILD [REFR:084D18F5] ...

[sheson]

11 hours ago, Blackread said:

I was wondering, since DynDOLOD already warns about overwritten large references and large references with the Initially Disabled flag, would it also be possible to add a warning about large references that have been moved outside their original cell? At least on my setup these kind of edits seem to fairly consistently trigger an issue where the data of the last plugin that places it in the origin cell is used instead of the override which moved it to another cell. This is especially true whenever the large ref system is enabled (uLargeRefLODGridSize > uGridsToLoad).

As an example, COTN Falkreath swaps the model of the Jarl's Longhouse and moves it up the hill (which is to say, into another exterior cell). If I have uLargeRefLODGridSize = uGridsToLoad it works fine, but if I enable large refs the longhouse ends up in its old position and using its old model. I can work around this with the disable & duplicate trick, but finding these issues would be a lot easier (and faster) if I had a list of all the records that need to be addressed, instead of having to manually check every overwritten large reference.

With either 1.5.97 or 1.6.353, either with the plugin COTN - Falkreath.esp from https://www.nexusmods.com/skyrimspecialedition/mods/56731 as is or after ESM flagging it without generating RNAM data, then generating LOD, I always see the new model and also the large reference seems to behave normally, e. g. it loads past the uGridsToLoad and turns off beyond uLargeRefLODGridSize.

[sheson]

5 hours ago, Mousetick said:

• Player approaches Cell x2,y2 by entering one of the near cells inside the uGrid encompassing Cell x2,y2: full model is loaded in Cell x2,y2, as expected.
• Player approaches Cell x2,y2 by entering one of the far cells inside the uLargeRefLODGridSize encompassing Cell x1,y1: full model is loaded in Cell x1,y1, which is the wrong one.

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.

[Mousetick]

1 hour ago, 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?

I had one a while ago. But it was with a large reference to a PlaneMarker STAT, so "full model" doesn't really apply there. I believe it's the same or very similar problem though.

@Blackread describes a better example in details with a boat in Solitude in this topic.

[sheson]

1 hour ago, Mousetick said:

I had one a while ago. But it was with a large reference to a PlaneMarker STAT, so "full model" doesn't really apply there. I believe it's the same or very similar problem though.

@Blackread describes a better example in details with a boat in Solitude in this topic.

There has to be something else at work, too. Save games do save positions of things, so any tests need to be with new game.

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.