DynDOLOD 3.00 Alpha 190

[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]

  On 6/23/2023 at 6:14 PM, 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...

Expand  

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]

  On 6/23/2023 at 7:59 PM, 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())

Expand  

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

  On 6/23/2023 at 8:00 PM, 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.

Expand  

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]

  On 6/23/2023 at 8:51 PM, 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.

Expand  

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]

  On 6/23/2023 at 9:14 PM, sheson said:

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

Expand  

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/23/2023 at 11:58 PM, 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.

Expand  

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.

[yxzhang]

  On 6/23/2023 at 8:11 PM, sheson said:

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. 

Expand  

Here's the log, https://ufile.io/eniga12z, and in summary my version is 3.0.0.128, latest one from nexus.

That's the intended behavior, I know. But I find the counter negative in my save file, and the loop never ends. Not sure how. Heavily loaded Papyrus can be weird.

[sheson]

  On 6/24/2023 at 11:55 AM, yxzhang said:

Here's the log, https://ufile.io/eniga12z, and in summary my version is 3.0.0.128, latest one from nexus.

That's the intended behavior, I know. But I find the counter negative in my save file, and the loop never ends. Not sure how. Heavily loaded Papyrus can be weird.

Expand  

From the log it seems you are using DynDOLOD.DLL 2.45 for 1.6.640 with DynDOLOD DLL SE - Scripts 2.82.5.

Does that sound correct? If it does, download the DynDOLOD DLL SE - Scripts 2.82.6.

You might need to do a clean save without the plugins and scripts in the load order, so the old scripts are removed.
If you can repeat whatever you believe might have caused this, test if the never ending loop situation does not happen anymore.

[yxzhang]

  On 6/24/2023 at 11:59 AM, sheson said:

From the log it seems you are using DynDOLOD.DLL 2.45 for 1.6.640 with DynDOLOD DLL SE - Scripts 2.82.5.

Does that sound correct? If it does, download the DynDOLOD DLL SE - Scripts 2.82.6.

You might need to do a clean save without the plugins and scripts in the load order, so the old scripts are removed.
If you can repeat whatever you believe might have caused this, test if the never ending loop situation does not happen anymore.

Expand  

Thanks for the quick response.

Just updated to 2.82.6. As soon as I load the game, those active scripts decided to kill themselves.

I see you've made it a local variable, so that should solve the race condition, hopefully.

[Floop]

DynDOLOD is saying that the dragonborn dlc has Large References. I cleaned all of my mods with xedit so idk what's happening. Any fix for this? 

mod/plugin list:https://loadorderlibrary.com/lists/dyndolod-help-1 

 

[sheson]

  On 6/24/2023 at 6:35 PM, Floop said:

DynDOLOD is saying that the dragonborn dlc has Large References. I cleaned all of my mods with xedit so idk what's happening. Any fix for this? 

mod/plugin list:https://loadorderlibrary.com/lists/dyndolod-help-1 

 

Expand  

Moved to the DynDOLOD 3 Alpha thread.

Read the first post or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log and debug log to upload when making posts.

Do not post screenshots of messages, use the "Copy message to clipboard" and paste the text instead as explained in the first post or at https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text

The message is saying that Unofficial Ghosts of the Tribunal Patch.esl has a large reference entry which links to the FormID 0x0401E343, which is a reference that normally exists in Dragonborn.esm. That FormID can not be found. Typically Unofficial Ghosts of the Tribunal Patch.esl should only have that large reference entry if it overwrites the reference added by Dragonbon.esm.

Use the "Click on this link for additional explanations and help for this message" to open https://dyndolod.info/Messages/Unresolved-Form-ID as explained in the first post or at https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages
Start by checking the plugin and record with xEdit mentioned in the Error in ... message.

So, start by checking with xEdit if the plugin load order 0x04 is Dragonborn.esm. Then check if you can find the formID 0x0401E343 in it.

If unresolved form ID errors happen in the latest and all updated vanilla game files (including DLC and CC), consider using the Unofficial Skyrim Legendary Edition Patch, Unofficial Skyrim Special Edition Patch and/or Unofficial Skyrim Creation Club Content Patches.

Make sure the vanilla and CC game plugins are all in sync for the same game version and that the patch plugin was made for that version.

The order of the 3 vanilla DLC is wrong in the modlist.txt you uploaded. Make sure the plugins are sorted properly.

[Mousetick]

  On 6/24/2023 at 6:01 AM, sheson said:

If you are unable to do what I am asking directly, then simply say so.

Expand  

I'm unwilling to do these tests. I'm not going to regenerate Tamriel LODs for ~20 trees in a corner of Solitude, with any DynDOLOD version, old or latest. I've already spent a lot time of time reporting, researching and documenting the issue caused by the USSEP rules. @MisterMorden also researched the issue on his side and helped with our findings. It's unfortunate that the most important post slipped through the cracks, but that's ok. I'm a bit fed up at this point, though, to tell you the truth.

The simple questions I asked were:

  Quote

