Repeated Crash while loading in plugins

[NairSiddharth]

Hello! I keep getting an error while my plugins are loading in to begin the selection process for NPCS. I suspect its related to the amount of plugins I'm loading in because I'm trying to use this program to reduce my plugin count to below the allowed amount (287 esps->254 esps). I'm not 100% sure though which is why I'm uploading this report. Please feel free to ask any questions or close this if previously addressed. Looking forward to hearing back.
Log_20210628_114548_7048429.txt

[focustense]

It's definitely not related to the number of plugins - those load order limitations only affect the game itself and possibly some xEdit-based code.

The usual reason why the app might fail to load is missing masters, which #2 makes effectively impossible, although I haven't created a new release with those changes yet. In your case, it looks slightly different. We've got this error:

System.Collections.Generic.KeyNotFoundException: The given key '480C1F:Relationship Dialogue Overhaul.esp' was not present in the dictionary.
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at Focus.Apps.EasyNpc.Mutagen.MutagenAdapter.ReadNpcRecords(String pluginName, IDictionary`2 cache)
   at Focus.Apps.EasyNpc.Main.LoaderViewModel`1.GetNpcs()

Although I can't be 100% sure without line numbers (i.e. running it with a PDB file), it's very likely to be this line:

if (formKey.ModKey != modKey)
{
    var npc = cache[formKey];
   // ...

Specifically, this code will throw if the NPC isn't in the dictionary yet, and if it's not in the dictionary yet, then it hasn't encountered the master for that record yet. In this case, it's looking for an NPC from RDO (Relationship Dialogue Overhaul) but hasn't seen it yet. And RDO does indeed declare a few new NPCs.

The problem here is that your load order is out of order. You have plugins that depend on RDO that are loading before RDO. As a consequence, there is nothing that EasyNPC can do that will actually make sense in this context; it either throws an exception like what it's doing now, or it skips the record from whichever plugin it's currently on, leaving you confused as to why it's not showing up later.

In theory I could do something similar to xEdit's "smart load" - that is, reorder the load order internally so that dependencies are always loaded before anything that depends on them. The reason I don't like this approach, and would rather not do it, is that what you end up with is arbitrary and may not reflect what you're actually trying to accomplish with a particular load order. At best, I could improve the error messaging here, or better yet, add some warnings or messaging to the loader screen similar to those added for #2, preventing the app from being started with out-of-order plugin lists, treating it similar to a missing master.

tl;dr, you need to sort your load order. If it's not already obvious to you what that means, just use LOOT. If you intentionally don't use LOOT and prefer to do your own sorting, you have to make sure that whenever plugin B depends on master A, then master A gets loaded first (is higher in the plugin order).

[NairSiddharth]

Thank you! I ran LOOT right before ordering this and thought I had addressed this :/. Time to go back, tweak my LO manually and I'll let you know the results. Again, thank you for the guidance.

[focustense]

Always a possibility that I misinterpreted the log - don't think so, though. Let me know if adjusting the load order doesn't resolve it.

In the meantime I've tagged this usability as it does point to some possible improvements in guards and/or error messaging.

[NairSiddharth]

So I just was able to test it during a work break, I'm still getting the error. It appears to be the same error related to the same files, but I've confirmed that they're in the correct order :/

Log_20210628_160121_6104306.txt

[focustense]

You may be right, the error does seem to come up when loading RDO Updated, and I can see that even in the log it loads after RDO.

Have you tried taking a look at these two plugins together in xEdit/zEdit? The log itself is not really ambiguous as to the cause; it's pretty clear that it's finding an NPC record in RDO Updated that it can't find in Relationship Dialogue Overhaul. Therefore, my second guess would be a version conflict: the version of RDO Updated that you have was designed for a newer (or perhaps older) version of RDO than the one you're using, and includes a reference to an RDO NPC that doesn't actually exist.

Can you open up RDO (not RDO Updated) in one of the editors and see if there is actually an NPC with the form ID 480C1F or 00480C1F?

[focustense]

Incidentally, I have RDO in my load order and don't see any form ID like that.

The prefix ("05") isn't important, that's just the current position of RDO in the load order. So in this particular load order I should see 05480C1F, but there is no such NPC. And my version of RDO is current, as far as I know.

Another out-there possibility is that you're using a converted Oldrim (LE) version of RDO, rather than the SE version, or that RDO Updated was designed for LE rather than SE. I don't have the LE version to check. Sometimes the SE versions do not preserve form IDs and aren't actually compatible with updates or add-ons designed for LE.

[NairSiddharth]

Yeah I'm not seeing it either. Weird thing is that I've grabbed this one from the page on SSE nexus. So I'm coming up stumped as well. Possibility that the RDO updated plugin is wrong? EDIT-> I'm not even seeing it in SSEedit in the RDO update. I don't know where its coming from. :/

[focustense]

I can see it in xEdit. You're probably fixating on the two-digit prefix which doesn't matter. The string to look for is 480c1f.

The record is italicized, which is apparently some concept I'd never heard of before called "record injection", which is, quite literally, declaring a record as an override that does not exist in the master. It's an override that doesn't actually override anything. The best analogy would be something like a polyfill in JS.

This seems like a bad idea for so many reasons, not least of which being that changing the form ID for any reason (including merging or ESLifying) has the potential to create completely hidden and undetectable conflicts. But apparently, a number of mod authors have decided that this is a feature, rather than a bug, because they get to theoretically eliminate one master.

This leaves us with a conundrum: it's literally impossible to know whether a record is intentionally "injected", or just the result of careless merging/ESLifying, version conflicts, or other errors. Unless there's something I'm missing from the various pages describing the process, the record structure is exactly the same. There is nothing to actually identify an injected record, it's just assumed to be the case when the master doesn't have it.

I think the best thing to do right now is have EasyNPC ignore these records entirely, and maybe spit out a warning. I'd prefer not to go anywhere near this hornet's nest, and I've never heard of an "injected NPC" being overhauled anyway - in this case it is not even a human actor. So for now we just won't support them. I'll write a patch that checks for this exact condition - i.e. that the master is in fact loaded, but doesn't contain the record - and skip adding them instead of throwing an exception.

[NairSiddharth]

Ok. Is there anything on my end that I can do to solve the issue temporarily while the patch is being implemented? I assume it'd be solved by me disabling RDO Updated

[focustense]

The patch won't take very long, but if you're in a hurry, my suggestion would be to untick both RDO and the RDO update in EasyNPC's loading screen - or disable them in the mod manager if that's easier. From looking at these plugins in xEdit, none of them actually touch any vanilla NPCs, they just add a few new ones. So if you disable the update and the original RDO while running EasyNPC, then EasyNPC just won't touch those new NPCs at all, which is approximately the same as what you'd end up with anyway, unless you have an RDO-specific visual overhaul.

[focustense]

Almost ready to cut another release that includes this fix, there are just a couple of other things to take care of first. Workaround should be OK in a pinch, though.

[NairSiddharth]

Just as a heads up in case its relevant for anything, BUVARP is another mod with the same issue. I think I'm just going to wait for the patch :) . Thanks again for all the help with identifying the problem!

[focustense]

Don't think I've heard of a BUVARP, but I just finished uploading the release, which I know fixes the issue for RDO-U and I assume will fix it for your other mod.

[NairSiddharth]

If this is a quick fix and if possible, for the plugins that're marked as selected but can't be loaded, could you make it so that that these plugins could be unselected in the selection menu itself? Currently it just has the red warning and it cannot be unselected (as far as I can tell) without exiting and changing manually.
EX:

-be able to click the symbol and unselect the plugin

[focustense]

You don't have to unselect it - plugins showing that warning won't be loaded (they can't be).