DynDOLOD 3.00 Alpha 180

[sheson]

59 minutes ago, milliedarc said:

Hello! Using the Alpha-108 version, I get the following error:

<Error: File not found textures\landscape\trees\northern hemispheres\aspenbark.dds. Used by Meshes\jelidity\trees\treeaspen02spring.nif Turn of the Seasons.esp TreeAspen02Spring [TREE:FE06E803]>

This causes the bark textures to be missing in game.

I aborted the operation because I tried reinstalling Seasonal Landscapes & moving things around a bit in my load order to see if this would be fixed, but it wasn't. Thanks for your help!

  TexGen_SSE_Debug_log.txt 2.44 MB · 0 downloads TexGen_SSE_log.txt 425.29 kB · 1 download

See https://dyndolod.info/Messages/File-Not-Found-Textures

The message tells you the plugin and NIF that require the texture. Make sure the mod and its requirements are installed correctly. Check the comments and bug report of the mod.

[kazoku]

Idk what to do, everything download correctly.

[sheson]

https://dyndolod.info/Help/Summary-Of-Messages

1 hour ago, kazoku said:

Idk what to d o, everything download correctly.

Moved to the DynDOLOD 3 Alpha thread. Read the first post which log and debug to upload when making posts. Do not post screenshots of text.

Use modwatch or loadorderlibrary websites instead of posting screenshots of modmanagers.

Read https://dyndolod.info/Messages and the summary of messages https://dyndolod.info/Help/Summary-Of-Messages for explanations of messages andwhat/if anything needs tone done about them.

Ask specific question if help with a particular message and mod is required.

[SeaSparrow]

I can't seem to get seasonal grass lods to function in 1.6.353.

I created an MO2 clone instance, downgraded it to 1.5.97, installed NGiO, set the required settings in the relevant INI, and generated grass cache for each season. I then batch renamed them appropriately (from *.cgid to *.<season identifier>.gid), put them all in one mod and transfered it over to the 1.6.353 instance. So far, so good. I then attempted to create Grass LOD with DynDOLOD advanced mode, made sure that Grass LOD mode was set to 1, made sure that the grass references were being read and let DynDOLOD do its thing. And no grass LODs were generated, because Tamriel finished in 10 minutes.

 

[sheson]

On 12/24/2022 at 4:26 PM, SeaSparrow said:

I can't seem to get seasonal grass lods to function in 1.6.353.

I created an MO2 clone instance, downgraded it to 1.5.97, installed NGiO, set the required settings in the relevant INI, and generated grass cache for each season. I then batch renamed them appropriately (from *.cgid to *.<season identifier>.gid), put them all in one mod and transfered it over to the 1.6.353 instance. So far, so good. I then attempted to create Grass LOD with DynDOLOD advanced mode, made sure that Grass LOD mode was set to 1, made sure that the grass references were being read and let DynDOLOD do its thing. And no grass LODs were generated, because Tamriel finished in 10 minutes.

 

Read the first post which log and debug log to upload when making post.

Do not forget to tell DynDOLOD to use gid files instead of cgid files with GrassGID=gid in the DynDOLOD_SSE.ini.

https://dyndolod.info/Help/Grass-LOD

[z929669]

This post was moved from the DynDOLOD DLL topic. See my original post for context.

17 hours ago, sheson said:

Use the DynDOLOD 3 Alpha thread to ask questions or report problems with DynDOLOD 3 Alpha. Read the first post which log and debug log to upload in that case.

Not sure what "../DynDOLOD/Logs/LR%20Fix%20Off/Summary/." is supposed to mean?
https://dyndolod.info/Messages and https://dyndolod.info/Help/Summary-Of-Messages. The summary is only crated for certain warning and error messages.

Please recognize that I know this.... of all people, I know this. My questions preclude log files, as I had no issues other than missing HTML files that are normally generated. Sorry, I  pasted the incorrect path from my saved logs location.

When running DynDOLOD, a HTML summary of warnings and issues appears. Surely you know this, since you implemented it. The HTML files are created at:

..\DynDOLOD\Summary\.

These files are not created nor automatically presented in the default browser at the end of DynDOLOD run when the "Large reference workarounds fix" check box is ticked. The LO hasn't changed, so the warnings are expected regardless ... or a Summary indicating that NO errors exist is expected (maybe because they do not apply when the LR fix is toggled? Please explain).

Logs and output AND Summary for each run:

"Large" toggle unticked

"Large" toggle ticked