• Can you confirm our findings and would you agree this is an issue, or at least an unexpected visual behavior.
• Is this the way it's supposed to be, or have we messed up somewhere?
• What would be a solution?

Expand  

 

  On 6/23/2023 at 9:14 PM, sheson said:

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.

Expand  

I have no idea what this means pertaining to the specific issue at hand.

DynDOLOD is a computer program - of which you're the developer - with a defined, expected behavior based on its algorithms and implementation. We should be able to have a rational discussion about predicted vs. observed behavior, or about predictable output based on specific input, without running tests to "see what happens". DynDOLOD is not a black box.

  On 6/24/2023 at 6:01 AM, sheson said:

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?

Expand  

I don't know, I haven't tried. Do you know? It seems to me if the USSEP rules are removed and the USSEP trees are left as is by DynDOLOD, then the Tamriel LODs will overlap with the full models of the Persistent, IsFullLOD USSEP references. In which case we'd be back to the original issue that the USSEP rules were intended to prevent. Unless DynDOLOD removes the IsFullLOD flag on tree references when doing ultra tree LODs. Does it? Do you know if it does? We should be able to predict the results based on the implemented logic, without running tests.

Lastly, if you're affirming (rather than speculating) that removing the USSEP rules should just work with ultra tree LODs, without undesirable side-effects, why are these rules enabled by default and have been for a very very long time? It's still not clear to me after all the back-and-forth whether you agree the USSEP "delete" rules are an issue when used with ultra tree LODs.

Thanks for your time and attention. I'm now going back to lurking in the corner, while playing the game with my "dirty" against-the-rules patch.

[MisterMorden]

Hey y'all I'm running 128 right now with the rules in question removed, I'll be back shortly with results/logs.

[sheson]

  On 6/25/2023 at 3:24 PM, Mousetick said:

• Can you confirm our findings and would you agree this is an issue, or at least an unexpected visual behavior.
• Is this the way it's supposed to be, or have we messed up somewhere?
• What would be a solution?

Expand  

I already explained the how - and thus confirmed your findings - the "Delete" rules work and why they were added for standard tree LOD generation.
For standard tree LOD, which does not unload in child worldspace, this used to be the desired and expected outcome.
Obviously that outcome is not desired when generating ultra tree LOD - which unloads properly.
Hence my suggestion to generate ultra tree LOD without the rules. Despite my troubleshooting suggestions had no feedback from anyone so far. So the best working solution is yet undetermined. So in your case, the solution is to wait for the next version, as I have repeatably said already.

  On 6/25/2023 at 3:24 PM, Mousetick said:

I have no idea what this means pertaining to the specific issue at hand.

Expand  

It means, deleting the rules and then generating ultra tree LOD may just have the correct/desired outcome without having to do anything else. Potentially a quick and easy fix to the issue without having to wait for me to to tests and waiting for the next version.

  On 6/25/2023 at 3:24 PM, Mousetick said:

DynDOLOD is a computer program - of which you're the developer - with a defined, expected behavior based on its algorithms and implementation. We should be able to have a rational discussion about predicted vs. observed behavior, or about predictable output based on specific input, without running tests to "see what happens". DynDOLOD is not a black box.

Expand  

Yes, that is why I answer questions and explain how things work and why and post links etc.
You are participating in an Alpha test, reporting an issue. I am suggesting a solution that might immediately rectify that issue.  You do not seem to be interested having a shot at an immediate solution and no interest to report the outcome to improve the tool/configs so everyone's saves time.
I prominently require users to make an effort and help with the development of the tools to improve them, including troubleshooting and reporting. This is typically done, so users can address issues without having to wait for me trying to replicate issues and to publish an update. Editable configurations and settings exist for this reason. It is impossible to know if something works or not without testing it. Without testing the outcome has not been proven. That is the scientific method that drives the development/troubleshooting.
Me asking users to test or try things is the modus oprandi since inception and a requirement to use the tools in order to advance the development and compatibility.

  On 6/25/2023 at 3:24 PM, Mousetick said:

Lastly, if you're affirming (rather than speculating) that removing the USSEP rules should just work with ultra tree LODs, without undesirable side-effects, why are these rules enabled by default and have been for a very very long time? It's still not clear to me after all the back-and-forth whether you agree the USSEP "delete" rules are an issue when used with ultra tree LODs.

Expand  

I have already explained why the rules were added: It was done because when generating standard tree LOD, the standard tree LOD does not unload in child worlds and there there will be billboards and full models showing at the same time. The fact that the references are added as IsFullLOD results in similar issues in the parent worldspace.
I am not speculating why nobody noticed or reported the issues with ultra tree LOD before. 
Since I now have been informed that you are unable to do the troubleshooting I asked for, I have added this issue to my long list of things to do, as I said I would. I can not affirm anything until then.
That means - as I already said - the next version will have an appropriate solution.
I have repeatedly suggested a potential solution for the issue, awaited the success or failure report for it  and promised an appropriate solution for the next version for this issue. In case having said these things in several posts didn't make it clear: This is an issue and that is why it will be fixed in the next version.