Possible to get a separate script for all plugins that have one or more unacceptable errors?

[fractalbase]

Hi Sheson,

Many including me have run into the issue where a plugin in a load order has at least one unacceptable error according to DynDOLOD, where DynDOLOD only gives you the option to exit.  If you get rid of the mod and try generating DynDOLOD again, DynDOLOD might run into yet another plugin with at least one unacceptable error, and the process continues.

Finding these errors with DynDOLOD is a pain because the user is notified of only the first such error, and that all involves the DynDOLOD LOD generation process.

I'm wondering if it is possible to write an xEdit script that looks for all such errors in a person's load order without the LOD generation overhead and allowing processing of all plugins so if there are multiple plugins with unacceptable errors, those all can be displayed from one running of the script?

[sheson]

  On 7/27/2023 at 6:22 PM, fractalbase said:

Hi Sheson,

Many including me have run into the issue where a plugin in a load order has at least one unacceptable error according to DynDOLOD, where DynDOLOD only gives you the option to exit.  If you get rid of the mod and try generating DynDOLOD again, DynDOLOD might run into yet another plugin with at least one unacceptable error, and the process continues.

Finding these errors with DynDOLOD is a pain because the user is notified of only the first such error, and that all involves the DynDOLOD LOD generation process.

I'm wondering if it is possible to write an xEdit script that looks for all such errors in a person's load order without the LOD generation overhead and allowing processing of all plugins so if there are multiple plugins with unacceptable errors, those all can be displayed from one running of the script?

Expand  

https://dyndolod.info/Generation-Instructions#Prerequisites
Finalize the load order. Install mods and their requirements. Sort and resolve conflicts. Clean and error check the load order with xEdit.

Usually errors that prevent successful LOD generation are errors reported by xEdit. The background loader of xEdit reports the duplicate, overriden or invalid object IDs etc. The xEdit error check reports the unresolved form ID errors. Having a stable/working load order or creating a patch plugin is pretty much impossible with these errors in the load order.

Most of the stop errors should have been discovered and fixed long before running DynDOLOD when following proper modding practice.
One would expect mods or plugins that have errors are fixed by mod authors or in case the mods are older/unmaintained and nobody made a fix yet they have newer alternatives.

You can "try/dry run" most of the checks quicker by selecting dynamic LOD only and not selecting anything else, in particular object LOD.

[fractalbase]

Hi sheson, I have a request.  I understand that plugins that dyndolod finds problems with shouldn't be used period.

however, finding those mods does take a long time, as DynDOLOD stops at the first found problematic plugin.

removing that mod and restarting DynDOLOD takes time.

my request: am xEdit script that processes an entire load order without stopping at each problematic plugin, so that a list of all problematic plugins can be acquired quickly and simply for the purpose of reporting such errors to mod authors, etc.

[sheson]

  On 9/13/2024 at 7:07 PM, fractalbase said:

Hi sheson, I have a request.  I understand that plugins that dyndolod finds problems with shouldn't be used period.

however, finding those mods does take a long time, as DynDOLOD stops at the first found problematic plugin.

removing that mod and restarting DynDOLOD takes time.

my request: am xEdit script that processes an entire load order without stopping at each problematic plugin, so that a list of all problematic plugins can be acquired quickly and simply for the purpose of reporting such errors to mod authors, etc.

Expand  

https://dyndolod.info/Generation-Instructions#Prerequisites
Clean and error check the load order with xEdit.

https://dyndolod.info/Generation-Instructions#1-Generate-The-Required-LOD-Assets-with-TexGen
Make sure all mods, plugins and patches (that affect affect trees, grasses or any textures) are enabled and their overwrite order is sorted. ... In case of issues, solve the cause .. . Disabling plugins, mods, meshes or textures is a troubleshooting step and not a fix.

