Jump to content

DynDOLOD 3.00 Alpha 167


sheson

Recommended Posts

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

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.

Link to comment
Share on other sites

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

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.

Link to comment
Share on other sites

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

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.

Link to comment
Share on other sites

11 hours ago, 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 

 

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.

Link to comment
Share on other sites

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

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

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?

 

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

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 8: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?

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.

Link to comment
Share on other sites

5 hours ago, 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?

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.

5 hours ago, Mousetick said:

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

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.

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

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.

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

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.

Link to comment
Share on other sites

Ok, here's what I've found...loading "high" rules in the advanced mode, removing the USSEP mesh rules for the trees and using ultra lod did result in most of the trees behind the Winking Skeever remaining without vanishing when approached.  There are still some trees further back behind these, though, as well as some behind Castle Dour that do still disappear when you get within a certain distance.  When I discussed this issue with Mousetick a couple months ago, I also mentioned how 3 or 4 mountain peak/ridge/cliffs (also behind Castle Dour) had no lod representation when approached from the Blue Palace and would suddenly render into place.  I'm guessing these other objects weren't addresses by USSEP (at least not the version I'm using which is the last one for 1.5.97) Anyhoo here are my logs:

No bugreport generated

Dyndolod & TexGen logs: https://ufile.io/f/kj4qh

TexGen debug (there was no Dyndolod debug generated): https://ufile.io/rw2kbfzg

 

I hope this helps, I really appreciate it!

Edited by MisterMorden
  • Thanks 1
Link to comment
Share on other sites

I've followed along with GamerPoets' DynDOLOD guide and everything had gone smoothly until I reached the part where it was time to run DynDOLOD itself. For whatever reason, DynDOLOD absolutely crawls and can't run without freezing or crashing.

According to Task Manager, it utilizes less than 1% of my CPU, but it eats up around 30% of my Memory. TexGen went smoothly and took no more than 15 minutes from start to finish, whereas I've let DynDOLOD run for over an hour and it was unable to finish even one worldspace before hard crashing and closing itself, with many lengthy periods of freezing along the way where the Time Elapsed counter would be perpetually suspended around 10-13 seconds even if 30+ minutes had elapsed.

Here's my modlist. The only mods not shown are DynDOLOD Resources SE, DynDOLOD DLL SE - Scripts, DynDOLOD DLL SE - DLL, and TexGen_Output, all done and arranged in accordance with GamerPoets' guide. He did mention that DynDOLOD takes significantly longer to run than TexGen, but in my case, there's definitely something wrong and I have no idea what it is.

Any help in diagnosing/resolving the issue would be much appreciated.

Link to comment
Share on other sites

6 hours ago, MisterMorden said:

Ok, here's what I've found...loading "high" rules in the advanced mode, removing the USSEP mesh rules for the trees and using ultra lod did result in most of the trees behind the Winking Skeever remaining without vanishing when approached.  There are still some trees further back behind these, though, as well as some behind Castle Dour that do still disappear when you get within a certain distance.  When I discussed this issue with Mousetick a couple months ago, I also mentioned how 3 or 4 mountain peak/ridge/cliffs (also behind Castle Dour) had no lod representation when approached from the Blue Palace and would suddenly render into place.  I'm guessing these other objects weren't addresses by USSEP (at least not the version I'm using which is the last one for 1.5.97) Anyhoo here are my logs:

No bugreport generated

Dyndolod & TexGen logs: https://ufile.io/f/kj4qh

TexGen debug (there was no Dyndolod debug generated): https://ufile.io/rw2kbfzg

 

I hope this helps, I really appreciate it!

Thanks. If you say most of the trees, it probably means, that the unofficial patch does not add references for all trees that happen have references/LOD in the parent worldspace. After all, the trees in Solitude not having full models is how the vanilla game was made. I suppose an appropriate solution will have to cover all trees and work regardless of the patch.

If something doesn't have LOD it is typically because there is no reference for it in the parent worldspace Tamriel. Screenshots of the full models with more informative console would help. Mountains/Rocks are on the ignore list for the automatic carbon copies to the parent to avoid unnecessary conflicts. Large references make this more obvious, since where the LOD starts to show is pushed further away.

The tools save the log and then debug log right after when they shutdown. Give the saving of the logs some time. Just let the tools close on their own. Otherwise there should be an error message if something prevents saving of the debug log.

Link to comment
Share on other sites

1 hour ago, redrapptor said:

I've followed along with GamerPoets' DynDOLOD guide and everything had gone smoothly until I reached the part where it was time to run DynDOLOD itself. For whatever reason, DynDOLOD absolutely crawls and can't run without freezing or crashing.

According to Task Manager, it utilizes less than 1% of my CPU, but it eats up around 30% of my Memory. TexGen went smoothly and took no more than 15 minutes from start to finish, whereas I've let DynDOLOD run for over an hour and it was unable to finish even one worldspace before hard crashing and closing itself, with many lengthy periods of freezing along the way where the Time Elapsed counter would be perpetually suspended around 10-13 seconds even if 30+ minutes had elapsed.

Here's my modlist. The only mods not shown are DynDOLOD Resources SE, DynDOLOD DLL SE - Scripts, DynDOLOD DLL SE - DLL, and TexGen_Output, all done and arranged in accordance with GamerPoets' guide. He did mention that DynDOLOD takes significantly longer to run than TexGen, but in my case, there's definitely something wrong and I have no idea what it is.

Any help in diagnosing/resolving the issue would be much appreciated.

Moved to the DynDOLOD 3 Alpha thread.

Read the first post or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log, debug log and bugrepost.txt (if it exists) to upload when making posts.

See Long running time or output several GB in file size at https://dyndolod.info/FAQ. In particular, see if removing or terminating crapware installed with the graphics drivers helps.

Check if there are Texconv background processes DynDOLOD might be waiting on.

Link to comment
Share on other sites

8 hours ago, sheson said:

Thanks. If you say most of the trees, it probably means, that the unofficial patch does not add references for all trees that happen have references/LOD in the parent worldspace. After all, the trees in Solitude not having full models is how the vanilla game was made. I suppose an appropriate solution will have to cover all trees and work regardless of the patch.

If something doesn't have LOD it is typically because there is no reference for it in the parent worldspace Tamriel. Screenshots of the full models with more informative console would help. Mountains/Rocks are on the ignore list for the automatic carbon copies to the parent to avoid unnecessary conflicts. Large references make this more obvious, since where the LOD starts to show is pushed further away.

The tools save the log and then debug log right after when they shutdown. Give the saving of the logs some time. Just let the tools close on their own. Otherwise there should be an error message if something prevents saving of the debug log.

I do let the tool close on it's own,  I don't know why the dyndolod debug didn't show up...I usually just hit "save and exit" and let it finish that.  Sorry I didn't have that piece of info for you.  If it helps at all, I have several tree and a couple mountain ids in the patch I made to make them visible inside Solitude that cover some of these non-USSEP fixed objects I can post when I get home this evening (might be more thorough to browse the cells in question I suppose). 

Link to comment
Share on other sites

11 hours ago, sheson said:

Moved to the DynDOLOD 3 Alpha thread.

Read the first post or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log, debug log and bugrepost.txt (if it exists) to upload when making posts.

See Long running time or output several GB in file size at https://dyndolod.info/FAQ. In particular, see if removing or terminating crapware installed with the graphics drivers helps.

Check if there are Texconv background processes DynDOLOD might be waiting on.

 

11 hours ago, sheson said:

Moved to the DynDOLOD 3 Alpha thread.

Read the first post or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log, debug log and bugrepost.txt (if it exists) to upload when making posts.

See Long running time or output several GB in file size at https://dyndolod.info/FAQ. In particular, see if removing or terminating crapware installed with the graphics drivers helps.

Check if there are Texconv background processes DynDOLOD might be waiting on.

 

If you are using AMD graphics, try running Taskmanager and killing anything beginning with 'AMD':

image.png

Then repeat TexGen processing to see if long-running time is significantly reduced.

Link to comment
Share on other sites

17 hours ago, MisterMorden said:

I do let the tool close on it's own,  I don't know why the dyndolod debug didn't show up...I usually just hit "save and exit" and let it finish that.  Sorry I didn't have that piece of info for you.  If it helps at all, I have several tree and a couple mountain ids in the patch I made to make them visible inside Solitude that cover some of these non-USSEP fixed objects I can post when I get home this evening (might be more thorough to browse the cells in question I suppose). 

Just listing the form ids of mountain/rock references that have no representation in the Solitude child worldspace works, too.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.