Jump to content


Photo

Staged Conflict Resolution?


Best Answer ElminsterAU , 04 July 2014 - 06:38 PM

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
[/list]

 

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
Go to the full post


  • Please log in to reply
7 replies to this topic

#1 Muladhara86

Muladhara86

    Guard

  • Members
  • PipPip
  • 113 posts

Posted 02 July 2014 - 08:30 PM

A facet of this post that I'm still curious about is staged conflict resolution.  I rarely have long periods to work on this.  I want to work on merge patches in stages, building smaller patches similar/overlapping mods, then carrying forward the changes into the next patch, etc., until I have one for my core group of stable mods.  

If I can get to a stable platform on which to mess around on, and if it'll be stable enough that I can do said modding while getting to finally experience DG/DB content I will be content.

 

I think this should end up being a reasonable approach, but I'm not sure about the grouping specifics.  Here are the mods and categories I will potentially be working with:

 

 

A random REGS question: I don't care for EWDR v2+; can I use it, CWI, and ETaC - Winterhold w/o a patch, or is the ETaC Patch implying correctly that I must include the caverns if I want to get these three working together?


Edited by Muladhara86, 02 July 2014 - 08:31 PM.

  • 0

#2 ElminsterAU

ElminsterAU

    Prisoner

  • Mod Authors
  • 16 posts

Posted 02 July 2014 - 09:04 PM

Sounds like what you need is ModGroups. A feature that has been in xEdit going all the way back to when it was TES4View. To see what ModGroups are and also to get some enhancements I've implemented for them in the last few days, check out https://afkmods.igua...5edit/?p=151819 and the following post.


  • 0

#3 Muladhara86

Muladhara86

    Guard

  • Members
  • PipPip
  • 113 posts

Posted 04 July 2014 - 07:12 AM

That does sound like what I need!  I'm not sure I'm fully grasping it though; I'll have to read through it again when I'm more alert.  After reading that, I'm still not sure how I should go about grouping my mods.  It see,s as though ModGroups will need an entirely different grouping scheme than the makeshift one I used above.


  • 0

#4 Barthanes

Barthanes

    Prisoner

  • Members
  • 45 posts

Posted 04 July 2014 - 05:53 PM

Been playing with the latest Tes5edit, (you can find it here, xEdit svn1633 ) and I have to tell you I'm really loving it. I dowloaded this from the Tes5edit forum, https://www.dropbox....ch_ModGroups.7z as well. These files go in the data folder so just make an MO folder called Modgroups or something and activate. Recommend you install the r1633 version onto a separate file folder and make a second executable in MO to use it. Also copy any scripts like the merge one into this test version if you want to do any scripting with it.

 

Seriously makes conflict resolution much easier. I just did all my, lighting, weather, water height in about 1/3 of the time it usually takes. By "hiding" the conflicts between the DLC's and UP's it gives a much cleaer picture of what is actually conflicted. Haven't tried making any mod groups yet, but I think I will when I get to doing NPC's. The ability to hide conflicts that you don't really need to deal with is a big deal for me.  

It supposedly does a better job of finding ITM's as well so cleaning mods with it may be more complete. Haven't got that far though.


Edited by Barthanes, 04 July 2014 - 05:55 PM.

  • 0

#5 ElminsterAU

ElminsterAU

    Prisoner

  • Mod Authors
  • 16 posts

Posted 04 July 2014 - 06:38 PM   Best Answer

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
[/list]

 

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

  • 0

#6 Barthanes

Barthanes

    Prisoner

  • Members
  • 45 posts

Posted 04 July 2014 - 07:20 PM

I see what you mean about loading smaller subets and then creating a modgroup. This is an enorrmous help in a heavily modded game. You can really drill down to resolve  conflicts and then not have to see them anymore once they're fixed. It makes finding all the conflicts much easier. And ultimately it will make a much more stable game.


  • 0

#7 ElminsterAU

ElminsterAU

    Prisoner

  • Mod Authors
  • 16 posts

Posted 04 July 2014 - 07:42 PM

I originally implemented ModGroups during the early days of TES4View/TES4Edit to deal with all the conflicts showing up in an FCOM setup. The only thing really new now is that you can defined ModGroups in module co-files instead of having to put them into TES5Edit.modgroups.

 

Back then I tried to create some excitement for the feature, but the reception was pretty lukewarm.


  • 0

#8 Barthanes

Barthanes

    Prisoner

  • Members
  • 45 posts

Posted 04 July 2014 - 07:51 PM

Well I for one heartily thank you. I use Tesedit a lot and modgroups are a huge benefit. If modders start to fully utilize the feature, as you said by including them in their mods, it will make for much smoother and more accurate conflict resolution.

 

Again thanks!


  • 0


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users