Jump to content
  • 0

Bashed Patch does more harm than good?


beej175560

Question

I've followed the instructions on the STEP 2.2.8 page, section 3.A.2 "Create the Bashed Patch", to the letter. Unfortunately, after examining the resulting patch in TES5Edit, it looks like it would do more harm than good. This is with a completely fresh STEP Core installation.

 

Things the Bashed Patch does right:

 

1. It includes the Timescale and iCrimeAlarmRecDistance changes that I selected in Wrye Bash.

2. It correctly incorporates the edits from moveitLWT.esp, allowing me to remove that mod from my load list.

 

Things the Bashed Patch does wrong:

 

1. It tries to incorporate the changes from Traps Make Noise.esp, but it subtly changes the data from that mod in a way that might be erroneous. (A FormID is moved from a "FormID" to an "Unknown" field, leaving the "FormID" field set to zero. Perhaps this is an old Oblivion convention, but who knows if it works to restructure the records like this in Skyrim?)

2. It reverts several item names that were enhanced in WAF back to the original names. Example: the four "Fur Armor" items, which were nicely renamed by WAF, all go back to being "Fur Armor". (I know I can turn this off in Wrye Bash; my question is why this setting is on in the first place? To make the game worse for me, I guess?)

3. It does not succeed in fixing any problems with Leveled Lists, and introduces additional problems of its own. Most of the Leveled List entries it generates make no changes to the furthest-down .esp's version of the List, so those entries have no purpose. A few Leveled Lists are mysteriously made empty, which is completely wrong. And the small number of Leveled Lists which had genuine problems are not actually corrected by the Bashed Patch, because their problems require human intelligence to solve -- e.g. WAF adding a Fire enchant to the Dwarven Greatsword FEAR enchant list, or War Axe enchants appearing in the Dwarven WarHAMMER enchant lists (a bug corrected by USKP, but reintroduced by WAF). For these truly bugged Leveled List entries, Wrye Bash can only generate a partly-fixed but still mostly-wrong result.

 

In summary, for STEP Core, I see the Bashed Patch messing things up and not solving any real problems. I understand the Leveled List merging is valuable with a more highly modded setup, and I'll report back after I finish installing STEP Extended. But the merging logic looks iffy -- why are some Leveled Lists becoming completely empty? So, between that and the other problems, I'm leaning towards Wrye Bash doing more harm than good.

 

Let the flame wars begin... *ducks for cover*...

Link to comment
Share on other sites

Recommended Posts

  • 0

Yeah, the Bashed Patch does do an awful job of correctly making the changes. I haven't used the Skyrim version in a while, but I've been using the New Vegas version lately for my TTW/Fear and Loathing playthrough, and I doubt there's much difference. I've had to go into FNVEdit and manually go through the Bashed Patch records to correct them all and remove bad edits, and even on top of that I had to create a custom Merged Patch to fix other things it completely ignored. I do remember having to do this for Skyrim in the past too, and I've had to do it for a lot of other installs of the Fallout/Elder Scrolls games. I honestly don't get why the Bashed Patch is so blindly something people are told to create, considering the amount of mods it can break.

 

Seeing as there are STEP patches though, I don't see why a large part of these changes can't be included in that. It'd reduce the load order (even if only by one), and wouldn't require users to manually tweak the records to stop there being problems, unless they're using non-STEP mods, but that's not really something that a lot can be done about.

Link to comment
Share on other sites

  • 0

Bashed Patches, if created automatically, may very well do "things" you don't want, this is why bashed patches can be customized IF the user knows how to do so by making exclusions and so forth.

 

So, no need to bash Bash patches, if you are astute enough to see something your bash patch is doing you don't like, you probably are in a good place to start manually adjusting your Bash patches instead of letting Wyre Bash try to read your intents.

 

People mistake things as problems when they aren't actually "problems".

 

LOOT is a good example. Someone will say, "Zomg LOOT put this patch in the wrong order!" Well, how is LOOT to know which edits you want? It can't read your mind, and without a user rule, it will simply decide on the more comprehensive edit to have priority.

 

