Skip to content

Instantly share code, notes, and snippets.

@CovenantTurtle
Last active May 1, 2022 10:48
Show Gist options
  • Save CovenantTurtle/9992289653e91455a06753ef6275590a to your computer and use it in GitHub Desktop.
Save CovenantTurtle/9992289653e91455a06753ef6275590a to your computer and use it in GitHub Desktop.

"The Method" - A basic guide to using ModGroups for a clean install of SSE or FO4 in xEdit through Mod Organizer 2

"The Method as such is about getting human eyes, as effectively and with as little redundancy as possible, on every conflict. It doesn't explicit tell you how to recognize and fix conflicts that you then see. That's something you'll have to learn as you go along and for which is pretty much impossible to create clear step by step rules for anyone to follow."

  • ElminsterAU, original developer of xEdit

IMPORTANT NOTES:

  1. This guide assumes that you are already familiar with manual conflict resolution using xEdit. It also assumes that you are competent enough to check the author-advised requirements, possible conflicts, and installation instructions of any mods you install. It is on YOU to properly follow the instructions for whatever you install!

  2. Script and NavMesh conflicts, while being relatively uncommon, are more difficult to resolve and require use of the appropriate Creation Kit/GECK for the game you're working with, and thus are beyond the scope of this guide. If you come across such a conflict, look it up first! Trying to fix it yourself without knowing what you're doing has a 99.999% chance of breaking whatever you're working on.

  3. So far only Skyrim Special Edition and Fallout 4 support the ESL flag - however, one can still follow this guide for Fallout 3, Oblivion, New Vegas, and Skyrim Legendary Edition, with a few minor differences:

    • DO NOT clean masters for Fallout 3 or New Vegas! This will break your game.

    • Instead of flagging your micropatches as ESL, keep them as normal .esp files and merge them either by hand in xEdit, or using a tool such as zMerge (recommended for merging 254 plugins or less) or Wrye Bash with only the merge plugins options enabled (advanced users only). Launching xEdit with the parameter -pseudoESL will show you which files could in theory be safely flagged as ESL, and thus are also safe to merge. Whenever using an automated tool to generate a module of some kind, ALWAYS go over it by hand in xEdit to make sure everything is as it should be. No exceptions.

    • IT IS ON YOU TO RESEARCH HOW TO PROPERLY SET UP EACH GAME! This guide is simply an overview of the best technique for conflict resolution - it does NOT include instructions on which mods to install (except the Unofficial Patch for SSE/FO4), or how to properly install them.


  1. Start with a completely fresh load order. Install the Unofficial Patch and launch xEdit.

  2. Select all the modules in the list on the left, open the context menu, and select “Create ModGroup”. When prompted “Do you want to include the current CRC32s?”, select yes[1]. Enter an appropriate name in the field at the top (e.g. Main Masters), and hit OK.

    • [1]: This makes it so that should any of the mods within the group be updated, the entire group will be disabled when loaded in xEdit. If this happens, check for any new conflicts within the mod group, deal with them as necessary, and then select the “Update CRC in ModGroups” option in the context menu of the module list.
  3. In the next menu, when prompted “In which module’s .modgroups file should the new ModGroup be stored?”, select the Unofficial Patch and hit okay. Finally, when prompted “Which ModGroups do you want to activate?”, select the group you just made and hit OK.

  4. Close xEdit, install your next mod of choice (ONE AT A TIME), and check to see if it added any modules (i.e. .esm, .esp, or .esl files). If not, keep installing your mods one at a time until a module is added. Launch xEdit again with the parameter -veryquickshowconflicts, which can be added in the “…” menu of Mod Organizer, in the “Arguments” field for xEdit. This can be removed when you’ve finished making ModGroups, or you can make another entry specifically for it.

  5. Perform manual conflict resolution between any conflicting modules[2], including ITM (Identical To Master) and UDR (Undelete and Disable Records) cleaning where necessary[3].

    • [2]: When making manual patches which simply consist of overrides, it is recommend to use the template of an .esp file with the ESL flag. This makes it occupy a “light slot” rather than a “full slot”, thus maximizing the number of modules you can load at any one time.

    • [3]: Cleaning is easily accomplished using the -quickautoclean parameter for xEdit. Simply load a module in xEdit using this parameter and allow it time to work, then close the program when finished and repeat for all modules which need cleaning. Do NOT attempt manual cleaning unless you know precisely what you are doing, and can fully explain why -quickautoclean doesn’t do the job for you.

  6. In the View tab, when viewing a record with overrides from two or more modules (not including Skyrim.esm or equivalent), right click the name of a module in the banner along the top and select “Create ModGroup”. This will open the interface for creating a ModGroup, and prompt you to select which of the modules currently in the View tab you’d like to add to it – this should include your patch for the mod you’re currently resolving conflicts for, if you’ve made one. Alternatively, select the conflicting modules in the list on the left, right click to open the context menu, and select “Create ModGroup” from there.

    • [4]: Ideally, ModGroups should be made as small possible, including the fewest possible modules while still properly dealing with all conflicts. Doing this ensures greater freedom to disable individual modules without introducing false positives to xEdit’s conflict filter.
  7. Just as with the first ModGroup you made for the Unofficial Patch and the game itself, click yes to CRC32s, and name the group appropriately[5].

    • [5]: Pressing Ctrl+N while having a module selected will set the name of the ModGroup to the name of the module, without the extension.
  8. Before hitting OK, assign the appropriate flags to each module within the ModGroup by clicking on the tiles to the right of each module’s name. The different kinds of flags are as follows:

    • Optional: If a module is flagged as “Optional”, the ModGroup will load regardless of if it’s missing.

    • Target: If a module is flagged as “Target”, its override records are hidden if it loses a conflict to a module further down within the ModGroup.

    • Source: If a module is flagged as “Source”, an override record within it will cause the overrides with the same FormID to be hidden from all modules flagged as Target and listed above this Source in the ModGroup.

    • Forbidden: If a module is flagged as “Forbidden” and loaded in to xEdit, its respective ModGroup is automatically disabled until the module itself is disabled.

    • Ignore LO:

      • If not flagged, then the module must be loaded in the same order as listed in the ModGroup.

      • If flagged as “Always”, the ModGroup will load as long the module is present, regardless of load order.

      • If flagged as “In Block”, all consecutive modules which share this flag will 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

  9. Once finished assigning flags, hit OK to go the next menu. Store the ModGroup with the module which does the most conflict solving[6], and hit OK.

    • [6]: ModGroups are best saved with the module which corrects, or overwrites, whatever you want fixed. For example, in a conflict between two modules, even if you don’t make a patch because you’re satisfied with the way the overwrites occur, saving the ModGroup with the latter-loading module ensures that the relevant ModGroup is only active when the overwriting module is present. This ensures that conflicts will be detected when the overriding module, often a patch, is absent. Note that multiple ModGroups can be stored with a single module.
  10. Continue creating ModGroups and manual patches as required to resolve all conflicts reported by xEdit for the module you’ve loaded[7]. You’ll know this is the case when the tree-view in the left pane of xEdit is empty after running the conflict filter, which can be refreshed by right clicking said pane and selecting “Apply Filter to show Conflicts” from the context menu.

    • [7]: If adding a new module results in lots of conflicts showing up, you may find it useful to hold the Ctrl key when launching xEdit through Mod Organizer with the -veryquickshowconflicts parameter. This allows you to choose which modules you want to load, which can make it easier to resolve one conflict without seeing all the others.
  11. Repeat steps 4 to 10 until you’ve finished installing all your mods, and xEdit reports no more conflicts. You might like to remove the -veryquickshowconflicts parameter from xEdit in Mod Organizer if you chose not to make another entry for it.

