DynDOLOD 3.00 Alpha 182

[Epslion_09cc]

First, using alpha 53 of DynDOLOD 3, and the generation is fine, no interrupt in whole process.

But while using DynDOLODx64.exe to generate it goes with heavy number of "Warning: Overwritten large reference in.." or "Warning: Initially disabled large reference in..", and few Warning: File not found..

I move the outputed file and create as a mod, load it and sort order, everything is OK. In game, the LOD looks fine and nothing obvious wrong.

BUT, when I move to a specific area(Windhelmet indeed), probably as the LOD near it started loading, the game crashed.

By reading README, I do what the manual said.

Hide generated mesh folder, Crashed.

Hide DynDOLOD.esp, No Crash.

Also, tons of error in Papyrus Log like that below:

Quote

[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C00241C) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C0026C6) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C00200B) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_LODObject to  (7C003DD8) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C003720) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C002D47) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C001E4F) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C002FB7) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C002ED3) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C002BF7) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C0037E2) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C0032A6) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C003563) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C00206B) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_LODObject to  (7C003B20) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C002A8A) because their base types do not match

Line 12521 to Line 12536

=====================================================================================================================

[11/02/2021 - 02:16:44PM] Error: Unable to bind script SHESON_DynDOLOD_Worshipper to  (1900163E) because their base types do not match
[11/02/2021 - 02:16:44PM] Error: Unable to bind script SHESON_DynDOLOD_Worshipper to  (19001650) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Worshipper to  (1900162C) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Worshipper to  (1900163F) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Worshipper to  (19001651) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Worshipper to  (1900162D) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Worshipper to  (19001652) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C001782) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C001783) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C0017A7) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C0017A6) because their base types do not match

Line 46436 to Line 46446

Same error "Unable to bind script SHESON_DynDOLOD_.." filled almost the whole log.

I searched for long time and trying find a similar issue like this, but there isn't any.

I don't know what's wrong with the damn mod file, I suffered this dumb problem for totally 3 days.

Also, I tried using the latest & stable version, DynDOLOD 2.96 and Resource 2.88 in Nexus Page, same.

Tried take off other irrelevant mods, keep only enviorment mod then generate LOD, same.

NEED HELP PLS

[sheson]

2 hours ago, Epslion_09cc said:

First, using alpha 53 of DynDOLOD 3, and the generation is fine, no interrupt in whole process.

But while using DynDOLODx64.exe to generate it goes with heavy number of "Warning: Overwritten large reference in.." or "Warning: Initially disabled large reference in..", and few Warning: File not found..

I move the outputed file and create as a mod, load it and sort order, everything is OK. In game, the LOD looks fine and nothing obvious wrong.

BUT, when I move to a specific area(Windhelmet indeed), probably as the LOD near it started loading, the game crashed.

By reading README, I do what the manual said.

Hide generated mesh folder, Crashed.

Hide DynDOLOD.esp, No Crash.

Also, tons of error in Papyrus Log like that below:

Same error "Unable to bind script SHESON_DynDOLOD_.." filled almost the whole log.

I searched for long time and trying find a similar issue like this, but there isn't any.

I don't know what's wrong with the damn mod file, I suffered this dumb problem for totally 3 days.

Also, I tried using the latest & stable version, DynDOLOD 2.96 and Resource 2.88 in Nexus Page, same.

Tried take off other irrelevant mods, keep only enviorment mod then generate LOD, same.

NEED HELP PLS

Read the first post.

You did not upload any logs. In this case the entire papyrus log also would be of interest.

"Unable to bind script" points to a an (incomplete) LOD generation or an installation problem (like DynDOLOD Resources missing or not installed completely).

Read ..\DynDOLOD\docs\help\LogMessages.html for explanations what log messages mean.

As the readme explains, install .NET Script Framework for Skyrim Special Edition and check its crash log for clues. Upload the crash log if help is required.

[mattski123]

On 10/31/2021 at 6:28 PM, sheson said:

Changing INI settings for the map or existing BTR/BTO Level 32 meshes and their textures have no relevance to LOD generation or DynDOLOD.

Where do I change those ini settings which ini? Also, in terms of game performance, which one is more liekly to cause lag spikes: Occlusion Datas quality 3 or quality 1? I'm just not sure what the difference is. Also, do neargridtoload & fargridtoload affect performance if those numbers are changed? Or does that just mean objects farther away like grass not showing on landscapes would be loaded? I was having that problem, and I precached the grass but it was still an issue. Any hints or resolves for showing grass in all countryside?

 

