DynDOLOD 3.00 Alpha 190

[sheson]

  On 6/22/2023 at 9:51 PM, Blackread said:

Here are the Editor IDs for the trees outside Solitude:

Tree1: unofficialskyrimspecialeditionpatchesp_063133_unofficialskyrimspecialeditionpatchesp_063133_DynDOLOD_REVERT_DynDOLOD_CHILD
Tree2: unofficialskyrimspecialeditionpatchesp_06312F_unofficialskyrimspecialeditionpatchesp_06312F_DynDOLOD_REVERT_DynDOLOD_CHILD

Editor ID for the Solitude windmill rotor: DynDOLOD_SSE_skyrimesm_tamrielpatch_000004_DynDOLOD_PATCH_SolitudeWindMillFan_Tamriel_DynDOLOD_LOD

Editor ID for the windmill rotor outside Whiterun: skyrimesm_096272_Tamriel_DynDOLOD_LOD

Expand  

Did you change the Ignore= list in ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_SSE_childworld_SolitudeWorld.ini so that trees in that child worldspace should have LOD in Tamriel?

If TGC Solitude Fixes disables trees added by the unofficial patch to Tamriel, it should probably also disable trees with the same position in the Solitude worldspace.

[Blackread]

  On 6/23/2023 at 5:19 AM, sheson said:

Did you change the Ignore= list in ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_SSE_childworld_SolitudeWorld.ini so that trees in that child worldspace should have LOD in Tamriel?

If TGC Solitude Fixes disables trees added by the unofficial patch to Tamriel, it should probably also disable trees with the same position in the Solitude worldspace.

Expand  

I don't think I have edited any of the ini files except for DynDOLOD_SSE.ini, here's what's in the list:

Ignore=treereach, treepine, treeaspen, treeclover, treegourd, treekelp, treethicket, treevine, gkbtree, jungletree, cedartree, shrub, fern, flora, wrtreecircle, windmill, mountain, rock, fxwater, water1024, rapids, dirtcliff, drift, road, hay, wrpondwall, fence, stonewall, shackroof, impstoneblock, whprisonwallcap, whouterwallstatue, mrkmillroof01, crafting, fxglow, whgate, whdoorfrontgate, slightpost, signrtpost, mrkkeepcollonadecolm, mrkbrazierhangingdeco, mrkwarrensarch, mrkarch, candlehorn, candlel, candles, candle0, rtcanals, rtlamppost, fxmist, door

I disabled those two trees in the Solitude worldspace, regenerated LODs and now the problem trees in Tamriel are gone, thank you. I don't quite understand how these trees work though. I was checking them in game with just USSEP enabled, and I could see the same refs in both the Tamriel and Solitude worldspace. And even though the ref is placed in the Solitude worldspace, player.moveto xx06312f teleports me into the Tamriel worldspace. Same with that other tree, xx063133. xx063133 has an equivalent tree with the same position in the Tamriel worldspace, xx063127, and these trees appear on top of each other in the Tamriel worldspace (like duplicated objects). But I can't seem to find a tree in the Tamriel worldspace with the same position as xx06312f.

[Blackread]

  On 6/23/2023 at 11:14 AM, Blackread said:

I don't think I have edited any of the ini files except for DynDOLOD_SSE.ini, here's what's in the list:

Ignore=treereach, treepine, treeaspen, treeclover, treegourd, treekelp, treethicket, treevine, gkbtree, jungletree, cedartree, shrub, fern, flora, wrtreecircle, windmill, mountain, rock, fxwater, water1024, rapids, dirtcliff, drift, road, hay, wrpondwall, fence, stonewall, shackroof, impstoneblock, whprisonwallcap, whouterwallstatue, mrkmillroof01, crafting, fxglow, whgate, whdoorfrontgate, slightpost, signrtpost, mrkkeepcollonadecolm, mrkbrazierhangingdeco, mrkwarrensarch, mrkarch, candlehorn, candlel, candles, candle0, rtcanals, rtlamppost, fxmist, door

I disabled those two trees in the Solitude worldspace, regenerated LODs and now the problem trees in Tamriel are gone, thank you. I don't quite understand how these trees work though. I was checking them in game with just USSEP enabled, and I could see the same refs in both the Tamriel and Solitude worldspace. And even though the ref is placed in the Solitude worldspace, player.moveto xx06312f teleports me into the Tamriel worldspace. Same with that other tree, xx063133. xx063133 has an equivalent tree with the same position in the Tamriel worldspace, xx063127, and these trees appear on top of each other in the Tamriel worldspace (like duplicated objects). But I can't seem to find a tree in the Tamriel worldspace with the same position as xx06312f.