@BLACKBERREST3
Copy link

Why is it through mo2? This can be done with only xedit. I believe your bias is introducing unnecessary dialogue.

@nicholasknight
Copy link

Why is it through mo2? This can be done with only xedit.

Because if you use MO2, you must launch xEdit through it due to the filesystem virtualization feature, otherwise xEdit will not be able to find your mods.

I believe your bias is introducing unnecessary dialogue.

Please don't throw ignorant accusations at people who are trying to help others.

@BLACKBERREST3
Copy link

wow! I don't even remember typing that above :( . I was reading the article to find out if there was an easy way to group conflicting mods after applying the "show conflicts" filter in xedit and I found out I commented on this page. You are right, I was being obnoxious. I think I was frustrated at the time for whatever reason. I remember back then it wasn't a good time if you were a vortex user on r/skyrimmods even though there was no functional difference between the two. I don't know if it's like that anymore, but I know some of the people on there have been pretty nice lately. I just want to say sorry for bringing the toxicity over here, no one deserves that.

side note in case anyone is curious; still using vortex, still don't see any downsides or limitations, and I have a stable build of 248 mods going on ae 1.6.323.0.

@BLACKBERREST3
Copy link

"Because if you use MO2, you must launch xEdit through it due to the filesystem virtualization feature, otherwise xEdit will not be able to find your mods."

I was a little confused by your answer re-reading it. I guess I left out context when I was badgering you. I have since learned about mo2s vfs system and your explanation of xedit in mo2 is pretty good. I'll add onto it for more info. Vortex uses hardlink deployment (limitation: staging folder must be on the same drive, but acts the same as a normal filesystem) so you can install xedit anywhere and point to the location of your games location. more info available here.

Thanks for your guide on modgroups, it is very useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment