DynDOLOD 3.00 Alpha 190

[Lavitz]

Hey All.

I'm getting this TexGen error 

Error: File not found textures\landscape\snow01landscape_n.dds.

I get no more info than this line, most errors at least tell you what mod it is in relation to as far as I've seen before.

I don't know what this is about as I've never had it come up before, I don't have any mods installed that cover this texture so I've no idea what this is about, It's almost like its missing from the vanilla game files too, otherwise TexGen would have fallen back on that file or am I wrong?

Losing my mind over this as i can't find any ref online to this specific texture.

[sheson]

  On 9/7/2023 at 9:45 PM, Lavitz said:

Hey All.

I'm getting this TexGen error 

Error: File not found textures\landscape\snow01landscape_n.dds.

I get no more info than this line, most errors at least tell you what mod it is in relation to as far as I've seen before.

I don't know what this is about as I've never had it come up before, I don't have any mods installed that cover this texture so I've no idea what this is about, It's almost like its missing from the vanilla game files too, otherwise TexGen would have fallen back on that file or am I wrong?

Losing my mind over this as i can't find any ref online to this specific texture.

Expand  

Moved to the DynDOLOD 3 Alpha forum. Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum which TexGen log and debug log to upload when making posts.

[Mousetick]

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

Fix for scanning Markarth with ScanParent=0 confirmed in new test version.

--

So I'm peering through the DynDOLOD plugins and identifying the initially disabled references that would need testing. Houston, we have another problem  

We forgot about the opposite scenario: a reference with dynamic LOD is initially enabled, then disabled later in-game. The child copy remains perpetually enabled.

For example, the Solitude Lighthouse fire:

• [REFR:0007526C] (places SlighthouseActivator [ACTI:000622F0])
• [REFR:00062832] (places SlighthouseFireOff [STAT:0001A0B4])

These 2 references are not linked together by an Enable Parent, they're toggled independently. Here's the bit of Papyrus code that does it, during the related quest:

;BEGIN FRAGMENT Fragment_14
Function Fragment_14()
;BEGIN CODE
alias_MS07LighthouseFireOff.GetRef().enable()
alias_MS07LighthouseFire.GetRef().Disable()
[...]

alias_MS07LighthouseFire.GetRef().Disable() is not going to affect the child copy:

skyrimesm_07526C_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD [REFR:5908ED4A] (places SlighthouseActivator "Solitude Lighthouse Fire" [ACTI:000622F0])

remains enabled.

Possible solution: extend the previous solution of linking the child copy to the parent reference via Enable Parent, to all copies of references with dynamic LOD.

As discussed before, this requires the parent reference to be persistent, but that theoretical limitation should have no impact in practice for references that are toggled via script, as they must already be persistent.

Thanks.

[sheson]

  On 9/8/2023 at 7:53 AM, Mousetick said:

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

Fix for scanning Markarth with ScanParent=0 confirmed in new test version.

--

So I'm peering through the DynDOLOD plugins and identifying the initially disabled references that would need testing. Houston, we have another problem  

We forgot about the opposite scenario: a reference with dynamic LOD is initially enabled, then disabled later in-game. The child copy remains perpetually enabled.

For example, the Solitude Lighthouse fire:

• [REFR:0007526C] (places SlighthouseActivator [ACTI:000622F0])
• [REFR:00062832] (places SlighthouseFireOff [STAT:0001A0B4])

These 2 references are not linked together by an Enable Parent, they're toggled independently. Here's the bit of Papyrus code that does it, during the related quest:

;BEGIN FRAGMENT Fragment_14
Function Fragment_14()
;BEGIN CODE
alias_MS07LighthouseFireOff.GetRef().enable()
alias_MS07LighthouseFire.GetRef().Disable()
[...]

alias_MS07LighthouseFire.GetRef().Disable() is not going to affect the child copy:

skyrimesm_07526C_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD [REFR:5908ED4A] (places SlighthouseActivator "Solitude Lighthouse Fire" [ACTI:000622F0])

remains enabled.

Possible solution: extend the previous solution of linking the child copy to the parent reference via Enable Parent, to all copies of references with dynamic LOD.

As discussed before, this requires the parent reference to be persistent, but that theoretical limitation should have no impact in practice for references that are toggled via script, as they must already be persistent.

Thanks.

Expand  

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.

[Lavitz]

Hey All.

I'm getting this TexGen error 

Error: File not found textures\landscape\snow01landscape_n.dds.

I get no more info than this line, most errors at least tell you what mod/file it is in relation to as far as I've seen before.

I don't know what this is about as I've never had it come up before, I don't have any mods installed that cover this texture so I've no idea what this is about, It's almost like its missing from the vanilla game files too, otherwise TexGen would have fallen back on that file or am I wrong?

Losing my mind over this as I can't find any ref online to this specific texture.

[sheson]

  On 9/8/2023 at 6:03 PM, Lavitz said:

Hey All.

I'm getting this TexGen error 

Error: File not found textures\landscape\snow01landscape_n.dds.

I get no more info than this line, most errors at least tell you what mod/file it is in relation to as far as I've seen before.

I don't know what this is about as I've never had it come up before, I don't have any mods installed that cover this texture so I've no idea what this is about, It's almost like its missing from the vanilla game files too, otherwise TexGen would have fallen back on that file or am I wrong?

Losing my mind over this as I can't find any ref online to this specific texture.

Expand  

Moved to the DynDLOD 3 Alpha thread. You already posted this before. See https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-142/?do=findComment&comment=274141

It is pretty much guaranteed that the requested log files contain more than that line.

[Lavitz]

  On 9/8/2023 at 6:13 PM, sheson said:

Moved to the DynDLOD 3 Alpha thread. You already posted this before. See 

 

It is pretty much guaranteed that the requested log files contain more than that line.

 

Expand  

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.txtFetching info...

[Cazime]

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.

[1erCru]

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 )

[sheson]

  On 9/8/2023 at 10:42 PM, 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

Expand  

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]

  On 9/8/2023 at 11:13 PM, 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.

Expand  

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

[Mousetick]

  On 9/8/2023 at 8:49 AM, 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.

Expand  

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]

  On 9/9/2023 at 12:33 AM, 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 )

Expand  

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

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

  On 9/9/2023 at 10:02 AM, 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

Expand  

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.