DynDOLOD 3.00 Alpha 173

[jimmywon34]

1 hour ago, sheson said:

Read the first post which log, debug log and bugreport.txt to upload when making posts.

Maybe even check the log messages yourself, I wouldn't be surprised if there is some kind of hint what might be going on.

Sorry. The File sharing site is saying the file size is too small so it's not uploading it. Any other way other than the two methods in the first post to share my logs? I'm not sure how to use the Text sharing service.

 

Edit - Nevermind here's the logs  https://ufile.io/t79az462

Edited August 22, 2022 by jimmywon34

[jimmywon34]

1 hour ago, sheson said:

Read the first post which log, debug log and bugreport.txt to upload when making posts.

Maybe even check the log messages yourself, I wouldn't be surprised if there is some kind of hint what might be going on.

Here are the logs from my most recent attempt, where it didn't generate the esps and esm - https://ufile.io/67jo4gac  

They might be better logs as this attempt it actually got through to the end where i was able to save zip and exit.

Edited August 22, 2022 by jimmywon34

[SilverJolteon]

When running TexGen, I decided to change the output directory to my mods folder so that it would export the zip file there. However, afterwards, I discovered that every mod's subfolders have been deleted, only leaving the esp/esm files. Is there any way to undo the process or recover the files? Thank you.

[sheson]

1 hour ago, SilverJolteon said:

When running TexGen, I decided to change the output directory to my mods folder so that it would export the zip file there. However, afterwards, I discovered that every mod's subfolders have been deleted, only leaving the esp/esm files. Is there any way to undo the process or recover the files? Thank you.

Moved to the DynDOLOD 3 Alpha thread. Make sure to read the first post.
Read the first post which log and debug log to upload when making posts.

No. I mean nothing but the usual Windows OS shadow copy/previous versions or 3rd party undelete tools.

https://dyndolod.info/Generation-Instructions
Select an output path. The output path should be outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game or any mod manager folders.
Click Exit TexGen or click Zip & Exit to create a *.zip archive of the output for easier mod installation. Creating an archive will clean the output folder while all relevant files are packed into the zip file.

I keep adding idiot proof checks trying to protect users from themselves, but as the saying goes, they keeping building a better idiots.

[sheson]

1 hour ago, jimmywon34 said:

Here are the logs from my most recent attempt, where it didn't generate the esps and esm - https://ufile.io/67jo4gac  

They might be better logs as this attempt it actually got through to the end where i was able to save zip and exit.

The log reports: <Error: Unspecified error while processing Archive> from the 7zip DLL, so that is not really helpfull. If not other error message from the DLL pops up, then I have no idea, other than maybe OS, antivir or drive problems.

Instead use only "Save & Exit" without the zipping and install the output as a mod directly (e.g. move files into a new mod folder in MO2), or use the https://www.7-zip.org directly to see if it works or also has a problem.

[jimmywon34]

52 minutes ago, sheson said:

The log reports: <Error: Unspecified error while processing Archive> from the 7zip DLL, so that is not really helpfull. If not other error message from the DLL pops up, then I have no idea, other than maybe OS, antivir or drive problems.

Instead use only "Save & Exit" without the zipping and install the output as a mod directly (e.g. move files into a new mod folder in MO2), or use the https://www.7-zip.org directly to see if it works or also has a problem.

That worked. By the way should the esps be the last in load order or does it matter? I watched Gamerpoets tutorial on Youtube and he didn't mention a load order so just wanted to ask.

[sheson]

40 minutes ago, jimmywon34 said:

That worked. By the way should the esps be the last in load order or does it matter? I watched Gamerpoets tutorial on Youtube and he didn't mention a load order so just wanted to ask.

https://dyndolod.info/Generation-Instructions#2-Generate-The-LOD-Mod-with-DynDOLOD
Install the contents of the output path or the *.zip archive as a mod. It should overwrite everything.
Activate the plugins(s). In case Occlusion.esp was generated, it should be the last plugin to load right after DynDOLOD.esp.

Also see https://dyndolod.info/Help/Load-Overwrite-Orders#After-Generation

[dizieball]

I'm consistently getting an error running TexGen through vortex.

"Error: OpenGL: invalid operation while processing textures\
WIth the texture changing each time.: 

It feels like it times out.

I've updated the Adrenalin software and drivers as of 8/22/22 for amd.

It lasts about 2 min... then the error continually occurs... about 6 times tried so far.

I've attached Logs in a zip

I appreciate your hard work. 
Any thoughts or direction is appreciated.

Logs.7z

[jimmywon34]

3 hours ago, sheson said:

https://dyndolod.info/Generation-Instructions#2-Generate-The-LOD-Mod-with-DynDOLOD
Install the contents of the output path or the *.zip archive as a mod. It should overwrite everything.
Activate the plugins(s). In case Occlusion.esp was generated, it should be the last plugin to load right after DynDOLOD.esp.

Also see https://dyndolod.info/Help/Load-Overwrite-Orders#After-Generation

thanks

[facebutt92]

