DynDOLOD 3.00 Alpha 182

[sheson]

1 hour ago, 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.

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]

12 minutes ago, 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.

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]

3 hours ago, 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.

 

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

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

[ArdentKumquat]

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.

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

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.