[Charles Weber]

While I realize their value, and I'm not saying that they're pointless or anything like that, but what exactly does a merged patch do? And I don't want an answer like "It makes stuff work right", I mean what, exactly, does creating a merged patch do?

/random pointless curiosity

[Taylah Illies]

I belive it makes two incompatible mods work together.

[glot]

In my understanding (and digging trough it with FO3Edit ) it merges changes two or more mods make to leveled lists and FormID lists. In english, it makes items and enemies from all of your mods work correctly in your game. Usually the mod that loads last wins when the records they change are the same, a merged patch allows both mods changes to take place.

And that actually is quite a good question.

[Rozlyn Robinson]

If you have two mods that make changes to the same item in a game then which ever mod gets loaded last will be the one that effects that item. Some examples:

Mod A changes the clip size on the 10MM Pistol.
Mod B changes the damage on the 10MM Pistol
Mod C adds chainsaws and butcher knives to Raider inventory lists
Mod D adds swords, axes and shields to Raider inventory list

Normally, no matter what order you load these in, only 2 will ever effect your game at the same time, because one change is being overwritten by another. This is where the Merged Patch comes into play. Seeing that while yes these mods may appear to conflict to the game, in reality they change different aspects of the same items and therefore should be able to work together. The Merged Patch will take these mods and filter them together so that all the intended changes show up in the patch, then as long as you load the path last it will overide all the overides with the combined overall effects.

Like my dad used to tell me: There are no dumb questions, only dumb people. Dumb people are the ones afraid to ask questions.

[Michelle Chau]

Some other remarks:

The merged patch should NEVER be considered a blind fix to make incompatible mods compatible. First of all, there are only certain types of records that are "merged" (formlists, leveled lists, npc/creature records, etc...) . . . and mods may have conflicts beyond the scope of what a merged patch can address. Secondly, be aware than the merged patch process doesn't necessarily know if a particular record should be merged. By that, if two mods edit the same leveled npc list, and you as the user only want one of the mods list to be used, the merged patch will combine them regardless.

From a technical standpoint, the merged list works by combining separate changes to a single record. For example, one Mod A adds scrap metal as a repair part for power armor to the armor's repair list (a formlist record). Mod B adds fission batteries as a repair item to the same formlist. When you make a merged patch, the resulting repair list will contain the scrap metal from mod A and the fission battery from Mod B.

Take another example for an NPC record. Mod A changes the name of the NPC, and Mod B changes the characters equipment. In the merged patch, you'd get the name change plus the equipment change, when before, you'd only get one or the other (depending on which loaded last).

[Hazel Sian ogden]

A bashed patch is created by a more "intelligent" method, AFAIK no one uses merged patches with Oblivion anymore. But are Fallout 3's equivalent tools, Gary Bash and F-BOSS, already at the same level of reliability?

[Greg Swan]

A bashed patch is created by a more "intelligent" method, AFAIK no one uses merged patches with Oblivion anymore. But are Fallout 3's equivalent tools, Gary Bash and F-BOSS, already at the same level of reliability?

Absolutely. I would never go back to using only a merged patch in either Oblivion or Fallout 3. I do sometimes use both a merged and a bashed patch where I'll create the bashed patch, then create the merged patch, carefully examine records the merged patch is modifying, and then run the bashed patch again to put the changes from the merged patch into the bashed patch. However, this is not recommended in a lot of situations, so be careful if you want to try it.

[Jessie Rae Brouillette]

I trred BOSSing and Bashing my FWE-MMM-EVE-WMK load order earlier, but checking trough the bashed patch it seemed BOSS's load order template and mod tagging weren't quite correct in some cases, i ended up re-doing it the old-fashioned way.

Propably should try it again by locking FWE's recommended load order and adding/removing tags as seems approriate.

[Laura]

I trred BOSSing and Bashing my FWE-MMM-EVE-WMK load order earlier, but checking trough the bashed patch it seemed BOSS's load order template and mod tagging weren't quite correct in some cases, i ended up re-doing it the old-fashioned way.

Propably should try it again by locking FWE's recommended load order and adding/removing tags as seems approriate.

Understand that the FWE team has not embraced the use of the bashed patch so questions to them will likely not get answered. Valda has worked hard to answer questions about appropriate tagging and is probably the most knowledgeable person to ask about differences between merged patch and bashed patch.