Notice the lack of a HTML Summary in the latter. I repeated my test to confirm with "Large reference workarounds fix" toggled, and no Summary HTML messages are created even though the same LO is used and the same issues are inherent to that LO. This is an inconsistency.

17 hours ago, sheson said:

I have no idea what "our tree mods" are. The vanilla game master files add several 10k tree references to Tamriel and other worldspaces. https://dyndolod.info/Help/Large-References

"Our tree mods" are EVT and Aspens Ablaze. These are vanilla tree replacers defined by non-ESM plugins that override vanilla records. Vanilla records are defined by ESM.

SO ... will ticking the "Large" box add these trees as large references if the TreeLargeRefSize is greater than the 400 minimum set by default in DynDOLOD_SSE.ini?

Quote

; minimum size for a tree to be considered large in case large reference workarounds are used and ultra tree LOD with the large option is checked
TreeLargeRefSize=400

And from the doc (again, I post this):

Quote

In case Ultra is checked to generate ultra tree LOD, the Large checkbox can be checked to make the full model trees large references - if they are added by ESM flagged plugins.

This is what I want to understand through asking directly rather than discovering indirectly though blind testing and assumption.

---

Feel free to move this to the Alpha 3 topic. I thought that the new "LR fix" functionality was tied to the DLL and not DynDOLOD Alpha, so I posted here.

[sheson]

2 hours ago, z929669 said:

Please recognize that I know this.... of all people, I know this. My questions preclude log files, as I had no issues other than missing HTML files that are normally generated. Sorry, I  pasted the incorrect path from my saved logs location.

When running DynDOLOD, a HTML summary of warnings and issues appears. Surely you know this, since you implemented it. The HTML files are created at:

..\DynDOLOD\Summary\.

These files are not created nor automatically presented in the default browser at the end of DynDOLOD run when the "Large reference workarounds fix" check box is ticked. The LO hasn't changed, so the warnings are expected regardless ... or a Summary indicating that NO errors exist is expected (maybe because they do not apply when the LR fix is toggled? Please explain).

Logs and output AND Summary for each run:

"Large" toggle unticked

"Large" toggle ticked

Notice the lack of a HTML Summary in the latter. I repeated my test to confirm with "Large reference workarounds fix" toggled, and no Summary HTML messages are created even though the same LO is used and the same issues are inherent to that LO. This is an inconsistency.

"Our tree mods" are EVT and Aspens Ablaze. These are vanilla tree replacers defined by non-ESM plugins that override vanilla records. Vanilla records are defined by ESM.

SO ... will ticking the "Large" box add these trees as large references if the TreeLargeRefSize is greater than the 400 minimum set by default in DynDOLOD_SSE.ini?

And from the doc (again, I post this):

This is what I want to understand through asking directly rather than discovering indirectly though blind testing and assumption.

---

Feel free to move this to the Alpha 3 topic. I thought that the new "LR fix" functionality was tied to the DLL and not DynDOLOD Alpha, so I posted here.

https://dyndolod.info/Messages
For certain warning and error messages DynDOLOD and TexGen create a summary of messages and opens it in the default web browser.

https://dyndolod.info/Help/Summary-Of-Messages
DynDOLOD and TexGen create a summary of some similar warning and error messages for easier review and better understanding.
It does not substitute having to pay attention to all log messages.
In case there were matching warning or error message printed to the log, the summary should automatically be opened in the default web browser once all steps of the session ran.

https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Testing
Instead of the typical warning messages like overwritten large reference or initially disabled large reference, the log will print a line for each affected cell.

Once we are certain the newly added experimental workarounds work, this particular message will not be written to the log anymore by default. Just like the messages for all the other fixes that are already known to work.

The summary contains messages about things that affect visuals or the game negatively to notify the user so they can be checked immediately or when they are noticed in the game in order to rectify the cause. In a properly setup game with well made mods there should be no warning or error messages and thus no summary either. That is the expected result.

 

Large references are references that are shown outside the loaded cells. This is done by adding the form id of a reference to the RNAM list on the worldspace record. The engine only reads the RNAM data from master plugins. The Large checkbox adds all references of trees added by master plugins with a "size" greater or equal than TreeLargeRefSize  to the RNAM record in DynDOLOD.esm. The only relevance base records have is their object bound values. The DynDOLOD DLL NG patches the engine so that doing this does not trigger the large reference bugs.

[Mousetick]

24 minutes ago, sheson said:

Large references are references that are shown outside the loaded cells. This is done by adding the form id of a reference to the RNAM list on the worldspace record. The engine only reads the RNAM data from master plugins. The Large checkbox adds all references of trees added by master plugins with a "size" greater or equal than TreeLargeRefSize  to the RNAM record in DynDOLOD.esm. The only relevance base records have is their object bound values.

