DynDOLOD 3.00 Alpha 169

[sheson]

2 hours ago, skyrimfreak360 said:

Hi Sheson, so thankfully I've got my DynDOLOD and all that in working order, but if I were to say, make a bashed patch, would I do this before generating xLODGen and after SSELODGen? And I recently downloaded Synthesis Patcher as I hear the great things it can do. 
This is the order that comes to vision:
SSELODGen > Wrye Bash > xLODGen > TexGen > DynDOLOD > Synthesis

I might also get a word from that Discord community behind Synthesis. I got the ingame map of Skyrim produced by A Clear Map of Skyrim and Other Worlds working, I just need trees to appear on the map but I forgot how it was done... there's some tweaking that you can do about it in xLODGen to make that happen I believe? Although I got my map working, the outside edges of it has some gaps so I would need SSE Terrain Tamriel on during SSELODGen's generation and then disable afterwards. I also tried getting Solstheim to appear close to Skyrim with Worldspace Transition Tweaks but to no avail, I'll have to try all of this another time and with more knowledge ingrained in me. 

If there's a guide for me to follow with the proper order on using the modding tools that'd be great!!

Do not write messages into text files and then upload them as zip. Instead write the message directly into the text field of the forum. I edited your post an added the message.

Read the instructions, for example: https://dyndolod.info/Generation-Instructions#Prerequisites
Finalize the load order. Install mods and their requirements. Sort and resolve conflicts. Clean and error check the load order with xEdit. Clean every plugin that LOOT suggests to clean [..]
Typically create all other patches first. Especially all patches affecting exterior worldspaces in any way should be done before generating LOD.
Typically generate terrain LOD meshes and textures with xLODGen before generating the LOD mod with DynDOLOD, [..]

The plugin and asset load order should be "final". All patches should be created. LOD should be generated last. The order is xLODGen, TexGen, DynDOLOD obviously.

See https://dyndolod.info/Help/Ultra-Tree-LOD#Trees-on-the-Map and https://dyndolod.info/Mods/Maps-And-Map-Mods

xLODGen is used to generate terrain LOD. See https://dyndolod.info/Generation-Instructions#Prerequisites and https://dyndolod.info/Help/xLODGen#Requirements
Terrain LOD is generated from the data found in the game plugins. For memory and performance reasons Bethesda removed landscape information from the Skyim.esm which were restored from the vanilla terrain LOD meshes in the xLODGen Resource mods below.

The DynDOLOD manual explains the use of DynDOLOD, TexGen and xLODGen to some extent. It is not a modding guide. Make sure to read the description/instructions of third party mods/tools. Consider following a modding guide like STEP from start to finish once to properly learn how to mod.

For how to ask questions/what logs to provide when asking specific questions about problems related to the use of the tools and to LOD generation, see the first post and https://dyndolod.info/Official-DynDOLOD-Support-Forum

[aragonit]

When I'm trying to enter Avanchnzel I get a CTD.

 

Unhandled native exception occurred at 0x7FF7C10CB3F9 (SkyrimSE.exe+9FB3F9) on thread 84416!

FrameworkName: NetScriptFramework
FrameworkVersion: 15
FrameworkArchitecture: x64
GameLibrary: SkyrimSE
GameLibraryVersion: 18
ApplicationName: SkyrimSE.exe
ApplicationVersion: 1.5.97.0
VersionInfo: Successfully loaded
Time: 23 Mar 2024 21:14:24.307

Possible relevant objects (5)
{
  [   6]    TESObjectSTAT(FormId: 291FBE52, File: `Dwarfsphere.esp`)
  [   6]    TESObjectREFR(FormId: 29247F34, File: `DynDOLOD.esp <- Dwarfsphere.esp`, BaseForm: TESObjectSTAT(FormId: 291FBE52, File: `Dwarfsphere.esp`))
  [ 307]    BSFadeNode(Name: `DweSphereCenturionPort01`)
  [ 409]    Script(FormId: FF03FB63)
  [ 414]    TESObjectCELL(Name: AvanchnzelExterior03, FormId: 000098E9, File: `Occlusion.esp <- DynDOLOD.esp <- DwarfsphereImprovedPatch.esp <- Lux Via - plugin.esp <- DynDOLOD.esm <- Lux Via.esp <- Dwarfsphere.esp <- MajesticMountains_Moss.esp <- Treescale.esm <- Unofficial Skyrim Special Edition Patch.esp <- Update.esm <- Skyrim.esm`)
}

