Bash Tags and the Wrye Bash Patch

From Nexus Mods Wiki
Revision as of 05:14, 29 May 2018 by Dubiousintent (talk | contribs) (→‎Tags Function)
Jump to: navigation, search

Introduction

"Bash Tags" are an important part of the proper functioning of the "Bash Patch" built by the various versions of Wrye's original "Wrye Bash" program for Oblivion. (The variations are "forks" from the original to work with the changes in record types in various games such as Morrowind (Wrye Mash), Skyrim (Wrye Smash), and Fallout (Wrye Flash). An ongoing community effort to "restructure" the original Wrye Bash to provide support for the various games in a single interface is nearing conclusion in 2017. Coders experienced in Python and C++ are always needed to work on the "patchers" for specific games. The (quite active) development community with the latest WIP versions are found in the Official Wrye Bash thread on the AFK Mods Forum.)

While "Bash Tags" are generally the responsibility of the mod creator to assign, it is also important for the user to understand their role and occasionally to add or remove them. This article will hopefully clarify the subject. A certain level of basic understanding of common terminology is assumed. Please see the wiki article FNV General Mod Use Advice section on "Terminology" if necessary.

Programs and Tools

  • Wrye Bash variations for specific games:

Essential Background

First of all it is necessary to understand how the game engine handles mod plugin conflicts, which is commonly known as "The Rule of One". What this means is that when two (or more) plugins attempt to modify the same record in the vanilla game, only the last plugin loaded (determined by the "load order") "wins"; totally and completely. Even if the other plugins make changes to other records that the "winner" doesn't touch, they still lose out and those changes do not take effect.

If you aren't familiar with the terms "plugin" and "record", the analogy of a "filing cabinet" is a common reference. In this instance of the analogy, the game "Data" folder is the "cabinet". A "mod" is a "folder" in the cabinet; a collection of related "documents". Some of the mod's "documents" are instructions on how they are introduced into the game (ESM & ESP files: collectively called "plugins"), and some are "assets" which provide the raw resources used (meshes, textures, sounds, etc.). Some assets (such as most of the vanilla game ones) are collected into BSA files which are a Bethesda specific archive format. In order for a BSA to get used, it must begin with the same name as it's related ESP plugin file (e.g. the vanilla game <esp_filename> is "FalloutNV" in "FalloutNV - Textures.BSA". If the ESP plugin is not used, then the BSA assets aren't either. (An ESM plugin can't be used to invoke a BSA file.) Other assets (commonly those provided by mods) are stored as "loose files" in categorized sub-folders under the "Data" folder, such as "Data\meshes", "Data\textures", etc. Where these files are intended to be use in place of the same vanilla files, an "ArchiveInvalidation" technique is used to cause the game engine to handle that substitution.
An ESM or ESP plugin internally consists of "records" (think of them as "individual pages of standardized forms" in it's "folder" of instructions), which are grouped in categories of "record types", and have individual "Form-ID" numbers (which are hexadecimal numbers) and are how the game sees everything in the "game world". The first two characters of a "Form-ID" are assigned by the game engine when it loads plugins, and are referred to as the "mod index". Obviously this "mod index" will change when the plugin is placed in a different position in the "load order". The remainder of the "Form-ID" is unique within that plugin, but can also match (to include their respective "mod index" portion) with any preexisting record in the "vanilla" game and it's official DLCs ESM or ESP files, overriding them. The "mod index" of "00" is reserved for the game plugins (both "FalloutNV.ESM" and "FalloutNV.ESP"). The "mod index" of "FF" is reserved for those "Ref-ID" records that are dynamically created instances of "Form-IDs" during game play and stored in, or loaded from, the "save game" files. (For specifics on the differences between the various "<form_reference>-IDs", see the "GECK Form-ID, Base-ID, Ref-ID, and Editor-ID" section of the Getting started creating mods using GECK article. But generally the distinctions are not important to understanding the role of "records".)

By default, the game engine deals with "record level" conflicts by using the last to load. But because it is not designed to reconcile record level conflicts, it does this by simply ignoring the earlier loaded plugin ... completely. The key point here is that if a plugin is not the "winner" of a record level conflict, it might as well not be included in the "load order". Only the last loading plugin touching any given record will be the winner. Only plugins which do not have any record level conflicts will otherwise "win" to be used if they are not the last such "record conflict winner".

As a common example, supposed you have several mods that add "weapons" to the game. If two of them happen to replace the same record of a weapon (either provided in the "vanilla" game or added/modified by another mod), only the last loading will be used. Every weapon that was in the "losing" mod will not make it into the game, even though only one record pertaining to one weapon was in conflict. This is why it is called "The Rule of One": 'There can be only one' plugin as the winner.

As you might imagine, the modding community found this solution ... lacking. Enter the "Bash Patch" produced by Wrye Bash in it's various game specific incarnations, which provides "record level conflict resolution" in an automated fashion. (Admittedly, xEdit (under it's various game specific names) has the capability to do such conflict resolution by way of a "Merge Patch" or "Merge Plugin", but manually. However that capability is outside of the focus of this article.) Wrye Bash does this by applying it's algorithms producing a "patch file" (the "Bash Patch") consisting of the winners of all record level conflicts, and all the non-conflicting records that would otherwise not get used from the losers. However, the game engine is unchanged in how it deals with conflict, so the "Bash Patch" has to be the last loaded plugin in order for it to be the "plugin winner". (There are some plugin files which do not touch on the same record types that can be loaded after it, but in general they are rare and exceptions you need to be careful to understand. It is common for mod authors to say "load this last" so their mod will be the plugin winner, but that assumes you are not using a "Bash Patch" unless the subject is specifically addressed in it's documentation.)

