DynDOLOD 3.00 Alpha 196

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

[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

[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

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