DynDOLOD 3.00 Alpha 169

[sheson]

Ok I believe I know why only two lod grasses exist they are TundraGrass01 and TundraGrass03 respectively and both are vanilla records, they both contain custom grass meshes and thats fine apparently and billboards generated for them are fine but any new grass form i.d.'s added by mods don't get added to the LOD even though billboards for them do get generated.

Use the latest alpha version.

 

Check ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Grass_Map_Tamriel.txt, it will list all the grass LOD billboards that were discovered and used.

 

For me it lists over 70 lines with entries for grasses added by Verdant, e.g.

textures\terrain\lodgen\verdant - a skyrim grass plugin sse version.esp\13grassobj_0001b660_1.dds

[sheson]

CPU usage is minimal, between 2-10% most of the time, with the occasional spike to around 50%, memory-wise it eats every bit of RAM it finds (haven't tried limiting anything yet), currently that's 55GB. There's also some disk activity (anywhere between 10 and 100MBps, it's an NVMe SSD), so it does seem to be doing something, just extremely slowly. Weird thing is it starts off quite fast (using a lot more CPU too), then eventually slows down to this complete crawl. 

How many cores.

 

It typically starts as many threads as there are cores. Each thread is one LOD quad/file (4x4, 8x8, 16x16 cells). Generating a LOD quad can easily require several GB in memory in order to be generated. If it runs out of physical memory because of the parallel threads, it might mean some of those threads have to wait. It may only be able to run one thread at a time if things get tight. Less threads means less competition for physical memory.

 

Depending on settings, load order, grass density etc. you will find BTO files that larger than 100MB. Load one of those with NifSkope and then check its memory usage to get a feel for it.

[S_K_U_L_L_]

Forgive me if this isn't the correct spot for this, I don't know whether I should make a new topic or respond to the Alpha's topic.

 

I am just about done with my pretty sizable modlist and ran TexGen and DynDOLOD through MO2 to ensure everything worked. TexGen ran correctly with zero errors but when running DynDOLOD I get the following fatal error:

 

Can not resolve cell or worldspace for Solitude Skyway SE + BluePalaceTerrace [PATCH - LoTD] (STD).esp 0I_ADJ_CorridorToCourtyardDoor_001 [REFR:3F0029FE] (places SJailDoor02Load "Door" [DOOR:000E3E3F] in GRUP Cell Persistent Children of  WBPTLOTDPatchCorridors "Blue Palace - Corridors" [CELL:FE025827])

 

The DynDOLOD_SSE_Debug_log has not updated with my most recent runs of DynDOLOD (Its last log is when I accidentally ran it yesterday without enabling the TexGen Output)

The DynDOLOD_SSE_log does not display any errors, I just get the pop-up without any pattern I can discern (The final lines of the log are always different with each attempt before the error pop-up)

 

The .esp producing the error comes from KhrysINXS's Modular PatchxPress. They could not replicate the error with an earlier 3.0 Alpha build so they suggested I just use the mods I was attempting to patch and their patches. So I made a fresh MO2 profile using simply USSEP, Legacy of the Dragonborn, Blue Palace Terrace, The Great City of Solitude, and Solitude Skyway. I then installed KhrysINXS's Solitude Exterior LOD Unlocker Advocate II, the GCoS + Skyway + Blue Palace Terrace patch, and the Skyway + Terrace + LoTD patch. I installed it all according to the mod author's instructions and... got the same exact error running DynDOLOD.

 

KhrysINXS could not replicate the error with the same load order so they suggested I make a post here. The only settings I changed in DynDOLOD were the setting for Grass LOD with No Grass in Objects' grass cache and ultra trees. 

 

I'm still unsure if this is a fault on my end or on DynDOLOD's side but any help would be appreciated. I would like to use these mods AND have the fantastic LOD DynDOLOD provides. 

 

 

[soupdragon]

nevermind missed something will report back later

Edited January 15, 2021 by soupdragon

[soupdragon]

I'm using Alpha 18/resources Alpha 4. So the verdant grass billboards are listed in LODGen_SSE_Grass_Map_Tamriel.txt but for some reason they're not showing up... I might go back to my original plan and regenerate cgid and see if that makes any difference

[sheson]

 

Forgive me if this isn't the correct spot for this, I don't know whether I should make a new topic or respond to the Alpha's topic.

 

