With ModGroups, the way I envision it, the procedure to follow for resolving conflicts in a large and complex set of modules is the following:
(a) Load all your active modules into TES5Edit, activating all ModGroups "Apply Filter to show Conflict Losers" Look through the reported conflicts and pick 2 modules that seem to be conflicting with each other Close TES5Edit (b) Load only the two modules you picked. (Plus appropiate DLCs and all applicable Unofficial Patches, activate all mod groups for the UPs.) "Apply Filter for Cleaning" (we aren't going to be cleaning, at this point it's assumed that all your mods are already clean, but this filter preset is appropiate to then look through the records and see if there are any problems that need to be resolved) Look through the records of the two modules check out how they interact with each other. Depending on what you find you might decide that: The modules, while touching the same records, do not actually conflict in their current load order -> Create a ModGroup listing these modules, then go back to (a) and repeat The conflicts between the two modules might be resolved (or at least reduced) if the load order is reversed -> Reorder the modules, then go back to (b) and repeat There are conflicts between the modules that can only be resolved by a compatibility patch -> If there already exists one for these modules and you didn't load it, go back to (b) and this time load it as well If not, create a new one by doing a "Copy as override" on one of the conflicting records (into a new file), then manually resolve the conflict. Do this for all conflicts. Then close TES5Edit (saving the new file) and go back to (b), making sure the load the new patch as well
Obviously, that's only a general guide, not a hard and fast rule. There are certainly many cases (mods that come in multiple modules, mods that have numerus compatibility patches already, a 3rd mod that conflicts with two mods for which you've already created a compatibility patch, and so on) where you will need common sense, and experience, to adjust the procedure as needed.
But the general goal remains unchanged: defeat in detail.
ModGroups, when used correctly, allow you to resolve conflicts between a small subset of all your mods, and then, when you are happy that all conflicts in this subset are resolved, hide any remaining (potential) conflicts that are detected away, so that you can concentrate on another subset.
The best way to do this would be to start with an empty data folder, then after installing each mod, resolve all conflicts and create appropiate mod groups until the "Filter to show Conflict Losers" just returns an empty list.
Long term, I hope that mod authors that create compatibility patches will include appropiate mod groups with their downloads.
To help with preventing the possibility that the promise of a ModGroup (loading all these modules in that order results in all winning records being correct for this set of modules) is broken (by updating one of the mods involved) without noticing it (so the mod group would then hide true conflicts), I've added the possibility to specify a list of valid CRCs, e.g.: [Unofficial Skyrim Patch]Update.esm:E5B67BDA,1FDAB215 ;Original, CleanedUnofficial Skyrim Patch.esp:FB709557 ;2.0.4
You probably shouldn't have any explicitly mods with the same name as the auto-generated ones. Just call yours "Cleaned Dawnguard", "Cleaned Heartfire", and so on... (or "Optimized Dawnguard" or whatever you want.. mine contain cleaned ESMs and [no longer needed with the changes in MO] copies of the original BSAs)
