DynDOLOD 3.00 Alpha 180

[StrayHALO_MAN]

18 hours ago, sheson said:

Moved to the DynDOLOD 3 Alpha thread.

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

Lookup the reference form id in xEdit to find out its editor id which shows the source for which the reference was added as explained at https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots.

The land and building should be two separate references and using two different LOD models. 

Thank you for the help, here is my log and updated screenshots:
https://mega.nz/file/8kZjVLpI#RXZPI7s0bP139Nv8uZzLKoZQg0DkkUy5J4mCtGTWT6Y

I also did disable+enable on the lod to show that it's still the same mesh and not landscape.
That large slab of LOD is actually sitting just under the landscape LOD.
I don't have any mods messing with Windhelm's geometry so if I could disable the child LOD being generated in the parent world that would be fine with me... Though it I guess that's only a band-aid fix.

Looking at this second image, the inn's LOD looks to be backwards, the long slab of LOD being the front area of Ulfric's castle.

Edited September 5, 2023 by StrayHALO_MAN

[Mousetick]

14 hours ago, sheson said:

Dynamic LOD is done for references with enable parent or initially disabled flag.

About initially disabled references: I'm assuming those that can have LOD receive dynamic LOD in case they might be enabled later by a Papyrus script. Is this correct?

As I mentioned, I don't seem to have any copies of such references in my DynDOLOD plugins, so I need to ask for confirmation: Is their child copy a clone of the parent reference, with the initially disabled flag carried over?

If this is correct, we have a problem, Houston

The Papyrus script which toggles the parent reference is oblivious to the existence of the child copy, so the child copy is going to remain perpetually disabled.

Possible solution: don't carry the initially disabled flag over to the child copy, add the parent reference as enable parent of the child copy. So the child copy automatically remains synchronized with the parent reference.

[sheson]

7 hours ago, StrayHALO_MAN said:

Thank you for the help, here is my log and updated screenshots:
https://mega.nz/file/8kZjVLpI#RXZPI7s0bP139Nv8uZzLKoZQg0DkkUy5J4mCtGTWT6Y

I also did disable+enable on the lod to show that it's still the same mesh and not landscape.
That large slab of LOD is actually sitting just under the landscape LOD.
I don't have any mods messing with Windhelm's geometry so if I could disable the child LOD being generated in the parent world that would be fine with me... Though it I guess that's only a band-aid fix.

Looking at this second image, the inn's LOD looks to be backwards, the long slab of LOD being the front area of Ulfric's castle.

Do not check "Prefer base record LOD assignments over rules" for now.

[Mousetick]

I've compiled a list of enable parent switches grouped by city and affected cells. Toggling a switch may enable or disable objects depending on opposite state. The list was based on Parent > Child copies generated with NoCellsWithNAVM=1 so is probably incomplete. Only vanilla references were considered.

I'm putting it here in case it might be of some use to you:

Spoiler

Markarth -37,4
- dunReachcliffExitMarker [REFR:000DE164]

Markarth -39,6
- DragonMoundReach01_Disable [REFR:000FDB1F]

Markarth -40,1
- CaravanMarkarthCampEnable [REFR:001030E2]

Markarth -39,0
- [REFR:00094BF4] (no Editor ID, CW Siege Imperial Camp)

Riften 35,-20
- DragonMoundFallForest02_Disable [REFR:000FDB31]

Riften 36,-24
Riften 36,-25
Riften 37,-23
Riften 37,-24
- TG02GoldenglowGuardsEnabler [REFR:000B6311]

Riften 39,-24
- TG07WreckEnabler [REFR:000C04C6]

Riften 42,-20
- CWRiftenImpCampEnabler [REFR:0008FA4B]

Riften 42,-21
Riften 42,-22
- CWRiftenAttDefEnabler [REFR:0008F99A]

Riften 41,-22
Riften 42,-22
- CaravanRiftenCampEnable [REFR:0010311B]

Riften 42,-29
- DragonMoundFallForest01_Disable [REFR:000FDAD8]

Riften 42,-31
- DragonLair07ClutterEnableMarker [REFR:0005EFC3]

