primem0ver

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

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.

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

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.

@sheson. Thanks for your input. Found one problem: my new merge mod to settle the Cities of the North problem had a higher mod priority so was overwriting some of the textures. That was my bad. I should have thought of it. That solved the issues around Riverwood and Whiterun. Will check into the other issues as I play.

Ok. This time I have pictures and logs. I also have to report that this problem has gotten worse since I started playing through the various versions of DyndoLOD. I have been "finishing" a load order in my spare time (not a lot since September) since June. In June through August, when running Dyndolod, I have gotten the occasional plus shaped object in certain areas of Tamriel. Just a few (I only remember seeing 3 near Winterhold). Last time I reported 4-5 between Riverwood and Whiterun which was after a rebuild in November. As you can see from the pictures, that has changed with later versions of DyndoLOD (up from 95 to 106). The only thing that has changed since my previous post (in November which was apparently deleted) was the DyndoLOD version and me switching from Sunhelm to Last Seed. Plus one or two other minor mods that looked interesting. Nothing to merit the changes you see in the pictures. Before that, back in September, I added a bunch of patch mods to fix some major issues around Morthal and Dawnstar caused by Cities of the North mods. I may have added a few more patch mods but little else. Before that I had ZERO tall plus shaped objects between Riverwood and Whiterun. So something has changed with DyndoLOD to cause these issues. As mentioned earlier, in the original build (with zero in this scene) the only plusses I ever saw in the game that far back were 2-3 of them near Winterhold. That is all. Now as I look over the Whiterun Valley from the path from Riverwood, this is what I see (two different runs of DyndoLOD. The first one without HQ trees, the second with.) The log can be downloaded here.

Sorry about not including the "Copy Message to Clipboard". I didn't here either until Crash4. I have been including the logs that have been written to when the errors occured (based on timestamp). So the reason the others were left out was because they weren't updated... probably because I didn't exit Dyndolod when making the copies (write buffer wasn't cleared/file updated). I have included the requested files this time in Crash3 and Crash4. The fourth file is too big to upload here so you can get it here. I will try your linked version on my next attempt. EDIT: The issue might have something to do with having Bashed Patch,0.esp being enabled... or not. Not sure. It was disabled for times that it worked (at least the most recent ones). Crash2.zip Crash3.7z

I had to redo the entire build because not everything was made correctly due to a crash caused by music files I didn't mean to include in my load order. So it appears there might be a "pattern" after all. The same errors repeat once per build session but it seems to not repeat any of these errors in the session. (By session I mean a single set of built attempts until I get the output). So here is the first crash. I will add more to this post for each crash. The logs and an image of the crash are in each report. Crash1.zip

I am getting "random" errors (crashes) pointing to two merge mods that I have created. I say "random" because they are inconsistent. Referenced objects change, the source of the error changes, and many times the errors don't occur at all. I am posting this because I recently changed one of the merges and have to rebuild. Since then, the crashes are more frequent. The errors seem to be erroneous if you will forgive the pun as there doesn't seem to be anything wrong with the reference data in question when scanned for errors in xEdit (some errors do exist in these files but not the ones being referenced and not in the objects mentioned). I think the errors are related to large reference objects if I remember correctly. I will post such an error if I can catch it this time around. EDIT: As mentioned, the errors are inconsistent. This time (my fourth time through) running Dyndolod no crash occurred. I am curious if there is a reason for this.

I am pretty frustrated with SSEEdit lately. There is no 64 bit version with the latest download and I cannot get my older version (4.0.3h) to work anymore. It keeps telling me there was an error and that editing is disabled. I can't run scripts or anything. (There IS NO ERROR in the log). Was something changed? Every time I try running 4.0.4 I get an out of memory error. Whats more I can no longer post on Discord to get help. I have to sign up? EDIT: More Info: Version 4.0.3h used to work fine without using the 64 bit version until a couple of weeks ago. The 64 bit version seems to be working ok so I guess I will use that until I get an answer.

I did this. However I think I fixed it. Tree LODs seem to be working now. It was an issue with MO2 where old (bad) output that had been redirected to overwrite was overwriting my most recent run of dyndolod.

I am relatively new to DyndoLOD (and Skyrim SE). Normal LODs seem to work and load ok. However I can't get any tree LODs to work After running DyndoLOD not even Vanilla tree LODs load. I am using the ultra tree feature because when I used the regular trees it said it ran out of space in the lod files (or some such similar warning). I am using several tree mods as well as seasons.

Oh... thanks. Yup. That worked. I am used to that being a button.

This is a suggestion/question as I am surprised this feature doesn't already exist (to me it is a fairly obvious feature). I am curious if there is a reason why a "Select All" option doesn't exist on the "Select Worldspaces" page. Is there a reason why we shouldn't do all world spaces? EDIT: I have used dyndolod a few times in the past with mixed results. Last time the trees didn't turn out well but with the new version I hope things go better.

Hello GrantSP. How do I report my issue there? I finally logged on today after building a new system. Is this a real time location? I typed it in the issue reports section.