DynDOLOD 3.00 Alpha 173

[sheson]

17 minutes ago, imnotfamous said:

Thanks Sheson for the fast answer. I add LockTexconv=1 and unselected the Fake lights child world option, and it works now. 
I think it could have been a light issue as I use the recent Light Limit Fix mod with its candle glow fake texture, and with LLF Particle Lights instead of Fake Glow mod as well. Not sure how this will be compatible with the Fake lights child world option. Or maybe it's just the LockTexconv that has resolve the issue. Thanks anyway. 
Keep the good work.
Best Regards.

PS: I don't get it about the allegory, maybe something related to dragonborn  Anyway, your choice, just I'm probably not only to not get it. 

The fake light child world option is entirely unrelated to generating textures or Texconv.

As explained at https://dyndolod.info/Help/Glow-LOD#Fake-Lights, the fake light option adds dynamic LOD references at the same position where there are reference with LIGH base records that match a certain criteria. The only incompatibility is things not matching well visually.

[Mousetick]

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

Preliminary test results with Icerunner in Solitude: Before > After 👍

I'm trying to take a systemic approach to testing rather than wandering around haphazardly and visually checking stuff:

• I loaded the DynDOLOD plugins in xEdit and applied a filter by references with EDID containing "DYNDOLOD_PARENT".
• Then I applied a custom script to list all records that have an Enable Parent.

Notes:

• My cities are vanilla with minor changes, mostly various small fixes.
• I always use the default NoCellsWithNAVM=1.

Results:

• A total of 993 references were copied, which is a pretty high number, but not too bad.
• Most of the copied references are vanilla stuff for Civil War sieges, and Khajiit Caravans.
• The rest of the copied references are from mods which in my case are not at all close to the cities, the changes are at least 3 or 4 cells away from the city walls. Such as Goldenglow Estate in Riften, or the Western Watchtower in Whiterun, or a buildable house on the road up to Riverwood, at the foot of the mountains.

Next Steps:

• It should be fairly easy to check the Khajiit Caravans when they're in town, so I'm going to do that.
• As for the Civil War siege stuff, I think each city is controlled by its own enable parent common to all the changes, more or less - I hope - so I should be able to toggle them and check them out.
• In order to save time, I don't think it's worth checking the copies that are far away from the walls. It may be important for players who fly/glide, but I don't. Even if I did, it doesn't make sense to me to fly out of cities. Once the player reaches the border of the child worldspace, there is nowhere else to go.

Questions:

• Are there other types of references beside Enable Parent that have dynamic LOD and that I should look for copies in DynDOLOD plugins?
• Any thoughts, comments, advice?

Thanks.

Full logs here if you'd like to take a look: https://drive.google.com/file/d/1HBzSJ56QkptARN150kduGita9awnWx77/view

[sheson]

21 minutes ago, Mousetick said:

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

Preliminary test results with Icerunner in Solitude: Before > After 👍

I'm trying to take a systemic approach to testing rather than wandering around haphazardly and visually checking stuff:

• I loaded the DynDOLOD plugins in xEdit and applied a filter by references with EDID containing "DYNDOLOD_PARENT".
• Then I applied a custom script to list all records that have an Enable Parent.

Notes:

• My cities are vanilla with minor changes, mostly various small fixes.
• I always use the default NoCellsWithNAVM=1.

Results:

• A total of 993 references were copied, which is a pretty high number, but not too bad.
• Most of the copied references are vanilla stuff for Civil War sieges, and Khajiit Caravans.
• The rest of the copied references are from mods which in my case are not at all close to the cities, the changes are at least 3 or 4 cells away from the city walls. Such as Goldenglow Estate in Riften, or the Western Watchtower in Whiterun, or a buildable house on the road up to Riverwood, at the foot of the mountains.

Next Steps:

• It should be fairly easy to check the Khajiit Caravans when they're in town, so I'm going to do that.
• As for the Civil War siege stuff, I think each city is controlled by its own enable parent common to all the changes, more or less - I hope - so I should be able to toggle them and check them out.
• In order to save time, I don't think it's worth checking the copies that are far away from the walls. It may be important for players who fly/glide, but I don't. Even if I did, it doesn't make sense to me to fly out of cities. Once the player reaches the border of the child worldspace, there is nowhere else to go.

Questions:

