DynDOLOD 3.00 Alpha 180

[sheson]

6 hours ago, Lavitz said:

Apologies for double posting, I've gone back to read the first post and attached the requested files.

Can't find ..\DynDOLOD\bugreport.txt, not there.

Let me know if this I'snt the correct info, I appreciate your time on this matter.

https://ufile.io/lhheuelr TexGen_TES5_Debug_log.txt

TexGen_TES5_log.txt 453.48 kB · 1 download

Download this file DynDOLOD_TES5_TexGen_copy_skyrimesm.txt 
Replace the existing one in ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\ with it.

TexGen should then run through.
Will be fixed next Alpha version, too.

[sheson]

6 hours ago, Cazime said:

As the title says, both LodGen and TexGen have both been freezing during generation. The programs stop responding to input, and their CPU/Disk usage both drop to 0% while the memory remains stuck at whatever it was at when it froze. Generally this happens around 5-10 seconds into generation, but LodGen can generally be brute-forced into completing generation through piecemealing the generation files a little at a time. TexGen, however, doesn't seem to use the same system that detects whether or not a file has already been created, so it basically just keeps generating the same files over and over again.

I'm fairly certain it's one of my mods causing it, but I have so many mods that I don't know how to figure out which mod is doing this, and I don't have the time to just disable everything and rule them out one by one.

I've disabled my antivirus, my files are on a completely separate drive to my game and OS files, and I can't get the logs from the programs because it literally won't let me. The whole program locks up and I have to use task manager to close it. And no, it's not anything to do with the texture converter program that occasionally runs, I've left these programs alone for 8 hours straight and nothing changes.

If anyone is curious, my mod list is this: https://modwat.ch/u/RadiaDaku

Yes, there are some conflicting mods, a lot of the list on Mod Organizer is made up of patches for most of those conflicts. I generally try my best to check what conflicts a mod may have before committing it to my modlist, but I'm unsure about how to go about checking which mod or mods is causing these issues.

If anyone can help, please do. I just want to go back to playing my game. The older versions of DynDOLOD didn't do this--but I need the newer version for a couple of the mods that I use that change the way light from the in-game sun interacts with the terrain and trees.

Moved to the DynDOLOD 3 Alpha thread.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which logs and debugs to upload or how to enable the realtimelog and check the Windows Event log.

See https://dyndolod.info/FAQ#TexGen-DynDOLOD-stuck-while-creating-textures
https://dyndolod.info/FAQ#High-memory-usage-Out-of-memory
https://dyndolod.info/FAQ#Long-running-time-or-output-several-GB-in-file-size
https://dyndolod.info/Help/LODGen#Out-of-Memory

[sheson]

5 hours ago, ArdentKumquat said:

Hello. I just used this to generate LOD and so far it looks good, but there's a snowstorm in Skyrim right now, so things are a little blurry. I did run into one issue. A mod I'm using that I ported from Skyrim LE, "Women's Faces" (I believe) apparently overrides some headpart definitions from the Hearthfire DLC.  This caused an error when I ran texgen, along with a warning that it could result in game crashes. I have been using this mod for years, in both Skyrim LE and now SSE. I disabled the plugin and restarted the processing and it all went smoothly after that. I'm wondering if that is a necessary check. I'm impressed with the level of validation texgen is doing, since it called my attention to a couple of invalid IDs for ESL flagged plugins (when I ran the older version yesterday), but I'm wondering about the significance of these new errors regarding the headparts. Is that always considered an error?

 