https://dyndolod.info/Generation-Instructions#2-Generate-The-LOD-Mod-with-DynDOLOD
Finalize the load order as explained in the prerequisites above. Clean and error check the load order with xEdit. Make sure all mods, plugins and patches (that affect exterior cells and worldspaces and base records used by references in exterior cells) are enabled and their overwrite order is sorted. Ignore wrong 3rd party advice to temporarily disable plugins, mods, meshes or textures. .. In case of issues, solve the cause or use appropriate mesh mask rules or settings for desired results. Disabling plugins, mods, meshes or textures is a troubleshooting step and not a fix.

https://dyndolod.info/Messages#Warning-and-Error-Messages
Some errors stop the process with a dedicated pop-up window with further details and a "Click on this link for additional explanations and help for this message" link which directly opens a listed message below. Problems that stop the process are because of errors in the setup, mods, load order, unknown situations, bugs with the tools or third party issues (like OS, antivir, drivers, crapware, hardware etc.) that prevent a successful or safe LOD patch generation. As explained in the Generation Instructions, finalize the load order, install mods, sort and resolve conflicts. Clean and error check the load order with xEdit before generating LOD. Error checking the load order with xEdit will report many of the stop errors like unresolved Form ID in a single run. It also is possible to dry run most things a bit quicker by checking dynamic LOD only in the advanced mode.

Problems in plugins should be fixed or the mod should not ne used at all. Not fixing a problem that stopped the process pretty much guarantees there will be an issue in the game. If the problem is properly investigated to find out its severeness it can also be fixed in the process.

DynDOLOD is based on xEdit. Most of the errors that stop the process are from the xEdit background loader and the xEdit error check.

[primem0ver]

PLEASE NOTE: I am very aware that people are lending/giving their time volutarily to produce tools like this (though I imagine some funds come from Patreon supporters for the widely used ones).  I have been working on my own tool for more than 5 years.  As you read this, please keep in mind that I am not unappreciative.  It just strongly dislike forcing people through a lengthy process that could easily be simplified (and better explained).  Take this as a suggestion that will help people know exactly what to clean ahead of time. 

I have used DyndoLOD in the past and love what it does.  I haven't used it though in about 2 and a half years because I am too busy with other things (including my utility).  Recently (about three months ago) I have wanted to start a new game so I am building on my previous large large load order (and updating mods).  To be frank, DyndoLOD's "new" insistence on having no Unresolved References is a tall order that I am not sure I agree should be forced on people.  Having the occasional wrong model for a distant object isn't the end of the world.  After all, my last game was pretty stable (in terms of CTDs).  

I spent over half of a day of free time to get to the point where DyndoLOD would show the UI.  Now these errors are plaguing me.  These types of errors are so common and without a tool to even detect these outright (select and report only these errors for example in xEdit)  it is downright frustrating to run DyndoLOD over and over and over again just to find another unresolved reference.  Perhaps the biggest source of frustration is what follows.  On the error it says: "Use the xEdit error check to find and fix all unresolved Form ID errors in one single session as explained in the intructions."  I cannot find those instructions (I clicked the link and skimmed through the linked page) and while I eventually located a linked video online that explains how to do this on S.T.E.P., it doesn't exactly explain how to do it in one session.  Not with potentially 60+ mods that need this type of cleaning (see below) unless there is something that automatically cleans there errors that I don't know about.  The "xEdit" error check also adds every other type of error in among the ones we need and as far as I am aware, there is nothing to mitigate that.

As the author of a hopefully upcoming "Swiss Army Knife" like utility for mods and managing larger load orders, I previously added the ability to parse xEdit error logs and today added the ability to look for these specific errors to my tool (which we can use as a proof of concept of my suggestion), but it seems clear that not every case is an issue.  Since the authors of Dyndolod are far more capable of knowing which of these errors cause problems (which specific instances of this error are a problem), could we please pre-scan for these types of errors and warn the user before beginning the lengthy process, only to detect these errors one by one?  (Like before we get to the UI?)  Perhaps output a list?  So far I have had to clean about 12 mods based on these errors (before adding this ability to my own utility).  Based on my utility, there are around 50 more mods that have these kinds of errors.  That is A LOT of mods to sort through (especially one at a time).  It is also a lot of cleaning to do and if not all of them need to be cleaned, it would be rather helpful to know that.