Expand  

Out of interest I also tried generating LOD with just USSEP, Happy Little Trees, the DynDOLOD 3 Addon for HLT and a custom plugin that disables xx063127 from USSEP. Nothing weird happened, and the tree was gone as expected, no passthru models were put in its place, or on the spot of xx06312f. Not sure what's going on in my main modlist that prompts it to happen.

Here are the logs and the plugin if you're interested.

USSEP Tree Disable.espFetching info...

[sheson]

  On 6/23/2023 at 11:14 AM, Blackread said:

I don't think I have edited any of the ini files except for DynDOLOD_SSE.ini, here's what's in the list:

Ignore=treereach, treepine, treeaspen, treeclover, treegourd, treekelp, treethicket, treevine, gkbtree, jungletree, cedartree, shrub, fern, flora, wrtreecircle, windmill, mountain, rock, fxwater, water1024, rapids, dirtcliff, drift, road, hay, wrpondwall, fence, stonewall, shackroof, impstoneblock, whprisonwallcap, whouterwallstatue, mrkmillroof01, crafting, fxglow, whgate, whdoorfrontgate, slightpost, signrtpost, mrkkeepcollonadecolm, mrkbrazierhangingdeco, mrkwarrensarch, mrkarch, candlehorn, candlel, candles, candle0, rtcanals, rtlamppost, fxmist, door

I disabled those two trees in the Solitude worldspace, regenerated LODs and now the problem trees in Tamriel are gone, thank you. I don't quite understand how these trees work though. I was checking them in game with just USSEP enabled, and I could see the same refs in both the Tamriel and Solitude worldspace. And even though the ref is placed in the Solitude worldspace, player.moveto xx06312f teleports me into the Tamriel worldspace. Same with that other tree, xx063133. xx063133 has an equivalent tree with the same position in the Tamriel worldspace, xx063127, and these trees appear on top of each other in the Tamriel worldspace (like duplicated objects). But I can't seem to find a tree in the Tamriel worldspace with the same position as xx06312f.

Expand  

Persistent references are always loaded. Persistent references with IsFullLOD show also when the cells for the position of the reference are not attached.
Solitude is a childworld of Tamriel and uses its SkyCell, which means persistent references with IsFullLOD show in both worldspaces either way.

References in the child worlspace that have the IsFullLOD flag are being patched by DynDOLOD and a carbon copy is created in the parent worldspace, so proper working LOD can be added instead.

Without TGC Solitude Fixes active, the carbon copy should not happen, if a reference already exists for the same position with the same model. Proper LOD will be added for it instead.

So, in any case, if the purpose is to remove the trees, TGC Solitude Fixes needs to disable the trees in both worldspaces regardless of using DynDOLOD or not.

DynDOLOD however, also has some reference rules that disable some trees added by the unofficial patch including 0006312F, 00063133 etc. since they are unnecessary, because of the IsFullLOD tree references in the childworld being patched to have proper LOD as explained above. 

[Blackread]

  On 6/23/2023 at 12:08 PM, sheson said:

Persistent references are always loaded. Persistent references with IsFullLOD show also when the cells for the position of the reference are not attached.
Solitude is a childworld of Tamriel and uses its SkyCell, which means persistent references with IsFullLOD show in both worldspaces either way.

References in the child worlspace that have the IsFullLOD flag are being patched by DynDOLOD and a carbon copy is created in the parent worldspace, so proper working LOD can be added instead.

Without TGC Solitude Fixes active, the carbon copy should not happen, if a reference already exists for the same position with the same model. Proper LOD will be added for it instead.

So, in any case, if the purpose is to remove the trees, TGC Solitude Fixes needs to disable the trees in both worldspaces regardless of using DynDOLOD or not.

DynDOLOD however, also has some reference rules that disable some trees added by the unofficial patch including 0006312F, 00063133 etc. since they are unnecessary, because of the IsFullLOD tree references in the child world being patched to have proper LOD as explained above. 

Expand  

Alright, thank you for the explanation. The only things I don't understand now are these:

xx06312f doesn't have an equivalent object in the Tamriel worldspace. So there was never any tree that was removed in the Tamriel worldspace, and thus no need to remove xx06312f from the Solitude world space. But for some reason this tree was still transported in that mutilated form into the Tamriel worldspace.

