DynDOLOD 3.00 Alpha 182

[DoubleYou]

Type the following into the in game console and report the result. @mooit

getini "uLockedObjectLOD:MapMenu"

I have seen cases where this ini setting can block lod from loading if set wrong for the given lod setup. If the result is 32, ensure that you set up DynDOLOD to generate level 32.

[Glanzer]

6 hours ago, Glanzer said:

I uploaded all of those, the link is in my message. EDIT: oh just saw your 2nd message. I'll try that. Yes I've been using expert mode to just run execute lodgen for just that worldspace to save time.

Ran the LODGen using LODGenx64.exe instead of LODGenx64Win.exe and it failed again. The logs all look the same, but the event log entry is slightly different:

Spoiler

 

Application: LODGenx64.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.NullReferenceException
   at LODGenerator.NifMain.BSSubIndexTriShape.SetSegments(System.Collections.Generic.List`1<LODGenerator.SegmentDesc>, Int32)
   at LODGenerator.LODApp.CreateLODNodesSSE(LODGenerator.NiFile, LODGenerator.NifMain.NiNode, LODGenerator.QuadDesc, System.Collections.Generic.List`1<LODGenerator.ShapeDesc>)
   at LODGenerator.LODApp.DoLOD(LODGenerator.QuadDesc, Boolean)
   at LODGenerator.LODApp+<>c__DisplayClass81_2.<GenerateLOD>b__0()
   at System.Threading.Tasks.Task.Execute()

Exception Info: System.AggregateException
   at System.Threading.Tasks.Task.WaitAll(System.Threading.Tasks.Task[], Int32, System.Threading.CancellationToken)
   at LODGenerator.LODApp.GenerateLOD(System.Collections.Generic.List`1<LODGenerator.StaticDesc>)
   at LODGeneratorCMD.Program.Main(System.String[])

 

 

 

[mooit]

1 hour ago, DoubleYou said:

Type the following into the in game console and report the result. @mooit

getini "uLockedObjectLOD:MapMenu"

I have seen cases where this ini setting can block lod from loading if set wrong for the given lod setup. If the result is 32, ensure that you set up DynDOLOD to generate level 32.

Alpha95 & Alpha98 both say the same thing; NOT FOUND

Screen shots of Alpha95 & Alpha98 showing this;

Alpha95 getini — Freeimage.host (You can see the object lod in the distance too.)

Alpha98 getini — Freeimage.host

I use the same DynDOLOD settings for both Alpha95 & 98.

DynDOLOD — Freeimage.host - (This works just fine for Alpha95.)

Edited September 25, 2022 by mooit

[sheson]

7 hours ago, mooit said:

Well well well, I disabled all the mods in MO2, and only left enabled DynDOLOD Resources and DynDOLOD with the occlusion disabled and loaded it Vanilla and it bloody worked!

Does the object LOD Level 16 show on the map? - > no object LOD

These are the screen shots I posted before for Alpha98 so you can see there is no object LOD;

So it only happens in combination with one or more other mods. It should be easy now to find out which via binary search. E.g.  Disable/Enable groups of mods until you only have the one(s) left that contribute to the problem.

A screenshot of the map would be nice. If it also doesn't show object LOD, then the INI [MapMenu] uLockedObjectMapLOD settings mentioned by DoubleYou might be related. However, INI settings starting with "u" can not be "get" via the game console, only "set". Check the game INIs and custom INIs and also if mods that have their own INI files in the data folder first.

[sheson]

5 hours ago, mooit said:

Alpha98 both say the same thing; NOT FOUND

Alpha98 showing this;

Alpha98 getini — Freeimage.host

LOD meshes and textures do not affect INI settings. The version of the LOD generators does not matter for the INI setting.

See above about the INI setting. You need to actually check all the used INI files. The last one the game loads is the one that is being used.

Read the first post: "Do not waste time using older versions or reporting problems with older versions."

[sheson]

5 hours ago, Glanzer said:

Ran the LODGen using LODGenx64.exe instead of LODGenx64Win.exe and it failed again. The logs all look the same, but the event log entry is slightly different:

  Reveal hidden contents

 

Application: LODGenx64.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.NullReferenceException
   at LODGenerator.NifMain.BSSubIndexTriShape.SetSegments(System.Collections.Generic.List`1<LODGenerator.SegmentDesc>, Int32)
   at LODGenerator.LODApp.CreateLODNodesSSE(LODGenerator.NiFile, LODGenerator.NifMain.NiNode, LODGenerator.QuadDesc, System.Collections.Generic.List`1<LODGenerator.ShapeDesc>)
   at LODGenerator.LODApp.DoLOD(LODGenerator.QuadDesc, Boolean)
   at LODGenerator.LODApp+<>c__DisplayClass81_2.<GenerateLOD>b__0()
   at System.Threading.Tasks.Task.Execute()

Exception Info: System.AggregateException
   at System.Threading.Tasks.Task.WaitAll(System.Threading.Tasks.Task[], Int32, System.Threading.CancellationToken)
   at LODGenerator.LODApp.GenerateLOD(System.Collections.Generic.List`1<LODGenerator.StaticDesc>)
   at LODGeneratorCMD.Program.Main(System.String[])

 

 

