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

Yes, but for those that do not, we can help ;)

 

Also, it would be nice to track the info on our mod pages anyway, so I will see about adding a dropdown list combobox to allow selection of this attribute when adding/editing mod pages. A brief write up of instructions on end user adding tags manually would be useful within our WB Guide for linking elsewhere.

Link to comment
Share on other sites

  • 0

 If you play Oblivion, FO3, or FNV, you also have to go through tons of mods with tags, since the Bashed Patch is so much more dynamic. If someone would implement a tag for Location, Climate, and all the Sound types for Skyrim, I'd probably gift them a new car.

Amen, but don't forget the C.Light tag. By itself it would eliminate the majority of the records in the SR:LE and REGS patches it it were available in Skyrim.

Link to comment
Share on other sites

  • 0

Amen, but don't forget the C.Light tag. By itself it would eliminate the majority of the records in the SR:LE and REGS patches it it were available in Skyrim.

If they also did some new sound, region, and location tags it would mean I could just dump the step patches altogether.
Link to comment
Share on other sites

  • 0

EssArrBee and I have recently been providing data to the LOOT developers so Bash Tags are added to the mod data for Fallout NV and Fallout 3 when this data isn't already available in LOOT. Ideally we will not need to add any of this to mod pages or guides since LOOT will provide it. STEP could also do this for Skyrim mods vs. having to add the bash tags to our mod pages and/or guides.

Link to comment
Share on other sites

  • 0

True, but it is useful to have this info within our Dbase, since it allows us to use this info as a filter in mod selection among other things. Many mod attributes are recorded off site, but we collect them anyway for our use here, so it is not redundant to do the same with tags (glad you guys are providing info to LOOT team though, and I encourage we do the same for Skyrim).

Link to comment
Share on other sites

  • 0

Wow, there's some good info in this. The how copy the override thing is useful in most situations where it isn't useful is when a competent human has to make a patch because some records need to be merged rather than overridden and wb seems to call it patched.... There are more but it's over my head at this time.

 

For now I'm going with CBash until I am able to take a proper look and create a few -maybe- necessary patches

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?

When mods load after your mod, those plugins normally overwrite the values and in game nothing seems to have changed. The current Experimental Beta will handle more of the records then the current release. I recommend trying it and enabling only the Leveld lists and Stats patcher to start with. Make a bash patch and see how it turns out. As long as all your mods have the proper Stats bash tag the winning plugin with the winning Bash tag will have its values written the the bash patch. When you look at the bash patch if the record from the plugin does not appear first see if it is already the winning plugin.

 

EDIT: Should have looked to see how old this post was, LOL  :woot:

Edited by Sharlikran
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.