Disabling the tree xx063127, which is the Tamriel equivalent to xx063133, with USSEP Tree Disable.esp has no adverse side effects, but when done with TGC Solitude Fixes.esp, it does. Though I suspect it has nothing to do with either of these plugins, but something else entirely...

But these things will likely remain a mystery.

TGC Solitude Fixes.espFetching info...

[sheson]

  On 6/23/2023 at 12:29 PM, Blackread said:

Alright, thank you for the explanation. The only things I don't understand now are these:

xx06312f doesn't have an equivalent object in the Tamriel worldspace. So there was never any tree that was removed in the Tamriel worldspace, and thus no need to remove xx06312f from the Solitude world space. But for some reason this tree was still transported in that mutilated form into the Tamriel worldspace.

Disabling the tree xx063127, which is the Tamriel equivalent to xx063133, with USSEP Tree Disable.esp has no adverse side effects, but when done with TGC Solitude Fixes.esp, it does. Though I suspect it has nothing to do with either of these plugins, but something else entirely...

But these things will likely remain a mystery.

TGC Solitude Fixes.esp 68.91 kB · 0 downloads

Expand  

If 0006312F (and others) is not "deleted" per the references rules, then there is a bug I will have to look into.

[Blackread]

  On 6/23/2023 at 12:45 PM, sheson said:

If 0006312F (and others) is not "deleted" per the references rules, then there is a bug I will have to look into.

Expand  

I found a fairly minimal reproducible example. Here are the mods I had active:

If generating LODs with these mods the passthru for the tree (with the flat trunk) where xx06312f would be is added.

Editor ID: unofficialskyrimspecialeditionpatchesp_06312F_unofficialskyrimspecialeditionpatchesp_06312F_DynDOLOD_REVERT_DynDOLOD_CHILD

The TGC Solitude installation is stock from the Nexus, and doesn't edit any USSEP records.

Here are the logs for this run.

[sheson]

  On 6/23/2023 at 1:13 PM, Blackread said:

I found a fairly minimal reproducible example. Here are the mods I had active:

If generating LODs with these mods the passthru for the tree (with the flat trunk) where xx06312f would be is added.

Editor ID: unofficialskyrimspecialeditionpatchesp_06312F_unofficialskyrimspecialeditionpatchesp_06312F_DynDOLOD_REVERT_DynDOLOD_CHILD

The TGC Solitude installation is stock from the Nexus, and doesn't edit any USSEP records.

Here are the logs for this run.

Expand  

Just load DynDOLOD, advanced mode, click low, medium or high to update rules, Check if the reference rules for the unofficial patch resolve to references by hovering the mouse pointer over them. If it just shows the filename of the rules INI, the reference was not resolved. If it was resolved, there will be second line with info from the record. Just compare to the Skyrim.esm reference rule above, they should always resolve.

This worked at least up to the unofficial patch 4.25b but not anymore for some reason. Not quite sure about the cause, but it will be fixed in the next alpha.

[Mousetick]

  On 6/23/2023 at 12:08 PM, sheson said:

DynDOLOD however, also has some reference rules that disable some trees added by the unofficial patch including 0006312F, 00063133 etc. since they are unnecessary, because of the IsFullLOD tree references in the childworld being patched to have proper LOD as explained above. 

Expand  

I reported an issue related to this a while ago: 

My post was completely ignored, for whatever reason.

The report was based on Alpha 118, with USSEP 4.2.8, though the issue was noticed with much older Alphas before that. I haven't tested again with newer Alphas since 121.

  On 6/23/2023 at 12:08 PM, sheson said:

References in the child worlspace that have the IsFullLOD flag are being patched by DynDOLOD and a carbon copy is created in the parent worldspace, so proper working LOD can be added instead.

Expand  

We were able to determine that the USSEP Neverfades in SolitudeWorld were indeed patched/disabled. But the carbon copy that's supposed to be created in Tamriel seems to be missing, or not visible for some reason.

[sheson]

  On 6/23/2023 at 3:17 PM, Mousetick said:

I reported an issue related to this a while ago: 

My post was completely ignored, for whatever reason.

The report was based on Alpha 118, with USSEP 4.2.8, though the issue was noticed with much older Alphas before that. I haven't tested again with newer Alphas since 121.

We were able to determine that the USSEP Neverfades in SolitudeWorld were indeed patched/disabled. But the carbon copy that's supposed to be created in Tamriel seems to be missing, or not visible for some reason.

Expand  

