DynDOLOD 3.00 Alpha 190

[Mousetick]

  On 9/6/2023 at 10:04 AM, 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

Expand  

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]

  On 9/6/2023 at 12:12 PM, 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.

Expand  

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]

  On 9/6/2023 at 1:18 PM, 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

Expand  

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]

  On 9/6/2023 at 1:54 PM, ccaacc said:

Expand  

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]

  On 9/6/2023 at 2:38 PM, 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

Expand  

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:

  Reveal hidden contents

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]

  On 9/6/2023 at 4:49 PM, 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?

Expand  

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

[Mousetick]

  On 9/6/2023 at 8:50 PM, sheson said:

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

Expand  

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

[Mousetick]

  On 9/6/2023 at 4:49 PM, Mousetick said:

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

Expand  

So it's not really a DynDOLOD problem:

• The house in question is located in Whiterun exterior (Tamriel).
• It uses WRHouseWind01 [STAT:0003CDE3] as the base model, and WRDragonDoor01 [DOOR:000252C7] for its door. Both of which are normally found only inside Whiterun.
• WRHouseWind01 [STAT:0003CDE3] has LOD but WRDragonDoor01 [DOOR:000252C7] doesn't.
• So Parent > Child results in the house being copied to WhiterunWorld, but not the door.

I guess one solution could be: Add a rule to give LOD to WRDragonDoor01 [DOOR:000252C7] but I'm worried the door LOD could clash with DynDOLOD Resources' LOD model for WRHouseWind01 [STAT:0003CDE3], which already has the door built-in.

 

wrhousewind01_lod_0.nif

[sheson]

  On 9/6/2023 at 4:08 PM, redshift87 said:

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

Expand  

Check if this test version runs through https://mega.nz/file/VI5TVDCS#r8EsTQqlIQ_8_3O5XdTrpv2lYbiOnBdD2tBINSEKfT4
If not upload new log, debug log and bugreport.txt  if it exists.

[sheson]

  On 9/7/2023 at 3:15 AM, Mousetick said:

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

Expand  

This test version should fix scanning Markarth with ScanParent=0 https://mega.nz/file/VI5TVDCS#r8EsTQqlIQ_8_3O5XdTrpv2lYbiOnBdD2tBINSEKfT4

Is the range error 100% repeatable?

[redshift87]

  On 9/7/2023 at 3:08 PM, sheson said:

Check if this test version runs through https://mega.nz/file/VI5TVDCS#r8EsTQqlIQ_8_3O5XdTrpv2lYbiOnBdD2tBINSEKfT4
If not upload new log, debug log and bugreport.txt  if it exists.

Expand  

That fixed it for me, thank you sheson! Run completed successfully this time, and everything I checked in-game looked great too.

[Mousetick]

  On 9/7/2023 at 3:16 PM, sheson said:

This test version should fix scanning Markarth with ScanParent=0 https://mega.nz/file/VI5TVDCS#r8EsTQqlIQ_8_3O5XdTrpv2lYbiOnBdD2tBINSEKfT4

Is the range error 100% repeatable?

Expand  

I only tried once. The new version ran successfully to completion. Thanks.