DynDOLOD 3.00 Alpha 198

[Blackread]

1 hour ago, Mousetick said:

It may not be visible at a glance but a potential adverse side effect is that of breaking NPC pathing. If you blindly copy an object, e.g. a rock, from the parent worldspace's cell into the child, and it ends up in the middle of the navmesh, NPCs may get stuck on it.

Which is why NoCellsWithNAVM=1 by default for safety, I'm guessing, as there is no way to predict whether or how the copied object will conflict with the existing navmesh.

That is true, but I checked pretty much the whole of Riften and couldn't find any rogue objects anywhere.

[Mousetick]

2 hours ago, Blackread said:

That is true, but I checked pretty much the whole of Riften and couldn't find any rogue objects anywhere.

Sure. I wasn't questioning your observations They're valid for your specific load order.

I don't think they can be generalized to any arbitrary load order. So the safe default NoCellsWithNAVM=1 is justified in the absence of custom, load order-specific DynDOLOD_[GAME MODE]_childworld_[WORLDSPACE].ini configuration. It's also a shorthand to limit copying references to cells outside the city walls only (which typically don't have navmeshes in the child worldspace). Blindly copying stuff from the parent worldspace to child cells (wholly or partially) inside the city walls is more likely to produce "rogue" objects inside the walls, as demonstrated by your Solitude example.

Copying is done on an entire cell basis but city walls are not aligned on cell boundaries. Ideally and hypothetically, if only parent worldspace's references placed outside the walls were copied, while the parent areas inside the walls were ignored, this could prevent visually "rogue" objects and navmesh interferences.

It's probably simpler and more efficient to manually fix individual mods than trying to find a generic solution.

[Blackread]

30 minutes ago, Mousetick said:

Sure. I wasn't questioning your observations They're valid for your specific load order.

I don't think they can be generalized to any arbitrary load order. So the safe default NoCellsWithNAVM=1 is justified in the absence of custom, load order-specific DynDOLOD_[GAME MODE]_childworld_[WORLDSPACE].ini configuration. It's also a shorthand to limit copying references to cells outside the city walls only (which typically don't have navmeshes in the child worldspace). Blindly copying stuff from the parent worldspace to child cells (wholly or partially) inside the city walls is more likely to produce "rogue" objects inside the walls, as demonstrated by your Solitude example.

Copying is done on an entire cell basis but city walls are not aligned on cell boundaries. Ideally and hypothetically, if only parent worldspace's references placed outside the walls were copied, while the parent areas inside the walls were ignored, this could prevent visually "rogue" objects and navmesh interferences.

It's probably simpler and more efficient to manually fix individual mods than trying to find a generic solution.

Very true, and I have barely any mods modifying the exterior areas of cities, with Solitude being the exception, so my load order is fairly easy on that regard.

[Blackread]

I noticed that some dock corner pieces are rotated 90 degrees clockwise in the LOD, despite the lod and full model meshes being perfectly aligned. Here are pictures of one example:

Caption for the pictures in their order of appearance:
1. The dock copy as seen in the child worldspace (SolitudeWorld)
2. The dock LOD as seen in the child worldspace
3. The original dock as seen in the parent worldspace (Tamriel)
4. The dock LOD as seen in the parent worldspace

EDID of the dock copy: skyrimesm_01991F_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD

Logs: https://mega.nz/file/8adAyAyb#MD_N7VeQYpMyLxIRf2nGm5IlU-2YVMgbRBro4r2kWY4

The full model dock is from Static Mesh Improvement Mod, and the LOD model is from DynDOLOD Resources SE.

Edited August 17, 2023 by Blackread

[ks182]

hello, I use DLL NG Alpha-9, every time I load a save in the upper left corner I get notifications "DynDOLOD" and "DynDOLOD successfully initialized". not just once, but constantly, at each boot. is it possible to disable this somehow?

[sheson]

19 hours ago, Blackread said:

Update:

I tried hiding the landscape as you suggested, but force hiding the quads made no difference in the xLODGen terrain LOD output. I instead made a plugin with which I dug a "hole" (or a valley) into the hill where the mine entrance is, that got rid of the terrain LOD in the tunnel, and the underside too.

I am going to answer to each thing in a separate posts. If there is something I haven'r replied to in say a week (and it is still present after any updates that I might release in the meantime) feel free to post a reminder for that particular issue.

So far the hide quad flag was only used for terrain under side generation. Get xLODGen beta 99 that now has a corresponding check box for LOD level 4.
Unless the hidden quads are properly covered by LOD objects, the holes might become very visible. That is probably one of the reassons CK doesn't do it for terrain LOD generation.
Hence disabled by default. If you know the exact filename of the terrain LOD mesh, just use Specific Chunk: 4, -44, 0 for example.

[z929669]

29 minutes ago, ks182 said:

 

hello, I use DLL NG Alpha-9, every time I load a save in the upper left corner I get notifications "DynDOLOD" and "DynDOLOD successfully initialized". not just once, but constantly, at each boot. is it possible to disable this somehow?

Please see this post for a direct answer to your question (Click the first link at top to access the post with your answer. The second link below that points to the latest post, which is not what you want):

The gist is that 'yes' this message is expected behavior, as DynDOLOD DLL NG and DynDOLOD 3 itself are still in 'alpha' release versioning, which means that testing/validation is favored over UX.

[sheson]

30 minutes ago, ks182 said:

hello, I use DLL NG Alpha-9, every time I load a save in the upper left corner I get notifications "DynDOLOD" and "DynDOLOD successfully initialized". not just once, but constantly, at each boot. is it possible to disable this somehow?

Get DynDOLOD DLL NG and Scripts 3.0 Alpha-10

[ks182]

27 minutes ago, sheson said:

Get DynDOLOD DLL NG and Scripts 3.0 Alpha-10

Thank you very much)

[sheson]

2 hours ago, Blackread said:

I noticed that some dock corner pieces are rotated 90 degrees clockwise in the LOD, despite the lod and full model meshes being perfectly aligned. Here are pictures of one example:

Caption for the pictures in their order of appearance:
1. The dock copy as seen in the child worldspace (SolitudeWorld)
2. The dock LOD as seen in the child worldspace
3. The original dock as seen in the parent worldspace (Tamriel)
4. The dock LOD as seen in the parent worldspace

EDID of the dock copy: skyrimesm_01991F_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD

Logs: https://mega.nz/file/8adAyAyb#MD_N7VeQYpMyLxIRf2nGm5IlU-2YVMgbRBro4r2kWY4

The full model dock is from Static Mesh Improvement Mod, and the LOD model is from DynDOLOD Resources SE.

Will be fixed next alpha version of DynDOLOD Resources.

[Mousetick]

About https://dyndolod.info/Help/Child-Parent-Worldspace-Copies

Quote

Specific Reference Matching

If the same reference is listed for both, it means it does not have a match in the other worldspace but should also be ignored for copying.

In case a mod requires manual additions to specifically match references or to ignore them for copying, make a post on the official DynDOLOD support forum so the data can be added for all users in a future update.

• Does this mean ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_[GAME MODE]_ChildworldMatches.txt is off-limit to end-users?
• How should an end-user proceed to exclude specific references from copying without requesting an official update, which may not be applicable to all users?

Thank you.

[sheson]

30 minutes ago, Mousetick said:

About https://dyndolod.info/Help/Child-Parent-Worldspace-Copies

• Does this mean ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_[GAME MODE]_ChildworldMatches.txt is off-limit to end-users?
• How should an end-user proceed to exclude specific references from copying without requesting an official update, which may not be applicable to all users?

Thank you.

Users who do not want to edit the configuration file themselves can post on the official DynDOLOD support forum with logs and useful screenshots, thus help improve the tools for everyone and themselves with the next update.

Users who can edit the configuration file with the help of the explanations can at the same time post the edits to the official DynDOLOD support forum to help improve the tools for everyone without having to wait for the update to be released. Once they install the new version, the changes are included and they won't have to remember to edit the configuration file again.

[Blackread]

3 hours ago, sheson said:

I am going to answer to each thing in a separate posts. If there is something I haven'r replied to in say a week (and it is still present after any updates that I might release in the meantime) feel free to post a reminder for that particular issue.

So far the hide quad flag was only used for terrain under side generation. Get xLODGen beta 99 that now has a corresponding check box for LOD level 4.
Unless the hidden quads are properly covered by LOD objects, the holes might become very visible. That is probably one of the reassons CK doesn't do it for terrain LOD generation.
Hence disabled by default. If you know the exact filename of the terrain LOD mesh, just use Specific Chunk: 4, -44, 0 for example.

Thank you I got the terrain LOD to work now. However, the underside is still in the way. For some reason it looks like I'm getting a hole in the cell -43, -1 where I hid quads 3 and 4, but not in the cell -43, 0 where I hid quads 1,2,3 and 4.

First picture is from inside the mine tunnel, looking towards Markarth. The last picture is from under the terrain. The black tube is the mine tunnel, which pierces the underside. The gap in the underside is visible above it.

Logs and the plugin I used to hide the terrain. It was placed dead last in my load order while generating, so shouldn't be overwritten by anything. https://mega.nz/file/RG1mAbKC#4dlXjUlkrZkNXjB_JcCYHyl3sF8TO3-MkbMMJBKOvzE

[sheson]

2 minutes ago, Blackread said:

Thank you I got the terrain LOD to work now. However, the underside is still in the way. For some reason it looks like I'm getting a hole in the cell -43, -1 where I hid quads 3 and 4, but not in the cell -43, 0 where I hid quads 1,2,3 and 4.

First picture is from inside the mine tunnel, looking towards Markarth. The last picture is from under the terrain. The black tube is the mine tunnel, which pierces the underside. The gap in the underside is visible above it.

Logs and the plugin I used to hide the terrain. It was placed dead last in my load order while generating, so shouldn't be overwritten by anything. https://mega.nz/file/RG1mAbKC#4dlXjUlkrZkNXjB_JcCYHyl3sF8TO3-MkbMMJBKOvzE

Upload the terrain BTR and the underside NIF.

[teadude]

Hi. i get this error when i am trying to update my occlusion.esp through dyndolod.

[Window Title]
DynDOLOD

[Main Instruction]
Error: Duplicate editor ID in DynDOLOD.esm [CELL:15025E93] (in WindhelmWorld "Windhelm" [WRLD:0001691D] at 26,7) and DynDOLOD.esm [CELL:15025A57] (in WhiterunWorld "Whiterun" [WRLD:0001A26F] at 8,-6)

[Content]

Click on this link for additional explanations and help for this message

For qualified help and advice or to report a problem make a post on the official DynDOLOD support forum.

[Exit DynDOLOD]

[Footer]
Online Help | Support Forum | Copy message to clipboard

 

these were the only logs that were generated

Logs.zip