Level Lists and Bashed Patch
Verbatim Post from the Forum. This page created to prevent bad link when the thread expires.
Can someone please explain what a bashed patch is?[edit | edit source]
DragoonWraith Oct 14 2008, 04:08 PM
OK, really? I know several of you in here know what the Bashed Patch does and how it does it, why the lack of explanations?
The first step to understanding the Bashed Patch is to understand how load order works. To understand that, you need to understand the basics of how mods work.
OK, so, to begin - Oblivion.esm. This file was created by Bethesda using the Construction Set (allegedly identical to the one we get to download; I have my doubts about that, but whatever, theirs was certainly similar). It contains lots of data. This data can be divided into several different types. The most basic of these is the "Form". Pretty much everything in the game is a Form. Forms have FormIDs, these are the hexadecimal numbers you use with AddItem if you're using the console to cheat. Items have them, weathers have them, characters have them, cells have them, quests have them. Some things do not - magic effects, for example, are hard-coded. Game settings are hard-coded. Skills are hard-coded. But most everything that can be made with the construction set gets a FormID and thus is a form.
Forms can generally be broken down into base objects and references. Not all base objects have references, and not all types of base objects can have references, but all references refer to a base object. References are the 3D representations of base objects. This has lots of importance all over the place, but is a bit tangential to the Bashed Patch.
The way mods work is that .esp files modify (or add) forms. Most are based on Oblivion.esm, which means they are dependent on it, and can change things about its forms. When Oblivion loads, it starts with Oblivion.esm. After that, it loads .esp plug-ins by date order. It reads the .esp, and when it comes across a form that is also found in Oblivion.esm, it first checks to make sure that the Forms have the same type (reference, weather, item, quest, whatever), and as long as that is true (which it should be), it replaces Oblivion's version with the mod's version. If another mod later changes the same Form, Oblivion replaces the first mod's with the second mod's. And therein lies the problem.
Because it's out-right replacement, if two mods change two different things about a Form, only one of those changes actually gets loaded; the other gets overwritten. In the case of Leveled Lists, this is especially bad - simply adding items to a Leveled List changes the Form. So if two different mods try to add things to the same list - only one is going to work.
What the Bashed Patch does is it goes through the forms, and combines changes from different mods into one mod, so that Oblivion can load all of them. Therefore, multiple different mods can add items to the Leveled Lists and it will work.
Does that explain things? I know I haven't gone into how to decide what mods should be merged; that's better answered by others. But I think some people were interested in this information.
Entire Thread[edit | edit source]
Posted by: urthman Oct 14 2008, 02:32 PM
Really I have tried to read through all the Wyre Bash docs I could find.
I've read the main http://wrye.ufrealms.net/Wrye%20Bash.html.
I've read the http://www.uesp.net/wiki/Tes4Mod:Wrye_Bash/Bashed_Patch.
I've read the FCOM pages at devnull.
The only reason I know the bashed patch exists at all is http://fivefries.googlepages.com/fcominstallationguidecookbook for installing the daunting list of FCOM mods. Which is so carefully detailed and well done I was able to get FCOM working smoothly without really understanding what I was doing. (Thanks FiveFries!)
They all seem to assume I already know what the bashed patch is for and which mods I'd want to include in it and get on to telling me how to do it.
I know that it's somehow necessary to make the FCOM mods work together, but I don't understand what it does. I don't know why I would need to rebuild the Bashed Patch (Tes4Mod says every time you add a new mod but doesn't say why). I don't know which (if any) of the other mods that Wyre Bash lists as "mergable" I ought to include in the Bashed Patch. There's probably other stuff that I don't even know that I don't know <img src="http://static.bethsoft.com/bgs/style_emoticons/default/wacko.gif" style="vertical-align:middle" emoid=":wacko:" border="0" alt="wacko.gif" />
If any of you likes to edit the Tes4Mod wiki, then surely the first item on the Bashed Patch page should not be "What's the difference between Import and Merge?" but rather "What exactly is a Bashed Patch, why do I need it and what does it do?"
Posted by: running4cover Oct 14 2008, 02:39 PM
Basically it's a mod (a patch) that mixes different aspects of your active mods together. For example, the most necassary/prevelant use a the Bashed Patch is to merge "Levelled Lists", essentially mixing loot from different mods together (like making it possible to find items from COBL in the same places you could find items from Armamentarium or FCOM or whatever). Bashed Patch is a mini-mod that merges different aspects of your other mods, and makes them run together more smoothly with less incompatabilities. I don't know how else to explain it, and I'm sure a mod guru will be along soon to answer better than I am, but that is my basic summery. Hope I Helped...
CC
Posted by: tauntedflail Oct 14 2008, 02:40 PM
I've read the main http://wrye.ufrealms.net/Wrye%20Bash.html.
I've read the http://www.uesp.net/wiki/Tes4Mod:Wrye_Bash/Bashed_Patch.
I've read the FCOM pages at devnull.
The only reason I know the bashed patch exists at all is http://fivefries.googlepages.com/fcominstallationguidecookbook for installing the daunting list of FCOM mods. Which is so carefully detailed and well done I was able to get FCOM working smoothly without really understanding what I was doing. (Thanks FiveFries!)
They all seem to assume I already know what the bashed patch is for and which mods I'd want to include in it and get on to telling me how to do it.
I know that it's somehow necessary to make the FCOM mods work together, but I don't understand what it does. I don't know why I would need to rebuild the Bashed Patch (Tes4Mod says every time you add a new mod but doesn't say why). I don't know which (if any) of the other mods that Wyre Bash lists as "mergable" I ought to include in the Bashed Patch. There's probably other stuff that I don't even know that I don't know <img src="http://static.bethsoft.com/bgs/style_emoticons/default/wacko.gif" style="vertical-align:middle" emoid=":wacko:" border="0" alt="wacko.gif" />
If any of you likes to edit the Tes4Mod wiki, then surely the first item on the Bashed Patch page should not be "What's the difference between Import and Merge?" but rather "What exactly is a Bashed Patch, why do I need it and what does it do?"
You know, this is a good question. Because, i'll admit - i've never been entirley sure either. And thats always worried me, I like to know how everything works.. but wyre bash just seems so... complex at times.
Posted by: mxms Oct 14 2008, 02:43 PM
Good post, because I don't really know either. I did the same thing as you, and managed to get it (mostly) working by pure luck as I didn't really know what I was doing, I was just following instructions.
Like, it doesn't say if you have to remerge or relevel every new mod you add. It's confusing, but then again I might not be reading it right.
Posted by: dev_akm Oct 14 2008, 03:13 PM
The Bashed Patch is like duck tape. It's the single most important thing in your mod list because it holds everything else together. Does that help?
Posted by: baker99 Oct 14 2008, 03:31 PM
One more bash newbie question, when I make a bashed patch should I then disable the original mods, for example npc face mods like renansoya and beautiful people? Or should I only disable merged esp's, colour me confused too.
Posted by: raven777 Oct 14 2008, 03:32 PM
But how does it do it? If I was to open it in the CS, what would I see? How can Wrye Bash create a functional .esp mixing so many different things by itself?
We want the truth <img src="http://static.bethsoft.com/bgs/style_emoticons/default/happy.gif" style="vertical-align:middle" emoid="^_^" border="0" alt="happy.gif" />
Posted by: tauntedflail Oct 14 2008, 03:37 PM
Yeah, exactly what i'm thinking. Sure, I can be taught how to use it, and have it work well. But what is it that is exactly going on on the inside, kind of thing.
I dont know, maybe i'm just a curious person.. but i'd love to know. So far I can only ponder without acurcay, really.
Posted by: shadowchao Oct 14 2008, 03:38 PM
We want the truth <img src="http://static.bethsoft.com/bgs/style_emoticons/default/happy.gif" style="vertical-align:middle" emoid="^_^" border="0" alt="happy.gif" />
Monkey magic.
Posted by: dev_akm Oct 14 2008, 03:55 PM
We want the truth <img src="http://static.bethsoft.com/bgs/style_emoticons/default/happy.gif" style="vertical-align:middle" emoid="^_^" border="0" alt="happy.gif" />
It will crash the CS.
However, you can see every detail of what it does if you open your load list in TES4View/TES4Edit.
I dont know, maybe i'm just a curious person.. but i'd love to know. So far I can only ponder without acurcay, really.
See above. Experiment with different settings and use TES4View to see what changes in the patch file.
Exactly! <img src="http://static.bethsoft.com/bgs/style_emoticons/default/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" />
Posted by: Shikishima Oct 14 2008, 04:07 PM
We want the truth <img src="http://static.bethsoft.com/bgs/style_emoticons/default/happy.gif" style="vertical-align:middle" emoid="^_^" border="0" alt="happy.gif" />
I don't know how my hi-fi works either, but I do know if I plug it in and turn it on it works just fine.......... <img src="http://static.bethsoft.com/bgs/style_emoticons/default/whistling.gif" style="vertical-align:middle" emoid=":whistle:" border="0" alt="whistling.gif" />
Posted by: urthman Oct 14 2008, 04:34 PM
That's a good first sentence to introduce the thing. But do you really mean "everything"? Every single mod in my mod list is supposed to be held together with the Bashed Patch? Or is it only some of them? And if only some of them, why those and not the others? My impression (thanks, running4cover!) is that some mods work ok if they're just loaded in the right order, but others need to be reconciled somehow by the bashed patch.
The practical question is, do I need to rebuild my Bashed Patch, and if so, which mods should be included?
I wasn't really asking, as some here seem to be, how exactly the code works. Just enough to figure out which mods it's needed for. (And by extension which mods should go before / after the bashed patch in the load order).
Posted by: running4cover Oct 14 2008, 05:23 PM
All your mods should still be chacked off as active, even if they are in your bashed patch. If they are merged, then they should have the "+" symbol instead of the check mark. Bashed patch is NOT the result of mixing all your mods together, it is what you USE to mix them together. It takes aspects (like levelled lists and inventories) fro different mods, and nixes them, like say two mods change the same levelled list; without using Bashed Patch correctly, then whichever of those two mods loads later will be the only one that actually changes the Levelled List, however, if you use both of those mods together WHILE running your Bashed Patch correctly, then both of them will make changes to the same list properly (i.e. mod 1 adds rubys to a levelled list, mod 2 adds saphires, if you run Wrye Bash while running both of these, then both Rubys AND Sapphires will be added to the levelled list). I hope this helps people out.
CC
EDIT:
The practical question is, do I need to rebuild my Bashed Patch, and if so, which mods should be included?
I wasn't really asking, as some here seem to be, how exactly the code works. Just enough to figure out which mods it's needed for. (And by extension which mods should go before / after the bashed patch in the load order).
If you add a mod that Wrye Bash would change (alters levelled list for example), then you should always highlight the mod, right click, click "mark levellers", then rebuild your Bashed Patch (while it's active). You can sort of decide on your own what you want it to do, but generally speaking, whenever a mod has something that your Bashed Patch would change, then you should mark levellers and rebuild. I hope this is more of the answer you were looking for, and apologise for not reading your last post before posting :-P
Posted by: DragoonWraith Oct 14 2008, 06:08 PM
OK, really? I know several of you in here know what the Bashed Patch does and how it does it, why the lack of explanations?
The first step to understanding the Bashed Patch is to understand how load order works. To understand that, you need to understand the basics of how mods work.
OK, so, to begin - Oblivion.esm. This file was created by Bethesda using the Construction Set (allegedly identical to the one we get to download; I have my doubts about that, but whatever, theirs was certainly similar). It contains lots of data. This data can be divided into several different types. The most basic of these is the "Form". Pretty much everything in the game is a Form. Forms have FormIDs, these are the hexadecimal numbers you use with AddItem if you're using the console to cheat. Items have them, weathers have them, characters have them, cells have them, quests have them. Some things do not - magic effects, for example, are hard-coded. Game settings are hard-coded. Skills are hard-coded. But most everything that can be made with the construction set gets a FormID and thus is a form.
Forms can generally be broken down into base objects and references. Not all base objects have references, and not all types of base objects can have references, but all references refer to a base object. References are the 3D representations of base objects. This has lots of importance all over the place, but is a bit tangential to the Bashed Patch.
The way mods work is that .esp files modify (or add) forms. Most are based on Oblivion.esm, which means they are dependent on it, and can change things about its forms. When Oblivion loads, it starts with Oblivion.esm. After that, it loads .esp plug-ins by date order. It reads the .esp, and when it comes across a form that is also found in Oblivion.esm, it first checks to make sure that the Forms have the same type (reference, weather, item, quest, whatever), and as long as that is true (which it should be), it replaces Oblivion's version with the mod's version. If another mod later changes the same Form, Oblivion replaces the first mod's with the second mod's. And therein lies the problem.
Because it's out-right replacement, if two mods change two different things about a Form, only one of those changes actually gets loaded; the other gets overwritten. In the case of Leveled Lists, this is especially bad - simply adding items to a Leveled List changes the Form. So if two different mods try to add things to the same list - only one is going to work.
What the Bashed Patch does is it goes through the forms, and combines changes from different mods into one mod, so that Oblivion can load all of them. Therefore, multiple different mods can add items to the Leveled Lists and it will work.
Does that explain things? I know I haven't gone into how to decide what mods should be merged; that's better answered by others. But I think some people were interested in this information.
Posted by: baker99 Oct 14 2008, 09:08 PM
Thanks both of you that helps a lot.
Posted by: dogeese Oct 14 2008, 09:30 PM
Gold star goes to DragoonWraith, well put.
I knew most of that but my brain dont work that way, wouldnt be able to write it down..
Posted by: Sphagne Oct 15 2008, 12:51 AM
You can include some game tweaks in Bashed Patch as well, for instance the amount and time of arrows on the ground and the like...
As for merging mods together here are some examples:
If a mod changes the voices of a race and another one changes another characteristics like the races skills, normally the mod that comes later overwrites the changes from earlier mods, but with bashed patch you can have them all work together.
Like-wise a mod may change an NPC's inventory and another mod can change his face and so on... You need Wrye's Bashed Patch to make them work together...
The list of example and go on and on, but you get the point, I hope. <img src="http://static.bethsoft.com/bgs/style_emoticons/default/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" />
Thanks Wrye for the masterpiece.
Posted by: TamaraUK Oct 15 2008, 01:37 AM
Not if you are only taking the graphics from one to use with another. Here is an example from my experience. Please note the last line particularly. Needless to say, if someone else has a better way I am open to learning.:
From the readme:
'Tamriel Travellers Horse Textures is a simple fix to make Slof's horses textures and reins appear on travelling merchant's horses. This mod only changes the appearance of the horses from Tamriel Travellers mod, by CorePC.
I (Ulrim) created it to allow the merchants to ride Slof's beautiful horses.'
Being a bit 'BASH challenged' I needed help from the BASH thread to understand how to get this mod working. I'm glad I took the trouble because it is great. Most of the instructions are thanks to Vacuity of 'Item Interchange mod' fame with a couple of clarifications and slight changes from me.
1) Make sure the mod you want the graphics from is activated. (In this case, I made an OMOD and activated Tamriel Travellers Horse Textures.esp)
2) Open Wrye Bash.
3) Locate the mod with the graphics: In this case, Tamriel Travellers Horse Textures.esp) and select it.
4) Look at the frames in the right column of Bash
You should see File, Author, Modified and Description. You want to change the Description.
5) Add a new first line "Template:BASH:Graphics" (without the "s) In this case, there was a similar line, but I needed to make the line exactly "Template:BASH:Graphics" (without the "s) so that I could save it.
6) Click the save button in the lower right hand corner of Bash.
If you forget to click save before you click somewhere else you will lose your new first line, repeat steps 5 and 6.
7) Right click on 'Bash Patch esp and click on 'Rebuild' to Rebuild your patch, you should now see an option to import graphics.
Remember to select both the Import graphics feature in the left pane *and* the mod concerned in the right pane. In this case, Tamriel Travellers Horse Textures was already in the right hand frame and checked.
8) DEACTIVATE Tamriel Travellers Horse Textures (Ulrim's instructions were confusing in this case as he said not to activate it. As TTHT did not appear in the BASH list when it was was not activated, I chose to activate it to do the BASHing and then deactivated before loading Oblivion.
Posted by: Bal Cleric Oct 15 2008, 07:03 AM
Yay I'm not the only one, this thread is helping to clear up my niggling doubts. I understood the gyst of it all but my mind needed to know how it all worked and it all makes sense now. Thank you all. Damn I love this community.
Posted by: Vacuity Oct 15 2008, 07:14 AM
Kudos to Dragoonwraith for giving the "why" and TamaraUK for giving the quintessential "how to" for importing.
I am hoping one of these days I'll get to write a "Bash patch for dummies" guide. For computer-savvy native English speakers the Bash documentation is generally quite sufficient (though I sometimes query whether I am understanding things correctly), but for people who are, uhh, less computer-literate, or just find English difficult the documentation is a bit impenetrable.
As always, it's a lack of time and I've also no idea where would be a suitable place to post the guide. There's no question to me that there's a need for it as questions along these lines are asked very frequently.
If people could suggest a good place to host a dummies guide then I'm listening and I might get around to writing it (or some other Bash-literate person might do it first, of course (no, really, go on!)).
Vac
Posted by: amitlath Oct 15 2008, 08:25 AM
two places come to mind: stickied in this forum (link to any of the free hosting sites like rapidshare) and link on dev_akm's googlepages site.
edit: how about tesnexus too? i have seen other such guides hosted there.
Posted by: AlizarinCrimson Oct 15 2008, 09:08 AM
Vac
Here's how I'd release a guide:
Post it as a download on TESnexus; in the guide and in the description I would add this info:
I'd also ask dev-akm if he could host the guide as well; I'd also ask Wrye as well.
Posted by: TamaraUK Oct 15 2008, 09:11 AM
I am hoping one of these days I'll get to write a "Bash patch for dummies" guide. For computer-savvy native English speakers the Bash documentation is generally quite sufficient (though I sometimes query whether I am understanding things correctly), but for people who are, uhh, less computer-literate, or just find English difficult the documentation is a bit impenetrable.
As always, it's a lack of time and I've also no idea where would be a suitable place to post the guide. There's no question to me that there's a need for it as questions along these lines are asked very frequently.
If people could suggest a good place to host a dummies guide then I'm listening and I might get around to writing it (or some other Bash-literate person might do it first, of course (no, really, go on!)).
Vac
Vac, Thanks back to you, mate. <img src="http://static.bethsoft.com/bgs/style_emoticons/default/foodndrink.gif" style="vertical-align:middle" emoid=":foodndrink:" border="0" alt="foodndrink.gif" /> I can only take credit for doing what you told me to do and for changing / adding point 8 of the instructions. YOU need accept credit for the rest, as it is from what you told me to do (as I said in my post). So, maybe this section on how to Bash Patch graphics is the first section of your 'How to Bash with Style Manual'. <img src="http://static.bethsoft.com/bgs/style_emoticons/default/1277.gif" style="vertical-align:middle" emoid=":bigsmile:" border="0" alt="1277.gif" />
Posted by: dev_akm Oct 15 2008, 09:47 AM
I am hoping one of these days I'll get to write a "Bash patch for dummies" guide. For computer-savvy native English speakers the Bash documentation is generally quite sufficient (though I sometimes query whether I am understanding things correctly), but for people who are, uhh, less computer-literate, or just find English difficult the documentation is a bit impenetrable.
As always, it's a lack of time and I've also no idea where would be a suitable place to post the guide. There's no question to me that there's a need for it as questions along these lines are asked very frequently.
If people could suggest a good place to host a dummies guide then I'm listening and I might get around to writing it (or some other Bash-literate person might do it first, of course (no, really, go on!)).
I would be willing to help with this effort.
I'd suggest hosting it on UESP or the CS Wiki. That way it's easy to collaborate on it with others, keep it updated, etc.
Posted by: urthman Oct 15 2008, 03:19 PM
Thanks to everyone who pitched in with an explanation. This really helps.
The main question remaining for me is how do you know which mods to bash patch?
For instance. I just installed LAME and Supreme Magicka. It seems that they manage to resolve their overlaps just by having you load them in a certain order. But would they benefit from being bashed together? Or would that just screw everything up?
These two mods have explicit instructions saying they can work together. But if they didn't, if i have other mods that seem like they might have overlap in them, should I just assume they need to be bashed together?
Also I use FCOM helper, which automatically rearranges the mods it recognizes into the best order and gives a little report about it. For some of the mods it says something like "tag as hair, and BASH". I sorta know what that means, having done it cookbookstyle when I installed TNR, but (I forget the exact wording) FCOM helper makes it sound like a recommendation that might make things smoother rather than a "WARNING this won't work unless you BASH it!" So is it just something that will make mods load faster or is it actually something I need to do to prevent problems?
Posted by: bg2408 Oct 15 2008, 03:31 PM
Bash them together? How?
What bashing does is combining different subrecord changes to a record. Example given two mods add something (subrecords) to a leveled list (record). Due to the http://www.bethsoft.com/bgsforums/index.php?showtopic=775917 the two mods would completely overwrite each other, because changes are saved on a record level. Thanks to Bash both subrecords get combined into the record, so both things added to the list can appear.
This does not work with magic. At least not that good. Stuff like damage, duration, base cost and all that are not different subrecords, but the same subrecord - whatever you do, only one can take effect. A fireball can only deal 30 or 40 or 50 damage, but not 30 and 40 and 50 damage. <img src="http://static.bethsoft.com/bgs/style_emoticons/default/blink.gif" style="vertical-align:middle" emoid=":blink:" border="0" alt="blink.gif" />
The thing with FCOM Helper's recommendation is to understand why it prints these warnings. Bashing is for many record types essential to prevent the rule of one kicking in. Example given OOO + TNR: Without Bash ( -> rule of one) you can either have new faces + complete level scaling, or no new faces + OOO's scaling overhaul.
Posted by: Riston Oct 15 2008, 03:47 PM
then what about the Replacers tab in Wrye? I have not been able to figure out what that is for. i for the most part just se4lectall my mods, mark levellers, mark mergable, and then rebuild my patch selecting the options i want. is this not the way to do it? am i missing something? <img src="http://static.bethsoft.com/bgs/style_emoticons/default/shrug.gif" style="vertical-align:middle" emoid=":shrug:" border="0" alt="shrug.gif" />
Posted by: AHumbleUnitarian Oct 15 2008, 04:20 PM
All a bashed patch happens to be is a merger of leveled list and container/inventory contents across mods. If you've got a mod that adds something to a container, and another one does as well, the bashed patch makes sure both items show up, rather than the last mod getting the changes made, and the lower ranking one getting no changes at all.
It's just a fix to get around some basic problems with changing the same inventory/container/leveled list in several different mods.
There are some other more complex uses for a bashed patch, but the main thing you need to know is what I just told you.
Edit: The replacers tab I would assume is to install any mesh changes that various mods put in. Basically, if you change the body meshes from normal to Exnem's or something like that, and you're forming a bashed patch, that's what it would be under. Same for houses and retexes I would think. This is if it's done on an ESP level though, rather than just installing the meshes where the old ones were supposed to go. (Thank god for .bsa files...)
Posted by: Fillythebish Oct 15 2008, 04:47 PM
What if I "want" a certain mod to over write another, would the bash patch stop that from happening?
For example.
If I make a mod that changes the level lists completely and I want that mod to load last so it overwrites the past mods, would a bashed patch get in the way of that and cause the mod to take on some elements of the past level lists that I'm trying to overwrite?
Posted by: MadCat221 Oct 15 2008, 04:52 PM
For example.
If I make a mod that changes the level lists completely and I want that mod to load last so it overwrites the past mods, would a bashed patch get in the way of that and cause the mod to take on some elements of the past level lists that I'm trying to overwrite?
Yes, through proper application of the NoMerge bash tag.
Posted by: baker99 Oct 15 2008, 04:53 PM
Thanks TamaraUK, that tip about deactivating is useful, I think I now get why fcomhelper sometimes says bash then deactivate and other times just bash.
A dummies guide would be great, I am a native english speaker (not american english but true english <img src="http://static.bethsoft.com/bgs/style_emoticons/default/tongue.gif" style="vertical-align:middle" emoid=":P" border="0" alt="tongue.gif" /> ) and also pretty tech savvy, I work with the OSC on NASA World Wind, but the bash docs still confuse me <img src="http://static.bethsoft.com/bgs/style_emoticons/default/wink.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink.gif" />
Posted by: Wrye Oct 15 2008, 04:56 PM
Bash Guide for Dummies:
Don't use it. <img src="http://static.bethsoft.com/bgs/style_emoticons/default/biggrin.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin.gif" />
Okay, a bit more nicely...
Using lots of different mods with Oblivion is inherently complicated. No matter what you do, or how you talk about it, the subject is inherently complicated, and so the instructions are complicated as well. No way around that.
As for the Bashed Patch, that's inherently complicated too. That one patch does twenty or thirty very different things. E.g. I was just posting on Sage Rime's topic. Of the four or so mods listed in Sage Rime's sig, two are "Horse Turning Speed" and "Armor Repair Costs". Two mods that do quite different things -- yet the full functionality of those mods is available in the bashed patch as two relatively minor options. (I say this not to dis Sage Rime -- my point is solely that the Bashed Patch is BIG -- it's got a lot of features and can do a lot of stuff. I.e. there's a limit to how simply you can explain Wrye Bash.
So, in practice there are two approaches to understanding what you can and should do with Wrye Bash:
1) Understand how mods work. Understand about records. Understand the Rule of One. Understand how specific records conflict (e.g. race records). Understand how one mod can override (patch) another mods records (including esp-mastering). Understand how given records would need to be manually patched to resolve differences. Understand how rebuilding a Bashed Patch does that automatically. (Understanding at the same time, that different components of the Bashed Patch work quite differently from each other.)
2) Black box. Forget understanding how it works, just understand the steps of what you're supposed to do.
Obviously approach number one is pretty complicated -- few people do this -- I'm probably the only one who does it fully, although dev_akm and other experienced integrative modders probably get most of it. On the other extreme, people who have the hardest time with bash have to stick with approach two. Someone else lays out step by step instructions and they follow that. The nice thing about this is that normally, you only configure your bashed patch once -- after that you just select "Rebuild Patch" and then click Okay without changing any settings.
In between those two extremes, many user/players will understand some components, but not others. E.g. if you know what a GMST is, then Bash's "Tweak Settings" is pretty easy -- each tweaked setting just sets a GMST. Likewise, if you know about light flickering, then you understand that it's turned off by editing the light records from various mods, so it's not that hard to understand how Bash's "No Light Flicker" works.
OTOH, some Bash components are inherently complicated. Leveled list merging is moderately complicated. Even if you don't understand the internals of how Bash shuffles the lists, you still have to understand:
1) generally how lists work,
2) difference between: a. adding a new item to the list, b. changing the level of an item in the list, and c. deleting an item from a list.
3) specific mods well enough to know how they're modifying lists (adding, releveling or deleveling), etc.
In practice, so few people know this stuff well enough, that instead most people rely on pre-existing knowledge about what should be tagged. Pre-existing knowledge comes from:
1) Authors pre-tagging their mods.
2) Mark Levelers which knows about a few specific mods
3) FCOM Helper which knows quite a few mods
4) Forum experts who can tell you what and what not to tag.
Summary:
It would be nice if the Bashed Patch were simpler to use, but the fact is that it does a lot of very different, and sometimes very complicated things -- and it does them to resolve conflicts between mods that already are pretty complicated things.
In games, you get complexity bit by bit. First, learn one power, then expand it. Then go on to a different power. You end up with a complicated set of powers, but you forget that it took you a while to get there.
With Bash you get all that power up front. Don't try to understand it all at once! Take it in pieces -- start with one component and then gradually expand to other components that you find interesting. You won't get there in a day, but if you keep playing and occasionally "upgrading" your patch, you'll get there soon enough.
Posted by: Fillythebish Oct 15 2008, 05:12 PM
Well all my mod changes appear to be working as I expect them to, so I shall not mess with the batched patch... What ever its doing <img src="http://static.bethsoft.com/bgs/style_emoticons/default/1277.gif" style="vertical-align:middle" emoid=":bigsmile:" border="0" alt="1277.gif" />
Posted by: MystykStar Oct 15 2008, 05:13 PM
2) Open Wrye Bash.
3) Locate the mod with the graphics: In this case, Tamriel Travellers Horse Textures.esp) and select it.
4) Look at the frames in the right column of Bash
You should see File, Author, Modified and Description. You want to change the Description.
5) Add a new first line "Template:BASH:Graphics" (without the "s) In this case, there was a similar line, but I needed to make the line exactly "Template:BASH:Graphics" (without the "s) so that I could save it.
6) Click the save button in the lower right hand corner of Bash.
If you forget to click save before you click somewhere else you will lose your new first line, repeat steps 5 and 6.
7) Right click on 'Bash Patch esp and click on 'Rebuild' to Rebuild your patch, you should now see an option to import graphics.
Remember to select both the Import graphics feature in the left pane *and* the mod concerned in the right pane. In this case, Tamriel Travellers Horse Textures was already in the right hand frame and checked.
8) DEACTIVATE Tamriel Travellers Horse Textures (Ulrim's instructions were confusing in this case as he said not to activate it. As TTHT did not appear in the BASH list when it was was not activated, I chose to activate it to do the BASHing and then deactivated before loading Oblivion.
Ahhhhh, that's how to do that. When I used FCOM Helper for my load order some suggestions were to tag some mods as BASH:Something and I had no clue what that meant or how to do that. I just rebuilt my patch the only way I know how.
Thanks for including those instructions, TamaraUK, that is handy for me and makes sense <img src="http://static.bethsoft.com/bgs/style_emoticons/default/fing34.gif" style="vertical-align:middle" emoid=":goodjob:" border="0" alt="fing34.gif" />
Posted by: Wrye Oct 15 2008, 05:51 PM
Bash Help Guide Location
Although I argue in the previous post that there's a pretty strong limit on how simply an inherently complicated tool for an inherently complicated modding world can be explained, it's still an option. If someone wants to take that on, then the place to do it is at UESP which already has an area set aside for http://www.uesp.net/wiki/Tes4Mod:Wrye_Bash. Specifically:
* General, step by step instructions should be done on http://www.uesp.net/wiki/Tes4Mod:Wrye_Bash/Basic.
* Bashed patch how to's and FAQs go on http://www.uesp.net/wiki/Tes4Mod:Wrye_Bash/Bashed_Patch.
Other than that, poke around a bit on the other pages to see what's appropriate.
Semi-Cynical Observations
* Many people underestimate how difficult it is to write simple instructions. I've several times seen people try to explain a Bash (or Mash) feature "simply" and end up with an explanation that's longer than my own.
* Most users don't read docs. (E.g. discussion above strongly suggests to me that most people here are NOT familiar with the Bash docs at UESP, despite the fact that they're linked to from multiple places (my home page, bash docs themselves, top of the bashed patch thread, etc.).
* When doccing complicated stuff, there's a difficult trade off. Step by step instructions are long. If you put a bunch of them together, some people will find them "too complicated" simply because there's a lot of text. On the other hand, if you make the instructions more concise, then readers won't understand them because they're too short. <img src="http://static.bethsoft.com/bgs/style_emoticons/default/shrug.gif" style="vertical-align:middle" emoid=":shrug:" border="0" alt="shrug.gif" />
* Many users find it simpler to ask on a forum for an answer that's already answered quite clearly in a readme. Despite the fact that the web, search buttons, highlighting etc. make it terrifically easy to search for information, many people still will not make that effort, but instead will ask other people to, in effect, search and read the docs for them. :angry: (I while back I flamed Aelius for exactly this sort of thing.)
I very much appreciate it when folks help other users to understand and use Bash -- I'm just saying that it may be more difficult and frustrating than you expect it to be.
Posted by: AlizarinCrimson Oct 15 2008, 07:42 PM
This is exactly where I stand; I would love to fully understand the magic it works, but I really don't have to the time to figure it out; my use of bash is pretty much merge and level stuff and some tweaks and then I actually make custom patches with tes4edit since I just don't no what tags to use and when to use them and all that neat and cool stuff so I do it by hand with a custom patch.
My bashed patch works therefor I trust that I followed the instructions and shall not go further on my own.
Posted by: urthman Oct 16 2008, 01:58 PM
This does not work with magic. At least not that good. Stuff like damage, duration, base cost and all that are not different subrecords, but the same subrecord - whatever you do, only one can take effect. A fireball can only deal 30 or 40 or 50 damage, but not 30 and 40 and 50 damage. <img src="http://static.bethsoft.com/bgs/style_emoticons/default/blink.gif" style="vertical-align:middle" emoid=":blink:" border="0" alt="blink.gif" />
I guess I was thinking that since both mods add new spells for merchants to sell that you might need to bash them together so that the same merchant can get new spells from both mods. That doesn't seem to be the case because the mods claim to work together fine if you just get the load order right, but I have no idea why you can have different mods adding spells to the same merchant but can't have different mods adding items to the same merchant's inventory without bashing them together.
But I appreciate what Wyre is saying. This is rocket science and I'm happy to leave the whole thing alone and just be grateful to geniuses like Wrye for their hard work and assume I don't need to touch it unless a mod like TNR comes along with step-by-step instructions for doing so.
Which means that Wyre's instructions for Wyre Bash are actually quite helpful. They made it clear to me "You don't understand this. Don't fool yourself into thinking you do!"
Posted by: bg2408 Oct 16 2008, 02:20 PM
There are ways around certain limitations and compatibility problems. In fact if we had used the "brute force" approach and added the spells directly to the merchants, then both mods wouldn't work together (and with a high number of other mods). That's the same as adding something to the default merchant chest - bad idea, because then the "rule of one" kicks in.
Both mods are using long since known workarounds to keep compatibility. This is possible for spells (a one time running quest script does the trick), as it is possible for merchants and items (using simply new unique chests).
Unfortunately many modders - especially those not present here - don't know about or even ignore simple compatibility tricks and instead resort to "brute force". There are cases in which not even Bash can save the day then <img src="http://static.bethsoft.com/bgs/style_emoticons/default/nope.gif" style="vertical-align:middle" emoid=":nope:" border="0" alt="nope.gif" /> .
Posted by: Vacuity Oct 16 2008, 05:47 PM
Don't use it. <img src="http://static.bethsoft.com/bgs/style_emoticons/default/biggrin.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin.gif" />
Semi-Cynical Observations
* Many people underestimate how difficult it is to write simple instructions. I've several times seen people try to explain a Bash (or Mash) feature "simply" and end up with an explanation that's longer than my own.
I agree, largely, with your opinion. When dealing with complex tools there's an inverse relationship to writing simple instructions. The simpler your instructions, the harder it is to write them. Personally, I'm just as put off by the simple fact that most people just aren't going to read documentation and will just post here. If they're told to read it they'll click the link, look for three seconds and then re-post saying they looked and didn't understand it and could someone please waste 5 minutes of their life repeating the relevant bit of information for them.
I would argue the problem here is that many people don't even get this level of understanding, and that's the level of guide I think is missing. And, really, I'm busy and I frankly doubt it's going to be read properly by that many people, so this just isn't anywhere near the top of my list of things to do.
Vac
Posted by: phillygirl41 Oct 16 2008, 11:19 PM
Wrye is right. ..
Unless my 25 yr old Linux red hat user is right next to me when I do something I'm hopeless.
He built my patch, he modified my load order. He knows Python. He gets it. I don't.
Thank god he's here and he doesn't even play ob. He just looks at files/cmd thingies. I dunno. I don't get it and never will.
but I can play OB now with Wrye and as long as my son breathes I'm o.k. LOL.
Maybe people will say I shouldn't play OB cause I can't get it, but I look at it as, I can play it without mods, my son helps me to enhance it.
Big deal? not really.
Posted by: urthman Oct 21 2008, 01:03 PM
One last stupid. black-boxy question.
Am I supposed to un-check (remove from load-order) mods included in the bashed patch? That seems to be what Wyre's instructions are saying, but the cookbook I used to install FCOM didn't tell me to uncheck the FCOM mods that are in the patch.
Posted by: Vacuity Oct 21 2008, 01:18 PM
Am I supposed to un-check (remove from load-order) mods included in the bashed patch? That seems to be what Wyre's instructions are saying, but the cookbook I used to install FCOM didn't tell me to uncheck the FCOM mods that are in the patch.
"included"? If you mean merged, then it is perfectly safe to de-activate them, but I wouldn't recommend removing them from the data folder (and thus removing them from your load order completely).
Once a mod is merged it's fine to click the check box to it's left and you should then see a "+" sign instead of a check. The mod remains in the correct space in your load order and will show up when you ask Bash to display a text list of your mods.
Hope this helps,
Vac
Posted by: wmj Oct 21 2008, 03:14 PM
1. deactivate all mergeable mods to be selected in the Bashed Patch configuration menu (I mean leave them selected in the Bashed Patch configuration menu, of course, but deselect them in the main mod list), as well as all mods that only add tagged data types to the Bashed Patch (like TNR, or mods tagged with Graphics that only add Graphics, or say, Robert's Male, which only adds Body-M data);
2. deactivate the Bashed Patch itself
3. rebuild the Bashed Patch.
When the rebuild is complete, Bash will ask if you want to activate the Patch; say yes and the patch will activate, and all the merged mods will automatically be "virtually" activated with a "+" sign, and the "tagged only" mods will be virtually activated with a "*". Saves having to click everything to change the status of the mods from really to virtually active, and saves having to remember which mods need to have their status changed (since if you deactivate a mod that is not virtually active in the patch, but is instead a master of the patch, the patch will deactivate (because you've deactivated a master that it depends on), and then you have to futz around with the thing even longer <img src="http://static.bethsoft.com/bgs/style_emoticons/default/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /> ).
Posted by: dev_akm Oct 21 2008, 04:08 PM
1. deactivate all mergeable mods to be selected in the Bashed Patch configuration menu (I mean leave them selected in the Bashed Patch configuration menu, of course, but deselect them in the main mod list), as well as all mods that only add tagged data types to the Bashed Patch (like TNR, or mods tagged with Graphics that only add Graphics, or say, Robert's Male, which only adds Body-M data);
2. deactivate the Bashed Patch itself
3. rebuild the Bashed Patch.
When the rebuild is complete, Bash will ask if you want to activate the Patch; say yes and the patch will activate, and all the merged mods will automatically be "virtually" activated with a "+" sign, and the "tagged only" mods will be virtually activated with a "*". Saves having to click everything to change the status of the mods from really to virtually active, and saves having to remember which mods need to have their status changed (since if you deactivate a mod that is not virtually active in the patch, but is instead a master of the patch, the patch will deactivate (because you've deactivated a master that it depends on), and then you have to futz around with the thing even longer <img src="http://static.bethsoft.com/bgs/style_emoticons/default/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /> ).
Yeah, I have to agree with this. It would be way too much hassle to for me to constantly activate/rebuild/deactivate so many imported/merged mods. I have a lot of them and I rebuild my Bashed Patch multiple times every day because I'm doing a lot of development/testing.
I've never found any problem with leaving them inactive while Rebuilding the Bashed Patch.
Posted by: six Oct 21 2008, 04:23 PM
Gnomes climb out of the spikes in dev_akims hair when you install FCOM or when you use a Bashed Patch. Its quite amazing actually. And they fiddle until it works, which usually takes 45.68.01 [yes .01 of .68...not exactly .67 and not .69] trigilomanomagigawonanoseconds.
Posted by: Vacuity Oct 21 2008, 09:07 PM
I've never found any problem with leaving them inactive while Rebuilding the Bashed Patch.
That's what I get for replying when I am tired, isn't it? <img src="http://static.bethsoft.com/bgs/style_emoticons/default/tongue.gif" style="vertical-align:middle" emoid=":P" border="0" alt="tongue.gif" />
I should have added a line about not needing to re-activate them again subsequently, as heaven knows re-activating and de-activating patches like you guys describe it on a regular basis would have caused me to cease developing II a long time ago. In fact I'm not even sure where it sounded like I was saying to do that...
To be honest, I don't see much difference between deactivating all the merged patches before rebuilding the bashed patch and deactivating them all after building the bashed patch. The way I suggested saves you deactivating something accidentally that you need active in the bashed patch, as if you do the deactivation beforehand you might not notice, but if you do it afterwards the bashed patch will be deactivated automatically which will tell you about your boo-boo.
Cool! Does it happen for people who aren't running FCOM too?
Vac
Posted by: wmj Oct 22 2008, 06:29 AM
"Active in the Bashed Patch" is not the same as "Active in the game".
To be "active" in the Bashed Patch, a mod need only be:
1) present in the Data folder (meaning physically there so that it shows up in the mod list, but it need not necessarily be active in the mod list in the main Bash window);
2) tagged so that it shows up in a section of the Bashed Patch Configurator (that dialog that shows up when you choose "Rebuild Patch");
3) in an "active" section of the Bashed Patch Configurator (in other words, if the mod is tagged with, let's say, Template:Hair, Eyes, the "Race Records" option of the Bashed Patch Configurator must be checked on the left side of the Bashed Patch Configurator so that Bash looks at that section at all)
4) active in the active section of the Bashed Patch Configurator (in other words, if the mod is tagged with Template:Hair, Eyes and the "Race Records" section of the Bashed Patch Configurator is active, the mod itself must be checked in the right hand panel of the Bashed Patch Configurator when the "Race Records" section is selected, so that Bash knows that it should look at that specific mod for race records).
This is completely internal to the Bashed Patch itself, and is separate from activation or deactivation in the mod list as a whole. It is quite possible to have a tagged mod ignored entirely by the Bashed Patch (by unchecking its section, by unchecking the specific mod in its section, even if the section itself remains active, and/or by deactivating it in the mod list (so it's not even considered a master of the Bashed Patch) and deactivating it in its section (so that no records are imported from that mod to the Bashed Patch).
I'm going to try a concrete example to illustrate what I'm talking about (hope it works <img src="http://static.bethsoft.com/bgs/style_emoticons/default/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /> ).
Let's take Ethereal Eyes (replacer version), which only adds eyes (using the default meshes) to the default races. This should of course be tagged with Template:BASH:Eyes.
Let's talk about the tags and the purpose of tagging for a minute.
As many of you know, the whole problem with an eye mod (for example) is that the CS/Game engine can't just say "add these eyes to the race record" and leave it at that. To add eyes (which are a subrecord of the RACE record), the game/CS has to take the whole rest of the RACE record, which also includes:
- the racial skill bonuses
- the racial spells/abilities
- the height and weight of the race's members
- the pointers to the body part meshes and textures for that race
- the facial shape parameters of the race
- the text name and description of the race as seen in character gen
- the racial relationships to other races (how much Khajiit hate Wood Elves, and vice versa).
- and of course, the hair and eyes associated with the race
So the problem is that if another mod wants to change the body mesh and textures (like UFF, say, and Robert's Male) and Ethereal Eyes wants to change the eyes, the data in both mods necessarily contains all the other subrecords of the race as well-- which are probably set at vanilla defaults-- in addition to the subrecord that they are changing..
So if Ethereal Eyes loads after UFF, Ethereal Eyes (which must also contain the RACE subrecord of the pointers to the body mesh, which in Ethereal Eyes is set to default, because Ethereal Eyes doesn't change the body, only the eye availability) will set the body back to default (because of the Rule of One-- if two mods affect the same thing, in this case, RACE, the mod loaded last wins).
If UFF loads after Ethereal Eyes, UFF (which must by necessity also contain the RACE subrecords of eye availablity, which in UFF is set to default, because UFF doesn't change eyes, only the body) will set the eyes back to the default eye selection (because of the Rule of One).
What the Bashed Tag does is tell Bash to copy out the Eye subrecords from Ethereal Eyes, and the Body Pointers from UFF--and only those subrecords-- and append (add) them to a new RACE record in the Bashed Patch itself.
So the Bashed Patch's RACE record contains the subrecord pointing to Ethereal Eyes, and the subrecord pointing to the UFF body. If you then added oh, Babe hair (which only adds new hair selections) and tagged that with Template:BASH:Hair the Bashed Patch would snip out the hair subrecords from Babe and add them to its own RACE record, so that would now contain Ethereal Eye selections, Babe hair selections, and pointers to the UFF body.
Because the Bashed Patch loads last (or as close to as possible), its RACE record overrides everything else, by the Rule of One.
But in this case, there's no reason to even invoke the Rule of One-- because all of the relevant records for hair, eyes and body have been imported into the Bashed Patch itself, there's no reason to ask the game to load the original mods at all, because all they have to offer is the data that will be loaded by the Bashed Patch anyway.
So it's perfectly fine to deactivate those mods-- and since the mod doesn't have to be active for its data to be imported into the Bashed Patch (it just needs to be present in the Data folder, and activated in the Bashed Patch configurator to tell the BPC to import data from that specific ESP), you can just as well do it before even building the Bashed Patch as after (which you're less likely to remember).
Again, if you deactivate mods whose records are completely imported into the Bashed Patch (even if the mod is not merged; in this case, the relevant records are imported and the rest of the mod-- which only contains "junk" (junk in the sense that they're of no use to us) vanilla settings for the other subrecords-- is essentially thrown away), and also the Bashed Patch prior to rebuilding the Bashed Patch (that's just good sense; you don't really want the Bashed Patch rebuilding itself while it itself is active, just like you wait for the first coat of paint to dry before putting on the second), when you activate the Bashed Patch after rebuilding, it will itself "mark" the formerly deactivated merged and "import only" mods as "virtually" active all by itself (with a "+" or a "*" as relevant). So that is much easier in that you don't have to change the status from a full checkmark to a "+" or a "*" by clicking your whole list afterwards, and you don't have to remember after the fact which mods are really and virtually active to "un"check the right ones-- you can uncheck them when you tag them, which is much easier to remember (one mod at a time, not a list of 225).
On the other hand, a mod like, say Beautiful People contains much more data than just what is imported by the Bashed Tag (hair and eye records). These do need to be imported into the Bashed Patch (in the event that other mods also affect the RACE record, we still want BP to add its hair and eye selections), but we certainly don't want to lose the new races, and the custom race fix which are also included, and which records will not be imported by the Bashed Patch via the Template:Hair,Eyes tag. These will only be loaded by the game if the ESP is active, so even though some of its records are imported to the Bashed Patch, BP must remain active in the main mod list (both during and after rebuilding the Bashed Patch), so that the game will have access to this additional data which is not contained in the Bashed Patch, but only the mod.
The mod list in the main Bash window represents the mods to be loaded by the game engine when you click the Oblivion shortcut on your desktop, and the Bashed Patch is at that point just another ESP in the list. The Bashed Patch Configurator is (oversimplified) a kind of super-CS, cutting and snipping and copying and pasting records from mod ESPs to its own (the Bashed Patch), but just like the CS, it is totally separate from the action of your mod list, in that whether or not mods are active in your mod list is not controlled by the Bashed Patch any more than having Beautiful People active in your mod list controls whether CM Partners is active or not elsewhere in that list.
However, the Bashed Patch does have influence on whether or not particular mods it includes should be active in your mod list when it's creating its database of what records it contains, and their place in the load order... but as always, you the user are responsible for the "fine tuning" that is required. And again, as always, that means knowing what your mods do, fairly precisely, in order to correctly know what needs to stay active even if in the Bashed Patch, and what doesn't, because it's in the Bashed Patch.
Posted by: Vacuity Oct 22 2008, 07:08 AM
Am I supposed to un-check (remove from load-order) mods included in the bashed patch? That seems to be what Wyre's instructions are saying, but the cookbook I used to install FCOM didn't tell me to uncheck the FCOM mods that are in the patch.
I don't think I am getting confused in the slightest <img src="http://static.bethsoft.com/bgs/style_emoticons/default/whistling.gif" style="vertical-align:middle" emoid=":whistle:" border="0" alt="whistling.gif" /> : the question was about un-checking mods merged into the bashed patch. I assumed he had already made the bashed patch and told him he could de-activate the mods that were merged.
All credit to you for going to all that effort to write everything out though...
Vac
Edit: Well, perhaps my explanations are not as well laid out as they could be. <img src="http://static.bethsoft.com/bgs/style_emoticons/default/biggrin.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin.gif" />
Posted by: dev_akm Oct 22 2008, 10:40 AM
"Active in the Bashed Patch" is not the same as "Active in the game".
To be "active" in the Bashed Patch, a mod need only be:
1) present in the Data folder (meaning physically there so that it shows up in the mod list, but it need not necessarily be active in the mod list in the main Bash window);
2) tagged so that it shows up in a section of the Bashed Patch Configurator (that dialog that shows up when you choose "Rebuild Patch");
3) in an "active" section of the Bashed Patch Configurator (in other words, if the mod is tagged with, let's say, Template:Hair, Eyes, the "Race Records" option of the Bashed Patch Configurator must be checked on the left side of the Bashed Patch Configurator so that Bash looks at that section at all)
4) active in the active section of the Bashed Patch Configurator (in other words, if the mod is tagged with Template:Hair, Eyes and the "Race Records" section of the Bashed Patch Configurator is active, the mod itself must be checked in the right hand panel of the Bashed Patch Configurator when the "Race Records" section is selected, so that Bash knows that it should look at that specific mod for race records).
....
Hey, you've written a very nice explanation of some essential Wrye Bash concepts here. I think it would be worth posting this to a more permanent spot, either on
http://www.uesp.net/wiki/Tes4Mod:Wrye_Bash/Bashed_Patch
or maybe make a related subpage there. What do you think?
Posted by: wmj Oct 22 2008, 04:05 PM
http://www.uesp.net/wiki/Tes4Mod:Wrye_Bash/Bashed_Patch
or maybe make a related subpage there. What do you think?
Thanks for the compliment, and glad to be of help <img src="http://static.bethsoft.com/bgs/style_emoticons/default/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /> .
Posted by: TamaraUK Oct 22 2008, 04:12 PM
Umm, I think I have been doing things wrong, but I don't think I have screwed anything up...
I haven't been deactivating and reactivating the Bash patch when I rebuild it and it still seems to have included the stuff I added. How would I know if I have messed it up?
Posted by: Riston Oct 22 2008, 04:29 PM
i was wondering if for other people, does wrye bash uncheck all of your mods when you go into OBMM and change some load order stuff? whenever i go in and change something, like move a mod up, upon exiting, wrye unchecks all of my mods, then i have to go through and figure out which i had on the last save. i think i may be doing something wrong too. <img src="http://static.bethsoft.com/bgs/style_emoticons/default/shrug.gif" style="vertical-align:middle" emoid=":shrug:" border="0" alt="shrug.gif" />
Posted by: wmj Oct 22 2008, 04:46 PM
I know that you can open the OBMM from Wrye Bash, but you don't leave Wrye Bash open while you're working in the OBMM, do you?
I don't think that's recommended procedure, since both programs are trying to read and display the contents of the Data folder --- and it seems to me that WB works in real time, as opposed to the OBMM which reads the Data folder when it opens, then writes its changes when it is closed. If you move stuff around by other means such as the CS or TES4Files, the changes will not display in the OBMM until you close and reopen it, whereas I think they will display immediately in WB (but I'm not sure, because I don't use two active programs that affect load order at the same time).
In any case, if you move stuff around in the OBMM while WB is open, when you exit the OBMM, it's going to write its changes to the load order at that time. If WB is open and trying to figure out what has happened to plugins.txt, it may well have a problem doing so (and therefore knowing what your load order actually is at that moment), and (as a safety measure), I could see how it would just uncheck everything until you close and reopen it (so that it can re-read plugins.txt).
But can't you just tell what mods were active in your save by clicking the save in the Saves tab and looking at the masters?
Posted by: urthman Oct 22 2008, 06:04 PM
WMJ, that's very helpful. Let me see if I have this straight:
There are (at least ) 3 ways that the Bashed Patch merges information from multiple mods:
1. Reconciling leveled lists. The bashed patch takes two or more mods that are trying to make changes to the same list at the same time and reconciles their changes so that, for instance, two mods can both make changes to the inventory of a particular monster.
These mods should NOT be deactivated because Wyre Bash is only reconciling the leveled lists and is not necessarily including the other information from those mods.
2. Taking specific information from a tagged mod. If you only want a mod to change the hair and eyes of a race but nothing else, tag it Template:Hair, Eyes then select it in the "Race Records" and Wyre Bash will take that data only and leave the rest out.
You can then deactivate (uncheck) the mod from your load order, because all the data you wanted from that mod has been taken out and incorporated into the bashed patch.
3. Merging entire mods. If a mod is tagged automatically by Wyre Bash as "Mergable" then you can select it on the list of mods to be merged when you rebuild your bashed patch.
You can then deactivate (uncheck) the mod from your load order because all the data from the mod is now incorporated into the bashed patch.
Is that right? What I'm not clear on is why you should bother merging entire mods into your bashed patch instead of just loading them as usual. Does merging them into the patch speed up your total loading time when you start the game or something?
Posted by: wmj Oct 22 2008, 06:22 PM
If you merge 25 mods into your Bashed Patch (and uncheck them), you have 24 less mods in your list (because you unchecked 25, and activated one -- the Bashed Patch-- which includes all the data of the 25 mods that are no longer considered active by the game engine).
Congratulations on getting the hang of the Bashed Patch. It's pretty straightforward once you understand how it "thinks" <img src="http://static.bethsoft.com/bgs/style_emoticons/default/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /> .
Posted by: dev_akm Oct 23 2008, 03:33 PM
I haven't been deactivating and reactivating the Bash patch when I rebuild it and it still seems to have included the stuff I added. How would I know if I have messed it up?
I don't think this step is necessary anymore. It was recommended a long time ago, but I think the issue was resolved quite a while back. I never uncheck the patch before rebuilding.
Posted by: dev_akm Oct 23 2008, 03:45 PM
Thanks for the compliment, and glad to be of help <img src="http://static.bethsoft.com/bgs/style_emoticons/default/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /> .
You betcha. Will do. <img src="http://static.bethsoft.com/bgs/style_emoticons/default/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" />
Posted by: Shield Watcher Oct 23 2008, 04:16 PM
The first step to understanding the Bashed Patch is to understand how load order works. To understand that, you need to understand the basics of how mods work.
OK, so, to begin - Oblivion.esm. This file was created by Bethesda using the Construction Set (allegedly identical to the one we get to download; I have my doubts about that, but whatever, theirs was certainly similar). It contains lots of data. This data can be divided into several different types. The most basic of these is the "Form". Pretty much everything in the game is a Form. Forms have FormIDs, these are the hexadecimal numbers you use with AddItem if you're using the console to cheat. Items have them, weathers have them, characters have them, cells have them, quests have them. Some things do not - magic effects, for example, are hard-coded. Game settings are hard-coded. Skills are hard-coded. But most everything that can be made with the construction set gets a FormID and thus is a form.
Forms can generally be broken down into base objects and references. Not all base objects have references, and not all types of base objects can have references, but all references refer to a base object. References are the 3D representations of base objects. This has lots of importance all over the place, but is a bit tangential to the Bashed Patch.
The way mods work is that .esp files modify (or add) forms. Most are based on Oblivion.esm, which means they are dependent on it, and can change things about its forms. When Oblivion loads, it starts with Oblivion.esm. After that, it loads .esp plug-ins by date order. It reads the .esp, and when it comes across a form that is also found in Oblivion.esm, it first checks to make sure that the Forms have the same type (reference, weather, item, quest, whatever), and as long as that is true (which it should be), it replaces Oblivion's version with the mod's version. If another mod later changes the same Form, Oblivion replaces the first mod's with the second mod's. And therein lies the problem.
Because it's out-right replacement, if two mods change two different things about a Form, only one of those changes actually gets loaded; the other gets overwritten. In the case of Leveled Lists, this is especially bad - simply adding items to a Leveled List changes the Form. So if two different mods try to add things to the same list - only one is going to work.
What the Bashed Patch does is it goes through the forms, and combines changes from different mods into one mod, so that Oblivion can load all of them. Therefore, multiple different mods can add items to the Leveled Lists and it will work.
Does that explain things? I know I haven't gone into how to decide what mods should be merged; that's better answered by others. But I think some people were interested in this information.
WOW! someone`s who has actually explained the Wrye Bash thing in a manner I can actually comprehend! thankyou.
Perhaps, just perhaps I`ll give it a go one day. Although actually making it work is another story with the amalgamation of bits needed for it, then to make work with it all at once, then making sure the mods bashed like it! But it`ll be a relief when the thing is made so that us mere mortals can use it successfully. last time I tried it, it destroyed my game and my daughter`s. My daughter still gives me a hard time over it.
Everything else, Fcom, OBMM, OBSE, I`ve learned, but Wrye Bash... shudder....
Should a game utility for non-scientists really be so hard to use?
Posted by: Wrye Oct 23 2008, 05:28 PM
OBMM and Mod Selection
Hmm... First I heard of that. (But I don't use OBMM that much.) Simply reordering mods in OBMM shouldn't deactivate anything. (Although simply opening OBMM can reorder mods (grrr), which bash will reorder if you have "Lock Times" on in Wrye Bash.
If someone else can confirm the behavior, I would appreciate it. Realistically, there no reason for a conflict. Selected mods are specified in a plugins.txt file, and as long as OBMM keeps that properly up to date, and monitors for changes (as Bash does), then there shouldn't be a problem.
Deactivating the Patch
If the bashed patch is de-activated, then wait until after it's rebuilt to activate it. However, if it's already active, no worries. Just rebuild it.
Deactivating Mods
Basic rules are:
1) If you're going to merge a mod in, then it's better to deactivate it before building the bashed patch.
--* This allows you to go over the 255 mod limit.
--* It also is required for a few very specific mods. E.g. some esps in Item Interchange MUST be deactivated before building the patch even though they're being merged in (because there's a filtering process involved which only works if the mod is merged but not active at build time).
2) If you want to include changes to race records and/or leveled lists from given mods, then those mods must be either active or merged in. Theoretically, you have some such mods be active before building the patch and then deactivate them afterwards. However, then you would have to remember to reactivate the next time you rebuilt the patch. If you want to save a slot, then it's better/simpler to include such mods as merged mods. Just use load order to prevent undesirable side effects (e.g. eye/hair mods should load before mods that make more substantive changes to races, e.g. RBP).
Posted by: Wrye Oct 23 2008, 05:40 PM
Should a game utility for non-scientists really be so hard to use?
Word processors, which do nothing but put text on a page are complex.
In contrast, Wrye Bash is world processor. You should expect a little complexity.
Posted by: large jack Oct 23 2008, 06:28 PM
In a nutshell <img src="http://static.bethsoft.com/bgs/style_emoticons/default/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" />
Posted by: Riston Oct 27 2008, 11:28 AM
I don't think that's recommended procedure, since both programs are trying to read and display the contents of the Data folder --- and it seems to me that WB works in real time, as opposed to the OBMM which reads the Data folder when it opens, then writes its changes when it is closed. If you move stuff around by other means such as the CS or TES4Files, the changes will not display in the OBMM until you close and reopen it, whereas I think they will display immediately in WB (but I'm not sure, because I don't use two active programs that affect load order at the same time).
In any case, if you move stuff around in the OBMM while WB is open, when you exit the OBMM, it's going to write its changes to the load order at that time. If WB is open and trying to figure out what has happened to plugins.txt, it may well have a problem doing so (and therefore knowing what your load order actually is at that moment), and (as a safety measure), I could see how it would just uncheck everything until you close and reopen it (so that it can re-read plugins.txt).
But can't you just tell what mods were active in your save by clicking the save in the Saves tab and looking at the masters?
sorry it took so long to get back to this, but yeah, i usually open OBMM thru Wrye and just make my changes and close it. only every so often does it uncheck everything, it is probably based on what changes i made. and yes, i do have to look at the saves tab to see what mods were on last, then i go through and check them. i guess i shouldn't do that. well, very good points and that seems to make sense, at least it does sound very possible. thanks.
---
wow, after finishing reading the thread, i did not also know that once i merge a esp, i can uncheck it. so, which section can i look in to see what mods i can uncheck? if i open the bashed patch, can i think i can see the mods included right in the beginning, right? wow, i really wasn't getting it.
Posted by: Wrye Oct 27 2008, 01:34 PM
Personally, I don't use OBMM that much. But when I do, I run it at same time as Bash. But of course, I don't use OBMM to order or activate/deactivate mods. (Though that happens to some degree as you load/unload mods.)
Notes:
1) Just right click on most recent save and "Load Masters".
2) Whenever bash window comes to front, it checks to see if plugins.txt has changed (e.g. by OBMM or launcher). If so, it re-reads it and applies changes.
3) Bash also pays attentions to parents and children. E.g. if you de-activate Oblivion.esm, then all mods that depend on Oblivion.esm also get deactivated. Which is to say all mods -- since all mods depend on oblivion.esm. It's possible that something like that is happening.
Posted by: Blade Of Mercy Oct 27 2008, 01:37 PM
Bashed Patch is like your mum or your teacher:
You want cookie, you go to your mum.
You want help cheatin' you go to your tutor.
You want your game playable - you go to Wrye.