DynDOLOD 3.00 Alpha 169

[sheson]

53 minutes ago, 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.

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]

3 hours ago, 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. 

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.

3 hours ago, 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.

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]

58 minutes ago, 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.

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]

2 hours ago, 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.

Yes, looks like the rules indeed do not resolve.

[Mousetick]

19 minutes ago, 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.

Right.

20 minutes ago, 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.

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.

29 minutes ago, 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.

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]

20 minutes ago, 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?

 

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]

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

 

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...

 

 

[yxzhang]

Hi Sheson, I noticed some SHESON_DynDOLOD_LODObject scripts stuck in infinite loop on my game. The variable SatetyCounter is 0-10 for most script instances, but for the stuck ones, SatetyCounter became negative, and the while loop never ends. There are 8 of them in my 40 hour save.

Given that the wait time is utility.wait(1), I believe it should be this while loop: while self && SafetyCounter && (OpenState != self.GetOpenState())

[sheson]

1 hour ago, Mousetick said:

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...

The current alpha version has a bug, so it does not delete those references when the current unofficial patch is used. If the references are not deleted by DynDOLOD, then the full models added by the unofficial patch to the Solitude worldspace should still be visible. You know if the bug happens, if the advanced interface shows the reference rules as not resolved as I explained here already https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-128/?do=findComment&comment=272122. Does the bug not happen for you?

If the current alpha version still deletes those references because the bug does not happen for your load order, then obviously just remove the reference rules that delete those references via the advanced interface or directly from the DynDOLOD_SSE_unofficialskyrimspecialeditionpatchesp.ini. Then everything should just work with ultra tree LOD. Does it not?

As usual, always use the latest Alpha version. Whatever older versions do is irrelevant.

[sheson]

22 minutes ago, yxzhang said:

Hi Sheson, I noticed some SHESON_DynDOLOD_LODObject scripts stuck in infinite loop on my game. The variable SatetyCounter is 0-10 for most script instances, but for the stuck ones, SatetyCounter became negative, and the while loop never ends. There are 8 of them in my 40 hour save.

Given that the wait time is utility.wait(1), I believe it should be this while loop: while self && SafetyCounter && (OpenState != self.GetOpenState())

Read the first post which DynDOLOD log and debug log to upload when making posts. That would help determine which scripts you are actually using.

If the counter goes to 0, it evaluates to false and exists the while loop. 

[Mousetick]

I really appreciate your patience and willingness to respond, but I'm afraid we're still talking past each other

19 minutes ago, sheson said:

If the current alpha version still deletes those references because the bug does not happen for your load order, then obviously just remove the reference rules that delete those references via the advanced interface or directly from the DynDOLOD_SSE_unofficialskyrimspecialeditionpatchesp.ini.

The rules bug doesn't happen to me because I'm using Alpha 120. The USSEP rules are detected and seemingly applied correctly, as they've ever been since a long time ago:

Forget about the current rules bug for a minute, assume it doesn't exist, and let me ask differently. I'm just trying to understand what is the expected behavior inside SolitudeWorld when DynDOLOD and the USSEP rules work as intended.

• What is supposed to be in the DynDOLOD plugin(s) exactly when the USSEP patch is working as intended?

It's understood that the neverfade trees added by USSEP in SolitudeWorld are "deleted" by overriding them with UDR'ed XMarkers. Ok, that part is fine.

But is that it? The trees are removed but not replaced by regular temporary duplicate references?

• Is it expected that the LODs for the "deleted" trees still be visible from SolitudeWorld then?

Thanks.

[sheson]

43 minutes ago, Mousetick said:

I really appreciate your patience and willingness to respond, but I'm afraid we're still talking past each other

The rules bug doesn't happen to me because I'm using Alpha 120. The USSEP rules are detected and seemingly applied correctly, as they've ever been since a long time ago:

Forget about the current rules bug for a minute, assume it doesn't exist, and let me ask differently. I'm just trying to understand what is the expected behavior inside SolitudeWorld when DynDOLOD and the USSEP rules work as intended.

• What is supposed to be in the DynDOLOD plugin(s) exactly when the USSEP patch is working as intended?

