modgroups

For a modgroup the be activateable, the order of the mods in the load order and modgroup must match.

If a modgroup is active, what it essentially means is that for each record that is contained in more than one mod of the modgroup, only the last (in load order) is visible. That’s it. The invisible record versions simply don’t participate in the normal conflict detection mechanisms at all.

Defining a modgroup essentially says: “I’ve checked these mods, when loaded in that order, against each other, and for each record, any conflict that may exists between them has been successfully resolved in the winning record version.”

A modgroup does not perform any merge or make any changes to any mod. All it does it hide away version of records that you’ve stated (by defining the modgroup) that you’ve already checked them against each other and the hidden record is simply irrelevant.

What masters the individual mods have is totally irrelevant, I’m not sure why you listed that information. All that counts is that a modgroup says “if these mods are loaded together in that order, then the winning version of the record out of these has been verified to be ok, don’t worry about the versions from the other mods in the group”.

I’m not quite sure what you are trying to show with that screenshot, but it looks correct to me, that is:

[SnB Homemaker Patch] hides away record versions from Homemaker.esm if another version is contained in Snap'n Build.esm or Snap'n Build - Patches_HMM.esp, and it hiddes records from Snap'n Build.esm if there is another version in Snap'n Build - Patches_HMM.esp.

[SnB SK Patch] hides away record versions from SettlementKeywords.esm if another version is contained in Snap'n Build.esm or Snap'n Build - Patches_SK.esp, and it hiddes records from Snap'n Build.esm if there is another version in Snap'n Build - Patches_SK.esp.

In both cases the modgroup promising that between the mods in each group, the winning record is correctly resolving all conflicts (even if they would still be detected as conflicts by xEdit).

This now makes it a lot easier to see that there are conflicts between Snap'n Build - Patches_HMM and Snap'n Build - Patches_SK, which would normally be hard to notice because of all the other (meaningless) conflicts that the modgroup is now hidding.

It is clear from this that it is necessary to create a Snap'n Build - Patches_HMM_SK (or SK_HMM, I don't know enough to figure out what would be the better load order to minimize the number of records that the patch needs to fix) which resolves any outstanding conflicts between the two patches if they are both loaded.

Once that patch is created and verified to resolve all remaining conflicts, another modgroup can be created:

[SnB HMM SK Patch]
Snap'n Build - Patches_SK.esp
Snap'n Build - Patches_HMM.esp
Snap'n Build - Patches_SK_HMM.esp

Which says that any records contained in more than one of these files do not conflict, and whatever record wins out of these 3 is the correct one.

That may actually not be exactly what you want, because if there are changes in the future, the above would hide conflicts between records in SK and HMM even if there is no record in SK_HMM that resolves the conflict, so you might be better served with this:

[SnB HMM SK Patch - SK]
Snap'n Build - Patches_SK.esp
-Snap'n Build - Patches_HMM.esp
Snap'n Build - Patches_SK_HMM.esp

[SnB HMM SK Patch - HMM]
-Snap'n Build - Patches_SK.esp
Snap'n Build - Patches_HMM.esp
Snap'n Build - Patches_SK_HMM.esp

The "-" means" "That mod must be present in that order, but records from it wont be hidden."

The result is that:

-If a record is present in SK_HMM and SK, the SK one will be hidden.
-If a record is present in SK_HMM and HMM, the HMM one will be hidden.

