Should I use a Merged patch, a Bashed patch, or both?

[MostOriginalName]

Hello, I’d really like to know if it’s possible to have both at the same time. If you can only have one, which one do you prefer?

[Billy1969]

Hello, I’d really like to know if it’s possible to have both at the same time. If you can only have one, which one do you prefer?

 

merged patch and bashed patch both at the same time would be redundant.

If you have an easy or straightforward load order and you want to keep it simple, use the merged patch from FNVedit.

If you want more control over what will exactly be merged (take the time to study the bashed tags and comprehend what they do), then go for the bashed patch from Wrye.

 

I use the latter since Morrowind, as I have a complicated load order with many merged files, and even then I create one manual override .esp myself to correct or add things the bashed patch didn't take into account.

 

For example let's say you have three mods that alter weapons, two .esm's and one .esp, the merged patch strictly follows your load order and the modifications made by the .esp will win as it is loaded after your esm's. In case of the bashed patch you can bypass that load order limitation by assigning bash tags to your loaded mods and it will import the things you selected, so it is more configurable than the merged patch.

 

But let's say I want the weapons stats from the first .esm, the "on dead" effects from the second (like the beautiful energy weapons criticals from EVE) and the weapon mods from the third then I have to create a manual override after the bashed patch to do just that. (by copying the weapons in a blank .esp file that I load after the bashed patch and copying the things I need from the three mods in my example.) Same thing for character appearances, Lings and Mikoto can be made to work together this way for example, by selecting the npc records you want from both, the possibilities are virtually endless.

 

But to summarize, want it simple with no headaches: go for merged patch

want more control? Go for bashed patch

Want headaches and other pains but have a great game afterwards? go for bashed patch + custom override .esp loaded after it :smile:

Edited April 19, 2016 by Billy1969

[dubiousintent]

I've only recently gotten into making and using my own "merged plugins", but as it's been successful I think I have it down correctly.

 

First some terminology clarification. Forgive me if this is covering old ground but it's better to ensure we are on the same page, and some lurkers may benefit.

 

Mods have (among other file types) "plugin files" with ESM and ESP extensions. These files contain records which are alterations to the vanilla game records or add new records to the game. In the normal course of events only the last such plugin to load that touches on a particular vanilla record "wins" when there are conflicting changes by different plugins. The winning plugin wins completely: all the other plugins that "lost" are simply ignored in their entirety, even the non-conflicting records. This is because the default conflict resolution behavior is "file" rather than "record" oriented. This is called "the rule of one".

 

A "merged plugin" combines more than one plugin into a single file. This is typically done to reduce the number of active ESPs (and occasionally ESMs), but it also has the benefit of allowing non-conflicting records from other plugins included in the merge to be added to the game as well.

 

A "merged patch" combines more than one plugin's conflicting records to get a particular "winner" as a result. The "Bashed Patch" (BP) is such a "merged patch" file. As a result it needs to be last (or near enough that no other plugin affects the same records) in the Load Order (LO) in order to ensure it's "winner" stays the winner. For this reason the advice is to use only one such "merged patch". If more than one patch file touches on the same record as the other, "the rule of one" comes into play and only one file will be used anyway.

 

So you have to choose between using either the BP (which uses algorithms to determine the winner) and a "roll your own" merged patch file.

 

The arguments come down to how much control you want to exert over the result and how much time you are willing to spend to get that result. The BP uses "bash tags" to enable an earlier loading plugin to win conflicts. Otherwise the later loading wins. A manually create "merged patch" is strictly controlled by the creator, who determines the conflict winner. However, my BP affects over 10,000 records. I prefer to spend the time playing instead of working out "winners" to that many record conflicts.

 

There is a mitigating factor though. I use "merged plugins" to both reduce the plugin count and to determine the winners of some conflicts within a subset of conflicts. Say I merge several plugins that affect "Perks". There may be a few conflicting records. I can determine which record wins in that "merged plugin" and then I have one file with only one "winner" record in each instance. No internal conflicts, and unless there are other "Perks" plugins not in my merge (which defeats one of the purposes), no other conflicting plugins. No conflict, no need for those records in the BP or "merged patch". It's a way of breaking down the problem into more manageable chunks.

 

