DynDOLOD 3.00 Alpha 182

[sheson]

2 hours ago, IX_Flipyap said:

The majestic mountain lod textures look blue from a distance could the northside MM retexture be causing this?

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

Get a base record form id of a full model and look it up in the ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt which should show the used texture, which you then can check where it comes from.

https://dyndolod.info/Mods/Majestic-Mountains

Make sure to run TexGen before generating LOD.

[TwistedModding]

Unsure if I missed something in the instructions, but the large ref workaround isn't in the gui on advanced mode, I'm currently on alpha 108

[sheson]

5 minutes ago, TwistedModding said:

Unsure if I missed something in the instructions, but the large ref workaround isn't in the gui on advanced mode, I'm currently on alpha 108

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

Read https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds

[TwistedModding]

31 minutes ago, sheson said:

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

Read https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds

I skipped over some text in the instructions, I noticed the log mentioned I still had some deleted references, and I just fixed the remaining few and now the options are there. 

[milliedarc]

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

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