2 hours ago, z929669 said:

SO ... will ticking the "Large" box add these trees as large references if the TreeLargeRefSize is greater than the 400 minimum set by default in DynDOLOD_SSE.ini?

In other words and in plain English, the 'Large' option will not apply to trees references added by EVT or AA, regardless of their size, because their plugins are not ESM. These references are not eligible for being 'promoted' to LR, as technically, their plugins being non-ESM, they can't define Large References.

Corollary question for sheson, out of curiosity, considering this example:

• Plugin1.esm adds REFR ID1 places BigTree at x1/y1/z1
• Plugin2.esp overrides REFR ID1 places BigTree at x2/y2/z2 (non-ESM plugin overrides Plugin1.esm)

If the reference ID1 is "big" enough to become a LR with the 'Large' option, what happens in that case? Probably nothing I'd assume, i.e. the 'Large' option doesn't apply.

[sheson]

1 hour ago, Mousetick said:

In other words and in plain English, the 'Large' option will not apply to trees references added by EVT or AA, regardless of their size, because their plugins are not ESM. These references are not eligible for being 'promoted' to LR, as technically, their plugins being non-ESM, they can't define Large References.

Corollary question for sheson, out of curiosity, considering this example:

• Plugin1.esm adds REFR ID1 places BigTree at x1/y1/z1
• Plugin2.esp overrides REFR ID1 places BigTree at x2/y2/z2 (non-ESM plugin overrides Plugin1.esm)

If the reference ID1 is "big" enough to become a LR with the 'Large' option, what happens in that case? Probably nothing I'd assume, i.e. the 'Large' option doesn't apply.

If you have to spell it out for particular plugins, then it might be worth mentioning that AFAIK EVT does not add new tree references, only AA does.

The position/rotation of a reference has no effect on its "size" / the condition if a reference can be a large reference or not.
A record being overwritten does not change if the original record is added by a master plugin.

[Mousetick]

42 minutes ago, sheson said:

The position/rotation of a reference has no effect on its "size" / the condition if a reference can be a large reference or not.
A record being overwritten does not change if the original record is added by a master plugin.

Understood. But a record being overwritten by non-ESM triggers LR bugs. Rephrasing my question of what happens in the previous case with the 'Large' tree option:

• The tree reference is promoted to LR in DynDOLOD.esm RNAM and a LR-bugs workaround is applied in DynDOLOD.esp?
• OR the tree reference is ignored by the 'Large' option to avoid LR-bugs?

[sheson]

19 minutes ago, Mousetick said:

Understood. But a record being overwritten by non-ESM triggers LR bugs. Rephrasing my question of what happens in the previous case with the 'Large' tree option:

• The tree reference is promoted to LR in DynDOLOD.esm RNAM and a LR-bugs workaround is applied in DynDOLOD.esp?
• OR the tree reference is ignored by the 'Large' option to avoid LR-bugs?

For now references that have non-ESM overwrites, enable parents or are initially disabled are not made large references.

[z929669]

5 hours ago, Mousetick said:

In other words and in plain English, the 'Large' option will not apply to trees references added by EVT or AA, regardless of their size, because their plugins are not ESM. These references are not eligible for being 'promoted' to LR, as technically, their plugins being non-ESM, they can't define Large References.

This was exactly my interpretation, and I thought I had phrased my original question in such a way as to imply this ... but perhaps not well enough. I was hoping to avoid experimenting with it to elucidate the behavior (potentially erroneously) by instead asking for clarification on this

Even with the clarifications of the above responses, I'm still not entirely clear if vanilla tree replacers that include overrides to vanilla trees defined in the vanilla ESM are expected to yield their trees as large references when "Large" is ticked. But it would seem that "Large" should have no impact on mods like this (HLT, EVT, SRO, and most tree mods ... I am not aware of a single tree mod that uses ESM to define new trees, but I have never explicitly checked this either).

3 hours ago, sheson said:

For now references that have non-ESM overwrites, enable parents or are initially disabled are not made large references.

... seems to confirm my assumption that EVT doesn't apply ... and probably not AA either, since the new trees it adds are small.

6 hours ago, sheson said:

https://dyndolod.info/Messages
For certain warning and error messages DynDOLOD and TexGen create a summary of messages and opens it in the default web browser.