It's understood that the neverfade trees added by USSEP in SolitudeWorld are "deleted" by overriding them with UDR'ed XMarkers. Ok, that part is fine.

But is that it? The trees are removed but not replaced by regular temporary duplicate references?

• Is it expected that the LODs for the "deleted" trees still be visible from SolitudeWorld then?

Thanks.

https://dyndolod.info
Always use the latest version. Using the latest version and to provide feedback or to report problems is a requirement to participate in the alpha test. Do not waste time using older versions or reporting problems with older versions.

Reference rules are simply supposed to do what they are documented to do:

https://dyndolod.info/Help/Mesh-Mask-Reference-Rules#Dynamic-LOD-Options
Delete disables original reference completely and there will not be any LOD.

The vanilla game already adds the corresponding tree reference in the Tamriel worldspace, for which LOD is generated. Solitude uses the parent worldspace Tamriel for LOD.

The unofficial patch adds tree references for the same positions in the child worldspace, which caused the standard tree LOD and full model to show at the same when the cells are active - when the user is close - in the child worldspace. Because they are flagged persistent and IsFullLOD, similar overlapping happens in the parent world. Hence references rules were added to delete them.

In the past few years new features were added that should automatically deal better with this if the references are not deleted. If not, then a new more appropriate solution that works for both standard and ultra tree LOD will be conceived.

So I ask again, does using the current version not applying the "deletions" / removing the reference rules solve the issue for you? 

[Mousetick]

3 hours ago, sheson said:

So I ask again, does using the current version not applying the "deletions" / removing the reference rules solve the issue for you? 

I'm not in the capacity to test the latest and greatest at this time, sorry.

So to summarize, after reading very hard between the lines of your oblique answers to my simple, direct questions: the issue is caused by the USSEP rules which should not be used (when doing tree LOD as object LOD? unclear, not sure).

Anyhow, reading https://dyndolod.info/DynDOLOD-Reference, specifically step #6 "Disable neverfades", gave me an idea. I made a patch that simply removes the IsFullLOD flag from the USSEP trees in SolitudeWorld. Problem solved. I guess that's what DynDOLOD would have done if I had run it without the USSEP rules?...

It's not perfect though, I'm guessing because the Tamriel LODs cover more trees/cells than there are duplicates in SolitudeWorld, quite a few trees still disappear when getting closer, but at least the closest trees (e.g. the ones in cell -17,26) don't vanish so it's not as noticeable and jarring.

Thanks.

[sheson]

On 6/24/2023 at 1:58 AM, Mousetick said:

I'm not in the capacity to test the latest and greatest at this time, sorry.

So to summarize, after reading very hard between the lines of your oblique answers to my simple, direct questions: the issue is caused by the USSEP rules which should not be used (when doing tree LOD as object LOD? unclear, not sure).

Anyhow, reading https://dyndolod.info/DynDOLOD-Reference, specifically step #6 "Disable neverfades", gave me an idea. I made a patch that simply removes the IsFullLOD flag from the USSEP trees in SolitudeWorld. Problem solved. I guess that's what DynDOLOD would have done if I had run it without the USSEP rules?...

It's not perfect though, I'm guessing because the Tamriel LODs cover more trees/cells than there are duplicates in SolitudeWorld, quite a few trees still disappear when getting closer, but at least the closest trees (e.g. the ones in cell -17,26) don't vanish so it's not as noticeable and jarring.

Thanks.

If you have problems using the current version, then report them. There is no reason not to use it.
I directly answered the questions what the rules are expected to do and how/why LOD for the trees is still be seen from Solitude.

If the current alpha version still deletes those references because the bug does not happen for your load order, then obviously just remove the reference rules that delete those references via the advanced interface or directly from the DynDOLOD_SSE_unofficialskyrimspecialeditionpatchesp.ini. Then everything should just work with ultra tree LOD. Does it not?

Does [..] removing the reference rules solve the issue for you? 

I am directly asking you to remove the reference rules instead of relying on the bug. Twice. Simply read the actual lines I am writing.

I am asking again, what happens when you do this? If the result still is not working, it will be addressed in the next update, as I already mentioned.

If you are unable to do what I am asking directly, then simply say so. Then I will add the tests to my long list of things to do. And you just need to wait for the next version for it to be resolved.