Edited March 18 by primem0ver

[sheson]

  On 3/18/2025 at 4:03 AM, primem0ver said:

PLEASE NOTE: I am very aware that people are lending/giving their time volutarily to produce tools like this (though I imagine some funds come from Patreon supporters for the widely used ones).  I have been working on my own tool for more than 5 years.  As you read this, please keep in mind that I am not unappreciative.  It just strongly dislike forcing people through a lengthy process that could easily be simplified (and better explained).  Take this as a suggestion that will help people know exactly what to clean ahead of time. 

I have used DyndoLOD in the past and love what it does.  I haven't used it though in about 2 and a half years because I am too busy with other things (including my utility).  Recently (about three months ago) I have wanted to start a new game so I am building on my previous large large load order (and updating mods).  To be frank, DyndoLOD's "new" insistence on having no Unresolved References is a tall order that I am not sure I agree should be forced on people.  Having the occasional wrong model for a distant object isn't the end of the world.  After all, my last game was pretty stable (in terms of CTDs).  

I spent over half of a day of free time to get to the point where DyndoLOD would show the UI.  Now these errors are plaguing me.  These types of errors are so common and without a tool to even detect these outright (select and report only these errors for example in xEdit)  it is downright frustrating to run DyndoLOD over and over and over again just to find another unresolved reference.  Perhaps the biggest source of frustration is what follows.  On the error it says: "Use the xEdit error check to find and fix all unresolved Form ID errors in one single session as explained in the intructions."  I cannot find those instructions (I clicked the link and skimmed through the linked page) and while I eventually located a linked video online that explains how to do this on S.T.E.P., it doesn't exactly explain how to do it in one session.  Not with potentially 60+ mods that need this type of cleaning (see below) unless there is something that automatically cleans there errors that I don't know about.  The "xEdit" error check also adds every other type of error in among the ones we need and as far as I am aware, there is nothing to mitigate that.

As the author of a hopefully upcoming "Swiss Army Knife" like utility for mods and managing larger load orders, I previously added the ability to parse xEdit error logs and today added the ability to look for these specific errors to my tool (which we can use as a proof of concept of my suggestion), but it seems clear that not every case is an issue.  Since the authors of Dyndolod are far more capable of knowing which of these errors cause problems (which specific instances of this error are a problem), could we please pre-scan for these types of errors and warn the user before beginning the lengthy process, only to detect these errors one by one?  (Like before we get to the UI?)  Perhaps output a list?  So far I have had to clean about 12 mods based on these errors (before adding this ability to my own utility).  Based on my utility, there are around 50 more mods that have these kinds of errors.  That is A LOT of mods to sort through (especially one at a time).  It is also a lot of cleaning to do and if not all of them need to be cleaned, it would be rather helpful to know that.

Expand  

Moved to a similar thread.

It is unclear what an "unresolved reference" is. No logs or actual error messages were provided. If you mean a reference that has no base record because that entry has an unresolved form ID, that error will cause the game to CTD. There is nothing new about unresolved form IDs causing problems in the LOD patch generation process or the game.

https://dyndolod.info/Messages#Warning-and-Error-Messages
Some errors stop the process with a dedicated pop-up window with further details and a Click on this link for additional explanations and help for this message link which directly opens a listed message below. Problems that stop the process are because of errors in the setup, mods, load order, unknown situations, bugs with the tools or third party issues (like OS, antivir, drivers, crapware, hardware etc.) that prevent a successful or safe LOD patch generation. As explained in the Generation Instructions, finalize the load order, install mods, sort and resolve conflicts.
DynDOLOD does not do a comprehensive check of the entire load order or of all assets. It only checks records and assets that are potentially eligible for LOD or which are used by records or assets eligible for LOD

