Wrye Bash/Flash - Bashed Patch Guide
Elder Scrolls IV - Oblivion
Topics and discussions on modding the popular Elder Scrolls IV Oblivion game produced by Bethesda Softworks.
Wrye Bash/Flash - Bashed Patch Guide
by buxton » March 10th, 2011, 3:48 pm
This page is intended for the users who are new to the Wrye Bash program and the concept of compiling a bashed patch. It provides answers for frequently asked new user questions. For other Wrye Bash topics see the links at the top right of this page.
Wrye Bash for the Elder Scrolls Oblivion game
Wrye Flash for the Fallout New Vegas game

Yes, but you shouldn't (at least not for the same savegame).
Every time you add or remove mods from your modlist, or update one of the mods in your modlist.
In actuality, that's a bit conservative -- it's often possible to get away with less frequent rebuilds. But since that rule is simple and safe, and since rebuilding the patch only takes a minute or so, you should stick to that rule.
The Bashed Patch build process will include all active mods that load before the bashed patch. Therefore you can either 1) deactivate the mod, or 2) move it to load after the bashed patch, and then rebuild the patch.
The masters list is not the list of mods that Bash processed. The masters list is instead the list of mods that contain records that bash needs to refer to.
Double click the Bashed Patch esp. This will bring up the doc browser which will contain the Patch Build Report. Active mods are shown at the top of the report.
No. Use "Mark Mergeable" instead. It's endowed with super-hyper-mergeability awareness and is never wrong.
Mark Mergeable command it will tell you why not. But, in short, "Why" comes down to two reasons:
The word "Merge" is something of misnomer. A more accurate term is "Virtually Active".
You don't. If the mod is active, then its lists will be merged.
Mods that change leveled lists only need to be tagged if:
If a mod neither deletes nor relevels items in a list, then don't tag it.
Generally speaking only overhaul mods need to be tagged with Relev/Delev. And these days, such mods are usually already pretagged or are covered by the "Mark Levellers" command.
No. Because that would interfere with mods that are designed to delete items and/or relevel lists. You should only tag a mod if you're sure it should be tagged.
The list in the leveled list dialog is only there to allow overriding existing Delev/Relev tags. Hence if a mod only adds new items (e.g. DLCSpellTomes.esp), then it won't show up in the list, even though its additions to the leveled list will be merged in.
Only advanced modders will need to modify the items in the leveled list dialog. Most users should just ignore it.
Bash can resolve most conflicts between various race mods through the "Import Race Info" feature of the Bashed Patch. This can get a bit complicated though...
Mods are tagged by adding something like
All eye textures are designed for a particular eye mesh. If a pair of eyes is used with an eye mesh that they're not designed for, then you'll get "googly eyes".
To avoid this, Bash checks the set of eyes for each race to see if they're all using the same mesh. If not, then it will pick one eye mesh as the "correct" one and discard ("filter") any eyes that don't fit that mesh.
Import Graphics lets you extract the graphics components from specified mods and merge them into other changes to the same records. The basic procedure (prior to version 211) is:
Version 211 adds a new feature to make it easier to add the tags you want. Yeah!
('Click' or 'Select' means use the Left mouse button. 'Right-click' means use the right mouse button.)
[size=5]Error Messages[/h3]
Explanation of error messages encountered while using Wrye Bash...
Mods that are tagged Filter are supposed to be merged into the Bashed Patch while inactive. (Otherwise missing masters and thus CTDs are likely to result.) To repair, simply deactivate the mods and rebuild the patch.
This message is sometimes encountered while building a patch. If it occurs, it will be listed at the top of the patch report (in the Overview section), next to the problem mod. It indicates that Bash was unable to read the problem mod and so skipped over it while building the patch. This happens for few mods and most likely will have no effect on the patch. However, if you would like to resolve it...
Usually the problem can be resolved by opening the mod in the construction set and then resaving it.
Under certain conditions TESCS will erroneously save groups of world cells (e.g. for Tamriel) into the mod file, but fail to include the worldspace record itself. Bash will skip over these orphaned cell records while building the patch, but it might be wise to remove the orphaned records from the mod. (Modders of course, should do this with their own mods before releasing.) You can use Wrye Bash's Remove World Orphans command to do this.
In the script editing window of TESCS is a red disk icon, that when clicked will recompile all scripts, including those from Oblivion. Since this brings all script records into the mod, the mod will end up blocking all intentional changes/recompiles to those scripts from other mods that load before it. (This will for example, break script fixes from UOP, and some info sharing between Cobl and other mods.)
These problems can be repaired by using Bash's Decompile All command on the problem mods.
Wrye Bash for the Elder Scrolls Oblivion game
Wrye Flash for the Fallout New Vegas game