So I disabled DynDolod.esp and Occlusion.esp, started the game (I saved before trying to enter) and everything is working perfectly fine.

The crashlog is uploaded.

Crash_2024_3_23_21-14-24.txt

[Jonado]

On 3/19/2024 at 1:01 PM, sheson said:

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

Post a useful screenshot of the full model(s) with more informative console and of the LOD model(s) as explained at https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots

Also upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt

https://dyndolod.info/Mods/Open-Exterior-Cities

All the logs are here, just as they were before: https://www.dropbox.com/scl/fi/ef90b9t3zloufid6620xn/Logs.7z?rlkey=nnt7uh9ohtanmkzlqktnsttdx&dl=0. I have added the object report log to the zip file too now. I can see if I can upload some screenshots later, but it at least affects the reference 0xC938~Open Cities Skyrim.esp and all objects with FormID 000801ED.

[Soulmancer]

Is this reversion intentional? I don't recall seeing this in past versions where these world not forwarded for the persistent world space cell.

http://icecream.me/uploads/c9d457317922354b909a694683de623e.png

 

[sheson]

10 hours ago, aragonit said:

When I'm trying to enter Avanchnzel I get a CTD.

 

Unhandled native exception occurred at 0x7FF7C10CB3F9 (SkyrimSE.exe+9FB3F9) on thread 84416!

FrameworkName: NetScriptFramework
FrameworkVersion: 15
FrameworkArchitecture: x64
GameLibrary: SkyrimSE
GameLibraryVersion: 18
ApplicationName: SkyrimSE.exe
ApplicationVersion: 1.5.97.0
VersionInfo: Successfully loaded
Time: 23 Mar 2024 21:14:24.307

Possible relevant objects (5)
{
  [   6]    TESObjectSTAT(FormId: 291FBE52, File: `Dwarfsphere.esp`)
  [   6]    TESObjectREFR(FormId: 29247F34, File: `DynDOLOD.esp <- Dwarfsphere.esp`, BaseForm: TESObjectSTAT(FormId: 291FBE52, File: `Dwarfsphere.esp`))
  [ 307]    BSFadeNode(Name: `DweSphereCenturionPort01`)
  [ 409]    Script(FormId: FF03FB63)
  [ 414]    TESObjectCELL(Name: AvanchnzelExterior03, FormId: 000098E9, File: `Occlusion.esp <- DynDOLOD.esp <- DwarfsphereImprovedPatch.esp <- Lux Via - plugin.esp <- DynDOLOD.esm <- Lux Via.esp <- Dwarfsphere.esp <- MajesticMountains_Moss.esp <- Treescale.esm <- Unofficial Skyrim Special Edition Patch.esp <- Update.esm <- Skyrim.esm`)
}

So I disabled DynDolod.esp and Occlusion.esp, started the game (I saved before trying to enter) and everything is working perfectly fine.

The crashlog is uploaded.

Crash_2024_3_23_21-14-24.txt 165.41 kB · 0 downloads

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

Am I correct to assume Dwarfsphere.esp is from Project AHO 2.0?
Is Meshes\DwarfSphere\Main\Other\DwarfSphereShipStat.nif in the load order also the from the mod?

[sheson]

2 hours ago, Soulmancer said:

Is this reversion intentional? I don't recall seeing this in past versions where these world not forwarded for the persistent world space cell.

http://icecream.me/uploads/c9d457317922354b909a694683de623e.png

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

The screenshot does not show a form id, so it unclear what record this is exactly. The screenshot does not show the header of the record. It most likely has the partial form flag set. It does not overwrite.

[sheson]

7 hours ago, Jonado said:

All the logs are here, just as they were before: https://www.dropbox.com/scl/fi/ef90b9t3zloufid6620xn/Logs.7z?rlkey=nnt7uh9ohtanmkzlqktnsttdx&dl=0. I have added the object report log to the zip file too now. I can see if I can upload some screenshots later, but it at least affects the reference 0xC938~Open Cities Skyrim.esp and all objects with FormID 000801ED.

The debug log seems to be from another generation session than the DynDOLOD log and the object report.

What mod are  SoS_Seasonspatch_Solitude.esp and SoS_Seasons - Vigilant.esp from?