https://dyndolod.info/Help/Summary-Of-Messages
DynDOLOD and TexGen create a summary of some similar warning and error messages for easier review and better understanding.
It does not substitute having to pay attention to all log messages.
In case there were matching warning or error message printed to the log, the summary should automatically be opened in the default web browser once all steps of the session ran.

https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Testing
Instead of the typical warning messages like overwritten large reference or initially disabled large reference, the log will print a line for each affected cell.

Once we are certain the newly added experimental workarounds work, this particular message will not be written to the log anymore by default. Just like the messages for all the other fixes that are already known to work.

The summary contains messages about things that affect visuals or the game negatively to notify the user so they can be checked immediately or when they are noticed in the game in order to rectify the cause. In a properly setup game with well made mods there should be no warning or error messages and thus no summary either. That is the expected result.

Apologies for "beating the dead horse", but I must respectfully disagree that this is expected behavior from the user ('my') perspective. As I mentioned a couple of times, my LO still has "initially disabled LRs" and "overwritten LRs", whether I tick the "LR workarounds fix" or not, so I expected those messages would still appear with perhaps some additional info regarding the workaround resolutions. I certainly expect to see Summary messages about missing scripts and such as well if that option is ticked ... so maybe I would if those messages applied to my LO with that option ticked?

Anyway, it's not a big deal. I was just curious and wanted to report what I thought was possibly unexpected behavior ... only trying to be helpful, so I will not mention it again

[sheson]

49 minutes ago, z929669 said:

This was exactly my interpretation, and I thought I had phrased my original question in such a way as to imply this ... but perhaps not well enough. I was hoping to avoid experimenting with it to elucidate the behavior (potentially erroneously) by instead asking for clarification on this

Even with the clarifications of the above responses, I'm still not entirely clear if vanilla tree replacers that include overrides to vanilla trees defined in the vanilla ESM are expected to yield their trees as large references when "Large" is ticked. But it would seem that "Large" should have no impact on mods like this (HLT, EVT, SRO, and most tree mods ... I am not aware of a single tree mod that uses ESM to define new trees, but I have never explicitly checked this either).

... seems to confirm my assumption that EVT doesn't apply ... and probably not AA either, since the new trees it adds are small.

Apologies for "beating the dead horse", but I must respectfully disagree that this is expected behavior from the user ('my') perspective. As I mentioned a couple of times, my LO still has "initially disabled LRs" and "overwritten LRs", whether I tick the "LR workarounds fix" or not, so I expected those messages would still appear with perhaps some additional info regarding the workaround resolutions. I certainly expect to see Summary messages about missing scripts and such as well if that option is ticked ... so maybe I would if those messages applied to my LO with that option ticked?

Anyway, it's not a big deal. I was just curious and wanted to report what I thought was possibly unexpected behavior ... only trying to be helpful, so I will not mention it again

If in doubt, flag whatever tree mod as ESM if you want to make sure all/most tree references are made large. I would assume, most tree replacer mods that do add/modify new reference are pretty simple and self contained, so most of the can be changed without problems. Of course there probably will be one for which that is not the case for some reason...

If you require more log messages about things that do not potentially need user attention, enable the notices and then check the debug log.

[Mousetick]

16 hours ago, z929669 said:

Even with the clarifications of the above responses, I'm still not entirely clear if vanilla tree replacers that include overrides to vanilla trees defined in the vanilla ESM are expected to yield their trees as large references when "Large" is ticked. But it would seem that "Large" should have no impact on mods like this (HLT, EVT, SRO, and most tree mods ... I am not aware of a single tree mod that uses ESM to define new trees, but I have never explicitly checked this either).

If you want "big" trees to be made LRs, so that their full model (as opposed to their 3D LOD or Hybrid model) is rendered within the LR grid, you need to use DynDOLOD's 'Large' option. Tree replacers typically only override the base records (TREE signature), not the tree references (REFR signature) placed into the world, nor do they add new tree references to the world. So they have no "impact" on the 'Large' option, or vice-versa.

All the tree references created by the vanilla masters (ESMs) will be "promoted" to LR if they're "big" enough and all other conditions are satisfied (don't have non-ESM overwrites, or enable parents and are not initially disabled).

Counter-examples:

• Aspens Ablaze moves/resizes/rotates ~7000 tree references, overriding the vanilla references.
• Happy Little Trees 'All trees' version adds ~400 new tree references.

The aspens touched by AA, and the new trees added by HLT, can't become LRs with the 'Large' option, no matter how big they are, because the AA and HLT plugins are not ESM. A simple solution is to ESM-flag those plugins.

Hope this helps.

[kazoku]

hi. I need ignore this or what ?