• Are there other types of references beside Enable Parent that have dynamic LOD and that I should look for copies in DynDOLOD plugins?
• Any thoughts, comments, advice?

Thanks.

Full logs here if you'd like to take a look: https://drive.google.com/file/d/1HBzSJ56QkptARN150kduGita9awnWx77/view

The covered area is the bounding box of cells with navmehes +- (uLargeRefLODGridSize/2)+1  or (uGridsToLoad/2)+1 

Dynamic LOD is done for references with enable parent or initially disabled flag. Also for animated models based on mesh mask or reference rules or via dynamic LOD asset filename matching, in this case waterfalls.

I am rather testing visually with mods that I know add stuff around towns that have enable parents, like LOTD. I am testing with NoCellsWithNAVM=0 to make sure fires/glows for example do not get duplicated.

[Mousetick]

I don't know what happened but the first post of this topic, authored by sheson and containing important README and BEFORE YOU POST type of information, has disappeared. Now there is an old 2019 post from user 'Caaros'.

Latest Wayback Machine capture: https://web.archive.org/web/20230530205331/https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-128/

[sheson]

35 minutes ago, Mousetick said:

I don't know what happened but the first post of this topic, authored by sheson and containing important README and BEFORE YOU POST type of information, has disappeared. Now there is an old 2019 post from user 'Caaros'.

Latest Wayback Machine capture: https://web.archive.org/web/20230530205331/https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-128/

That post got accidentally merged into this thread. I am hoping z929669 can fix it. I only know of a time consuming way.

[Mousetick]

2 hours ago, sheson said:

The covered area is the bounding box of cells with navmehes +- (uLargeRefLODGridSize/2)+1  or (uGridsToLoad/2)+1 

Sorry, I don't understand. Would you mind clarifying what covered area is referring to?

Let's say I'm standing on a city wall or atop a building at the edge of the city and looking at the surroundings. If the dynamic reference copy is outside the active cells grid, I'm not going to see its full model, I'm going to see its dynamic LOD instead. Unless the reference is a large reference. So it seems like a waste of time to visually check these dynamic reference copies that are too far from the cells containing the city limits.

2 hours ago, sheson said:

Dynamic LOD is done for references with enable parent or initially disabled flag. Also for animated models based on mesh mask or reference rules or via dynamic LOD asset filename matching, in this case waterfalls.

Ok. Animated models would be things like windmills I assume. I reran my filters to include initially disabled flag and that didn't change the results, in my case.

The reason I'm filtering to get the list of enable parent or initially disabled reference copies is so that I can identify which ones are dynamic, where they are, and how they are enabled. If I'm peaking over a city wall, and everything is looking fine because all the dynamic references are disabled and therefore not visible, it's not going to be a very good test, is it?  Like the Civil War stuff, it's always disabled except during sieges.

On second thought, the number of added dynamic reference copies is not a big deal in regards to performance, as most of them, at least in vanilla, are disabled most of the time.

Thanks for your input.

[sheson]

25 minutes ago, Mousetick said:

Sorry, I don't understand. Would you mind clarifying what covered area is referring to?

Let's say I'm standing on a city wall or atop a building at the edge of the city and looking at the surroundings. If the dynamic reference copy is outside the active cells grid, I'm not going to see its full model, I'm going to see its dynamic LOD instead. Unless the reference is a large reference. So it seems like a waste of time to visually check these dynamic reference copies that are too far from the cells containing the city limits.

Ok. Animated models would be things like windmills I assume. I reran my filters to include initially disabled flag and that didn't change the results, in my case.

The reason I'm filtering to get the list of enable parent or initially disabled reference copies is so that I can identify which ones are dynamic, where they are, and how they are enabled. If I'm peaking over a city wall, and everything is looking fine because all the dynamic references are disabled and therefore not visible, it's not going to be a very good test, is it?  Like the Civil War stuff, it's always disabled except during sieges.

On second thought, the number of added dynamic reference copies is not a big deal in regards to performance, as most of them, at least in vanilla, are disabled most of the time.

Thanks for your input.

I only explained how the size of the area around a city into which references are copied is determined. You seemed to wonder why things 3 or 4 cells away are being copied. Large references at 11 means 6 cells from the outer cells with navmeshes. This is unrelated to how you test.

Windmill fans happen to be an example of references that are not copied, because the dynamic LOD uses the full model and stays enabled also when active cells attach for continues animation.

[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