Is there a picture example of the prefer base record LOD assignments over rules? I just wanna see what I'd be losing for minimal performance gain.

Edited November 2, 2021 by mattski123

[sheson]

1 hour ago, mattski123 said:

Where do I change those ini settings which ini? Also, in terms of game performance, which one is more liekly to cause lag spikes: Occlusion Datas quality 3 or quality 1? I'm just not sure what the difference is. Also, do neargridtoload & fargridtoload affect performance if those numbers are changed? Or does that just mean objects farther away like grass not showing on landscapes would be loaded? I was having that problem, and I precached the grass but it was still an issue. Any hints or resolves for showing grass in all countryside?

 

Is there a picture example of the prefer base record LOD assignments over rules? I just wanna see what I'd be losing for minimal performance gain.

You yourself referred to the INI settings which object/terrain LOD level is used for the map:
"Which means we don't have to change the lod settings to 16 in his ini."

Occlusion data does not cause lag spikes. It determine which LOD quads are rendered for a cell.
Read ..\DynDOLOD\docs\help\OcclusionCulling.html
Read ..\DynDOLOD\docs\help\Advanced.html and hover the mouse pointer above a setting for hints.
Read ..\DynDOLOD\docs\DynDOLOD_Manual.html "TVDT - Occlusion Data"
They all explain the quality setting determines how many samples are used for the calculations to generate the occlusion data.

Read ..\DynDOLOD\docs\DynDOLOD_Manual.html "DynDOLOD Mod", which explains what the  Near and Far Grid is and that they are concepts of dynamic LOD. It goes without saying that the further or the more stuff is shown the more resources it uses. Regardless of LOD type/method.

Read ..\DynDOLOD\docs\help\GrassLOD.html which explains that grass LOD is done in object LOD level 4.
No idea what hints you are expecting for showing grass in all countrysides as you do not explain what the problem is.
Refer to the troubleshooting section in case grass LOD is incomplete.

If you want to see how different settings affect your unique load order and setup, take a before and after screenshots or refer to guides that do these things for their particular load order. The performance impact of the setting will be negligible with grass or 3D tree LOD,  too high INI settings or 8k apple textures.

[Epslion_09cc]

6 hours ago, sheson said:

Read the first post.

You did not upload any logs. In this case the entire papyrus log also would be of interest.

"Unable to bind script points to a an (incomplete) LOD generation or an installation problem (like DynDOLOD Resources missing or not installed completely).

Read ..\DynDOLOD\docs\help\LogMessages.html for explanations what log messages mean.

As the readme explains, install .NET Script Framework for Skyrim Special Edition and check its crash log for clues. Upload the crash log if help is required.

https://ufile.io/f/m4vox

Here are my logs, Papyrus logs and NetScriptFramework logs.

I checked the help docs earlier, but while doing I was under the side effect taking anti-cold drug, so no progress in checking.

I may will do a more detailed checking later, I am really tossed, thinking about why the hell "LOD generation" could problem me for goddamn 4 days.

[sheson]

42 minutes ago, Epslion_09cc said:

https://ufile.io/f/m4vox

Here are my logs, Papyrus logs and NetScriptFramework logs.

I checked the help docs earlier, but while doing I was under the side effect taking anti-cold drug, so no progress in checking.

I may will do a more detailed checking later, I am really tossed, thinking about why the hell "LOD generation" could problem me for goddamn 4 days.

These error messages in the papyrus log mean scripts files are missing:

'Cannot open store for class "...", missing file?'

As I already wrote in the earlier answer, the scripts are part of DynDOLOD Resources Core Files which needs to be installed completely.

Scripts from other mods seem to be missing, too.

[mattski123]

18 hours ago, sheson said:

You yourself referred to the INI settings which object/terrain LOD level is used for the map:
"Which means we don't have to change the lod settings to 16 in his ini."

Occlusion data does not cause lag spikes. It determine which LOD quads are rendered for a cell.
Read ..\DynDOLOD\docs\help\OcclusionCulling.html
Read ..\DynDOLOD\docs\help\Advanced.html and hover the mouse pointer above a setting for hints.
Read ..\DynDOLOD\docs\DynDOLOD_Manual.html "TVDT - Occlusion Data"
They all explain the quality setting determines how many samples are used for the calculations to generate the occlusion data.