Tags Function

Now to why we are here: "Bash Tags". The "Bash Patch" uses "bash tags" to determine record level conflict winners when it is important an earlier loading record be the winner instead of a later loading one without the tag. If more than one record has a tag, then the later loading wins as usual. As emphasized in the Wrye Bash Advanced ReadMe:

Note: A Bash Tag should only be applied when it is important that the plugin's change to whatever the Tag relates to is preserved. If a change your plugin makes is not important to the functioning of your mod, do not add a Bash Tag for it. Doing otherwise negates the purpose of the Bash Tag system.

Consequently you should be cautious about adding "Bash Tags" to your own, and especially other authors', plugins. "Load order" is still the primary way of determining conflict winners.

As each record is of a particular type, each "bash tag" only applies to particular types of records. This should prevent more than one tag applying to any given record, so there shouldn't be any "tag conflicts". The "Wrye Bash Advanced ReadMe" linked above has the list of tags and associated reocrd types for Oblivion. Different games have variations among record types.

Fortunately, the xEdit team has been diligently determining those record type differences and have provided a script called "Generate Bash Tags" which identifies the appropriate tags that are suitable for a given plugin and FO3/FNV/TES4 (Oblivion)/TES5 (Skyrim). (There is another script called "BASH tags autodetection", which is a more limited predecessor for Oblivion only. Don't confuse the two. Always use the latest version of TES5Edit/xEdit, which is available in the Skyrim Mods section of the Nexus site.) However, they are community members just like you and have to "discover" such changes for themselves. Do not expect omnipotence on their part. The script can be applied to a plugin ESP file or a specific record in such a file. The result can optionally be added to the plugin's "description" field so it will be available to "Bash Patch" aware tools like BOSS and LOOT.

Note that just because the xEdit script determines and adds "appropriate tags" does not mean they should necessarily be applied to your plugin. Remember tags are for "important changes" that are necessary to the correct functioning of the plugin. The desirability of a given plugin's changes varies by user depending upon other potentially conflicting plugins they include. Mod authors should be cautious and sparing about applying tags. Players should be equally cautious about removing any already applied to plugins.

Whether or not they are the records you as a player want to be the winners (in which case they should be applied) is a personal choice. Just don't apply any tags not listed by the xEdit script for that plugin. Simply ensuring a particular plugin is placed later in the "load order" than ones it conflicts with will also ensure it is the winner (unless the earlier loading has the same tags, which you will then need to remove contrary to the author's conclusions). Consider the use of a "Merge Patch", as described in the Beginners guide to Xedit merged patch / Wrye Bash - Bashed Patch used together thread on the Nexus Fallout New Vegas Mod Troubleshooting forum to reduce the number of conflicts. Tags should only need to be added when you can't force the mod you prefer to load later than a conflicting one without other problems or you need to add them to a plugin you create, such as a Merged Plugin Guidelines for Personal Use or "Merge Patch".

To manually add/remove "bash tags" to a plugin, use Wrye (Bash/Flash/etc.):

Wrye Bash Tags
  • On the "Mods" tab, in the right-hand panel of information that begins with "File:" (followed by "Author", "Modified", "Description:", etc.), at the bottom is a box field labelled: "Bash Tags:" (which may have some or be empty).
  • <Right-Click> in that box and it will bring up a context menu with a list of possible "Bash Tags".
(See Fig. "Wrye Bash Tags". Click the link/thumbnail to see the enlarged image. Use your browser "<back page>" control to return to this page.)
  • At the top of that context menu are two exclusive options: "Automatic" and "Copy to Description".
  • "Automatic" (the default) means it will use the "Bash Tags" found in LOOT and the description of the mod.
  • The "Copy" option will copy those (and any you add in that box) to the mod description field so it will have them there after.
  • Any tags already present will have a "check" next to their name in that context menu.
  • Click on any tags you want to add to "enable" (check) them, or uncheck any you want to remove. Remember that in the case of duplicate records with the same tag, the later loading record "wins", so be frugal with them.
  • "Uncheck" the "Automatic" option (which will close that context menu).
  • Re-open the context menu (<right-click> again), and click (enable) the "Copy to Description" option.
(That will close the context menu again.)
  • Note that the "Description:" field in that panel now has the bash tags listed within double braces: i.e. "{{BASH:<tag>,<tag>}}".
  • Re-open the context menu (<right-click> again), and click (enable) the "Automatic" option to restore it as the default (which will close that context menu again).

Now you have added (or removed) tags as you desire, and added them to the mod description so they will be used everytime you load that mod.

Note that if you edit the mod "Description" field when you create the mod to include that same "{{BASH:<tag>,<tag>}}" syntax, WB/WF will automatically recognize those tags (and LOOT will now as well).

References

Nexus wiki articles referred to by this article:



Nexus wiki articles that refer to this article:



Retrieved from "https://wiki.nexusmods.com/index.php?title=Bash_Tags_and_the_Wrye_Bash_Patch&oldid=31962"