(Which implies that a record that is present in all 3 will only show up once with it's SK_HMM version.)

But:

- If a record is present in SK and HMM, but NOT in SK_HMM, both the SK and HMM version will show and you can see if there is a conflict that needs to be resolved by creating a merged version in SK_HMM.

Even if you then later decide that any remaining cases where a record is contained in SK and HMM but not SK_HMM are correct, it's better to add a 3rd modgroup:

[SnB HMM SK Patch - SK/HMM]
Snap'n Build - Patches_SK.esp
Snap'n Build - Patches_HMM.esp
-Snap'n Build - Patches_SK_HMM.esp

instead of going back to a modgroup with 3 modules, because the modgroups can be turned on and off individually.

The same applies to [SnB Homemaker Patch] and [SnB SK Patch], which should be split apart into two mod groups.

Now, this modgroup:

[Snap and Build]
Snap'n Build.esm
Snap'n Build - Bunker.esp
Snap'n Build - Capsule.esp
Snap'n Build - Greenhouse.esp
Snap'n Build - Industrial.esp
Snap'n Build - Real Estate.esp

Is probably not what you want. It says that all these files need to be loaded together and in that particular order for the modgroup to be activateable.

I don't know anything about that mod, but I would assume that the individual esp's are actually each optional and can be present or not.

One way to express that is to mark the files as optional:

[Snap and Build]
Snap'n Build.esm
+Snap'n Build - Bunker.esp
+Snap'n Build - Capsule.esp
+Snap'n Build - Greenhouse.esp
+Snap'n Build - Industrial.esp
+Snap'n Build - Real Estate.esp

But that might actually not really what you want either, because suppose there is a conflict between a record in, say Bunker and Industrial, that the version from Industrial is correct and the conflict shouldn't show.

It's more likely that what you really want is something like:

[Snap and Build - Bunker]
Snap'n Build.esm
Snap'n Build - Bunker.esp

[Snap and Build - Capsule]
Snap'n Build.esm
Snap'n Build - Capsule.esp

[Snap and Build - Greenhouse]
Snap'n Build.esm
Snap'n Build - Greenhouse.esp

[Snap and Build - Industrial]
Snap'n Build.esm
Snap'n Build - Industrial.esp

[Snap and Build - Real Estate]
Snap'n Build.esm
Snap'n Build - Real Estate.esp

Which will end up hiding records from Snap'n Build.esm if they are contained in one of the esp's. But if the same record is contained in multiple esp's, it will still go through normal conflict detection and you'll see if there is a problem.

One of the implications of the individual modgroups like that is that the order of the individual esp's is now no longer strictly defined by the modgroup. They could occur in any order following the esm.

With these individual modgroups, let's say again that there is some conflict showing up between Bunker and Industrial, but you've looked at it and decided that if Industrial is loaded after Bunker, the conflict is correctly resolved, you can then add a modgroup:

[Snap and Build - Bunker/Industrial]
Snap'n Build - Bunker.esp
Snap'n Build - Industrial.esp

which would hide that conflict away to.

In almost all circumstances, modgroups should only contain 2 mods, or if there are more, only have 2 mods that are not marked with a "-".

This way you minimize the chance of accidentially hiding away a real remaining conflict by accident.

Putting some modgroups into FO4Edit.modgroups is fine enough if you just want to use them for yourself, but modgroups are really designed to give mod authors the ability to distribute them with their mods, basically promising mod users: "I've checked these mods against each other and I am confident that there are no unresolved conflicts".

The way to do that is to include .modgroups files with the same name as the .esp or .esm in the download. xEdit will then read and process these modgroups IF the module of the same name is active in the load order.

So you could have a Snap'n Build - Patches_SK_HMM.modgroups file with the following contents:

[SnB HMM SK Patch - SK]
Snap'n Build - Patches_SK.esp
-Snap'n Build - Patches_HMM.esp
Snap'n Build - Patches_SK_HMM.esp

[SnB HMM SK Patch - HMM]
-Snap'n Build - Patches_SK.esp
Snap'n Build - Patches_HMM.esp
Snap'n Build - Patches_SK_HMM.esp

And place that in the mods folder together with Snap'n Build - Patches_SK_HMM.esp

xEdit will then load that modgroups file, if Snap'n Build - Patches_SK_HMM.esp is active in the list of loaded modules.



Now, the last issue then is the the promise in a modgroup really only applies to a specifics versions of the listed modules. That's especially important if some of the listed modules are from another mod author and aren't distributed in the same download.



Because of that, it is possible to restrict modgroups based on the CRC (same value that BOSS/LOOT is using). It would look like:



[SnB HMM SK Patch - SK]

Snap'n Build - Patches_SK.esp:12345678

-Snap'n Build - Patches_HMM.esp:A1B2C3D4,F9E8D7C6

Snap'n Build - Patches_SK_HMM.esp



That is, if a module is followed by a list of one or more CRC values, the modgroup is only available if the module has one of the listed CRCs.



That's pretty much everything important about modgroups.



The main point is that conflicts between different modules can be checked and resolved just a module or two at a time, and then when it is verified that there are no remaining actual conflicts between certain modules (even if they would show up in xEdit), they can be hidden away.



So if you have a complex load order with 100's of modules which shows up as 1000's of conflicts in xEdit that you could never ever sort out, you could instead start with just a module or two, resolve conflicts and define modgroups, then add another module, resolve conflicts and define modgroups and so on, in an interative process. Leaving you at the end with a load order with all conflicts resolved and no false positives showing in xEdit.



If you then later add another module into your load order, you will only see true conflicts that are actually caused by that one module, without them being hidden by 1000's of false positives.