The debug log shows a couple duplicate EditorIDs which should be unique in the load order and can screw with swapping based on EditorIDs
Duplicate editor ID SBluePalaceGateWinter in SoS_Seasons - Vigilant.esp SBluePalaceGateWinter [STAT:FE2A4802] and SoS_Seasonspatch_Solitude.esp SBluePalaceGateWinter [STAT:FE0F2812]>

The object report shows that SBluePalaceGateWinter from SoS_Seasonspatch_Solitude.esp xxyyy812 uses the full model meshes\architecture\solitude\sbluepalacegate.nif for LOD which is most likely not what you want.

[Jonado]

12 hours ago, sheson said:

The debug log seems to be from another generation session than the DynDOLOD log and the object report.

What mod are  SoS_Seasonspatch_Solitude.esp and SoS_Seasons - Vigilant.esp from?

The debug log shows a couple duplicate EditorIDs which should be unique in the load order and can screw with swapping based on EditorIDs
Duplicate editor ID SBluePalaceGateWinter in SoS_Seasons - Vigilant.esp SBluePalaceGateWinter [STAT:FE2A4802] and SoS_Seasonspatch_Solitude.esp SBluePalaceGateWinter [STAT:FE0F2812]>

The object report shows that SBluePalaceGateWinter from SoS_Seasonspatch_Solitude.esp xxyyy812 uses the full model meshes\architecture\solitude\sbluepalacegate.nif for LOD which is most likely not what you want.