That post seems to have been lost on me among the other posts. If I don't reply to something in a matter of days/week just make a new post linking the old one.

The issue right now is that mesh references rules that "delete" specific tree references added by the unofficial patch in Solitude are not being applied.

If I interpret the screenshots correctly, the "deleting" of xx06313E etc. worked as desired, since it shows the xMarker.nif. That is done so LOD and full models do not show at the same time. Also, when in Tamriel, there is the original full model tree and the IsFullLOD tree from the unofficial patch showing at the same time. So there is two reasons to "delete" those tree references. These rules exist since a long time ago and were already made for Skyrim LE unofficial patch, IIRC even before ultra tree LOD was a thing. The automatic stuff that happens now instead might be actually better now when using ultra tree LOD.

[Blackread]

  On 6/23/2023 at 2:06 PM, sheson said:

Just load DynDOLOD, advanced mode, click low, medium or high to update rules, Check if the reference rules for the unofficial patch resolve to references by hovering the mouse pointer over them. If it just shows the filename of the rules INI, the reference was not resolved. If it was resolved, there will be second line with info from the record. Just compare to the Skyrim.esm reference rule above, they should always resolve.

This worked at least up to the unofficial patch 4.25b but not anymore for some reason. Not quite sure about the cause, but it will be fixed in the next alpha.

Expand  

Yes, looks like the rules indeed do not resolve.

[Mousetick]

  On 6/23/2023 at 3:58 PM, sheson said:

If I interpret the screenshots correctly, the "deleting" of xx06313E etc. worked as desired, since it shows the xMarker.nif. That is done so LOD and full models do not show at the same time.

Expand  

Right.

  On 6/23/2023 at 3:58 PM, sheson said:

Also, when in Tamirel, there is the original full model tree and the IsFullLOD tree from the unofficial patch showing at the same time. So there is two reasons to "delete" those tree references.

Expand  

The issue is that the tree references are "deleted" in SolitudeWorld, but there is visibly nothing to replace them, in SolitudeWorld.

When inside SolitudeWorld, looking from afar, the Tamriel LODs are visible, showing trees in the distance. Upon getting closer, the LODs turn off, and there are no full model trees where the LODs used to be shown, as I described in another, earlier post:

I don't understand why it's so difficult to convey to you what's happening and what the weirdness is. It should be straightforward to reproduce: USSEP + DynDOLOD object LOD is all that's needed.

1. Walk from Solitude catacombs towards Angeline Aromatics. Facing north, as you pass under the arch connecting to the windmill, see the tree LODs in the distance in the mountains behind the walls.
2. As you keep walking in the same direction, see the tree LODs turn off, and an empty space where they used to be. Instead of full model trees.

  On 6/23/2023 at 3:58 PM, sheson said:

These rules exist since a long time ago and were already made for Skyrim LE unofficial patch, IIRC even before ultra tree LOD was a thing.

Expand  

Perhaps. The question remains: is this weird behavior expected?

Where are the carbon copies of the "deleted" references created, if they are created in the first place? Which worldspace? What are their refids and/or editor ids?

 

[Blackread]

  On 6/23/2023 at 4:41 PM, Mousetick said:

Right.

The issue is that the tree references are "deleted" in SolitudeWorld, but there is visibly nothing to replace them, in SolitudeWorld.

When inside SolitudeWorld, looking from afar, the Tamriel LODs are visible, showing trees in the distance. Upon getting closer, the LODs turn off, and there are no full model trees where the LODs used to be shown, as I described in another, earlier post:

I don't understand why it's so difficult to convey to you what's happening and what the weirdness is. It should be straightforward to reproduce: USSEP + DynDOLOD object LOD is all that's needed.

1. Walk from Solitude catacombs towards Angeline Aromatics. Facing north, as you pass under the arch connecting to the windmill, see the tree LODs in the distance in the mountains behind the walls.
2. As you keep walking in the same direction, see the tree LODs turn off, and an empty space where they used to be. Instead of full model trees.

Perhaps. The question remains: is this weird behavior expected?

Where are the carbon copies of the "deleted" references created, if they are created in the first place? Which worldspace? What are their refids and/or editor ids?

 

Expand  

I checked this tree issue in my game to see if it's happening, but it doesn't seem to be. When the cells load the LOD trees turn into full models as expected.

However I did notice that when turning on large refs, the trees turn invisible in the large ref grid, like the ones I reported around Kynesgrove.

[sheson]

  On 6/23/2023 at 4:41 PM, Mousetick said:

Right.

