First-class support for mod compatibility patches

[W-Drew]

Problem

Mod compatibility patches are, by nature, doubly linked. They require both the mod that provides the compatibility patch, and the mod that it's patching. Unfortunately, almost the entire modding process treats them as singly linked to the mod that provides the patch, Mod Organizer included. As far as MO is concerned, this can lead to issues such as:

• If you install the mod that provides the patch before the mod that it's patching, the author may have configured it in a way that instructs the installer to never prompt the user to install the patch, or the patch installation never prompts the user & instead does it automatically (which still does not happen if you install the patch provider first)
• As long as you're careful you can avoid the above when installing conflicting mods around the same time, but if you're introducing a conflicting mod a year after you installed the other? You may not even remember that you installed the other mod & need a compatibility patch if you have to manually select it in the installer
• If you disable one of the mods, you have to make sure you also disable the compatibility patch or otherwise risk mod bugs / being unable to load the game at all. You also have to remember to re-enable the compatibility patch when this mod is re-enabled

First-class support for mod compatibility patches

For starters, we should provide a way to manually link compatibility patches to mods. Linked compatibility patches will only be enabled if all of the mods they're linked to are enabled. Otherwise they're disabled. This will at least solve the post-installation recurring problem that you need to babysit the enabled status of compatibility patches.

With child mods (#1041) we would display compatibility patches under the linked mods to further improve how they are surfaced in the UI.

In the long term, we should improve our installers so that they install all compatibility patches regardless of whether both mods are present. If you install the conflicting mod later, the compatibility patch will automatically be enabled. We would need to hide these in the UI if the conflicting mod is not installed so you don't have 20 compatibility patches showing when you only have 1 conflicting mod installed.

The resulting impact is that compatibility patches become an automatic thing that mod users never have to worry about (though given MO's audience is power users compared to NMM / Vortex, there will likely be some fine grained control options we need to provide)

[twizz0r]

Sounds interesting.

Doesn't LOOT already handle this (providing info on missing patches)? MO shows missing masters if a patch author has added them correctly. FOMOD installers are increasingly sophisticated, auto-detecting installed mods.

I could be missing something but I'm not sure what it is that this solves that can't be fixed by the tools presently available, knowing what's in a LO and some RTFM on the users part.

[W-Drew]

LOOT only affects plugins. This is aimed at install-level decisions that scripted installers can make which includes far more than just plugins.

This does not solve any problem that can't be solved by existing tools + RTFM. If you read every mod description & review your entire mod list before installing, enabling, or disabling mods, this would not provide any benefit to you. Given that MO is tailored towards power users with hundreds of installed mods though, a comprehensive review of every mod is not feasible at that scale. Nor is it a valuable use of time to regularly repeat this. This Issue eliminates these problems via upfront linkage to enable MO to handle most of the involved busywork and allow mod users to spend their time more valuably.

We are planning to add this for non-install-level dependencies in #838 as well.

[twizz0r]

This is user-applied correct? So the user has to do the homework at least once...yes?

Considering MO and LOOT cover plugins, is this for things like SKSE mods that depend on an external DLL (like address library or jcontainers) or hotfixes/updates for mods without a plugin? What happens when a mod is updated and the fix/update is no longer necessary?

Wouldn't it be more beneficial to have a loot-like internal database to eliminate the homework altogether? Maybe a way for users to share rules would be much more practical. What about a wabbajack like function that resolves dependency issues on the fly (poll loot then grab files)?

Thanks for taking the time to answer my questions.

[Al12rs]

@twizz0r There is no way to identify a mod currently as people can name and repackage mods however they like so there is no way to implement a master list for mods like for the plugins.

What @W-Drew is proposing here is to basically expand fomod capabilities to let mod authors define requirements, but this is also useless as long as there is no way to correctly identify mods.

I talked to the nexus guys and they said that they plan to per file dependency system like there is currently for mods (can be queried through the API) which would make this system work assuming we store the Nexus file Id, which I'm not sure we are doing currently. Of course this only works for queried downloads from nexus.

Still wouldn't be perfect and still would not cover most cases as a single file could have different dependencies based on which fomod options are chosen (so here the fomod expansion idea comes in).

To expand fomod standard we need to discuss with other mod manager authors to see if they have similar needs and suggestions/alternatives or even reasons not to add this.