Main Table Of Contents
xEdit Mod Groups
Contents...
• 4.3.1 Creating a ModGroup form within xEdit
• 4.3.2 Editing a ModGroup form within xEdit.
• 4.5 Adding and Deleting a CRC value
• 4.6 Quotes and summaries about ModGroups
4.1 - ModGroups
What are ModGroups?
ElminsterAU
One way to see mod groups is to say, "all overrides from a source file are guaranteed to contain all relevant changes from overrides in all target files listed above it, so they don't need to be shown anymore."
If you create a mod group, you are saying, "I have verified that this (above) statement is true".
Modgroups are the answer to the "I installed [Insert Mod Here] and everything is red! What do I do now?" question.
There are groups of mods that, while raising heaps of conflict warnings, should be considered as non-conflicting. e.g. if you've installed FCOM then you are not interested in seeing conflicts between the mods that make up FCOM. The solution for this is to define a mod group. Mod groups are stored in a TES4View.modgroups file in the same directory as TES4Edit.exe.
Not all modgroups defined in that file will necessarily show up in the selection list. ModGroups for which less then 2 plugins are currently active are filtered. If the load order of plugins doesn't match the order in the mod group it is also filtered.
This file contains example mod groups. These are just examples and not meant as a guarantee that these specific modgroups are "clean" and conflicts can safely be ignored.
• Example_modgroups.zip Download Link
What's the effect of having a mod group active?
When the detail view for a record is generated and multiple files of the same mod group modify this record, then only the newest of the files in that modgroup will be shown. So instead of seeing 5 different files with numerous conflicts you are only seeing the newest file in that mod group. This also affects conflict classification.
It's worth pointing out here that if a record is overridden by both plugins in a mod group and other plugins that normal conflict detection will still work perfectly.
Basically this system can be used to reduce a lot of noise from the conflict reports.
4.2 - Choosing a ModGroup
For a modgroup the be activatable, 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.
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.
4.3 - Built In Editor
4.3.1 - Creating a ModGroup form within xEdit
If using MO2 close xEdit and move the new ModGroup from your overwrite folder to the mod folder for which the Modgroup is intended for. This can be done by double clicking overwrite and just dragging the .ModGroup file over the mod in question. It is best to keep the ModGroup with the mod. That way if you deactivate the mod its ModGroup will not show up in xEdit.
4.3.2 - Editing a ModGroup form within xEdit.
You will not be able to activate the Mod Group if all the conditions are not met.
4.4 - ModGroup Flags
• 
- All modules NOT flagged as optional must be present for the ModGroup to be valid.
• 
- Override records in this module can be hidden.
• 
- A override record in this module will cause the overrides with the same FormID to be hidden from all modules flagged as Target and listed above this Source in this ModGroup.
• 
- If this module is loaded, the ModGroup is invalid.
• 
- If not flagged, then the module must be loaded in the same order as listed in this ModGroup. There are two possible flagged values for this column.
• 
- The load order of the module does not matter at all.
• 
- all consecutive modules with this flag form a Block. Any module above the block must be loaded before any module in the block. Any module after the block must be loaded after any module in the block. The modules inside the block can load in any order.
For more information see Quotes and summaries about ModGroups.
4.5 - Adding and Deleting a CRC value
4.5.1 - Adding a CRC value
4.5.2 - Deleting a CRC value
4.6 - Quotes and summaries about ModGroups
Target:
• Override records in this module can be hidden.
• Target means the record can be hidden.
• Another way to see it is that it says: this source record preserves then intent of the changes of all these target records, so they can be ignored now.
Source
• A override record in this module will cause the overrides with the same FormID to be hidden from all modules flagged as Target and listed above this Source in this ModGroup.
• Source means it hides all targets above it.
• Source means that if a record in this mod is found, then it will hide the versions of the same record from all mods listed above it that are targets.
Ignore load order:
• The modgroup will be available regardless of the order of the mods.
• See Quote: Ignore Load Order
• <filename>:CRC32 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.
ElminsterAU
If you need to have modA, modB, patchAB loaded in that order, and you want unpatched records from b to override a, you would keep the default. But if a and b can be loaded in any order, you would have them as only targets and ignore lo in block
ElminsterAU
For example, you could have a mod group with modA and modB as target, and patchAB as source. A record in patchAB would hide records with the same form id from both modA and modB. However, records with the same FormID in modA and modB would NOT be hidden if there is no record with the same form id in patchAB
ElminsterAU
Mod groups don't "hide conflicts", they hide complete records. The fact that conflict detection against the not hidden records might then have less conflicts is only a consequence of that.
When a record is found in a module that's flagged as source in a mod group, then (override) records with the same form id are hidden from all modules which are flagged as target and listed above in the same mod groups that had the source.
Quote
thegamemaster1234: I don't know what "in Block" load order ignore means though
ElminsterAU: It means that the load order between all mods in an uninterrupted block that are flagged as such is ignored
ElminsterAU
As for the difference between "Ignore Loadorder Always" and "Ignore Loadorder in block", the later allows you to have:
:Block of 5 modules x.esp :Block of 3 modules
With the order of the modules in each block being irrelevant