This is an update to my previous post (I don't see how to simply reply to it):

TexGen

[Main Instruction]
Record [INFO:03000D9D] in file HearthFires.esm is being overridden by record [HDPT:03000D9D] in file NPS_Female_SE.esp.

[Content]
These errors can cause CTD and other serious issues and need to be fixed.

There were quite a few of these errors, so clicking ignore for each would be extremely tedious, so I disabled the .esp file while running texgen and dyndolod.

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

As explained use the "Click on this link for additional explanations and help for this message" from the message to open https://dyndolod.info/Messages/Record-Is-Being-Overridden

Plugins randomly replacing records in master plugins is an error that needs to be fixed. Not having encountered an issue in the game is not a valid method to assume something is fine. If you check the overwritten record in xEdit you will see it has to do with moving children to another home. You would have to create the right conditions that rely on this record in order to test what happens if the game, scripts can not find the record and data they are expecting.

Temporarily disabling the plugin is not going to fix its problems. The plugin needs to be fixed to work properly with the game plugins of Skyrim Special Edition.

[Mousetick]

21 hours ago, sheson said:

This test version https://mega.nz/file/sMQk3LDT#1g6LdrN5Pw90QmesBCmB1N5vwj7ZhM-CPw32s9v2a0o removes the IsInitiallyDisabled condition. So if the source reference is persistent and has no enabled parent itself, it is used as enable parent for the copy.

Thanks. I'm still compiling a list of references toggled by script and copied by Parent > Child, which is a bit time-consuming. Once that's done I'll go check things out in-game. I'll let you know the results later. But so far, things look great "on paper" (i.e. in xEdit).

[sheson]

5 hours ago, 1erCru said:

is it possible to run multiple DYNDOLOD ?

Lets say I render Skyrim but leave something like Chanterelle out 

Then can I rerun for Chanterelle only with different settings ? ( i.e. no ultra trees for Chanterelle or a lesser grass density for distant grass etc )

The principle is the same as the 3rd bullet point at https://dyndolod.info/Updating#New-or-Updated-Mods-or-Plugins

[ArdentKumquat]

48 minutes ago, sheson said:

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

As explained use the "Click on this link for additional explanations and help for this message" from the message to open https://dyndolod.info/Messages/Record-Is-Being-Overridden

Plugins randomly replacing records in master plugins is an error that needs to be fixed. Not having encountered an issue in the game is not a valid method to assume something is fine. If you check the overwritten record in xEdit you will see it has to do with moving children to another home. You would have to create the right conditions that rely on this record in order to test what happens if the game, scripts can not find the record and data they are expecting.

Temporarily disabling the plugin is not going to fix its problems. The plugin needs to be fixed to work properly with the game plugins of Skyrim Special Edition.

I don't see how something like this could happen. A HeadPart record overriding a DialogTopic? It makes no sense.The plugin was disabled solely for the purpose of generating LOD, which was what I was attempting to do.  Between SLE and SSE there must be over 200 hours with that mod installed. It may be missing some dialog topics, but they all seem to be related to marriage, which is something I didn't bother with in the game.  In any case, I just renumbered all the offending FormIDs using xEdit. What a strange thing to find.

[Mousetick]

DynDOLOD 3a143 Test version for Parent > Child copies of references with dynamic LOD

More observations while peering through the plugins:

• The 'No Respawn' flag doesn't appear to be carried over to the child copies. For example: MQ106DragonMoundREF [REFR:000CAF88] (places DragonMoundBase [ACTI:000CAF75])

Parent ref > Child copy

• Some parent references such as Windmills and Smelters have a XLRT - Location Ref Type: ResourceDestructibleObject [LCRT:0001D4DF] field. For example, ResourceObjectFarmPalagiaFarm [REFR:0005CA6C] (places SFarmhouseWindMillDirt02Whiterun [STAT:0001686D]). I don't know what this is intended to do and I couldn't find any info online. Going by the name, it would suggest the object can be destroyed, but how? I suspect this is a left-over from a game mechanic that was cut or never implemented. This post on reddit seems to confirm that.

• You said local scripts are not carried over to the child copies, which is good, but there may be a potential issue with local scripts attached to the base record. There is very little information available online, except this UESP article which doesn't match exactly the terminology used by xEdit. It's not clear to me what the default behavior is when the reference's VMAD section is empty. Are the base record's local scripts automatically inherited by the reference?

For example, DragonMoundBase [ACTI:000CAF75] has a local script:

This reference [REFR:00066953] (places DragonMoundBase [ACTI:000CAF75]), explicitly sets the 'Inherited and Removed' flag on the FXDragonMoundScript of the base record, which I'm interpreting as "don't inherit this base record script, remove it".

If this is correct, it may be necessary to apply a similar override to child copies using scripted base records in order to 1) prevent side-effects and 2) avoid bloating the save file by adding more unnecessary script instances. This would significantly complicate the copy process however. Hopefully your friends from the xEdit team can shed some light on this.