Not all unresolved form ID errors stop the process. Some are just printed to the (debug) log. For example, this is the case if a script does not have the property that is unresolved or if the script with unresolved form IDs on a base record is being replaced by a script on a reference. DynDOLOD only checks a small subset of records that are relevant to its patch generation and there is no intention to do anything beyond what is needed for LOD generation.

https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages
Read additional explanations and help for a message by clicking on the Click on this link for additional explanations and help for this message link of the message. That will open a corresponding page on this website with further explanations and help for the message.

Clicking the link opens https://dyndolod.info/Messages/Unresolved-Form-ID
See this video for help (ignore the old cleaning instructions as that was already done).
The linked video shows how to mark several plugin in the left window and check them all for errors.

The DynDOLOD instructions explain to Clean and error check the load order with xEdit, which links to https://tes5edit.github.io/docs/7-mod-cleaning-and-error-checking.html, which has a table of contents: 7.4.13 Checking For Errors. It links to https://tes5edit.github.io/docs/7-mod-cleaning-and-error-checking.html#CheckingForErrors
Cleaning ITMs and UDRs does not fix unresolved form ID errors.

The tool to find and fix unresolved form ID errors is xEdit. It already puts out a list of all unresolved form ID errors for all all marked plugins and all records. The main reason is outdated plugins, however each case is best looked at seperately to learn about the details. If you have questions how to use xEdit or suggestions how to improve it or its error checking, use the xEdit discord.

Building a working load order is the responsibility of the user. How to do that is taught for example by many modding guides and videos. How to use tools like xEdit is explained in its manual and also by guides/videos. These are a requirement for tools like DynDOLOD to work and to be used and existed long before DynDOLOD was conceived.

[primem0ver]

  On 3/18/2025 at 7:22 AM, sheson said:

The main reason is outdated plugins, however each case is best looked at seperately to learn about the details

Expand  

This may be well be true... but more often then not, there is no "updated" plugin.   Such is the nature of modding life when it isn't your real job.  Of the 12 I did yesterday, only 1-2 had an update.  (I updated 2 but one may have happened before I got to the UI). 

 

  On 3/18/2025 at 7:22 AM, sheson said:

Problems that stop the process are because of errors in the setup, mods, load order, unknown situations, bugs with the tools or third party issues (like OS, antivir, drivers, crapware, hardware etc.) that prevent a successful or safe LOD patch generation. As explained in the Generation Instructions, finalize the load order, install mods, sort and resolve conflicts.

Expand  

All of this has been done for the most part.  I am very aware of and don't install "crapware."  (I am assuming you mean anything beyond an anti-virus that software companies like to sell to the computer illiterate to assure them their computer is "safe" and conflict free).    "Resolve conflicts" is the only one that may or may not apply here.  I have a load order sorter which uses LOOT rules and some custom rules.  However, my use of that term generally applies to conflicts based on mod order in MO2, and not load order.  Yes.  I am aware that this can affect the outcome (different mod order affects which art is used for the LODs) but it shouldn't lead to the kind of errors I am getting.  I use a lot of mods so I generally run through the DyndoLod process twice.  The first to make sure the load order works in general.  Next, I test out the "load order" (more appropriately the "mod order") and get rid of/resolve small detailed issues I don't like.  Then I do a final DyndoLOD run. 

In the past I have run into a few of these "Unresolved Form IDs" as well.  But I don't recall there being this many.  That might be because some mods are updated while others aren't.  Your description includes at least one thing I noticed so far that will make it easier to nail down which items to address (such as the virtual machine stuff).  However...

  On 3/18/2025 at 7:22 AM, sheson said:

DynDOLOD only checks a small subset of records that are relevant to its patch generation and there is no intention to do anything beyond what is needed for LOD generation.

Expand  