I keep hearing people say that things are not right with bashed patch but not a lot of details as to how they are not right.

[Tarka]

I've gotten that impression, however bashed patch would seem to be the better way to go. As for the patch, i've again started building it, and really the only problems are the tags, not the bashing process. Those are easy enough to correct by checking the patch with FO3Edit, as long as it is clear what mod is supposed to win the conflicts.

[Steven Hardman]

This brings to mind a question I would like to ask. I want to merge a change to a mesh and texture from one mod into my bashed patch and leave it inactive otherwise. because the rest of themod seems tobreak some scripts in Mothership Zeta that are needed to finish the quest

[Jack Moves]

Fastest easiest answer= Deck of cards. 2 halves of that deck. Put them together into one deck.

Whether or not this file will work obviously correlates to the mods in it and whether or not those are not conflicting.

[Juan Cerda]

I stopped using Bashed Patches and returned to FO3Edit's Merged Patches, although the former does "seem" to provide a superior end result when it works, based on my meager understanding of what a Bashed Patch is.

When I was using Bashed Patches, two major issues cropped up:
1. Deputy Weld (the Protectron outside of Megaton) is missing his "glass dome" mesh/texture at the top of his body. I use Pintocat's mod "Weld - Badge and Hat.esp." Although this may seem like a trivial matter, this issue does not occur when using a Merged Patch.
2. There were a few red (dark-pink) colored lines for mods that appeared in Garybash. According to the Wrye Bash manual, this indicates "A file that shares a modification date/time with another file – with both files being activated." The manual also says that "This should definitely be corrected!" Unfortunately, I have no idea how to correct this issue and so it prompted me to end my usage of Garybash and Bashed Patches.

Because of these issues, and my own lack of understanding of how to troubleshoot Bashed Patch errors (I never used Wrye Bash for Oblivion as I stopped playing the game before Wrye Bash took off), I've returned to Merged Patches. It's possible that these issues exist in the Merged Patch as well, but the game runs just "fine" with the Merged Patch, and I haven't experienced any obvious texture/mesh or game errors outside the occasional crash (which are a fact of life with FO3). As they say, ignorance is bliss.

[Amie Mccubbing]

2. There were a few red (dark-pink) colored lines for mods that appeared in Garybash. According to the Wrye Bash manual, this indicates "A file that shares a modification date/time with another file – with both files being activated." The manual also says that "This should definitely be corrected!" Unfortunately, I have no idea how to correct this issue and so it prompted me to end my usage of Garybash and Bashed Patches.

Basicly the problem is that data files (esm and esp) are loaded in order after the last date they were edited. If two mods have the same date, the engine may be unable to load them correctly (or whatever), so the last edit date should be changed. In Wrye Bash the date can be changed directly in the UI. I haven't used Gary Bash, but if you can't find the functionality, simply open the esp in GECK and save it.

[Nichola Haynes]

Basicly the problem is that data files (esm and esp) are loaded in order after the last date they were edited. If two mods have the same date, the engine may be unable to load them correctly (or whatever), so the last edit date should be changed. In Wrye Bash the date can be changed directly in the UI. I haven't used Gary Bash, but if you can't find the functionality, simply open the esp in GECK and save it.

Thanks for the reply. The manual for Wrye Bash says to view the indicated files in Details.... However, when I do this and the corresponding detailed view opens, I can't edit any data within, nor do much else. Here's an example of the red-line errors I'm experiencing in Garybash with my current mod setup:

http://i.imgur.com/S0z2K.png

Though you see only four red-line errors in the picture, eight of my mods display the red-line coloration.