I am just about done with my pretty sizable modlist and ran TexGen and DynDOLOD through MO2 to ensure everything worked. TexGen ran correctly with zero errors but when running DynDOLOD I get the following fatal error:

 

Can not resolve cell or worldspace for Solitude Skyway SE + BluePalaceTerrace [PATCH - LoTD] (STD).esp 0I_ADJ_CorridorToCourtyardDoor_001 [REFR:3F0029FE] (places SJailDoor02Load "Door" [DOOR:000E3E3F] in GRUP Cell Persistent Children of  WBPTLOTDPatchCorridors "Blue Palace - Corridors" [CELL:FE025827])

 

The DynDOLOD_SSE_Debug_log has not updated with my most recent runs of DynDOLOD (Its last log is when I accidentally ran it yesterday without enabling the TexGen Output)

The DynDOLOD_SSE_log does not display any errors, I just get the pop-up without any pattern I can discern (The final lines of the log are always different with each attempt before the error pop-up)

 

The .esp producing the error comes from KhrysINXS's Modular PatchxPress. They could not replicate the error with an earlier 3.0 Alpha build so they suggested I just use the mods I was attempting to patch and their patches. So I made a fresh MO2 profile using simply USSEP, Legacy of the Dragonborn, Blue Palace Terrace, The Great City of Solitude, and Solitude Skyway. I then installed KhrysINXS's Solitude Exterior LOD Unlocker Advocate II, the GCoS + Skyway + Blue Palace Terrace patch, and the Skyway + Terrace + LoTD patch. I installed it all according to the mod author's instructions and... got the same exact error running DynDOLOD.

 

KhrysINXS could not replicate the error with the same load order so they suggested I make a post here. The only settings I changed in DynDOLOD were the setting for Grass LOD with No Grass in Objects' grass cache and ultra trees. 

 

I'm still unsure if this is a fault on my end or on DynDOLOD's side but any help would be appreciated. I would like to use these mods AND have the fantastic LOD DynDOLOD provides. 

 

 

Post the log that you have for the minimal setup. Also make sure to copy and paste the exact names for patch downloads so I can try to replicate the load order.

 

The problem seems obvious when looking at the mentioned reference xx0029FE in xEdit:

 

Solitude Skyway SE + BluePalaceTerrace [PATCH - LoTD] (STD).esp sets its Cell to be the internal cell xx003827, while the original reference itself is listed as child of the persistent cell 00000D74 of the Tamriel worldspace. This is most likely not correct and should probably be fixed? If this is in fact intended, please let me know.

Edited January 15, 2021 by sheson

[Soulmancer]

With the new feature to generate billboards can I now just delete the terrain/lodgen folder from HD LOD SE ?   The one that has all the plants, trees, and shrubs?

 

Some of those have varying quality,...I'm looking at you yellow tundra bushes.

 

Edit: gave this a test, it created billboards for any trees, but not plants/shrubs/pushes ... so I suppose that answers my question.  This objects are handled differently I assume?

Edited January 15, 2021 by Soulmancer

[S_K_U_L_L_]

Post the log that you have for the minimal setup. Also make sure to copy and paste the exact names for patch downloads so I can try to replicate the load order.

 

The problem seems obvious when looking at the mentioned reference xx0029FE in xEdit:

 

Solitude Skyway SE + BluePalaceTerrace [PATCH - LoTD] (STD).esp sets its Cell to be the internal cell xx003827, while the original reference itself is listed as child of the persistent cell 00000D74 of the Tamriel worldspace. This is most likely not correct and should probably be fixed? If this is in fact intended, please let me know.

 

Brought this up with the mod author and they do believe it is a bug on their end. Sorry to trouble you with the issue as DynDOLOD does not seem to be related to the problem. Thank you for assisting me anyways!

[Soulmancer]

Hmm... I got an error prompt and see this.

 

"[22:00] <Error: LODGenx64.exe failed to generate object LOD for DLC01FalmerValley. LODGenx64.exe returned E0434352. Check E:\SEMods\DynDOLOD-Standalone.2.69\DynDOLOD\Logs\LODGen_SSE_DLC01FalmerValley_log.txt"

 

But the log doesn't tell me anything specific about it.  It looks fine, I see no errors or warnings in that log.

Edited January 15, 2021 by Soulmancer

[Soulmancer]

