ElminsterAU

I've found Pathfinder to be a worthy successor to D&D (3.5). Not really impressed with what I've seen of D&D 5 so far, sticking with Pathfinder seems to be the best option for now.

Nothing to do with the original problem, but just a note that I noticed that WM/MT will override the PlayerSleepQuestScript which is also modified by HearthFires and the UHFP (to add the "Mother's/Father's Love" effect when sleeping in your home after adopting). So loading WM/MT in it's current version will disable that part of HF. Also, there are two minor conflicts with the current (2.0.5a) version of USKP: USKP adds the ClothingRing [KYWD:0010CD09] keyword to DA05HircinesRing "Ring of Hircine" [ARMO:0002AC60] which WM/MT overrides.In C01 "Proving Honor" [QUST:0006E803], USKP changes the value of the AelaOutfit property from ArmorStuddedSimpleOutfit [OTFT:00037C52] to DraugrArmorForNonDraugrOutfitNoHelmet [OTFT:000EA537] which WM/MT then overrides back to the vanilla value.

Who said life is fair? :P

To be a bit more specific, IIRC, WAF TW moved Orcish weapons from level 6 to 9 (or something like that) in the LItem lists. IW, loading after WAF and adding new items to the list still contained the orginal Orcish weapons at level 6. The Bashed Patch, seeing the Relev tag on IW seems to accept that IW is allowed to move the Orcish weapons back to level 6, and in the absence of any other changes that needed merging, just left the IW version of the LItem lists to stand as the winner. Resulting in WAF TWs (more powerful) Orcish weapons spawning at the vanilla level.

Ok, AMB CA is a bad example as it doesn't add much weapons. But e.g. IW adds a number of "orcish" weapons, which appear to be leveled (both in stats and in their levels in leveled lists) to match the power level of the vanilla "orcish" weapons. Two issue with that: 1) you end up with different "orcish" weapons at different power levels 2) because of the way how the leveled lists are structured, even with a bashed patch, there is the possibility that the (more powerful) WAF changed orcish weapons show up at the (lower) vanilla level already. Sorry, I haven't got WAF True Weapons installed right now, so I can't give specific examples.

Also, some values in the 2.2.8 STEP Patch indicate that the patch was generated against WAF with the True Weapons option.

https://wiki.step-project.com/Weapons_and_Armor_Fixes#Recommendations "Weapons and Armor Fixes - COMPLETE PLUS" "Compatibility Patch - Guard Dialogue Overhaul" - select the COMPLETE PLUS or TRUE WEAPONS option only

The current instructions recommend installing with the True Weapons option for STEP Core. I see this as quite problematic. That option changes weapon stats and leveled lists significantly. I guess if you are only installing STEP Core and not any mods which add new weapon variants, you might be ok, but if you install any mod which adds variants of the effected weapons (e.g. IW or AMB Content Addon), you would need a patch that adjusts both the stats and any leveled lists. Otherwise you end up with quite unbalanced game. I do not think that the True Weapons option makes a good foundation in STEP Core to expand upon in other STEP Packs.

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.

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 otherClose 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 repeatThe 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 repeatThere 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 wellIf 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

The priority doesn't matter because the backups are not called .esm and .esp anymore and are stored in a subfolder. You don't even need to activate the backup "mod".

TES5Edit will by default make a backup of the original of any file it saves. If you are using MO, these backups end up in overwrite. You can do with them what you want (delete, move in some dummy mod, whatever, ...), they have no effect on the game, they are just backups of the unmodified files in case you want to return to the original.

MO creates "virtual" mods for the DLCs so you can sort them in the mod order. The name of these "virtual" mods is identical to the esm/bsa files. If you have explicit mods of the same name, Bad Things[tm] happen.

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://www.afkmods.com/index.php?/topic/3750-wipz-tes5edit/?p=151819 and the following post.

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)

I'm not quite sure what all the angst about being "forced to endorse" is all about. It's just a reminder, you can just as easily click the "I don't intent to endorse that mod" button if you don't want to. It's useful to get a lot of potential endorsements out of limbo and get people to make a definite yes/no decision. But I don't see the reminder notice giving a preference for either yes or no.