Hey, I've been trying to get dyndolod working and the x64 executables for both texgen and dyndolod don't work through mo2. The thing is, it launches fine when I use the texgen and dyndolod that aren't x64. Can anyone help me with this? I also have the latest version of mo2.

Edit: I also put in the -sse argument and it still did not work

Edited August 23, 2022 by facebutt92

[DoubleYou]

I'm testing some new road LODs I made so that I can display the roads on the map. Therefore, I named them with the _3 modifier. Unfortunately, it seems that DynDOLOD for some reason skips them if they are named _3. Logs: https://mega.nz/file/1QhGVTDS#-dIWlZk3TCCdRvYCTSH8PB3OWdvNmLR72oUQBBk55PM

In this run, for demonstration, I set my normal roads, saved with _3 (e.g., Road3way01_lod_3.nif), as Level3, and the Blackreach roads (e.g. dweroad3way01_lod_2.nif) to Level2. The Level2 Blackreach roads show, but the normal roads aren't added at all to the BTO. Checking the LODGen export, it doesn't appear to find the _3 nifs. If I rename them to _2 they find them correctly and as expected.

[sheson]

7 hours ago, dizieball said:

I'm consistently getting an error running TexGen through vortex.

"Error: OpenGL: invalid operation while processing textures\
WIth the texture changing each time.: 

It feels like it times out.

I've updated the Adrenalin software and drivers as of 8/22/22 for amd.

It lasts about 2 min... then the error continually occurs... about 6 times tried so far.

I've attached Logs in a zip

I appreciate your hard work. 
Any thoughts or direction is appreciated.

Logs.7z 68.22 kB · 0 downloads

Use the Adrenalin 22.5.1 Recommended (WHQL) and not any of the optional newer drivers that still seem to contain OpenGL bugs as discussed several times in this thread recently

6 hours ago, facebutt92 said:

Hey, I've been trying to get dyndolod working and the x64 executables for both texgen and dyndolod don't work through mo2. The thing is, it launches fine when I use the texgen and dyndolod that aren't x64. Can anyone help me with this? I also have the latest version of mo2.

Edit: I also put in the -sse argument and it still did not work

Read the first post which explains which log and debug log upload when making posts. Delete the log from x86 version and start the x64 version again to write new log.

"Not working" is not a useful problem report. Report the actual version instead of "latest".

[sheson]

7 hours ago, DoubleYou said:

I'm testing some new road LODs I made so that I can display the roads on the map. Therefore, I named them with the _3 modifier. Unfortunately, it seems that DynDOLOD for some reason skips them if they are named _3. Logs: https://mega.nz/file/1QhGVTDS#-dIWlZk3TCCdRvYCTSH8PB3OWdvNmLR72oUQBBk55PM

In this run, for demonstration, I set my normal roads, saved with _3 (e.g., Road3way01_lod_3.nif), as Level3, and the Blackreach roads (e.g. dweroad3way01_lod_2.nif) to Level2. The Level2 Blackreach roads show, but the normal roads aren't added at all to the BTO. Checking the LODGen export, it doesn't appear to find the _3 nifs. If I rename them to _2 they find them correctly and as expected.

Since the game only uses 3 LOD Levels by default, the automatic LOD assignment only assigns to Level 0, 1 and 2. Only vanilla uses _3  and it is typically assigned like _2 if no _2 exists.

This probably could be different when LODLevel32 is set to true and/or the last / mesh mask rule sets LOD Level 32 not none.

The questions would be if there needs to an identifier that makes sure the LOD model is only ever used for LOD Level 32, so it does not end up in the LOD used in the normal world, because there is no _2 and Level2 gets auto filled with _3 because of those vanilla LOD models.

[DoubleYou]

I considered making higher quality versions for the map itself, as my main reason for using lod32 is to ensure I don't kill my performance in game. My lod_3 models are z height adjusted versions of my lod_0 lods (I created them all from scratch since I might as well have near perfect road lods in game as well). My lod_1 versions are lower poly then either. I planned to include a DynDOLOD rule tweak to set it correctly. I can of course use lod_2, but was worried about people accidentally placing them in lod16 and bogging down performance.

[sheson]

1 hour ago, DoubleYou said:

I considered making higher quality versions for the map itself, as my main reason for using lod32 is to ensure I don't kill my performance in game. My lod_3 models are z height adjusted versions of my lod_0 lods (I created them all from scratch since I might as well have near perfect road lods in game as well). My lod_1 versions are lower poly then either. I planned to include a DynDOLOD rule tweak to set it correctly. I can of course use lod_2, but was worried about people accidentally placing them in lod16 and bogging down performance.

I will add these changes to the next version:

Always assign lod_3.nif to Level3 instead of leaving Level3 empty. _lod_3.nif continues to fill lower levels if there are no _lod_[0|1|2].nif and no _lod.nif
In case a lod_4.nif exists, it will always be assigned to Level3 (replacing any _lod_3.nif) but without filling any lower levels.

Once the next version is out, double check those changes by checking DynDOLOD_SSE_Object_Report.txt