Read ..\DynDOLOD\docs\DynDOLOD_Manual.html "DynDOLOD Mod", which explains what the  Near and Far Grid is and that they are concepts of dynamic LOD. It goes without saying that the further or the more stuff is shown the more resources it uses. Regardless of LOD type/method.

Read ..\DynDOLOD\docs\help\GrassLOD.html which explains that grass LOD is done in object LOD level 4.
No idea what hints you are expecting for showing grass in all countrysides as you do not explain what the problem is.
Refer to the troubleshooting section in case grass LOD is incomplete.

If you want to see how different settings affect your unique load order and setup, take a before and after screenshots or refer to guides that do these things for their particular load order. The performance impact of the setting will be negligible with grass or 3D tree LOD,  too high INI settings or 8k apple textures.

Hey, what settings do I need to see this landscape section and load the grass?

 

Also, how do I find this cell in xEdit?https://i.imgur.com/TywtZEV.png

Edited November 3, 2021 by mattski123

[TechAngel85]

17 hours ago, sheson said:

Initially Disabled references can cause large reference bugs. The plugin type does not matter.  If they have an enable parent they most likely do. If they do not have an enable parent they might. It happens a few times in the vanilla game with references only defined in Skyrim.esm for example. It seems only the one at the Winterhold college bridge affects full and LOD models that occupy the same 3D space. In all other cases the LOD models in the cell are smaller so it isn't that obvious that full models and LOD models are loaded.

Typically the report is meant for reverse troubleshooting. If there is texture flicker because of full and LOD models being loaded at the same time, test if it is caused by the large reference bugs by disabling them. If  they are the cause, search for the cell coordinates in the log if they are being reported. In case there are no log entries, search the debug log, too.

The refs are "initially disabled", parent is set to "Player" with "enable opposite of parent" flag set, and then they are set to -30000 for Z value. They are mainly splashes (MSTT) that you're not going to see as large refs (I don't recall them having any LOD). I'm 99% positive DynDOLOD v2 doesn't call out these references but v3 is, which is why I'm confused as to what changed. I've never seen any issues with it in-game. Also with the amount of users installing RWT, I'm sure someone would have reported the issue by now too, if there was one. These edits have been with RWT since last year sometime. The only thing being reported now for some users are the messages from DynDOLOD v3.

[Epslion_09cc]

11 hours ago, sheson said:

These error messages in the papyrus log mean scripts files are missing:

'Cannot open store for class "...", missing file?'

As I already wrote in the earlier answer, the scripts are part of DynDOLOD Resources Core Files which needs to be installed completely.

Scripts from other mods seem to be missing, too.

Thanks mate, but that makes no sense.

I installed resource file for 6 times at least. And I just checked my resource file folder, It looks like that:

https://imgur.com/a/RNUFKHz

And here is the Script folder looks like:

https://imgur.com/a/yHeP9Zt

I will try only with DynDOLOD to generate files later, and re-install all files of course.

 

I already even tried, vanilla game +skse +USSEP +DynDOLOD. Still same problem, Unable to bind script..

Yes I am 100% sure I re-install resource files and re-generated files.

Here is the DynDOLOD log:

https://ufile.io/cxubudq6

[sheson]

10 hours ago, mattski123 said:

Hey, what settings do I need to see this landscape section and load the grass?

 

Also, how do I find this cell in xEdit?https://i.imgur.com/TywtZEV.png

This thread is for the DynDOLOD 3 alpha test. DynDOLOD does not change grass in loaded cells. DynDOLOD does nothing with landscape. Use xEdit cell browser with CTRL+SHIFT+F.

[sheson]

On 11/3/2021 at 12:18 AM, TechAngel85 said:

The refs are "initially disabled", parent is set to "Player" with "enable opposite of parent" flag set, and then they are set to -30000 for Z value. They are mainly splashes (MSTT) that you're not going to see as large refs (I don't recall them having any LOD). I'm 99% positive DynDOLOD v2 doesn't call out these references but v3 is, which is why I'm confused as to what changed. I've never seen any issues with it in-game. Also with the amount of users installing RWT, I'm sure someone would have reported the issue by now too, if there was one. These edits have been with RWT since last year sometime. The only thing being reported now for some users are the messages from DynDOLOD v3.

Large reference bugs cause the LOD for all large references in the same cell to stay loaded. It does not matter if the large reference causing the bug itself has LOD.

DynDOLOD 3.x reports many more problems and issues than DynDOLOD 2.x. The end of process summary about issues is not finished yet.