What's the Difference Between Import and Merge?
- Merge as in Merge Patches:
- All of the records of the mod are fully merged into the Bashed Patch. Except...
- If a record that is present in "merged" mod should be overshadowed by a different version of the same record a later loading mod, then the Bashed Patch won't merge that record into the Bashed Patch. This is why you sometimes see the term Virtually Active for a mod that's been merged into the Bashed Patch -- its effect on the game is the same as if it were actually active, even though it's not.
- Merge as in "Merge Leveleled Lists"
- Where different mods change the same leveled list, then their different contributions are merged together. I.e. all source mods contribute to the final list.
- Merge functions only extract data from mods that are currently or virtually active.
- Import
- Import means that some specific aspect of a mod is extracted from the source mod(s) and/or file(s), and then is applied in the patch over any subsequent changes.
- E.g. when "Import NPC Faces" is active, it extracts just the face data (eyes; face geometry and shading; and hair coloring, style and length) from the source mods and applies that over any subsequent changes to the same records.
- Usually "Import" functions extract data from their source mods regardless of whether those mods are active. (The exception to this is "Import Race Info" -- which will probably be renamed to "Merge Race Info" in a later release.)
- Tweak
- Tweaks have no source mods. These changes are specified fully in the Bash Patch interface.
Can I Have More Than One Bashed Patch?
Yes, but you shouldn't (at least not for the same savegame).
- If you only have one character, then you should only have one Bashed Patch.
- However, it you have several characters, then it's best to have a different Savegame Profile for each character, and have a different Bashed Patch for each character.
How Often Should I Rebuild the Bashed Patch?
Every time you add or remove mods from your modlist, or update one of the mods in your modlist.
In actuality, that's a bit conservative -- it's often possible to get away with less frequent rebuilds. But since that rule is simple and safe, and since rebuilding the patch only takes a minute or so, you should stick to that rule.
How Do I Avoid Including a Mod in the Bashed Patch?
The Bashed Patch build process will include all active mods that load before the bashed patch. Therefore you can either 1) deactivate the mod, or 2) move it to load after the bashed patch, and then rebuild the patch.
What Mods Should Not Be Active when the Bashed Patch is Rebuilt?
- Deadly Reflex
- Deadly Reflex apparently has to run dead last period, or else its scripts may go wonky and cause unintended effects, or the mod may not work at all, or the mod may cause CTDs.
- Perhaps this was also fixed as of Wrye Bash 151?
- Reneer's Guard Overhaul?
- RGO is safe to use with Wrye Bash 151 or higher. (Bash v 151 fixed a bug with merging scripts.)
- Oblivion Script Optimization?
- Script optimization is safe to use with Wrye Bash 151 or higher. (Bash v 151 fixed a bug with merging scripts.)
Masters List
The masters list is not the list of mods that Bash processed. The masters list is instead the list of mods that contain records that bash needs to refer to.
Why Do Some Mods Show Up as Masters, But Not Others?
- If Bash overrides a record from one of its masters then it will need to refer to that master. E.g. if Bash tweaks the name of a spell from a mod, then that mod will become one of the masters for the patch.
- If Bash includes a record that includes a reference to a second record, then master that provides that second record will be included in the patch.
- On the other hand, if Bash includes changes from a mod that don't require that Bash refer to records in that mod, then that mod will not be included in the masters list for the Bashed Patch.
- Example: Suppose there's a patch mod "OOO-SpellTomes.esp" that adds books from DLCSpellTomes.esp to OOO leveled lists. And suppose that the leveled lists merger merges these lists. In this case, the Bashed Patch will have "DLCSpellTomes.esp" and "Oscuro's_Oblivion_Overhaul.esm" as masters, but not "OOO-SpellTomes.esp". This is because OOO-SpellTomes doesn't actually supply any new records that need to be referred to. Instead it just uses and modifies records from its masters.
How Can I Tell Which Mods Were Used When Building a Bashed Patch?
Double click the Bashed Patch esp. This will bring up the doc browser which will contain the Patch Build Report. Active mods are shown at the top of the report.
Merging Mods
Can I Just Add the Tag "Merge" to Make a Mod Mergeable?
No. Use "Mark Mergeable" instead. It's endowed with super-hyper-mergeability awareness and is never wrong.
Why Can't I Merge Mod X Into the Bashed Patch?
Mark Mergeable command it will tell you why not. But, in short, "Why" comes down to two reasons:
- The mod contains new records. The Bashed Patch is indeed a Patch. I.e. it can only patch existing records. If a record doesn't exist in one of the masters of the Bashed Patch, then it can't exist in the Bashed Patch.
- The mod contains records that the Bashed Patch doesn't handle. Notably, the Bashed Patch does not handle: Cells, world spaces or dialog. It also (for complicated reasons) won't patch GMST (game setting) records. Plus a few others.
Why Isn't a Change from a Merged Mod Showing Up in the Bashed Patch?
The word "Merge" is something of misnomer. A more accurate term is "Virtually Active".
- Suppose that mod Alpha.esp changes a merchant to have 2000 barter gold. Then mod Beta.esp (which loads after mod Alpha) sets that merchant to have 1000 barter gold. In ordinary load ordering (without the Bashed Patch), mod Beta.esp would "win" and the merchant would have 1000 barter gold.
- But suppose that you merge mod Alpha.esp into the patch, which loads after Beta.esp, doesn't that mean that the merchant now has 2000 gold again (since the Bashed Patch) loads after Beta.esp?
- No. Because when Bash merges Alpha, it mirrors what ordinarily happens. I.e. the Bashed Patch will actually contain the NPC record from mod Beta.esp because Beta.esp overruled Alpha.esp (for that record).
- But suppose instead that you merged Alpha.esp when Beta.esp was not active. In that case, the bashed patch would contain the record from Alpha.esp, and so it would overrule the change in Beta.esp. This is (one of the reasons) why you should rebuild your Bashed Patch whenever you add/remove mods.
Leveled List Merging
How Do I Tag a Mod to Make Sure That Its Lists Are Merged?
You don't. If the mod is active, then its lists will be merged.
Which Mods Should be Tagged with Relev/Delev?
Mods that change leveled lists only need to be tagged if:
- The mod removes items from an existing list. Such mods should be marked with the
- Code: Select all
Delev
- The mod changes the level or number of items already in the list. E.g. if a leveled list originally has "Silver Sword" appear at level 10; but the mod changes this so that the "Silver Sword" first appears at level 9, then the mod needs to be tagged with
- Code: Select all
Relev
If a mod neither deletes nor relevels items in a list, then don't tag it.
Generally speaking only overhaul mods need to be tagged with Relev/Delev. And these days, such mods are usually already pretagged or are covered by the "Mark Levellers" command.
Should I Tag a Mod With Relev/Delev Just to Be Safe?
No. Because that would interfere with mods that are designed to delete items and/or relevel lists. You should only tag a mod if you're sure it should be tagged.
Why Isn't My Leveled List Mod Showing Up in the List Merger Dialog?
The list in the leveled list dialog is only there to allow overriding existing Delev/Relev tags. Hence if a mod only adds new items (e.g. DLCSpellTomes.esp), then it won't show up in the list, even though its additions to the leveled list will be merged in.
Only advanced modders will need to modify the items in the leveled list dialog. Most users should just ignore it.
Race Info Merging
Bash can resolve most conflicts between various race mods through the "Import Race Info" feature of the Bashed Patch. This can get a bit complicated though...
Basic Procedure
- Make sure that race mods are tagged correctly.
- Make sure that race mods are in correct load order.
- Rebuild Bashed Patch
- Check "Race Records"
- Check any race mods that you want to import info from.
- Click "Ok" to rebuild patch.
- Review the Patch Log after the patch is rebuilt!
Tagging Race Mods
Mods are tagged by adding something like
- Code: Select all
{{BASH:Hair,Eyes}}
- Hair [Hair]
- A mod that adds playable hair should be tagged with
- Code: Select all
Hair
- Eyes [Eyes]
- A mod that adds playable eyes should be tagged with
- Code: Select all
Eyes
- Body [Body-M, Body-F]
- A mod that modifies the physical structure of the body should be tagged with
- Code: Select all
Body-M
- Code: Select all
Body-F
- Voices [Voice-M, Voice-F]
- A mod that changes the voice identity of a race should be tagged with
- Code: Select all
Voice-M
- Code: Select all
Voice-F
- Code: Select all
Voice-M
- Factions, Racial Spells
- There are no tags for this sort of info. A mod that changes this sort of info should load after any other racial mods that are being "imported". The imported info will be merged into records from mods like this and included in the Bashed Patch.
Loading Racial Mods
- Activation
- Mods that change only voice or body structure do not need to be active.
- Mods that add hair and/or eyes must be active. (Since they add new HAIR and/or EYES records.)
- Order
- For mods tagged with Body or Voice tags, the last to load (for a given race/gender) wins.
- For mods tagged with Hair, order relevant to other tagged mods does not matter.
- For mods tagged with Eyes:
- If the mod replaces Vanilla eyes, then the last mod to load wins.
- If the mod only adds new eyes, then it's contributions will be merged with other eye-adding mods. However, these are still subject to filtering
- For misc. info (factions, racial spells) mods, the last to load (for a given race) will win.
Filtering Out Googly Eyes
All eye textures are designed for a particular eye mesh. If a pair of eyes is used with an eye mesh that they're not designed for, then you'll get "googly eyes".
To avoid this, Bash checks the set of eyes for each race to see if they're all using the same mesh. If not, then it will pick one eye mesh as the "correct" one and discard ("filter") any eyes that don't fit that mesh.
Importing Graphics
Import Graphics lets you extract the graphics components from specified mods and merge them into other changes to the same records. The basic procedure (prior to version 211) is:
- Check to be sure you have the latest version of Wrye Bash.
- Start Wrye Bash. You will see two columns of frames. At the top are a line of tabs ('Replacers', 'Mods', 'Saves', etc.).
- Click on 'Mods'. The mods you have loaded in your game will appear in the left frame.
- Locate the mod with the graphics and click on it to highlight the line.
- Look at the frames in the right hand column of the Wrye Bash window. You should see 'File', 'Author', 'Modified' and 'Description'. You want to change the 'Description'.
- Add a new first line
- Code: Select all
{{BASH:Graphics}}
- Click the 'Save' button in the lower right hand corner of Wrye Bash. If you forget to click on 'Save' before you click somewhere else in the window you will lose your new first line, in which case you'll need to repeat steps 5-8.
- Find the 'Bash Patch esp' in the left frame and Right-Click it to open the context menu.
- Left-click on 'Rebuild patch' in the context menu to Rebuild your patch. A new window called 'Update Bashed Patch, 0.esp' will open with 2 frames. On the left is a list of choices.
- You should now see an option to 'Import Graphics' in the left frame.
- Make sure there is a check mark in the Import Graphics box and click on 'Import Graphics' to highlight the line.
- Now in the right-hand frame you should see the name of the source file.
- Click in the box next to the name of the source file.
- Make sure you have selected both the 'Import Graphics' feature in the left frame *and* the mod concerned in the right frame under 'Source Mods/Files'.
- Click on 'Ok' to save your changes to the Bashed Patch.
- Another window will open and show the mod being processed. Click to close it when it has finished.
- Close Wrye Bash with the close button at the top right of the window.
Version 211 adds a new feature to make it easier to add the tags you want. Yeah!
('Click' or 'Select' means use the Left mouse button. 'Right-click' means use the right mouse button.)
[size=5]Error Messages[/h3]
Explanation of error messages encountered while using Wrye Bash...
Unfiltered Mods
Mods that are tagged Filter are supposed to be merged into the Bashed Patch while inactive. (Otherwise missing masters and thus CTDs are likely to result.) To repair, simply deactivate the mods and rebuild the patch.
Load Error Mods
This message is sometimes encountered while building a patch. If it occurs, it will be listed at the top of the patch report (in the Overview section), next to the problem mod. It indicates that Bash was unable to read the problem mod and so skipped over it while building the patch. This happens for few mods and most likely will have no effect on the patch. However, if you would like to resolve it...
Usually the problem can be resolved by opening the mod in the construction set and then resaving it.
- Usually the problem is due to the mod having a slightly odd file format. Opening and resaving the mod will save it back into a more standard format which Bash can read.
- If the mod cannot be opened in TESCS, then the mod is corrupt and should be removed.
- If the mod has an esp dependency, be careful to maintain those! I.e. use Esmify Masters before opening in TESCS and then use Espify Masters after saving changes.
- Alternatively, you may want to search for an updated version of the mod. E.g. old versions of Quest Award Leveler cause Load Errors, but newer non-problematic versions are already available.
World Orphans
Under certain conditions TESCS will erroneously save groups of world cells (e.g. for Tamriel) into the mod file, but fail to include the worldspace record itself. Bash will skip over these orphaned cell records while building the patch, but it might be wise to remove the orphaned records from the mod. (Modders of course, should do this with their own mods before releasing.) You can use Wrye Bash's Remove World Orphans command to do this.
Compiled All
In the script editing window of TESCS is a red disk icon, that when clicked will recompile all scripts, including those from Oblivion. Since this brings all script records into the mod, the mod will end up blocking all intentional changes/recompiles to those scripts from other mods that load before it. (This will for example, break script fixes from UOP, and some info sharing between Cobl and other mods.)
These problems can be repaired by using Bash's Decompile All command on the problem mods.

