Jump to content

Recommended Posts

First: Thank you Sheson et. al for DynDOLOD.

 

I have been using for a while (prior versions) without issue by RTFM advise & some great YouTube video tutorials.

 

With the DynDOLOD 3 I thought I would upload and give an attempt.

 

No issues with TexGen. DynDOLOD stops on the Heljarchen Farm Revamped mod. 

 

I know you cannot know my load order or what conflicts may exist. I am hoping you can translate the message below so I can look into learning more about the inner workings of modding. 

 

Thanks,

Dag

 

****ERROR COPIED BELOW*******

 

[Window Title]
DynDOLOD
 
[Main Instruction]
Unresolved FormID [5D01616C]
 
[Content]
Scripts Script Properties Property Value Object Union Object v2 FormID [5D01616C] < Error: Could not be resolved > 
Error in HeljarchenFarm.esp SKHFWorkbenchBeamRef [REFR:5D029640] (places SKHFWorkbenchBeam "Workbench Control" [ACTI:5D02963F] in GRUP Cell Persistent Children of [CELL:00000D74] (in Tamriel "Skyrim" [WRLD:0000003C]) at 8,7)
 
Help for this message
 
[Exit DynDOLOD]
 
[Footer]
DynDOLOD FAQ | Support Forum | Copy message to clipboard

Share this post


Link to post
Share on other sites

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

post-7981-0-85582900-1610683430_thumb.jpg

Share this post


Link to post
Share on other sites

 

First: Thank you Sheson et. al for DynDOLOD.

 

I have been using for a while (prior versions) without issue by RTFM advise & some great YouTube video tutorials.

 

With the DynDOLOD 3 I thought I would upload and give an attempt.

 

No issues with TexGen. DynDOLOD stops on the Heljarchen Farm Revamped mod. 

 

I know you cannot know my load order or what conflicts may exist. I am hoping you can translate the message below so I can look into learning more about the inner workings of modding. 

 

Thanks,

Dag

 

****ERROR COPIED BELOW*******

 

[Window Title]
DynDOLOD
 
[Main Instruction]
Unresolved FormID [5D01616C]
 
[Content]
Scripts Script Properties Property Value Object Union Object v2 FormID [5D01616C]  
Error in HeljarchenFarm.esp SKHFWorkbenchBeamRef [REFR:5D029640] (places SKHFWorkbenchBeam "Workbench Control" [ACTI:5D02963F] in GRUP Cell Persistent Children of [CELL:00000D74] (in Tamriel "Skyrim" [WRLD:0000003C]) at 8,7)
 
Help for this message
 
[Exit DynDOLOD]
 
[Footer]
DynDOLOD FAQ | Support Forum | Copy message to clipboard

 

Click "Help for this message" to read ..\DynDOLOD\docs\help\Unresolved.html. You need to fix errors in 3rd party plugins.

Share this post


Link to post
Share on other sites

 

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 by sheson

Share this post


Link to post
Share on other sites

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 by Soulmancer

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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 by Soulmancer

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

74L0TjR.jpg

 

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 by KhrysINXS

Share this post


Link to post
Share on other sites

 

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.

 

74L0TjR.jpg

 

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

14Vqlxt.png

 

 

 

 

 

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.

 

74L0TjR.jpg

 

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

14Vqlxt.png

[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

 

 

 

Share this post


Link to post
Share on other sites

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 by sheson

Share this post


Link to post
Share on other sites

 

 

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 by sheson

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

I just used DynDOLOD 3.18 and the only thing I have to complain about (all other aspects were due to errors made of myself) is this:

If you're using Immersive Armors and decide to let the config spell being removed (via MCM menu), there are some records/entries inside the plugin 'deleted'
which leads to 'unresolved errors depending on [refID]'.

I relate to this (checked for errors via xEdit and also the same error why dyndolod will not work further)

 

 

[00:00] Start: Checking for Errors
[00:00] Checking for Errors in [27] Hothtrooper44_ArmorCompilation.esp
[00:00] IAMEffConfig "'Immersive Armors' Konfiguration" [MGEF:27018379]
[00:00]     MGEF \ VMAD - Virtual Machine Adapter \ Scripts \ Script \ Properties \ Property \ Value \ Object Union \ Object v2 \ FormID -> [2701A47C] < Error: Could not be resolved >
[00:01] IAShieldPaintingACTIVATOR [REFR:27020EC5] (places WeaponRackCOAMidACTIVATORPlayerHouse "Schildständer" [ACTI:000E49CB] in GRUP Cell Persistent Children of [CELL:0001A270] (in WhiterunWorld "Weißlauf" [WRLD:0001A26F]) at 7,-1)
[00:01]     REFR \ VMAD - Virtual Machine Adapter \ Scripts \ Script \ Properties \ Property \ Value \ Object Union \ Object v2 \ FormID -> [2701A47C] < Error: Could not be resolved >
[00:01] IAAdminQuest "IA Admin" [QUST:27014836]
[00:01]     QUST \ VMAD - Virtual Machine Adapter \ Scripts \ Script \ Properties \ Property \ Value \ Object Union \ Object v2 \ FormID -> [2701A47C] < Error: Could not be resolved >
[00:01]     QUST \ VMAD - Virtual Machine Adapter \ Scripts \ Script \ Properties \ Property \ Value \ Object Union \ Object v2 \ FormID -> [2701A47C] < Error: Could not be resolved >
[00:02] Done: Checking for Errors, Processed Records: 5361, Errors found: 3, Elapsed Time: 00:02



It may be the wrong way to get rid of the config spell, but as this is an 'intended' error, would it be possible that DynDOLOD can ignore this one?
I had to redownload the whole mod again, to get the plugin where the entries weren't already edited or it would not have been possible for me to create

the LODs at all.

 

Also, does the LOD generation longer in the background?
Everything seems finished (no plugins are in the output folder at the moment), but I think something got stuck?

9qgho3pw.jpg

 

 

eel8y3qe.jpg

 

 

st5iwf57.jpg

 

This is the picture I have since 30 minutes now (RAM usage was 11GB at and is fallen down to the value seen in the picture and is starting to get higher again)
 

Edit: As there were no Logs with any errors inside it beside 'aborter by user' as I closed the LODGEN64.exe, I start over and will do Tamriel worldspace alone and at first.

Edited by PRieST

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.