I think this requires some explanation from my side. SoS_Seasonspatch_Solitude.esp is from the mod Simplicity of Seasons, which is an IMO broken mod which I have spent a lot of time in the last months to try to patch up. While working with that I decided to incorporate some of its features (with fixes) into a seasons mod for Vigilant, which I have published on Nexus with the mod name Seasons for Vigilant. As a workaround to avoid my mod to depend on Simplicity of Seasons, and while waiting for my bug fixes to get finished, I simply copied the relevant objects from Simplicity of Seasons to my mod (it should be fine according to the mod's permissions). That is the reason for the duplicate. But I am using FormIDs and not EditorIDs for seasonal swapping, so should it matter?

The full-model swap is likely from the mesh mask rules (the object in Simplicity of Seasons is using the same flags as the base object). I simply copied the rule from a similar line from RedBag's Solitude's custom rules (which I think are incorrectly configured, because that mod does not include any file called SBluePalaceGate.nif). But that should be same as for the non-formswapped object. The mesh mask rules only depend on the mesh, which is the same.

Also odd that the debug log seems to come from a different LOD generation. I noticed they have different timestamps, but it is the most recent debug log that I have. Perhaps the newer DynDOLOD generation did not produce any debug log, I don't know.

On 3/19/2024 at 12:08 AM, Jonado said:

Moreover, Mistveil Keep is not showing up on the map, and I have no idea what is causing it. It is getting level 4 and level 8 LOD, but not level 16 LOD. I am using Open Cities, but I don't know why that would matter. As far as I can tell, the generated DynDOLOD files are not touching the object, nor its worldspace references.

Regarding this issue, the reference form ID is 00080C57.

Edited March 24 by Jonado

[sheson]

38 minutes ago, Jonado said:

I think this requires some explanation from my side. SoS_Seasonspatch_Solitude.esp is from the mod Simplicity of Seasons, which is an IMO broken mod which I have spent a lot of time in the last months to try to patch up. While working with that I decided to incorporate some of its features (with fixes) into a seasons mod for Vigilant, which I have published on Nexus with the mod name Seasons for Vigilant. As a workaround to avoid my mod to depend on Simplicity of Seasons, and while waiting for my bug fixes to get finished, I simply copied the relevant objects from Simplicity of Seasons to my mod (it should be fine according to the mod's permissions). That is the reason for the duplicate. But I am using FormIDs and not EditorIDs for seasonal swapping, so should it matter?

The full-model swap is likely from the mesh mask rules (the object in Simplicity of Seasons is using the same flags as the base object). I simply copied the rule from a similar line from RedBag's Solitude's custom rules (which I think are incorrectly configured, because that mod does not include any file called SBluePalaceGate.nif). But that should be same as for the non-formswapped object. The mesh mask rules only depend on the mesh, which is the same.

Also odd that the debug log seems to come from a different LOD generation. I noticed they have different timestamps, but it is the most recent debug log that I have. Perhaps the newer DynDOLOD generation did not produce any debug log, I don't know.

Regarding this issue, the reference form ID is 00080C57.

I suggest to avoid having duplicate editor IDs in an load order for best compatibility, especially now with mods in the game and patchers making use of them to select records.

The debug log is saved and replaces the old debug log when the tool is shutting down. Let the tool close on its own, do not terminate it via X for example. Delete the log folder for a new session, so there are no write protected files or files in use preventing overwriting them.

In order to properly troubleshot the issue, provide updated log, debug log, object report all for the same LOD generation session.
Provide links to the mods where I can download them. send links to private mods/uploads via PM if needed.

Also upload ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_Tamriel.txt and LODGen_SSE_Export_Tamriel_WIN.txt

[Jonado]

Okay, if the issue persists after my next LOD generation, I will return to you then. Don't know when I will have time for it though.

[UomoBruco]

Hello,

I have two Skyrim installations, one in the Steam folder and one in a GameRoot folder inside my Mo2 folder. When running TexGen thru Mo2 it targeted the game in the steam folder, but I fixed the RegKey so now it targets the one in the Mo2 Folder. Now, the other files targeted by TexGen are in Appdata and MyGames, more precisely the temp and plugin list are in Appdata and the ini, custom ini and save paths are in Documents/My Games. Is this the right location TexGen should be targeting? Or should it target the files inside the Mo2 game directory? I'm sorry if this is a stupid question but I'm pretty new to modding and this got me pretty confused. Thank you.

Edited March 26 by UomoBruco

[sheson]

2 hours ago, UomoBruco said:

Hello,

I have two Skyrim installations, one in the Steam folder and one in a GameRoot folder inside my Mo2 folder. When running TexGen thru Mo2 it targeted the game in the steam folder, but I fixed the RegKey so now it targets the one in the Mo2 Folder. Now, the other files targeted by TexGen are in Appdata and MyGames, more precisely the temp and plugin list are in Appdata and the ini, custom ini and save paths are in Documents/My Games. Is this the right location TexGen should be targeting? Or should it target the files inside the Mo2 game directory? I'm sorry if this is a stupid question but I'm pretty new to modding and this got me pretty confused. Thank you.

You seem to have a question about how MO2 works. I suggest to read the MO2 documentation and to ask questions about it on the MO2 forum/discord.

By default the game and thus every tool made for it uses the the hard coded folders c:\Users\[username]\AppData\Local\Skyrim Special Edition\ and c:\Users\[Username]\Documents\My Games\Skyrim Special Edition\.

Typically MO2 virtually maps files from its folders to their default locations the game and thus any tools made for it uses.

https://dyndolod.info/Installation-Instructions
https://dyndolod.info/Messages/Windows-Registry-Key
https://dyndolod.info/Help/Command-Line-Argument

[PRieST]

Hey,

I don't know if this is an error done by DynDOLOD or a usererror of myself.
I installed Unique Wooden Bridges - Base Object Swapper recently. Because I wanted to reduce the plugin count on my side I merged everything into my own .esp plugin together with the corresponding swap file.
The mod is also shipping a LOD model for the bridge.

During the new generation of DynDOLOD I saw this message - which is also mentioned in the summary:

Warning: Textures do not match for "Bridge01:1": textures\architecture\farmhouse\stonewall01.dds in woodenbridge01.nif -> textures\architecture\farmhouse\woodwalkway01.dds in woodenbridge01_lod.nif for LittlePatchFixes.esp EastMarchBridge01 [STAT:68005DE7]

Full Model:
https://postimg.cc/BjDN32vM (textures\architecture\farmhouse\WoodWalkway01.dds / textures\architecture\farmhouse\WoodWalkway01_n.dds)
LOD Model:
https://postimg.cc/94hbQzRV (textures\architecture\farmhouse\WoodWalkway01.dds / textures\architecture\farmhouse\WoodWalkway01_n.dds)
In a corresponding .bto file:
https://postimg.cc/sB4cQy7W (textures\architecture\farmhouse\stonewall01.dds / textures\architecture\farmhouse\stonewall01_n.dds)

This is the corresponding record in xEdit:
https://postimg.cc/D4ryFCt7
Also not inside the DynDOLOD_SWAP.ini.

The only thing I can assume from this is, that the texture for the LOD model gets not applied correctly. Or do I have to set up a specific mesh mask rule for the wooden bridge?

Here are the logs:
Logs on MediaFire

Edited March 26 by PRieST

[sheson]

12 hours ago, PRieST said:

Hey,

I don't know if this is an error done by DynDOLOD or a usererror of myself.
I installed Unique Wooden Bridges - Base Object Swapper recently. Because I wanted to reduce the plugin count on my side I merged everything into my own .esp plugin together with the corresponding swap file.
The mod is also shipping a LOD model for the bridge.

During the new generation of DynDOLOD I saw this message - which is also mentioned in the summary:

Warning: Textures do not match for "Bridge01:1": textures\architecture\farmhouse\stonewall01.dds in woodenbridge01.nif -> textures\architecture\farmhouse\woodwalkway01.dds in woodenbridge01_lod.nif for LittlePatchFixes.esp EastMarchBridge01 [STAT:68005DE7]

Full Model:
https://postimg.cc/BjDN32vM (textures\architecture\farmhouse\WoodWalkway01.dds / textures\architecture\farmhouse\WoodWalkway01_n.dds)
LOD Model:
https://postimg.cc/94hbQzRV (textures\architecture\farmhouse\WoodWalkway01.dds / textures\architecture\farmhouse\WoodWalkway01_n.dds)
In a corresponding .bto file:
https://postimg.cc/sB4cQy7W (textures\architecture\farmhouse\stonewall01.dds / textures\architecture\farmhouse\stonewall01_n.dds)

This is the corresponding record in xEdit:
https://postimg.cc/D4ryFCt7
Also not inside the DynDOLOD_SWAP.ini.

The only thing I can assume from this is, that the texture for the LOD model gets not applied correctly. Or do I have to set up a specific mesh mask rule for the wooden bridge?

Here are the logs:
Logs on MediaFire

As you can see by the messages and when comparing the full model and the "LOD" model in NifSkope, the shape names do not match, thus causing the textures to not match.

The wooden pathway is "Bridge01:3" in the full model and "Bridge01:1" in the "LOD" model.
The wooden beams and railing is "Bridge:01:4" in the full model and "Bridge01:2" in the "LOD" model.
The shape names in the "LOD" model should match the names in the full models instead. That should address any wrong texture replacements.

The "LOD" model is not really an optimized/decimated LOD model. It would benefit already from its UVs being adjusted to be between 0.0 and 1.0.
The "LOD" model should be in ..\Data\Meshes\LOD\Bridge\ or ..\Data\Meshes\UniqueWoodenBridges\LOD\ or ..\Data\Meshes\UWB\LOD\ or something similar.

There seems to be a newer version of the mod that has the Radius 0.0 fixed which reported in your logs. See https://dyndolod.info/Messages/Radius-00.

[PRieST]

1 hour ago, sheson said:

As you can see by the messages and when comparing the full model and the "LOD" model in NifSkope, the shape names do not match, thus causing the textures to not match.

The wooden pathway is "Bridge01:3" in the full model and "Bridge01:1" in the "LOD" model.
The wooden beams and railing is "Bridge:01:4" in the full model and "Bridge01:2" in the "LOD" model.
The shape names in the "LOD" model should match the names in the full models instead. That should address any wrong texture replacements.

Oh, ok, it's because of the naming. Now that I know that...this should be something I need to consider for the other 'textures not match' messages :/

Quote

The "LOD" model is not really an optimized/decimated LOD model. It would benefit already from its UVs being adjusted to be between 0.0 and 1.0.
The "LOD" model should be in ..\Data\Meshes\LOD\Bridge\ or ..\Data\Meshes\UniqueWoodenBridges\LOD\ or ..\Data\Meshes\UWB\LOD\ or something similar.

There seems to be a newer version of the mod that has the Radius 0.0 fixed which reported in your logs. See https://dyndolod.info/Messages/Radius-00.

I'll see if I can even further decimate the model myself. But wouldn't this one not ok for level 1 and a more optimized version for level 2 - and if I am correct renaming the mesh to *_lod_1.nif and *_lod_2.nif would than apply it correspondingly?

I thought the new version only changed the NiTriShapes to BSTriShapes - will use the new version now.