You can also see some other errors in that picture as well, including the italicized text for Project Beauty ("A file that is reccommended to be imported and deactivated (ie. has the 'Deactivate' tag)"), or the fact that it has a dot in place of a plus-symbol or checkmark (can't find any explanation for this in the Wrye Bash manual).

[Kat Ives]

No no - up in the right hand panel area where it says date modified (under author) - manually change that date then click save at the bottom right. No need to open any context menu options on the esp themselves.

Or just open FOMM and shift the files around and that will change their date too, but you have to shift them away from each other (like 3-5 spaces) then put them back.

Both seem such incredible minor details, Although I can see how the file date issue could be frustrating - I do not see why you didn't report the issue with the robot in the gary bash thread.

I will. http://www.gamesas.com/index.php?/topic/1079607-relz-garybash/page__view__findpost__p__16116209.

Purple means that the mod can have records imported without need to merge the whole esp into the bashed patch.
And then the italicized means that the esp has been tagged with deactivate which is an extra precaution for the above case.
The dot means that the bashed patch is importing only records from the esp and not merging the whole thing.
a green cross means that the entire esp was merged into the bashed patch.

All of this is in the readme (question mark at bottom bar of wrye bash) and are standard usage features in the latest WB for oblivion.

Yes Wrye Bash means smarter merging with more features - and yes that means a steeper learning curve.

[Jonathan Egan]

No no - up in the right hand panel area where it says date modified (under author) - manually change that date then click save at the bottom right. No need to open any context menu options on the esp themselves.

Or just open FOMM and shift the files around and that will change their date too, but you have to shift them away from each other (like 3-5 spaces) then put them back.

Both seem such incredible minor details, Although I can see how the file date issue could be frustrating - I do not see why you didn't report the issue with the robot in the gary bash thread.

I will.

Purple means that the mod can have records imported without need to merge the whole esp into the bashed patch.
And then the italicized means that the esp has been tagged with deactivate which is an extra precaution for the above case.
The dot means that the bashed patch is importing only records from the esp and not merging the whole thing.
a green cross means that the entire esp was merged into the bashed patch.

All of this is in the readme (question mark at bottom bar of wrye bash) and are standard usage features in the latest WB for oblivion.

Yes Wrye Bash means smarter merging with more features - and yes that means a steeper learning curve.

There is no mention of the dot checkbox in the Mods Tab section of the Wrye Bash manual. I see it later in the INI Tab, which I overlooked. Still, clearly the dot checkmark also affects the Mod Tab and it should be there. Oh well. The rest of the problems are indeed explained in the manual's Mods Tab section. There's also no mention of what a grey-colored line means in the Mods Tab, (as occurs for =Medium+Very Far=DOF1.1.esp [a depth of field mod]), unless it's this entry here:

? Grey: Indicates that some files present in the package will not be installed. This is usually due to a complex structure that is only partially handled by Bain, but can also be due to having files that Bain refuses to install (exe's, dlls, sub-archives, etc.)

That's copied from the manual, from an entry referencing grey-lined text in the Installers Tab. It also references something called BAIN, which I'm mostly seeing appear in the manual's changelog.

Also, I edited the date, and saved the changes, as you suggested and the red-line colors are no longer there. Thanks for that.

I do not see why you didn't report the issue with the robot in the gary bash thread.

I will.

I thought it was probably because I was doing something wrong with the Bashed Patch (clearly a possibility in my case!). Nonetheless, thank you.

[Kit Marsden]

Couple of corrections - the purple just means the esp is tagged with NoMerge (can't be merged) while the italics indicate it has been tagged with deactivate (a check to make sure it wasn't activated by accident - often used with NoMerge, but not strictly necessary.

And yeah the readme does seem to lack these details - should be brought up in the official real Wrye Bash thread as that is what Valda is using. So the dot and the italics and the purple all need to be described - I'll bring that up there.

As for ini tweaks - I thought that they were not yet supported in F3 so I'd stay away for now.

Are you seeing grey text in the mods tab or the installers tab?
If the installers tab keep in mind that the archives have to be packaged correctly for that to work. I discuss that quite a bit in my http://www.gamesas.com/index.php?/topic/1084204-bain-mod-installation-projects/. Especially the second post under the section Mod Packaging.

So either the archive is not BAIN friendly or it includes files that BAIN will not install (shaders most likely). Having looked at http://www.fallout3nexus.com/downloads/file.php?id=7132 http://www.fallout3nexus.com/downloads/file.php?id=13303 mods I see that neither is BAIN friendly packaging which means they would have to be repackaged to use.

otherwise don't be afraind to jump in with feedback - that is how these utilities get better.

And even though Gary bash is late in the cycle of F3 - it is there already for New Vegas!

[ZzZz]

Are you seeing grey text in the mods tab or the installers tab?
If the installers tab keep in mind that the archives have to be packaged correctly for that to work. I discuss that quite a bit in my http://www.gamesas.com/index.php?/topic/1084204-bain-mod-installation-projects/. Especially the second post under the section Mod Packaging.

In the Mods Tab, the mod =Medium+Very Far=DOF1.1.esp has a grey-colored line background and the text for the mod is colored black, instead of blue as it would be normally. I have nothing at all appearing in my Installers Tab.

Thanks for the BAIN thread, I'll read it now.

[+++CAZZY]

I just put that mod in my data folder and the background is indeed grey but the text is normal.

Another question for Wrye Bash thread.

Will try it out and if it does not work will let you know.

[Eve Booker]

I just put that mod in my data folder and the background is indeed grey but the text is normal.

Another question for Wrye Bash thread.

Will try it out and if it does not work will let you know.

According to the Wrye Bash manual, blue colored text means the file is an .esm file. Perhaps black text is the NORMAL color, but because I was using a Merged Patch just before I recreated my Bashed Patch today, I guess Garybash is recognizing all the mods as .esm because that's what FO3Edit's MasterUpdate does, right?

EDIT: Just ran MasterRestore then restarted Garybash and most (not all, for whatever reason) of the mods are now displayed in black colored text.
EDIT 2: Ok, some remained blue (i.e. as .esm) because they were unchecked in FOMM when MasterRestore was run previously. Checked everything and re-ran MasterRestore and now everything is normally colored, unless for other reasons (e.g. MMM Project Beauty is purple since it's a NoMerge mod).

[XPidgex Jefferson]

Wait Oh I see now - you are using MasterUpdate.

Well I don't recommend using it, but of course it is a free world and I don't use companions.

Any mod you add will have to be masterupdated - so run the masterupdate version of FO3edit again after adding any mods. And after creating bashed patch too.

I never liked that - and my game runs very smooth without it at 210 mods.

I do recommend cleaning mods though - as detailed in my thread - just don't clean overhauls and follow the cleaning tutorials to a tee.

[Teghan Harris]

In the Mods Tab, the mod =Medium+Very Far=DOF1.1.esp has a grey-colored line background and the text for the mod is colored black, instead of blue as it would be normally. I have nothing at all appearing in my Installers Tab.

Thanks for the BAIN thread, I'll read it now.

Grey means either that the file is "ghosted" or that they're "sharing the same group header". I guess it's nothing to worry about.
you see a short descriptive text while hovering the mod-files in the list.

[jasminε]

Grey means either that the file is "ghosted" or that they're "sharing the same group header". I guess it's nothing to worry about.
you see a short descriptive text while hovering the mod-files in the list.

No it is a different shading as ghosted is and remains after ghosting is off.

Same header?

[Eilidh Brian]

Well, it's been a few hours since I returned to the world of Bashed Patches, and my crash frequency has increased about ten-fold. Prior to the Bashed Patch I created (while participating in this thread), I was running a Merged Patch and MasterUpdate in FO3. With a Merged Patch, I would crash, maybe, once every one to two hours. With the Bashed Patch, I effectively crash every other time I save, or zone, or do pretty much anything. I crash, approximately, every 10 minutes.

I would really like to continue using the Bashed Patch. It gets high-praise as the thing that saved Oblivion's modding scene, and people in this thread acknowledge that it's the best way to do things. Why is it not working for me?

Some more questions:

1. I have sorted Garybash to display my mods by Load Order. My mods are sorted by FO3's BOSS. However, when I run FOMM to compare load order between it and Garybash, the FOMM load order is completely fubared with respect to the Garybash load order. For example, amongst other things, two .ESM files show up near the bottom in FOMM, when they should clearly be at the top of the list (and are at the top in Garybash). Why is this? Does it matter (see question two)?

2. I currently run the game through Garybash, by clicking the Pipboy icon in the bottom left to launch FO3+FOSE. Should I be running the game through FOMM? Does it make a difference, given that the load orders are wildly different?

I looked at Psymon's mod cleaning tips, and frankly, I don't think I'm prepared to go through that as a layperson. I just want my game to run as "smoothly" as it did when using a Merged Patch. One thing I did when creating this Bashed Patch is I restored all my .ESPs using MasterRestore, because MasterUpdate makes them all .ESMs. Could this have "tainted" the .ESPs somehow in Garybash? Should I reinstall all my mods with their fresh .ESPs?

Thanks for any help.