The issue is that the tree references are "deleted" in SolitudeWorld, but there is visibly nothing to replace them, in SolitudeWorld.

When inside SolitudeWorld, looking from afar, the Tamriel LODs are visible, showing trees in the distance. Upon getting closer, the LODs turn off, and there are no full model trees where the LODs used to be shown, as I described in another, earlier post:

I don't understand why it's so difficult to convey to you what's happening and what the weirdness is. It should be straightforward to reproduce: USSEP + DynDOLOD object LOD is all that's needed.

1. Walk from Solitude catacombs towards Angeline Aromatics. Facing north, as you pass under the arch connecting to the windmill, see the tree LODs in the distance in the mountains behind the walls.
2. As you keep walking in the same direction, see the tree LODs turn off, and an empty space where they used to be. Instead of full model trees.

Perhaps. The question remains: is this weird behavior expected?

Where are the carbon copies of the "deleted" references created, if they are created in the first place? Which worldspace? What are their refids and/or editor ids?

 

Expand  

As I wrote, if the tree references inside Solitude are currently not "deleted" because of a bug, then I would expect ultra tree LOD generated with Alpha 128 to be better now.

As I explained, that setup was made for standard tree LOD many years ago.  Generate standard tree LOD instead of ultra tree LOD and test that too. I would expect the old issue of having billboard tree LOD and full model show at the same time may creep up again - or not, since additional features have been added in the past years to address that automatically.

Carbon copies for IsFullLOD references in a childworld are added to the parent world or vice versa if the IsFullLOD flag is removed. The editor id will always have the plugin and form id of their source reference in them.

[Mousetick]

I'm about to give up In fact I'd got tired of the runaround so I manually duplicated the USSEP tree neverfades disabled by DynDOLOD.esm into a custom patch plugin, as temporary references, in xEdit. So that I could see the full models.

nth attempt to describe the issue:

Cell -17,26

None of the references below are large references.

[CELL:0000925A] (in Tamriel "Skyrim" [WRLD:0000003C] at -17,26) 

USSEP adds [REFR:05063114] (places TreePineForestSnow04 [TREE:0005C06F] in GRUP Cell Temporary Children of [CELL:0000925A] (in Tamriel "Skyrim" [WRLD:0000003C] at -17,26))

DynDOLOD.esm changes nothing, it only adds Tamriel_Worshipper_%17_26 [REFR:XX02F280] (places DynDOLOD_WorshipperActivator [STAT:XX000926] in GRUP Cell Temporary Children of [CELL:0000925A] (in Tamriel "Skyrim" [WRLD:0000003C] at -17,26))

[CELL:00037EE6] (in SolitudeWorld "Solitude" [WRLD:00037EDF]) This is the persistent cell of SolitudeWorld.

USSEP adds [REFR:0506313E] (places TreePineForestSnow04 [TREE:0005C06F] in GRUP Cell Persistent Children of [CELL:00037EE6] (in SolitudeWorld "Solitude" [WRLD:00037EDF]) at -17,26) which is a neverfade duplicate of [REFR:05063114] above from Tamriel into SolitudeWorld.

DynDOLOD.esm "deletes" [REFR:0506313E]: [REFR:0506313E] (places XMarker [STAT:0000003B] in GRUP Cell Persistent Children of [CELL:00037EE6] (in SolitudeWorld "Solitude" [WRLD:00037EDF]) at -17,26) This is the USSEP rules patch which may not be currently working, but it used to work, at least until Alpha 121. Just assume that it works for the sake of this description.

[CELL:0004E3DC] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -17,26) Same cell position as [CELL:0000925A] but in Solitude worldspace.

USSEP changes nothing.

DynDOLOD.esm changes nothing, it only adds SolitudeWorld_Worshipper_%17_26 [REFR:XX02F632] (places DynDOLOD_WorshipperActivator [STAT:XX000926] in GRUP Cell Temporary Children of [CELL:0004E3DC] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -17,26))

End result:

• When [CELL:0004E3DC] is not loaded, the LOD of [REFR:05063114] is visible from inside SolitudeWorld. So far so good.
• When [CELL:0004E3DC] is loaded, the LOD of [REFR:05063114] is disabled, the full model of [REFR:05063114] is not visible since it's in another worldspace. But there is nothing to replace [REFR:0506313E], "deleted" by DynDOLOD, in SolitudeWorld. There is no tree reference in [CELL:0004E3DC] matching [REFR:05063114]. There is no tree where the LOD was showing...