This is exactly what I meant in my post when I said that you know what qualifies a record for needing to be fixed.  It is those details that can be used to make a quick "prescan" to make a list of mods that need to be fixed.  If you aren't interested in doing this, then perhaps you can just pass along these details.  As I stated in my post, my utility scans the output of xEdit to find Unresolved Form ID references.  Specifically it looks for this in the xEdit log: "<Error: Could not be resolved>" and tags these mods as potential causes of this particular problem.  I can now filter VMAD sub-records due to that specific details.  Are there any more criteria which could help the ones that need to be isolated and fixed?  Perhaps the types of records or sub-records your utility looks at?  You can get specific with me as I have spent 5 years studying this stuff in detail for my utility.  (The only reason I haven't released it is because it is very buggy due to changes I make at times like these when I just want to play the game.  Once I have the time to get rid the bugs I ignore in order to get to the game, I will offer a public release.)

[sheson]

  On 3/18/2025 at 8:24 PM, primem0ver said:

This may be well be true... but more often then not, there is no "updated" plugin.   Such is the nature of modding life when it isn't your real job.  Of the 12 I did yesterday, only 1-2 had an update.  (I updated 2 but one may have happened before I got to the UI). 

Expand  

if an updated version of an outdated plugin exists does not change the fact if an error in the load order exists that needs to be fixed.

  On 3/18/2025 at 8:24 PM, primem0ver said:

"Resolve conflicts" is the only one that may or may not apply here.  I have a load order sorter which uses LOOT rules and some custom rules.  However, my use of that term generally applies to conflicts based on mod order in MO2, and not load order. 

Expand  

Conflicts applies to conflicts in plugins/record just as well. https://tes5edit.github.io/docs/6-themethod.html

  On 3/18/2025 at 8:24 PM, primem0ver said:

This is exactly what I meant in my post when I said that you know what qualifies a record for needing to be fixed.  It is those details that can be used to make a quick "prescan" to make a list of mods that need to be fixed.

Expand  

Unresolved form IDs (or other errors) in records that are not specifically checked by DynDOLOD also need to be investigated and fixed just the same. Use the xEdit error check to find, investigate and fix errors.

Properly made plugins or properly build load orders do not have unresolved form ID errors usually. Ignoring such errors because they do not seem to cause issues in the game or they do not prevent DynDOLOD from creating a LOD patch is not really proper modding practice.

To know if an unresolved form ID reported by xEdit can be ignored or is a soft error (the unresolved form ID is actually resolved in the game once everything is loaded) depends on the specific error and involved plugins/load order.

[primem0ver]

  On 3/18/2025 at 11:04 PM, sheson said:

if an updated version of an outdated plugin exists does not change the fact if an error in the load order exists that needs to be fixed.

Expand  

 

  On 3/18/2025 at 11:04 PM, sheson said:

Properly made plugins or properly build load orders do not have unresolved form ID errors usually.

Expand  

From where I sit, the practical implications of these two statements are at odds with each other.  Yes... "properly made" plugins don't have unresolved form IDs.  However, it is a large modding community with an even larger collection of mods.  Some authors are active, some aren't.  Some have busy lives and get delayed in updating.  There is no way to keep mods without current authors in sync.  I am not speaking from the perspective of a mod author.  I have never uploaded a Bethesda mod.  My only file on Nexusmods is a utility (called ENB Workshop) I wrote 9 years ago.  Rather, I am a mod user who has no control over whether or not a mod author follows "proper modding practices."   These errors will appear and as you stated, they should be fixed.  I am not debating that and never intended to. 