Upload ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_aaChanterelle2.txt so I can compare it to mine here I did with a vanilla game + mod only which worked so far.

Could you test if not not unpacking the BSA and hiding the loose files makes a difference?

You would need to do a normal generation for that worldspace so the list of BSA files is updated for LODGen or manually add these lines under the existing ones to the file  mentioned above:

Resource=D:\Games\Steam\steamapps\common\Skyrim Special Edition\Data\Chanterelle World - Textures.bsa
Resource=D:\Games\Steam\steamapps\common\Skyrim Special Edition\Data\Chanterelle World.bsa
Resource=D:\Games\Steam\steamapps\common\Skyrim Special Edition\Data\Chanterelle World0 - Textures.bsa

[Abbot]

On 9/21/2022 at 7:57 PM, sheson said:

That looks similar to the first crash log, so refer to what I said in this post: https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-98/?do=findComment&comment=264175.
No log and no debug log of the DynDOLOD generation for the current load order.  No information if CTD stop with DynDOLOD output is not active. No papyrus logs with debug enabled. DynDOLOD plugin is still being overwritten by other plugins.

Together with the quest crash, it seems there might be different causes of CTD  and reportedly something more severe happening when enabling papyrus logging.

Do all those issues stop when deactivating the DynDOLOD output?

Hello Sheson,

You're right, I didn't give you much to work with....

Well, I have re-installed the modlist and then put the mods I added back in it... So far, DynDOLOD doens't seem to crash anymore... Finger crossed!!

Many thanks for your availability and willingness to help!

[z929669]

On 9/23/2022 at 2:24 AM, sheson said:

snip/

there seems to be a problem with search, though. Older posts seem not to be indexed right now.

/snip

I've corrected our server time, which was off. I'm also using creative ways to re-index search on forums, since there is evidently no simple way to do this via software admin (as there had been years ago ... this is what happens when UIs are 'upgraded' for dummies). My initial testing seems to have worked, so I am setting the lookback to three years to trigger another index. This will likely take minutes or hours to complete.

---

EDIT: It's fixed now with 3-year lookback. I'd rather have unlimited lookback, but 3 years seems like a viable compromise for 99% of search relevance

[sheson]

On 9/23/2022 at 3:25 PM, Blackread said:

Ah thanks for the explanation, I wasn't aware that references disabled via enable parent also trigger the bugs. I can test this too.

In the meantime, seeing as this will probably be the way moving forward, I generated full LODs with the workarounds enabled and checked the cells reported having bugs in the logs - which was painful, I doubt I'll do this ever again. I found very few references that had both the full and LOD model appear at the same time. Here's the full rundown:

  Hide contents

RedBag's Rorikstead - Large Refs.esm xxxxx800 in cell -20, 1 of Tamriel, no overwrites

Skyrim.esm aa6bc in cell -38, 2 of Tamriel, no overwrites

Skyrim.esm bbc23 in cell -38, 2 of Tamriel, no overwrites

Skyrim.esm 39055 in cell -38, 2 of Tamriel, no overwrites

Here are the logs for the generation: https://mega.nz/file/oK0EXKZA#-j__STXxB7dBA8srl5Z7XqSgfQE-gMe932k_kSWJILg I also included the custom RedBag's Rorikstead plugin and my modified version of the main plugin it was designed to be used with. If this interests you and there's anything you need let me know.

Of course my load order isn't super massive and it is already prepared for large references using the old methods, so I'm probably not the ideal test subject.

Can you check if cell -38,2 in DynDOLOD.esm has 2 references, one called Tamriel_Worshipper_%38_2 and the other Tamriel_Disciple_%38_2?
It seems you did something to the large reference 000DDD35 that is moved by Updates.esm from -39,2 to -38,2?

I believe the issue in -20,1 is because there is still a duplicate non large reference in RedBag's Rorikstead.esp with xx0012D8 and thus its non large ref LOD shows. I need to check and fix why that duplicate is not detected and ignored for LOD.  It is not reported because the records xxxxx800 and xx0012D8 are not equal, while the model, position, rotation is. So you will need to address in your edited plugins.

[Blackread]

1 hour ago, sheson said:

Can you check if cell -38,2 in DynDOLOD.esm has 2 references, one called Tamriel_Worshipper_%38_2 and the other Tamriel_Disciple_%38_2?
It seems you did something to the large reference 000DDD35 that is moved by Updates.esm from -39,2 to -38,2?

I believe the issue in -20,1 is because there is still a duplicate non large reference in RedBag's Rorikstead.esp with xx0012D8 and thus its non large ref LOD shows. I need to check and fix why that duplicate is not detected and ignored for LOD.  It is not reported because the records xxxxx800 and xx0012D8 are not equal, while the model, position, rotation is. So you will need to address in your edited plugins.