buxton- 1.0

- Posts: 186
- Kudos: 2
- CPU: Phenom II
- GPU: Nvidia 9800
- RAM: 4 GB
- Storage Space: 2 TB
Return to Elder Scrolls IV - Oblivion
- Related topics
- Replies
- Views
- Last post
- Deadly Reflex Guide
by loder » November 5th, 2010, 1:26 pm - 0 Replies
- 391 Views
- Last post by loder

November 5th, 2010, 1:26 pm
- Deadly Reflex Guide
- Load Order Guide Lines
by Dark Lilith » May 11th, 2009, 11:40 am - 4 Replies
- 701 Views
- Last post by Dark Lilith

May 22nd, 2009, 12:45 pm
- Load Order Guide Lines
- Guide to Optimizing/Modding Oblivion
by loder » September 16th, 2010, 3:57 pm - 0 Replies
- 715 Views
- Last post by loder

September 16th, 2010, 3:57 pm
- Guide to Optimizing/Modding Oblivion
- Oblivion Scripting Tutorial and Guide
by PsyclopS » August 6th, 2011, 5:11 pm - 0 Replies
- 154 Views
- Last post by PsyclopS

August 6th, 2011, 5:11 pm
- Oblivion Scripting Tutorial and Guide
- Oblivion Mod Manager OBMM guide
by Webslug » June 23rd, 2010, 9:26 am - 0 Replies
- 4316 Views
- Last post by Webslug

June 23rd, 2010, 9:26 am
- Oblivion Mod Manager OBMM guide
- Better graphics Landscape LOD detail guide
by Hoola » July 10th, 2010, 10:00 am - 1 Replies
- 1351 Views
- Last post by Webslug

July 12th, 2010, 10:08 pm
- Better graphics Landscape LOD detail guide