Thanks.

Full logs here if you need them: https://drive.google.com/file/d/1B18Drj8elt8ao0dIlBcw39eqMWYoH--h/view

[sheson]

1 hour ago, Mousetick said:

DynDOLOD 3a143 Test version for Parent > Child copies of references with dynamic LOD

More observations while peering through the plugins:

• The 'No Respawn' flag doesn't appear to be carried over to the child copies. For example: MQ106DragonMoundREF [REFR:000CAF88] (places DragonMoundBase [ACTI:000CAF75])

Parent ref > Child copy

• Some parent references such as Windmills and Smelters have a XLRT - Location Ref Type: ResourceDestructibleObject [LCRT:0001D4DF] field. For example, ResourceObjectFarmPalagiaFarm [REFR:0005CA6C] (places SFarmhouseWindMillDirt02Whiterun [STAT:0001686D]). I don't know what this is intended to do and I couldn't find any info online. Going by the name, it would suggest the object can be destroyed, but how? I suspect this is a left-over from a game mechanic that was cut or never implemented. This post on reddit seems to confirm that.

• You said local scripts are not carried over to the child copies, which is good, but there may be a potential issue with local scripts attached to the base record. There is very little information available online, except this UESP article which doesn't match exactly the terminology used by xEdit. It's not clear to me what the default behavior is when the reference's VMAD section is empty. Are the base record's local scripts automatically inherited by the reference?

For example, DragonMoundBase [ACTI:000CAF75] has a local script:

This reference [REFR:00066953] (places DragonMoundBase [ACTI:000CAF75]), explicitly sets the 'Inherited and Removed' flag on the FXDragonMoundScript of the base record, which I'm interpreting as "don't inherit this base record script, remove it".

If this is correct, it may be necessary to apply a similar override to child copies using scripted base records in order to 1) prevent side-effects and 2) avoid bloating the save file by adding more unnecessary script instances. This would significantly complicate the copy process however. Hopefully your friends from the xEdit team can shed some light on this.

Thanks.

Full logs here if you need them: https://drive.google.com/file/d/1B18Drj8elt8ao0dIlBcw39eqMWYoH--h/view

The copies are for now are deliberately not copying all flags, and some elements like linked references or locations. They are supposed to be "dumb" static copies on purpose.
The respawn flag will most likely not be needed if the copy uses the parent as enable parent. Need to check which flags are really save to keep.

Might probably be better to copy ACTI with scripts and remove the scripts. We'll see.

[Mousetick]

1 hour ago, sheson said:

The respawn flag will most likely not be needed if the copy uses the parent as enable parent. Need to check which flags are really save to keep.

On second thought, I think it's better not to carry it over. First, it wouldn't work: parent and child references being separate references in separate cells, each with their own reset timer, they wouldn't be in sync. Second, the No Respawn flag is useful with "smart" stateful references such as those using ACTI, and therefore would not be needed with dumb stateless static copies.

[RainingTacco]

Can we get separate folder for edit scripts/dyndolod.ini settings, because after you make some custom changes to them, it's then very unwieldy when upgrading to new version, making sure you don't overwrite these ini files is not an easy task as you have to first unpack stuff, delete the ini files and then copy and replace over. If we had them in separate folder without any .dll files that might had been updated, it would be just as easy as not selecting the appropraite folder during unpacking. @sheson 