Riften 44,-29
Riften 45,-28
- dunForelhostSonsEnable [REFR:00090F0A
- dunForelhostDisableMarker [REFR:0010F8D5]

Riften 46,-21
- DA06ExtClutterEnableMarker [REFR:000C216C]

Riften 46,-31
- dunPOIFallForestBurningHouseEnableParent [REFR:000CF36F]

Solitude -12,31
- SlighthouseFireOff [REFR:00062832]

Solitude -8,26
Solitude -9,26
- MS07IcerunnerEnableMarker [REFR:0004B55D]

Solitude -12,26
Solitude -13,26
- KatariahEnableMarker [REFR:0007265C]

Solitude -12,21
Solitude -13,21
Solitude -13,22
- dunFolgunthur_ExteriorResetEnableMarker [REFR:000860C2]

Solitude -17,24
Solitude -18,24
- CaravanSolitudeCampEnable [REFR:00104AD6]

Solitude -20,22
Solitude -20,23
Solitude -21,22
Solitude -21,23
- SolitudeSonsCampEnabler [REFR:00034899]

Solitude -23,21
- CWGarrisonEnableMarkerSonsCampHaafingar [REFR:00095777]

Solitude -20,19
- DragonMoundTundraMarsh02_Disable [REFR:000FDAD6]

Whiterun 12,-4
Whiterun 12,-5
- CWGarrisonEnableMarkerSonsCampWhiterun [REFR:00095872]

Whiterun 0,-4
- mq104FXDragonAttackEnablerRef [REFR:000D3FB3]

Whiteurn 5,-5
Whiterun 5,-6
Whiterun 6,-5
- CWSiegeAttackCampEnableMarkerSonsWhiterun [REFR:0008680C]

Whiterun 3,-3
- CaravanWhiterunCampEnable [REFR:0010372F]

Whiterun 4,-4
- CWWhiterunAttackSiegeEnabler [REFR:00045855]

Whiterun 4,-1
- CWWhiterunExtDisableOnly [REFR:000FC87D]

Whiterun 11,3
- DragonMoundTundra02_Disable [REFR:000FDB13]

Windhelm 26,12
Windhelm 27,12
Windhelm 27,13
- CWGarrisonEnableMarkerMonsterFortKastav [REFR:0005E8AC]

Windhelm 30,14
- dunStillbornBackEnableMarker [REFR:000D2001]

Windhelm 33,6
- CaravanWindhelmCampEnable [REFR:00103774]

Windhelm 35,13
- CWGarrisonEnableMarkerSonsCampWinterhold [REFR:00052948]
- dunPOICampWinterholdAltEnableMarker [REFR:0007F892]

Windhelm 35,16
- TG05CampEnableMarker [REFR:000644D8]

Windhelm 35,5
Windhelm 35,6
Windhelm 36,5
Windhelm 36,6
- dunWindhelmAttackStartPOIEnableMarker [REFR:0006AF52]
- [REFR:000BE270] (no Editor ID,  CW Siege Imperial Camp)

Now that the prep work is done, time to finally check things out in-game

[sheson]

4 hours ago, Mousetick said:

About initially disabled references: I'm assuming those that can have LOD receive dynamic LOD in case they might be enabled later by a Papyrus script. Is this correct?

As I mentioned, I don't seem to have any copies of such references in my DynDOLOD plugins, so I need to ask for confirmation: Is their child copy a clone of the parent reference, with the initially disabled flag carried over?

If this is correct, we have a problem, Houston

The Papyrus script which toggles the parent reference is oblivious to the existence of the child copy, so the child copy is going to remain perpetually disabled.

Possible solution: don't carry the initially disabled flag over to the child copy, add the parent reference as enable parent of the child copy. So the child copy automatically remains synchronized with the parent reference.

The references are not exact copies, scripts are removed for example. If the source reference has an enable parent, then the copy should already have it set.

An initially disabled reference without an enable parent that is copied would be 00062832. (Also 0005227F but it is ignored since it triggers large reference bugs. The harbor can typically not be seen from inside Windhelm anyways)

Enable parents need to be persistent. So one can not just blindly add the source references as enable parent without overwriting them and making them persistent - something to avoid at all cost This test version will set an enable parent to the source reference if it is initially disabled, persistent and does not have an enable parent.
https://mega.nz/file/IMowTbJK#30H0goSCiowS1jMqJYs_HaSe4rUu7lyG4m5GzEY8OtU

There are potentially more things (changing position, scale for example) that can happen to source references that are not covered. Those would be addressed if they actually happen / are reported.

[Mousetick]

1 hour ago, sheson said:

Enable parents need to be persistent. So one can not just blindly add the source references as enable parent without overwriting them and making them persistent - something to avoid at all cost

Yes, agreed. But I think it works out perfectly. A non-persistent reference used by a separate script is an anachronism. It's not safe. I believe CK enforces persistence of references used as script properties. If a mod uses a non-persistent reference in a script, that mod is already bugged, with or without DynDOLOD.

If there are non-persistent initially disabled references, it's probably because the mod author doesn't care or know about properly UDR'ing them, but they're actually never used/enabled by a script. In such a case, xEdit shows that the temporary reference is not referenced by anything else. In which case, they don't really need dynamic LOD.

--

I noticed I had some dynamic Parent > Child copies in Whiterunworld cell 4,-1 even though it is navmeshed. Then I noticed that NoCellsWithNAVM=0 in DynDOLOD_SSE_childworld_WhiterunWorld.ini. It's completely fine, I just want to confirm this is intended, as all other cities have NoCellsWithNAVM=1.

Thanks.

[sheson]

5 minutes ago, Mousetick said:

Yes, agreed. But I think it works out perfectly. A non-persistent reference used by a separate script is an anachronism. It's not safe. I believe CK enforces persistence of references used as script properties. If a mod uses a non-persistent reference in a script, that mod is already bugged, with or without DynDOLOD.

If there are non-persistent initially disabled references, it's probably because the mod author doesn't care or know about properly UDR'ing them, but they're actually never used/enabled by a script. In such a case, xEdit shows that the temporary reference is not referenced by anything else. In which case, they don't really need dynamic LOD.

--

I noticed I had some dynamic Parent > Child copies in Whiterunworld cell 4,-1 even though it is navmeshed. Then I noticed that NoCellsWithNAVM=0 in DynDOLOD_SSE_childworld_WhiterunWorld.ini. It's completely fine, I just want to confirm this is intended, as all other cities have NoCellsWithNAVM=1.

Thanks.

It is intended because the cell/area right outside the maingate would otherwise not have copies for the drawbridge etc.

[redshift87]

Hey there! I got the exact same Invalid Argument error on an Immersive College of Winterhold cell that JakoJako had a few pages back. I'm on the most recent alpha and resources version, have tried a few times now and always get the error. Attaching my log and debug file (did not see a bug report file):

https://www.dropbox.com/scl/fi/0ntgiat8csv9y09tqxwto/logs.7z?rlkey=yd7uxsi3rmb0x49whd9mjixcc&dl=0

[ccaacc]

[sheson]

1 hour ago, redshift87 said:

Hey there! I got the exact same Invalid Argument error on an Immersive College of Winterhold cell that JakoJako had a few pages back. I'm on the most recent alpha and resources version, have tried a few times now and always get the error. Attaching my log and debug file (did not see a bug report file):

https://www.dropbox.com/scl/fi/0ntgiat8csv9y09tqxwto/logs.7z?rlkey=yd7uxsi3rmb0x49whd9mjixcc&dl=0

Your DynDOLOD log show two generations. The first one worked. Can you tell what changed? They seem to have the same exact same plugin list and order.

Does it work with this test version? https://mega.nz/file/VYhQ3SqQ#wLIhiHVcYxN_m8Rw0xmBAAidLG0TlIJXLKl4fV4-pFQ
If not upload new log and debug please

[sheson]

1 hour ago, ccaacc said:

Moved from the xLODGen thread to the DynDOLOD 3 Alpha thread, assuming that you are using it.

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

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

[redshift87]

1 hour ago, sheson said:

Your DynDOLOD log show two generations. The first one worked. Can you tell what changed? They seem to have the same exact same plugin list and order.

Does it work with this test version? https://mega.nz/file/VYhQ3SqQ#wLIhiHVcYxN_m8Rw0xmBAAidLG0TlIJXLKl4fV4-pFQ
If not upload new log and debug please

After the very first run, I added my personal custom rules (mostly for mods that don't have LOD objects like Eli's Skaal Village and to remove LOD for a few plants I don't care to see). I'll include my preset file that has those custom rules just in case it's helpful. I have been using those same rules for quite awhile now.

Tried again with the new .exe you provided and got a range check error this time. Oddly, my log file did not update but debug file did:

https://www.dropbox.com/scl/fi/xq3q5yjfop0ms7shsb5ob/logs2.7z?rlkey=o3rrmoxduds0z3tmc9nv2g9vg&dl=0

[Mousetick]

DynDOLOD 3a143 Test version for Parent > Child copies of references with dynamic LOD

I've completed my testing. Here's an updated checklist with some corrections to markers I got wrong the first time, and my annotations on the results:

Spoiler

Markarth -37,4
- dunReachcliffExitMarker [REFR:000DE164]
>> Hidden by mountains

Markarth -39,6
- DragonMoundReach01_Disable [REFR:000FDB1F]
>> Hidden by mountains

Markarth -40,1
- CaravanMarkarthCampEnable [REFR:001030E2]
>> Hidden by mountains/terrain

Markarth -39,0
- [REFR:00094BF4] (no Editor ID, CW Siege Imperial Camp)
>> OK, too far, only dynamic LOD visible

Riften 35,-20
- DragonMoundFallForest02Marker [REFR:000FDB32]
>> Too far, hidden by terrain

Riften 36,-24
Riften 36,-25
Riften 37,-23
Riften 37,-24
- TG02GoldenglowGuardsEnabler [REFR:000B6311]
*** Can't see anything among all the trees

Riften 39,-24
- TG07WreckEnabler [REFR:000C04C6]
>> Not visible, stuff is underwater I think

Riften 42,-20
- CWRiftenImpCampEnabler [REFR:0008FA4B]
>> Hidden behind terrain/landscape

Riften 42,-21
Riften 42,-22
- CWRiftenAttDefEnabler [REFR:0008F99A]
>> OK

Riften 41,-22
Riften 42,-22
- CaravanRiftenCampEnable [REFR:0010311B]
>> OK

Riften 42,-29
- DragonMoundFallForest01_Disable [REFR:000FDAD8]
>> Hidden behind mountains

Riften 42,-31
- DragonLair07ClutterEnableMarker [REFR:0005EFC3]
>> Too far, hidden behind mountains/trees

Riften 44,-29
Riften 45,-28
- dunForelhostSonsEnable [REFR:00090F0A
- dunForelhostDisableMarker [REFR:0010F8D5]
>> Hidden behind mountains

Riften 46,-21
- DA06ExtClutterEnableMarker [REFR:000C216C]
>> Hidden below terrain

Riften 46,-31
- dunPOIFallForestBurningHouseEnableParent [REFR:000CF36F]
>> Too far, hidden behind mountains

Solitude -12,31
- SlighthouseFireOff [REFR:00062832]
>> Doesn't work

Solitude -8,26
Solitude -9,26
- MS07IcerunnerEnableMarker [REFR:0004B55D]
>> OK

Solitude -12,26
Solitude -13,26
- KatariahEnableMarker [REFR:0007265C]
>> OK

Solitude -12,21
Solitude -13,21
Solitude -13,22
- dunFolgunthur_ExteriorResetEnableMarker [REFR:000860C2]
*** Doesn't seem to ever be used in-game (i.e. everything always enabled)
>> OK

Solitude -17,24
Solitude -18,24
- CaravanSolitudeCampEnable [REFR:00104AD6]
>> OK

Solitude -20,22
Solitude -20,23
Solitude -21,22
Solitude -21,23
- SolitudeSonsCampEnabler [REFR:00034899]
>> Too far and hidden by trees/landscape

Solitude -23,21
- CWGarrisonEnableMarkerSonsCampHaafingar [REFR:00095777]
>> Too far hidden by terrain

Solitude -20,19
- DragonMoundTundraMarsh02Marker [REFR:000FDAD4]
>> Too far hidden by trees

Whiterun 12,-4
Whiterun 12,-5
- CWGarrisonEnableMarkerSonsCampWhiterun [REFR:00095872]
>> Too far hidden by mountains

Whiterun 0,-4
- mq104FXDragonAttackEnablerRef [REFR:000D3FB3]
>> Too far, can only see dynamic LOD
*** Unable to really test due to mod putting walls in front of fire

Whiterun 5,-5
Whiterun 5,-6
Whiterun 6,-5
- CWSiegeAttackCampEnableMarkerSonsWhiterun [REFR:0008680C]
>> OK

Whiterun 3,-3
- CaravanWhiterunCampEnable [REFR:0010372F]
>> OK

Whiterun 4,-4
- CWWhiterunAttackSiegeEnabler [REFR:00045855]
>> OK

Whiterun 4,-1
- CWWhiterunExtDisableOnly [REFR:000FC87D]
>> OK

Whiterun 11,3
- DragonMoundTundra02Marker [REFR:000FDB11]
>> Can only see dynamic LOD from Dragonsreach Porch
>> Have to exit/reenter Dragonsreach Porch to see dynamic LOD changes after toggling marker

Windhelm 26,12
Windhelm 27,12
Windhelm 27,13
- CWGarrisonEnableMarkerMonsterFortKastav [REFR:0005E8AC]
>> Hidden behind mountains

Windhelm 30,14
- dunStillbornBackEnableMarker [REFR:000D2001]
>> Hidden behind mountains

Windhelm 33,6
- CaravanWindhelmCampEnable [REFR:00103774]
>> OK

Windhelm 35,13
- CWGarrisonEnableMarkerSonsCampWinterhold [REFR:00052948]
- dunPOICampWinterholdAltEnableMarker [REFR:0007F892]
>> Could not test, view messed up by occlusion planes

Windhelm 35,16
- TG05CampEnableMarker [REFR:000644D8]
>> Too far, hidden by terrain

Windhelm 35,5
Windhelm 35,6
Windhelm 36,5
Windhelm 36,6
- [REFR:000BE270] (no Editor ID,  CW Siege Imperial Camp)
>> OK, too far, dynamic LOD visible only, barely due to terrain

Remarks:

• I had to disable collision to climb above walls or buildings for most of the verifications but always stayed within the city bounds.
• For Markarth, it appears Parent > Child copies of dynamic references were made even though ScanParent=0 in DynDOLOD_SSE_childworld_MarkarthWorld.ini. This allowed me to test them, but the fact they were made seems like a bug?
• Beside checking the references with enable parent above, I looked around the periphery of cities and everything looked OK. I didn't find anything visually broken.
• I think I'm going to switch to NoCellsWithNAVM=0 for Riften next time, to get more trees directly behind the walls and fix the view towards the docks from the canal.
• I found a small issue with a Cutting Room Floor house copy (object LOD, not dynamic LOD) in Whiterun but I need to investigate more before I can report the problem.

Next steps:

• I'm going to regenerate the plugins with the update you uploaded this morning, and take a look at the initially disabled references.

[sheson]

4 hours ago, Mousetick said:

• For Markarth, it appears Parent > Child copies of dynamic references were made even though ScanParent=0 in DynDOLOD_SSE_childworld_MarkarthWorld.ini. This allowed me to test them, but the fact they were made seems like a bug?

Upload the log and debug log to properly report the supposed bug.

[Mousetick]

6 hours ago, sheson said:

Upload the log and debug log to properly report the supposed bug.

Over there: https://drive.google.com/file/d/1HBzSJ56QkptARN150kduGita9awnWx77/view

Attempting to run the latest test version uploaded to Mega produces a Range Check exception. Logs: https://drive.google.com/file/d/1TeIv02YR4GZGDV1uydPJL2d_03fuvRYZ/view