DynDOLOD 3.00 Alpha 180

[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.

[mooit]

20 hours ago, sheson said:

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.

I don't see this any longer as my MODs, I disabled all of them, except only what is needed to use SKSE to start the game with DynDOLOD,  and it still doesn't work with the latest game save, but works with one of my earliest game saves.

So I see this as something to do with the Game Saves, where Alpha98 doesn't like them, and Alpha95 is fine with them.

And, the reason I am saying this, is because I enabled all my mods in MO2, then loaded one of my earliest game saves at Whiterun back in 2019, and guess what, it worked.

Here's a screen shot with all the mods enabled at Whiterun on Alpha98.

2019 Early Game Saves Alpha98 — Freeimage.host

The problem is that if I try to load saves I made recently they are not working.

But I followed the DynDOLOD guide correctly when I started using DynDOLOD when making my Saves. 

Clean Save | DynDOLOD

Now for whatever reason Alpha98 won't load these, and that I believe is the problem, otherwise, rhetorically speaking of, how then, did I get this to work, showing the Obeject LODs working on this earlier save.

Having game Saves work, is actually something I've had problems with in the past with DynDOLOD, where I've made proper saves and they also didn't work sometimes on Alpha95, and I would have to sometimes spend hours playing around with this.

So for me personally, I've always run into Game Save issues with DynDOLOD, just like what is going on now, but I've been able to fix it. This time, it's not giving an inch. So I'll just keep fiddling and try to get a game save to work, and see if it will finally give in for me.

I don't know if this is related to corrupt game saves, but on earlier game saves when I was testing this, I noticed what I thought were at first aurora borealis effects across the map, but then I'd never seen these before on the map. hmm

aurora borealis map — Freeimage.host

P.S. I tried making new game saves, I can't get this to work. errrr

Edited September 26, 2022 by mooit

[sheson]

4 hours ago, mooit said:

I don't see this any longer as my MODs, I disabled all of them, except only what is needed to use SKSE to start the game with DynDOLOD,  and it still doesn't work with the latest game save, but works with one of my earliest game saves.

So I see this as something to do with the Game Saves, where Alpha98 doesn't like them, and Alpha95 is fine with them.

And, the reason I am saying this, is because I enabled all my mods in MO2, then loaded one of my earliest game saves at Whiterun back in 2019, and guess what, it worked.

Here's a screen shot with all the mods enabled at Whiterun on Alpha98.

2019 Early Game Saves Alpha98 — Freeimage.host

The problem is that if I try to load saves I made recently they are not working.

But I followed the DynDOLOD guide correctly when I started using DynDOLOD when making my Saves. 

Clean Save | DynDOLOD

Now for whatever reason Alpha98 won't load these, and that I believe is the problem, otherwise, rhetorically speaking of, how then, did I get this to work, showing the Obeject LODs working on this earlier save.

Having game Saves work, is actually something I've had problems with in the past with DynDOLOD, where I've made proper saves and they also didn't work sometimes on Alpha95, and I would have to sometimes spend hours playing around with this.

So for me personally, I've always run into Game Save issues with DynDOLOD, just like what is going on now, but I've been able to fix it. This time, it's not giving an inch. So I'll just keep fiddling and try to get a game save to work, and see if it will finally give in for me.

I don't know if this is related to corrupt game saves, but on earlier game saves when I was testing this, I noticed what I thought were at first aurora borealis effects across the map, but then I'd never seen these before on the map. hmm

aurora borealis map — Freeimage.host

P.S. I tried making new game saves, I can't get this to work. errrr

As explained, always test with a new game. If something doesn't work with a save game, then there is a problem or setting baked into the save game that is out of the control of DynDOLOD.

LOD meshes and textures do not care about save games and are not part of the save game data. The game simple loads and displays them. LOD generation does not care save games.

The clean save is about data from plugins and scripts. If the game is started without the plugins, then most of the data for those plugins and scripts from the save is discarded already, .e.g a clean save. The data is all about the position of dynamic LOD references. The orphaned scripts can be cleaned with a tool. To also remove data form the SKSE co-save you would need to start without PapyrusUtil once (or delete the co-save for test), but that will also remove co-save data for other plugins.

DynDOLOD does not load save games.

Unless further specified or explained what the problems are, save game issues have to do with INI settings and the entire load order. For example unfixed issue and errors in plugins.
You can not add and remove plugins all the time. DynDOLOD is pretty safe because it is pretty much self contained. The worse that can happen is that a full model does not show anymore because its disable state got baked in the save.

DynDOLOD does not change or affects whatever the last screenshot shows, which looks like a textures problem of the cloud cover of the map.

If things work with a new game, then the object LOD meshes and texture work as expected. The meshes and textures are most likely not the problem, since they can not really affect a save game. Though I would do a binary search to see if it can be narrowed down to single BTO.

I am not going to suggest any more concrete troubleshooting steps, since things work with a new save and you seem not to be able to just do them and report back to determine the next step.

[blueetenicolet]

Hello, I update to Alpha 99 and noticed the experimental Large Reference Bugs Workarounds , I Set WorkaroundLargeReferencesBugs=1 and The DynDOLOD64 reporrt an error : Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 11909)  each time generated object LOD for Tamriel successfully.

I tried Set WorkaroundLargeReferencesBugs to 0 and it not happened again.

Setting: Upgrade NearGrid to Far enabled , Down GradeFar to Near disabled.  I tried disable or enable them but seems nothing changed.

BugReport :https://paste.ee/p/AEpo3

DynDOLOD_SSE_log.txt (2.45MB) https://ufile.io/rc5irbux

DynDOLOD_SSE_Debug_log.txt  (125MB) https://ufile.io/hbkoyy5a

 

[sheson]

46 minutes ago, blueetenicolet said:

Hello, I update to Alpha 99 and noticed the experimental Large Reference Bugs Workarounds , I Set WorkaroundLargeReferencesBugs=1 and The DynDOLOD64 reporrt an error : Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 11909)  each time generated object LOD for Tamriel successfully.

I tried Set WorkaroundLargeReferencesBugs to 0 and it not happened again.

Setting: Upgrade NearGrid to Far enabled , Down GradeFar to Near disabled.  I tried disable or enable them but seems nothing changed.

BugReport :https://paste.ee/p/AEpo3

DynDOLOD_SSE_log.txt (2.45MB) https://ufile.io/rc5irbux

DynDOLOD_SSE_Debug_log.txt  (125MB) https://ufile.io/hbkoyy5a

Bring up the reference 000DDD36 in xEdit and check the last plugin / column to the right. There might be something going on with the EditorID having weird characters. Let me know what you find.

[blueetenicolet]

3 minutes ago, sheson said:

Bring up the reference 000DDD36 in xEdit and check the last plugin / column to the right. There might be something going on with the EditorID having weird characters. Let me know what you find.

Looks like a smoke particle and deleted in update.esm