I ran it again and did encounter the same error.  Is the ESP safe to compress after dyndolod gen for an ESL flag? I see it is creating a bunch of new form x-markers... I don't recall this prior to 3.0.

 

sorry I tried to re-edit my post but it would not let me.

[KhrysINXS]

Post the log that you have for the minimal setup. Also make sure to copy and paste the exact names for patch downloads so I can try to replicate the load order.

 

The problem seems obvious when looking at the mentioned reference xx0029FE in xEdit:

 

Solitude Skyway SE + BluePalaceTerrace [PATCH - LoTD] (STD).esp sets its Cell to be the internal cell xx003827, while the original reference itself is listed as child of the persistent cell 00000D74 of the Tamriel worldspace. This is most likely not correct and should probably be fixed? If this is in fact intended, please let me know.

 

 

I am responding to this inquiry now as I have come to the conclusion that re-using door references (for a different purpose) and linking them to a separate worldspace or interior cell opposed to how they were originally referenced to from the module that created them is not valid? Is this correct because if it always was deemed as bad choice to use a door that already existed but to link it to a different cell or worldspace, why until now is DynDOLOD not accepting it? I should specify that I am changing the location of a persistent door ref from tamriel worldspace to be an interior cell. On the discord servers this conversation has already been looked into and it has come down to asking you Sheson if this was always a bad idea to commit. Should I just initially disable the old child references and remake new base object doors to fulfill the same purpose. This method seems to bypass the DyndoLOD error. 

Let me know and Thankyou

 

Edited January 16, 2021 by KhrysINXS

[KhrysINXS]

 

Post the log that you have for the minimal setup. Also make sure to copy and paste the exact names for patch downloads so I can try to replicate the load order.

 

The problem seems obvious when looking at the mentioned reference xx0029FE in xEdit:

 

Solitude Skyway SE + BluePalaceTerrace [PATCH - LoTD] (STD).esp sets its Cell to be the internal cell xx003827, while the original reference itself is listed as child of the persistent cell 00000D74 of the Tamriel worldspace. This is most likely not correct and should probably be fixed? If this is in fact intended, please let me know.

 

 

I am responding to this inquiry now as I have come to the conclusion that re-using door references (for a different purpose) and linking them to a separate worldspace or interior cell opposed to how they were originally referenced to from the module that created them is not valid? Is this correct because if it always was deemed as bad choice to use a door that already existed but to link it to a different cell or worldspace, why until now is DynDOLOD not accepting it? I should specify that I am changing the location of a persistent door ref from tamriel worldspace to be an interior cell. On the discord servers this conversation has already been looked into and it has come down to asking you Sheson if this was always a bad idea to commit. Should I just initially disable the old child references and remake new base object doors to fulfill the same purpose. This method seems to bypass the DyndoLOD error. 

Let me know and Thankyou

 

EDIT.

 

Since remaking all new unique doors in placement of the ones I borrowed from the master and reuse for another purpose; now the wall lean markers are are next in line to call for errors. what's next after this is not predicted but something isn't right I am suspecting... I am going to leave my stuff alone for now...

 

 

 

 

 

Post the log that you have for the minimal setup. Also make sure to copy and paste the exact names for patch downloads so I can try to replicate the load order.

 

The problem seems obvious when looking at the mentioned reference xx0029FE in xEdit:

 

Solitude Skyway SE + BluePalaceTerrace [PATCH - LoTD] (STD).esp sets its Cell to be the internal cell xx003827, while the original reference itself is listed as child of the persistent cell 00000D74 of the Tamriel worldspace. This is most likely not correct and should probably be fixed? If this is in fact intended, please let me know.

 

 

I am responding to this inquiry now as I have come to the conclusion that re-using door references (for a different purpose) and linking them to a separate worldspace or interior cell opposed to how they were originally referenced to from the module that created them is not valid? Is this correct because if it always was deemed as bad choice to use a door that already existed but to link it to a different cell or worldspace, why until now is DynDOLOD not accepting it? I should specify that I am changing the location of a persistent door ref from tamriel worldspace to be an interior cell. On the discord servers this conversation has already been looked into and it has come down to asking you Sheson if this was always a bad idea to commit. Should I just initially disable the old child references and remake new base object doors to fulfill the same purpose. This method seems to bypass the DyndoLOD error. 