I also know that it is my own responsibility to deal with the consequences of my choices.  However, I am not sure it is entirely reasonable to expect people who really enjoy mods to only use those that are error free (especially since there is no set way to predict that).  It follows that people like myself, or any of us involved in this thread (who don't author mods) are going to encounter errors like this.  While it would be nice for you to create such a utility or script, I don't expect that either.  All I want is a bit of information so that I can write one.  I already have several screenshots of pre-UI/TexGen errors.  I am now exclusively curious about this particular type of error.  (Pictured below.  Yes... I have uploaded the updated mod for this particular error.  Its just the latest error I ran into last night as an example).

If you are inclined to give such information, a list of which types of records (and subrecords) DyndoLOD is looking at that results in this kind of error would be all I need.  Two (probably not so educated) guesses off the top of my head would be TXST records and/or MODL subrecords.

Edited March 19 by primem0ver

[sheson]

  On 3/19/2025 at 5:52 AM, primem0ver said:

However, I am not sure it is entirely reasonable to expect people who really enjoy mods to only use those that are error free (especially since there is no set way to predict that).

Expand  

The requirement for tools like DynDOLOD to be able to work is a properly build load order. The same is typically required for mods and the game to work properly as well. The tools, explanations, guides, help systems, communities etc. to learn and achieve that exist since before DynDOLOD was made. It is unreasonable to expect something to work despite its requirements not being met.

  On 3/19/2025 at 5:52 AM, primem0ver said:

While it would be nice for you to create such a utility or script, I don't expect that either.

Expand  

xEdit already exists and is the tool to check the load order for unresolved form ID. Generally, using tools like xEdit is a requirement to build a working load order, for example for cleaning, conflict resolution, finding and fixing errors etc. It just so happens that I documented a couple recurring issues relevant to the LOD patch generation to help troubleshooting and fixing of issues. That only covers a fraction. If you have questions about xEdit or want to help to improve it or its documentation to improve finding and fixing errors in plugins or load orders, I suggest to use the xEdit discord.

  On 3/19/2025 at 5:52 AM, primem0ver said:

All I want is a bit of information so that I can write one.  I already have several screenshots of pre-UI/TexGen errors.  I am now exclusively curious about this particular type of error.  (Pictured below.  Yes... I have uploaded the updated mod for this particular error.  Its just the latest error I ran into last night as an example).

If you are inclined to give such information, a list of which types of records (and subrecords) DyndoLOD is looking at that results in this kind of error would be all I need.  Two (probably not so educated) guesses off the top of my head would be TXST records and/or MODL subrecords.

Expand  

What are you actually curious about this particular message?

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload.
Use the Copy message to clipboard link to post the text of a message instead of a screenshot as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text
Use search to find similar threads for the error message like https://stepmodifications.org/forum/topic/15567-unresolved-formid. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-Search

Click onto the link Click on this link for additional explanations and help for this message as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages. It will open https://dyndolod.info/Messages/Unresolved-Form-ID:
Start by checking the plugin and record with xEdit mentioned in the Error in ... message.

If using the latest versions of the mentioned plugins, the form ID xx1E58ED is a REGN record defined in Cutting Room Floor.esp that is used by the mentioned CELL record in the XCLR - Regions element.

 

The LOD generation process deals with the mentioned main records:

https://dyndolod.info/DynDOLOD-Reference#3-Scan-base-records
Build a list of ACTI, CONT, DOOR, FURN, MSTT, STAT, TREE, GRAS base records suitable for LOD.
If a base records defines texture sets (TXST) to replace textures on the full model, they are processed to try to apply a matching texture replacement on the LOD model.
The list of base records is defined by the DynDOLOD INI setting BaseSignatures.

https://dyndolod.info/DynDOLOD-Reference#5-Scan-worldspace
Scanning a worldspace looks for references (REFR records) that use base records for which LOD models have been found in step 3.
The processes also involve worldspace (WRLD), cell (CELL) and land (LAND) records naturally. Also light (LIGH) base records are accessed in case fake lights options are checked.

Occlusion generation also involves accessing region (REGN) records and using locational swaps with BOS may in addition also access location (LCTN)  records.

The records with all their elements are relevant. The list is probably incomplete, for example also due to the fact that *.patch files can potentially access any possible record for example.

[primem0ver]

  On 3/19/2025 at 7:54 AM, sheson said:

Build a list of ACTI, CONT, DOOR, FURN, MSTT, STAT, TREE, GRAS base records suitable for LOD.
If a base records defines texture sets (TXST) to replace textures on the full model, they are processed to try to apply a matching texture replacement on the LOD model.

Expand  

Thanks!  That is exactly the kind of thing I was looking for. I will glean more from your other linked sources.  I appreciate it.