I laid out my "FNV Personal Merge Plugin guidelines" here.

 

-Dubious-

[dubiousintent]

@Billy1969: Do I take it correctly that your "custom override" file is a patch upon the BP as a "master", to avoid "the rule of one"? Don't you need to rebuild it whenever your BP changes? Otherwise I'd like to better understand how that works.

 

-Dubious-

[Billy1969]

@Billy1969: Do I take it correctly that your "custom override" file is a patch upon the BP as a "master", to avoid "the rule of one"? Don't you need to rebuild it whenever your BP changes? Otherwise I'd like to better understand how that works.

 

-Dubious-

 

Hi Dubious,

 

My custom override file is not depending on the BP, the BP is not in it's masterlist, but it is rather complementary to the BP. Even the bashed patch can only do "so much".

 

I'll give another example that will hopefully help to make it clearer: I have many mods active that alter NPC appearances, unfortunately if you bash tag all these files with "npcfaces" the last loaded will win and all npc's it alters will have the appearance they have in that mod. However, if I prefer the appearance for a particular npc in a mod that's higher in my load order I do "copy as deep override" with FNVEdit all npc's I want to have a different appearance in my custom override file and load it after the BP to override it's changes I don't want. So my custom file has many masters, but the BP is not one of them.

Edited April 19, 2016 by Billy1969

[dubiousintent]

I believe I get it. As "record overrides", it is similar to the BP in making record level changes thus avoiding the default behavior. I'll dig into what the "deep override" difference is the xEdit docs.

 

Thanks for clarifying. (A good day: learned something new.)

 

-Dubious-

Edited April 20, 2016 by dubiousintent

[LegitMelonhead]

 

Hello, I’d really like to know if it’s possible to have both at the same time. If you can only have one, which one do you prefer?

 

merged patch and bashed patch both at the same time would be redundant.

If you have an easy or straightforward load order and you want to keep it simple, use the merged patch from FNVedit.

If you want more control over what will exactly be merged (take the time to study the bashed tags and comprehend what they do), then go for the bashed patch from Wrye.

Not really.

 

-----------------------------------------

 

Use both.

 

1. Delete Merged and Bashed Patches.

2. Build and activate Merged Patch and delete leveled lists before exiting xEdit

3. Build Bashed Patch (it *should* deactivate the merged patch because of its NoMerge tag - but if it doesn't then just do it manually before the Bashed Patch is created).

4. After bashed is built, re-activate the NoMerge but leave the others deactivated.

5. Play.

 

Merged and Bashed don't offer more or less control than the other, they offer different sorts of control.

xEdit is basically just a spreadsheet, and the Merged Patch takes the strain away from your game, and allows you to set priorities via "apply filter to show conflict losers" (want the retex from a weapon mod X but want to keep all the stats from weapon mod Y - you do this is xEdit)

 

 

[dubiousintent]

Clarification: the Wrye "bashed patch" (BP) should only "deactivate" a plugin (a "merged patch" file is just another plugin to it) IF (and only IF) you use the "Mark Mergeables" feature and the plugin can be fully incorporated into the BP. The "No Merge" "bash tag" should prevent that, but it only works correctly if you use the "Mark Mergeables" feature. (See the wiki "Bashed Patch file with Marked Mergeables" article.)

 

If you name your "merge patch" file "TES5Merged.esp", then LOOT will automatically sort it for you even with a BP in the same load order.

 

But that sort of glosses over the reasons for why to use both patch files. "Apply filters" is a "mask" in xEdit to show only certain types of records to enable you to focus on what's important at the moment. The "filter" does not apply to the result, but does enable you to determine which records have the "textures" and which have the "stats" in that example, which you then want to drag into the resulting "output" plugin as "conflict winners".

 

Please see the wiki "Merged Plugin Guidelines for Personal Use" article, which goes into this in much more depth. It's a complex subject with a lot of similar (and consequently confusing) terminology.

 

-Dubious-

Edited October 2, 2017 by dubiousintent