[sheson]

1 hour ago, RainingTacco said:

Can we get separate folder for edit scripts/dyndolod.ini settings, because after you make some custom changes to them, it's then very unwieldy when upgrading to new version, making sure you don't overwrite these ini files is not an easy task as you have to first unpack stuff, delete the ini files and then copy and replace over. If we had them in separate folder without any .dll files that might had been updated, it would be just as easy as not selecting the appropraite folder during unpacking. @sheson 

https://dyndolod.info/Installation-Instructions
Use 7-Zip to unpack the DynDOLOD Standalone archive into a new and empty 'DynDOLOD' directory that is outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game, Data or any mod manager folders. For example C:\Modding\DynDOLOD\.

https://dyndolod.info/Updating
Rename the DynDOLOD Standalone folder, for example from C:\Modding\DynDOLOD to C:\Modding\DynDOLOD.OLD
Unpack the new DynDOLOD Standalone using the same original installation path. See Installation Instructions.
If desired, reapply any customized INI settings. Open the old and new ..\DynDOLOD\Edit Scripts\DynDOLOD\[DynDOLOD|TexGen]_[GAME MODE].ini in notepad++ to compare to make sure to not accidentally remove any new INI Settings. If the Changelog does not mention any new or changed INI settings, the old INI can typically just be copied in case any settings were customized.

The download archive does not contain a ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD.ini, so it can not be accidentally overwritten when doings things wrong.

[RainingTacco]

I know about procedure, i just asked if you ever thought about separating these to make it hassle free. 

[sheson]

55 minutes ago, RainingTacco said:

I know about procedure, i just asked if you ever thought about separating these to make it hassle free. 

The DynDOLOD.ini and TexGen.ini are really only used to store the last window position.

[ArdentKumquat]

I ran DynDOLOD on high. It looks fantastic, although the tree LOD is far too bright, especially for yellow aspens. I turned off the ENB and the tree LOD looked perfect, so it's either a problem with the ENB engine, or the specific settings I have. Does anyone know what affects LOD brightness in ENB? I think ambient light does, and probably direct lighting, although I haven't tested that yet. Are there any special instructions for using this with  ENB? I have fixed it locally by significantly reducing both brightness and saturation directly on the texture file, and now it looks ok. Are all the ENB users doing something like this?

Edited September 9, 2023 by ArdentKumquat

[sheson]

6 minutes ago, ArdentKumquat said:

I ran DynDOLOD on high. It looks fantastic, although the tree LOD is far too bright, especially for yellow aspens. I turned off the ENB, and the tree LOD looked perfect, so it's either a problem with the ENB engine, or the specific settings I have. Does anyone know what affects LOD brightness in ENB? I think ambient light does, and probably direct lighting, although I haven't tested that yet. Are there any special instructions for using this with  ENB? I have fixed it locally by significantly reducing both brightness and saturation directly on the texture file, and now it looks ok. Are all the ENB users doing something like this?

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

Ask ENB related questions on the ENB forum or discord as whatever it does to tree LOD is unrelated to the tool, if any, that was used to generate tree LOD.

https://dyndolod.info/FAQ#Billboard-tree-LOD-does-not-match-close-up-full-model-trees
If the billboard tree LOD seems overly dark or bright, use the billboard brightness setting of the advanced mode to account for lighting changes made by ENBs or weather mods.

https://dyndolod.info/Help/Advanced-Mode#Tree-LOD
Negative Billboard Brightness values will make the billboard tree LOD darker, while positive values will make it brighter.

Also see https://dyndolod.info/Help/TexGen#Direct-Ambient-Smoothness

Consider to use https://dyndolod.info/Help/Ultra-Tree-LOD with 3D tree LOD models and/or HD Tree LOD billboards.
Consider generating HD Tree LOD billboards with normal map textures for better looking tree LOD that reacts more naturally to lighting than standard tree LOD.