There is no Tamriel_Disciple_%38_2 in -38,2, only Tamriel_Worshipper_%38_2.

Yes, I've done the standard fix for the moved reference in Update.esm: moved the original one back to its original position and disabled it, and created a new duplicate where the original was moved to by Update.esm. However, I've been meaning to remove all the plugins that fix moved large references and custom updates to stuff like lighting mods in favor of the new workarounds and see how things work out, just haven't found the time to do it yet. I'll let you know of the results when I do.

Thanks for looking into the Rorikstead situation! Completely missed that there was another model on top of the large ref one.

[sheson]

16 minutes ago, Blackread said:

There is no Tamriel_Disciple_%38_2 in -38,2, only Tamriel_Worshipper_%38_2.

Yes, I've done the standard fix for the moved reference in Update.esm: moved the original one back to its original position and disabled it, and created a new duplicate where the original was moved to by Update.esm. However, I've been meaning to remove all the plugins that fix moved large references and custom updates to stuff like lighting mods in favor of the new workarounds and see how things work out, just haven't found the time to do it yet. I'll let you know of the results when I do.

Thanks for looking into the Rorikstead situation! Completely missed that there was another model on top of the large ref one.

The fact that there is no disciple explains why the large references bugs still happen, the cell is not detected as having any bugs.

Why exactly, I am not sure without redoing the changes you did, if you still have the changed plugin, you could upload them so I might have a look in the next days.

On the other hand, if it is a typical constellation of things with "normal" mods/plugins we will come across similar cases anyways I suppose.

Do not kill yourself checking every report cell, do it other way around. Just play the game (yeah right) and whenever you notice large ref bugs, check if the cell coordinates were reported. I am pretty confident that the reported cells will look fine.

What also needs testing is that the scripted workaround do not cause script problems with larger load orders or persistent large references (HearthFires houses for example) to vanish (be disabled when they shouldn't).

[sheson]

@DoubleYou

Add FO4 support for TexGen stitched object LOD textures. Start with -FO4.

Let me know in case there are any issues.

If you have updated config files to update vanilla textures I'd happily include them.

[DoubleYou]

2 minutes ago, sheson said:

@DoubleYou

Add FO4 support for TexGen stitched object LOD textures. Start with -FO4.

Let me know in case there are any issues.

If you have updated config files to update vanilla textures I'd happily include them.

Thanks! Will test when I get the chance.

[Glanzer]

14 hours ago, sheson said:

Upload ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_aaChanterelle2.txt so I can compare it to mine here I did with a vanilla game + mod only which worked so far.

Could you test if not not unpacking the BSA and hiding the loose files makes a difference?

You would need to do a normal generation for that worldspace so the list of BSA files is updated for LODGen or manually add these lines under the existing ones to the file  mentioned above:

Resource=D:\Games\Steam\steamapps\common\Skyrim Special Edition\Data\Chanterelle World - Textures.bsa
Resource=D:\Games\Steam\steamapps\common\Skyrim Special Edition\Data\Chanterelle World.bsa
Resource=D:\Games\Steam\steamapps\common\Skyrim Special Edition\Data\Chanterelle World0 - Textures.bsa

Running without the loose files and with the BSAs only didn't help, the same error happened. But after some more experimentation I narrowed the problem to the precached grass. Unchecking the Grass option in Dyndolod let's it complete without errors. (Yes I did run all NGIO precaching before starting the texgen/dyndolod process.) I notice that Vactrol (mod author) put a note about generating the grass for two of his worldspaces separately, so I'm going to start over and see if that makes a difference. Another user said he didn't do that and had no problems.

In any case, let's consider this problem 'solved' for now because I'm taking this issue back to the mod and continuing the discussion/debugging there. If I find out anything of general interest that might help other users beyond that mod, I'll come back and post it here. Thanks so much for your help Sheson!

[sheson]

10 minutes ago, Glanzer said:

Running without the loose files and with the BSAs only didn't help, the same error happened. But after some more experimentation I narrowed the problem to the precached grass. Unchecking the Grass option in Dyndolod let's it complete without errors. (Yes I did run all NGIO precaching before starting the texgen/dyndolod process.) I notice that Vactrol (mod author) put a note about generating the grass for two of his worldspaces separately, so I'm going to start over and see if that makes a difference. Another user said he didn't do that and had no problems.

In any case, let's consider this problem 'solved' for now because I'm taking this issue back to the mod and continuing the discussion/debugging there. If I find out anything of general interest that might help other users beyond that mod, I'll come back and post it here. Thanks so much for your help Sheson!

That should still not be posisble to cause that error in .net with things randomly become undefined though.

I would be interested in the grass cache files for the worldspace and the all files with the worldspace name in the filename  from the..\DynDOLOD\Edit Scripts\Export\ folder and also LODGen_SSE_FlatTextures.txt and LODGen_SSE_Grass_Map_Tamriel.txt so I might be able to debug this properly in LODGen. At least a better error message should come out of this.