DynDOLOD 2.x/3.x fixes the UDR in ESM flagged plugins by removing the Initially Disabled flag and removing the enable parent to the player.

On 11/3/2021 at 1:35 AM, Epslion_09cc said:

Thanks mate, but that makes no sense.

I installed resource file for 6 times at least. And I just checked my resource file folder, It looks like that:

https://imgur.com/a/RNUFKHz

And here is the Script folder looks like:

https://imgur.com/a/yHeP9Zt

I will try only with DynDOLOD to generate files later, and re-install all files of course.

 

I already even tried, vanilla game +skse +USSEP +DynDOLOD. Still same problem, Unable to bind script..

Yes I am 100% sure I re-install resource files and re-generated files.

Here is the DynDOLOD log:

https://ufile.io/cxubudq6

The first two screenshots do not show if the DynDOLOD Resources are actually enabled and if the scripts are actually available in the ..\Data\Scripts\ folder and accessible by the game when it runs. Whatever problems causing the game not loading scripts from other mods and DynDOLOD Resources is outside of DynDOLOD control. Assuming the files are at the correct location and have the correct file names and the game is started from MO2, it could be permission problems, anti-vir etc.

[Tahano]

Just started using DynDOLOD fairly recently and it is amazing. Fixed all kind of issues with LOD's.

I'll try to be brief and I know this is going to sound really petty, but I gotta ask anyway.

I play Skyrim SE on my 42" TV. As a result I have to scale display to 200% to be able to see the desktop. When running TexGenx64, at the first GUI where you choose format type  and tile size, at a 200% scale, the last row with the buttons does not show. I have to change back to 100% scale to be able to see them, then go back to 200% scale. Kind of a pain, which no part of is any fault of yours.

I was wondering if, since the GUI is considered an Object with specific attributes, if someone could turn off the frame lock so the GUI  size could be adjusted.

Like I said, I know it's petty and probably only applies to my situation and "maybe" a few others.

If you wanna tell me tough cookie, I'll perfectly understand, but I just had to ask anyway.

Thanks again for all yall's great work and effort. Great Mod.

[TechAngel85]

6 hours ago, sheson said:

Large reference bugs cause the LOD for all large references in the same cell to stay loaded. It does not matter if the large reference causing the bug itself has LOD.

DynDOLOD 3.x reports many more problems and issues than DynDOLOD 2.x. The end of process summary about issues is not finished yet.

DynDOLOD 2.x/3.x fixes the UDR in ESM flagged plugins by removing the Initially Disabled flag and removing the enable parent to the player.

Upon closer testing, literally TFCing over there, I can see at least some of these splashes are, indeed, an issue. They are loaded for the first LOD level only in vanilla (and moving), but not when RWT is active. When I run DynDOLOD, the result is that the DynDOLOD plugin removes the "initially disabled" and "parent" records, but keeps the -30000 from the RWT changes. DynDOLOD does not touch RWT's custom placed references that replace these vanilla ones. In-game after DynDOLOD is ran, the result is the same for RWT assets. They do not show on LOD and pop-in when the cell is loaded. This means the RWT placed references aren't being see from afar (first LOD level).

Does these mean I need to remove the "initially disabled" and "parent" records from these references? Will that prevent the reported issues?