Let me know and Thankyou

 

EDIT.

 

Since remaking all new unique doors in placement of the ones I borrowed from the master and reuse for another purpose; now the wall lean markers are are next in line to call for errors. what's next after this is not predicted but something isn't right I am suspecting... I am going to leave my stuff alone for now...

[Window Title]

DynDOLOD

 

[Main Instruction]

Can not resolve cell or worldspace for Solitude Skyway SE + BluePalaceTerrace [PATCH - LoTD] (STD).esp 0I_ADJ_WallLeanMarker_001 [REFR:070242DA] (places WallLeanMarker [FURN:00052FF5] in GRUP Cell Persistent Children of WBPTLOTDPatchCorridors "Blue Palace - Corridors" [CELL:0C000827])

 

[Exit DynDOLOD]

 

[Footer]

DynDOLOD FAQ | Support Forum | Copy message to clipboard

 

 

 

[sheson]

With the new feature to generate billboards can I now just delete the terrain/lodgen folder from HD LOD SE ?   The one that has all the plants, trees, and shrubs?

 

Some of those have varying quality,...I'm looking at you yellow tundra bushes.

 

Edit: gave this a test, it created billboards for any trees, but not plants/shrubs/pushes ... so I suppose that answers my question.  This objects are handled differently I assume?

Read the included help files for TexGen ..\DynDOLOD\docs\help\TexGen.html and ..\DynDOLOD\docs\help\TexGenConfiguration.html which explains the automatic detection and forced creation of billboards.

Hmm... I got an error prompt and see this.

 

"[22:00]

 

But the log doesn't tell me anything specific about it.  It looks fine, I see no errors or warnings in that log.

Upload the logs as explained by the first post. Also check the command prompt window of LODGen itself if there is an addtiional information.

I ran it again and did encounter the same error.  Is the ESP safe to compress after dyndolod gen for an ESL flag? I see it is creating a bunch of new form x-markers... I don't recall this prior to 3.0.

If the DynDOLOD.esp has less than 2048 new records something is probably wrong.

Edited January 16, 2021 by sheson

[sheson]

 

 

I am responding to this inquiry now as I have come to the conclusion that re-using door references (for a different purpose) and linking them to a separate worldspace or interior cell opposed to how they were originally referenced to from the module that created them is not valid? Is this correct because if it always was deemed as bad choice to use a door that already existed but to link it to a different cell or worldspace, why until now is DynDOLOD not accepting it? I should specify that I am changing the location of a persistent door ref from tamriel worldspace to be an interior cell. On the discord servers this conversation has already been looked into and it has come down to asking you Sheson if this was always a bad idea to commit. Should I just initially disable the old child references and remake new base object doors to fulfill the same purpose. This method seems to bypass the DyndoLOD error. 

Let me know and Thankyou

 

DynDOLOD 3 is doing a lot of things more efficiently including additional error and sanity checks.

 

I am asking myself the same question. I do not really know if doing this with references might be causing problems in the game or not.

 

If CK allows it and it works in-game it might be fine. However, it just seems cleaner to disable them and add new references instead. That maybe just a personal preference.

 

There is a dozen references in Solitude Skyway SE + BluePalaceTerrace [PATCH - LoTD] (STD).esp that are moved to the interior cell.

xx0029FE, xx017602, xx018C1B, xx0242DA, xx029490, xx03DB38, xx06B5BA, xx084B15, xx084B16, xx084B17, xx0D0929, xx0D092A

 

DynDOLOD can be made to ignore them silently, ignore them with a warning message or stop with an error. Whatever we deem suitable.

For the next alpha version, DynDOLOD will just ignore them with a "Notice" - which only shows in the debug log with default settings.

Edited January 16, 2021 by sheson

[Soulmancer]

Read the included help files for TexGen ..\DynDOLOD\docs\help\TexGen.html and ..\DynDOLOD\docs\help\TexGenConfiguration.html which explains the automatic detection and forced creation of billboards.

 

Upload the logs as explained by the first post. Also check the command prompt window of LODGen itself if there is an addtiional information.

 

If the DynDOLOD.esp has less than 2048 new records something is probably wrong.

Sorry, mistyped above. When I ran dyndolod again I did NOT encounter the same error with falmer valley, seemed to work just fine.

 

Would compressing records of the ESP output to esl flag it be fine then? Thx