Flash/Bash Tags

[Guest deleted10552447]

I gave the new script for xEdit, the one to automatically generate Bashed tags, a try today, but I'm wondering: should you add tags to EVERY mod in your list that will support them? I ran it individually on every plugin, no issues, everything seemed fine, checked for errors in the new Bashed Patch I made, all good, so... is everything truly all good? Are there mods you shouldn't generate Bash tags for?

 

I checked through the Bashed Patch in xEdit just to be sure, and it seems like the records are good. No errors or anything. I also did doublecheck each plugin in Flash, and the tags had been properly added.

 

This is my first time messing with Bash/Wrye Flash tags, so I'm hoping I haven't catastrophically screwed things up.

Edited January 1, 2017 by Glenrhee

[dubiousintent]

While that script accurately (as far as I can tell) informs you as to what tags apply to a particular plugin, that does not mean you want to apply them all. The purpose of such tags is to inform the "Bashed Patch" build process that you want earlier loading plugins to be "the winner" for those types of records when a later loading plugin would otherwise be considered the winner. This is on a "record by record" conflict basis. In the case where more than one tagged record is in conflict, the normal "last one touching the record wins" rule prevails. So, it is still up to you to determine which plugin you want to be the overall winner for that type of record.

 

And bear in mind a tag is an "all or nothing" winner for that type of record in that plugin. If you want a particular record of a given "tag type" from modB to win in one specific instance and a different record of the same type from modA (loading earlier) to win in another instance, then you are going to have to manually create a "merge patch" file that will go after the BP to cause an override of the BP resolution. See the wiki article "Merge Plugin Guidelines for Personal Use" article which covers the tools and process for a "merge patch" file. It all depends upon how important a particular winner to you.

 

-Dubious-

[Guest deleted10552447]

While that script accurately (as far as I can tell) informs you as to what tags apply to a particular plugin, that does not mean you want to apply them all. The purpose of such tags is to inform the "Bashed Patch" build process that you want earlier loading plugins to be "the winner" for those types of records when a later loading plugin would otherwise be considered the winner. This is on a "record by record" conflict basis. In the case where more than one tagged record is in conflict, the normal "last one touching the record wins" rule prevails. So, it is still up to you to determine which plugin you want to be the overall winner for that type of record.

 

And bear in mind a tag is an "all or nothing" winner for that type of record in that plugin. If you want a particular record of a given "tag type" from modB to win in one specific instance and a different record of the same type from modA (loading earlier) to win in another instance, then you are going to have to manually create a "merge patch" file that will go after the BP to cause an override of the BP resolution. See the wiki article "Merge Plugin Guidelines for Personal Use" article which covers the tools and process for a "merge patch" file. It all depends upon how important a particular winner to you.

 

-Dubious-

 

So, if I use LOOT and ensure that Wrye keeps my load order, wouldn't it handle most of the automatic overriding, etc. on its own?

 

I did this, then made an "Override" merge patch in xEdit, then edited it to match up previous records how I wanted. Should I be good to go? Note that I have around 88 active mods, so it's not exactly a "light" installation.

[dubiousintent]

LOOT organizes the "load order" based upon dependencies. But that results in game default "the last one plugin to touch a record is the winner" for ANY record level conflicts. It does not perform record level conflict resolution that enables more than one plugin to be the "winner" where there are no other record conflicts (i.e. "overrides"). That is what the "bash patch" does.

 

Yes, you can manually create a "merge patch" instead of using the BP. That allows a much more precise resolution to your desires. However, the more plugins you have, the more records are involved and there a number of caveats and precise sequences to which you perform those overrides to get a successful merge. (See this part of the WIP article "Multiple file Merge-up procedure" for the basic override sequence. I'm not a "merging" expert, but I've been consulting with some and writing up the experience for others, which is why that is still a "work in progress". But that part is solid.)

 

For instance, I have some "merged plugin" files that enable me to have over 200 plugins in play. That results in over 10,000 records that the BP manages. I have neither the time nor the inclination to manually manage 10K records EVERY TIME MY LO CHANGES with updates or additions or removals, and am not interested enough in particular results to fiddle with a manually created "merge patch". But if I were, that is the way I would go as simply "good enough". My "load order" establishes which plugins dominate in general, the BP reconciles the "overrides" between plugins at the record level, and the "merge patch" is for editing those final tweaks to get "just the right result". If you want more precise results then you can skip the BP completely and use your own "merge patch" for all the record level reconciliation. It's a matter of how much effort you want to put into it.

 

-Dubious-

Edited January 2, 2017 by dubiousintent

[Guest deleted10552447]

LOOT organizes the "load order" based upon dependencies. But that results in game default "the last one plugin to touch a record is the winner" for ANY record level conflicts. It does not perform record level conflict resolution that enables more than one plugin to be the "winner" where there are no other record conflicts (i.e. "overrides"). That is what the "bash patch" does.

 

Yes, you can manually create a "merge patch" instead of using the BP. That allows a much more precise resolution to your desires. However, the more plugins you have, the more records are involved and there a number of caveats and precise sequences to which you perform those overrides to get a successful merge. (See this part of the WIP article "Multiple file Merge-up procedure" for the basic override sequence. I'm not a "merging" expert, but I've been consulting with some and writing up the experience for others, which is why that is still a "work in progress". But that part is solid.)

 

For instance, I have some "merged plugin" files that enable me to have over 200 plugins in play. That results in over 10,000 records that the BP manages. I have neither the time nor the inclination to manually manage 10K records EVERY TIME MY LO CHANGES with updates or additions or removals, and am not interested enough in particular results to fiddle with a manually created "merge patch". But if I were, that is the way I would go as simply "good enough". My "load order" establishes which plugins dominate in general, the BP reconciles the "overrides" between plugins at the record level, and the "merge patch" is for editing those final tweaks to get "just the right result". If you want more precise results then you can skip the BP completely and use your own "merge patch" for all the record level reconciliation. It's a matter of how much effort you want to put into it.

 

-Dubious-

 

From what I've done I've got the BP and a Merge Patch after it that let me tweak a few final things, and everything seems good. I guess it's fortunate that I've only got 88 active plugins (it'd bearound 158 without Bash's merges and my own merged mod).