Second, question is the script for new RNAM was never ran for RWT (wasn't aware of it). I take it this needs to be done, and if so, is the script included with xEdit up to date (currently using v4.0.3)? Will this enable the RWT references to show on the first LOD level like vanilla? Being a moveable static, I'm not sure if those are handled differently.

[sheson]

On 11/3/2021 at 3:24 PM, Tahano said:

Just started using DynDOLOD fairly recently and it is amazing. Fixed all kind of issues with LOD's.

I'll try to be brief and I know this is going to sound really petty, but I gotta ask anyway.

I play Skyrim SE on my 42" TV. As a result I have to scale display to 200% to be able to see the desktop. When running TexGenx64, at the first GUI where you choose format type  and tile size, at a 200% scale, the last row with the buttons does not show. I have to change back to 100% scale to be able to see them, then go back to 200% scale. Kind of a pain, which no part of is any fault of yours.

I was wondering if, since the GUI is considered an Object with specific attributes, if someone could turn off the frame lock so the GUI  size could be adjusted.

Like I said, I know it's petty and probably only applies to my situation and "maybe" a few others.

If you wanna tell me tough cookie, I'll perfectly understand, but I just had to ask anyway.

Thanks again for all yall's great work and effort. Great Mod.

Sounds like an issue with the OS not scaling things correctly. Is this Windows 10?

If I can replicate I might be able to add a pixel or two to prevent that.

On 11/3/2021 at 3:29 PM, TechAngel85 said:

Upon closer testing, literally TFCing over there, I can see at least some of these splashes are, indeed, an issue. They are loaded for the first LOD level only in vanilla (and moving), but not when RWT is active. When I run DynDOLOD, the result is that the DynDOLOD plugin removes the "initially disabled" and "parent" records, but keeps the -30000 from the RWT changes. DynDOLOD does not touch RWT's custom placed references that replace these vanilla ones. In-game after DynDOLOD is ran, the result is the same for RWT assets. They do not show on LOD and pop-in when the cell is loaded. This means the RWT placed references aren't being see from afar (first LOD level).

Does these mean I need to remove the "initially disabled" and "parent" records from these references? Will that prevent the reported issues?

Second, question is the script for new RNAM was never ran for RWT (wasn't aware of it). I take it this needs to be done, and if so, is the script included with xEdit up to date (currently using v4.0.3)? Will this enable the RWT references to show on the first LOD level like vanilla? Being a moveable static, I'm not sure if those are handled differently.

If you do not want Initial Disabled large references to trigger visible large reference bugs, then maybe change those records in the plugin.
However, DynDOLOD fixes those anyways. In the release version it will only report records that it couldn't fix, like DynDOLOD 2.x does.

If you have an ESM flagged plugin and want its references to be large reference, then you can use the script. Make sure to use this version:
https://github.com/TES5Edit/TES5Edit/blob/sheson-create-large-ref-script-updates/Build/Edit Scripts/Skyrim SE - Generate Large References.pas

Or better, add rules for DynDOLOD so the full model (or a special dynamic LOD model) gets dynamic LOD in the NearGrid.

Large references do not show in an object LOD Level. They are full models that are loaded already in the LOD area beyond the uGridsToLoad.
Similar to IsFullLOD/Persistent references.

[TechAngel85]

19 minutes ago, sheson said:

If yo do not want Initial Disabled large reference to trigger visible large reference bugs, then maybe change those records in the plugin.
However, DynDOLOD fixes those anyways. In the release version it will only report records that it couldn't fix, like DynDOLOD 2.x does.

Okay. I will change those since they seem to not be needed and just keep the -30000. This replicates the DynDOLOD results, regardless if the final version will print the messages or not. I would rather have it done right than DynDOLOD needing to fix it. 

19 minutes ago, sheson said:

If you have a ESM flagged plugin and want its references to be large reference, then you can use the script. Make sure to use this version:
https://github.com/TES5Edit/TES5Edit/blob/sheson-create-large-ref-script-updates/Build/Edit Scripts/Skyrim SE - Generate Large References.pas

Okay, that doesn't sound like what I want. The ESM is only used to move the vanilla references out of the way and contains no new references. The ESP is what places the new references in the same locations as the old. Should the new references also be in the ESM?

This option (call it option #1) would seem to be the only way to replicate vanilla without requiring DynDOLOD, correct?

19 minutes ago, sheson said:

Or better, add rules for DynDOLOD so the full model (or a special dynamic LOD model) gets dynamic LOD in the NearGrid.

Call this option #2; the preferable option?

I do like this better as it keeps the ESM to only vanilla records. This option would require DynDOLOD, though. The unfortunate reality is that there are still users that don't use DynDOLOD because they think it too complicated and then for those that do there are still users it would scare to add rules.  I have to consider that RWT has nearly 400K downloads at its peak and adding any requirements to the mod isn't a light decision. Any requirement added as to be weighted whether it's the right things to do. In this case, I would love to bring all those users onboard with DynDOLOD, but the reality is that decision could also alienate 100s of thousands of users. It would fall somewhere in the middle of alienation and onboarding, but how far the scale would tip one way or the other is totally unknown.

I think the best solution for everyone would be option #1, if it indeed replicates vanilla behavior (have to test). Else I will go with option #2 and make it "optional" for those users adventurous enough to learn new things; others will simply have to deal with the pop-in. I don't think there has been any reports, yet, because the issues are kind of hard to view from normal gameplay. I was TFCing and TCLing around to view them. Users would normally be within the loaded range of the cells before seeing most of the references so the issues are never noticed.