With Wyra Bash, it's the same thing, automatically generating patches works most of the time until someone throws a curve ball like some horrible mod that probably does a little too much to suit your particular needs. If this is the case, fire up Tes5Edit and start deleting fields so the bash won't try to incorporate stuff you don't want or just exclude the mod entirely from the bash process.

 

At the end of the day, bashing is a compromise. You can't get perfection because you can't have numerous mods editing the same records without something winning out.

Edited by Kuldebar
  • +1 3
Link to comment
Share on other sites

  • 0

Evidently you do not have your plugins correctly tagged in Wrye Bash, as it works fine for me. Please make certain that you use the tag settings provided by Boss/Loot. The bashed patch for STEP 2.2.8 core should be 8 kb. For Extended it should be 9 kb. If it is drastically larger, your have done something incorrectly and yes, you would be better off not using it.

Link to comment
Share on other sites

  • 0

I wish someone came up with standalone program that would simply create the "bashed patch", without the horribly slow/laggy UI and everything.

Wrye Bash was never laggy for me. The Bashed patch is a godsend powerful tool to automatically solve certain types of conflicts. Only too bad there aren't as powerful tags Skyrim as there where in Oblivion/Fallout.

Link to comment
Share on other sites

  • 0

I've just started using bashed patches and have delayed this long because I can't understand how a mod like CCOR and WAF can be bashed if their role is to change the vanilla and other mod records. To my thinking a bashed patch would just merge the data which is wrong. I ran my first batch patch this week and all my immersive patrol NPC's have 3 weapons and 2 sets of armor. I've got some work to do to get this right :( Happy to hear any ideas?

 

Edit* Ok, after some further reading I now have a better understanding of delev and relev. Plus a kind soul has advised that I can check the patch in TES5Edit which will certainly be a big help. I'd still like to hear other peoples thoughts / experiences.

Edited by Teabag86
Link to comment
Share on other sites

  • 0

Isn't WAF one of those mods created before the Creation Kit was released, so the author had to use SNIP to make it, and famously has not been seen since his mod plugin was proven to have corrupt data which was irreversible without recreating the whole mod from scratch ?

 

Or

 

Are you all using the sterling effort Sharlikran has put into solving such problems ..

 

Sharlikrans Compatability Patches

 

Which includes fixes for Headbombs mess, among many others.

 

 

For anyone who does not know, Sharlikran is probably one of very few people in our community able to solve such problems. If you use old mods with plugins which have an upload date before mid February 2012, then check the patches out for a fix before you use it. It might just save random problems going off like a time bomb later, or record corruption which is unfathomable .. And probably tripping up the correct function of tools like Wrye Bash

Link to comment
Share on other sites

  • 0

Quick question: I made a patch of my own that changes a few item stats (weight) to be specific for bags, bandoliers, pouches....

 

Each time I remake my bash patch, it reverts these changes. I tried using the NoMerge tag but that doesn't seem to work. When I have Wrye Bash open, can I just uncheck my patch file to exclude it from the bash before building it?

Link to comment
Share on other sites

  • 0

Quick question: I made a patch of my own that changes a few item stats (weight) to be specific for bags, bandoliers, pouches....

 

Each time I remake my bash patch, it reverts these changes. I tried using the NoMerge tag but that doesn't seem to work. When I have Wrye Bash open, can I just uncheck my patch file to exclude it from the bash before building it?

Stats is the tag you add. NoMerge is completely different and something we won't be needing until someone ports the Graphics tag over to Skyrim. 

Link to comment
Share on other sites

  • 0

For me Bashed patched is very much needed. You need to have the correct tags and the correct load order. Maybe even create a bashed patch, 0 that has all the names and stats in the correct order and then make another one to import the original and have it override most of the incorrect tags...

I think without it then a lot of patching will be required.

meh, just my humble opinion....

Link to comment
Share on other sites

  • 0

There's nothing special about bashed patches. They're just normal plugins named "Bashed Patch, #.esp."

 

Wrye Bash generates "bashed patches" with direction from you, so in effect, Wrye Bash is merely an interface for creating a customizable plugin.

  • If you want to merge potentially hundreds of leveled lists on your own, go right ahead.
  • If you want to make the tweaks that Wrye Bash gives you easy access to on your own, go right ahead.
  • If you want to figure out which plugins can be merged without problems and merge them on your own, go right ahead.

There's nothing wrong with not using Wrye Bash to create a bashed patch, but if you're not creating some sort of patch to merge leveled lists, your load order is probably not going to work right.

 

Like everything else, leveled lists (read: loot tables) are just records and each successive plugin that modifies those records overrides its predecessor.

 

Without merging all of the leveled lists that should be merged, you'll see only the last overriding leveled lists take effect in the game.

 

That said, Wrye Bash does take direction from you, so...

  • If your bashed patch is overriding item names, that's your fault for checking "Import Names."
  • If your bashed patch is overriding stats, that's also your fault for checking "Import Stats."

Most people should have no use for importing names and stats. Leave those options unchecked.

 

Why? There's no such thing as "importing" names and stats. Names and stats are parts of the records that hold them.

 

When you tell Wrye Bash to import names and/or stats, you're telling Wrye Bash to copy entire records into the bashed patch and then modify their names and/or stats.

 

How does Wrye Bash decide which records to copy? I could test and find out, but based on your experience and my own past experience, I'd guess that Wrye Bash decides which records to copy by either a) choosing the winning overrides (i.e., the last copy of the record in your load order that matters) or b) choosing the master records (i.e., the first copy of the record in your load order that should be overridden.) We don't want either of these things to happen.

 

If we use only the winning overrides, then, for example, the bashed patch will copy stats from a mod that was designed for vanilla Skyrim, instead of copying the stats from Weapons & Armor Fixes Remade, because that mod is farther down your load order. If we use only master records, then, for example, the bashed patch will copy names from the first copy of each record in your load order into the last plugin in your load order, effectively reverting any name changes that happened in between.

 

Wrye Bash isn't smart about the way names and stats are "imported." In fact, since a bashed patch is a plugin that loads last, when you import names and stats into that plugin, you're creating a plugin that overrides every single record that was copied. In effect, you're "resolving conflicts" by using brute force to eliminate them.

 

Actual conflict resolution, however, isn't about eliminating conflicts; it's about making conflicts work the way you want them. Wrye Bash's "import" features don't do that.

Edited by fireundubh
Link to comment
Share on other sites

  • 0

Most people should have no use for importing names and stats. Leave those options unchecked.

 

From the STEP 2.2.9 Detailed Instructions:

To create the Bashed Patch:

  • Ensure all your plugins are active in Mod Organizer.
  • Launch Wrye Bash via Mod Organizer.
  • Within the Mods tab, click the aMidianBorn_ContentAddon.esp to highlight it. On the bottom right side of the Wrye Bash window inside the Bash Tags pane, right click and click on Delev to add it. Do this again to add the Relev tag.
  • Right click on "bashed patch, 0.esp", and select "Rebuild Patch".
  • Tick the boxes next to "Merge Patches", "Import Names", "Import Stats", "Tweak Settings", and "Leveled Lists".
  • Highlight "Tweak Settings", and tick the box next to "Crime: Alarm Distance". Optional: tick the box next to "Timescale".
  • Right-click on "Crime: Alarm Distance" and select '1000' and optionally set "Timescale" to a value less than '20' but no less than '10'.
  • Next click [build Patch] at the bottom of the window to construct the patch based on the current plugin list/order

I understand where you are coming from Fire, but since the STEP Detailed Instructions specifically say to do that, why would you act surprised when people following the STEP Guide, as the OP is, do so?  Your wish to assist is a great thing, but in light of these now conflicting instructions, perhaps a bit more information on why you hold that position is required, since the people who wrote the other set of instructions appear to disagree with you at some level?

  • +1 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.