Bashed Patch does more harm than good?

[beej175560]

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*...

[Shadriss]

If I were a Mexican Cliff Diver, quite possibly, yes.

 

But you miss the point. Here, we have a host of people who have, though many hours of testing, trial and error, and a LOT more free time than I'll ever have, put together a guide aimed as much at the newer folks to modding as at those who have been around the block a few times. They have, through their processes, come to the conclusion I previously posted. You have said that this advice (and yes, I acknowledge that's what it is) is unsound, and should not be followed by the majority of modders but have provided no real reason for this statement other than an implicit, "because I said so". Granted, that is almost the same thing that the STEP team has done, but given that their recommendation comes by way of general discussion among multiple people, I'm more inclined to believe them than a lone voice.

 

I asked you to elaborate, not get snarky. If you have reasons, please give them. If you don't, I ask you keep the comment to yourself.

[EssArrBee]

You need Names and Stats tags for WAF, CCF, CCOR, and the UPs. Most of those load early, especially the UPs, so you should probably have those tags. 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.

[fireundubh]

You need Names and Stats tags for WAF, CCF, CCOR, and the UPs. Most of those load early, especially the UPs, so you should probably have those tags. 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.

I explained why most people shouldn't use Import Names and Import Stats in my edited post.

 

If you're knowledgeable enough to add the correct bash tags to every plugin in your load order though, you can ignore that advice. On the other hand, if you're knowledgeable enough to add the correct bash tags to every plugin in your load order, you don't need a guide in the first place.

 

If anyone wants to know more about bash tags, read this. The documentation also explains Import Names and Import Stats.

Edited August 29, 2014 by fireundubh

[EssArrBee]

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.

CBash (the library WB uses to scan plugins) takes the last loading record then scans all the plugins with the same record and moves the changed sub-records if that plugin is tagged properly. It does not copy the entire record from a plugin with the tag.

 

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.

No, USKP and WAF would have a Names and Stats tag and any mod that loads after it that had the same record would also need the tag if it changed those things as well. The last loading mod with the record would get copied into Bashed Patch, we'll call it Mod C, and then the Patcher would look through the mods with the same record and see if any had the tags and merge those changes into the record. It would do it the same way you drag a change from one column to the next in TES5Edit. If both USKP and WAF change a Stat or Name of the same record then the last loading mod is forwarded to Bashed Patch, 0.esp. So, record copied from Mod C, Names and Stats from WAF or USKP (if WAF didn't change them too).

 

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.

This is solved by Bashed Patch menu. You check the tag and then only tick the mods listed you want to have forwarded to Bashed Patch, 0.esp.

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.

You'd be surprised how well the import feature works when it is a fully fleshed patcher like it is for Oblivion, FO3 and FNV. I messed around with it a bunch my FNV guide it works extremely well. I have lots of mods that change all the weapons and armor and it is quite intelligent at combining records and merging records together. I had to put in the work to tag everything and pick the right ones, but that is much better than leaving out features from mods because they are overwritten.

[fireundubh]

CBash (the library WB uses to scan plugins) takes the last loading record then scans all the plugins with the same record and moves the changed sub-records if that plugin is tagged properly. It does not copy the entire record from a plugin with the tag.

When CBash takes the winning override, determines what changes to make, modifies the winning override, and copies the winning override into the bashed patch, CBash is still copying an entire record (i.e., the winning override.) If CBash copied only the name or the stats into the plugin, the file would be corrupted. You can't separate names and stats from records in plugins. You can do it in memory but who cares? Users are concerned with the end results. 

No, USKP and WAF would have a Names and Stats tag and any mod that loads after it that had the same record would also need the tag if it changed those things as well. The last loading mod with the record would get copied into Bashed Patch, we'll call it Mod C, and then the Patcher would look through the mods with the same record and see if any had the tags and merge those changes into the record. It would do it the same way you drag a change from one column to the next in TES5Edit. If both USKP and WAF change a Stat or Name of the same record then the last loading mod is forwarded to Bashed Patch, 0.esp. So, record copied from Mod C, Names and Stats from WAF or USKP (if WAF didn't change them too).

You're assuming that every plugin is bash tagged though. I'm not. 

This is solved by Bashed Patch menu. You check the tag and then only tick the mods listed you want to have forwarded to Bashed Patch, 0.esp.

If you use Import Names and Import Stats without bash tags and you're surprised that the names and stats are wrong in the game, you're probably not going to guess "user error." You're just going to blame bashed patches. See the OP. 

You'd be surprised how well the import feature works when it is a fully fleshed patcher like it is for Oblivion, FO3 and FNV. I messed around with it a bunch my FNV guide it works extremely well. I have lots of mods that change all the weapons and armor and it is quite intelligent at combining records and merging records together. I had to put in the work to tag everything and pick the right ones, but that is much better than leaving out features from mods because they are overwritten.

Wrye Bash for Skyrim is not such a patcher. It is defunct and no longer actively maintained. The main developers vanished and, apparently, there is a grand total of two people, generously speaking, in the Skyrim community who know Python and none are willing to pick up the pieces. 

There are two best practices here:Bash tag every plugin for use with Import Names and Import Stats.-- OR --Leave Import Names and Import Stats unchecked; and create a patch with TES5Edit.

Either way, you're not going to get out from doing more work.

Edited August 29, 2014 by fireundubh

[EssArrBee]

When CBash takes the winning override, determines what changes to make, modifies the winning override, and copies the winning override into the bashed patch, CBash is still copying an entire record (i.e., the winning override.) If CBash copied only the name or the stats into the plugin, the file would be corrupted. You can't separate names and stats from records in plugins. You can do it in memory but who cares? Users are concerned with the end results.

No, this is completely wrong. It merges records by basically doing what you do in TES5Edit by dragging a name or stat over from one column to another. It copies the last reocrd in load order, then forwards the sub records from plugins that are tagged. There is no separating names and stats going on, it is copying, but only the at the subrecord level not the entire record. I already explained how it works in my last post and that is exactly how it works.

 

You're assuming that every plugin is bash tagged though. I'm not.

I don't see how that doesn't also affect leveled lists. You could end up with lots of errors from not having Relev and Delev. Does that make merging leveled lists wrong? You don't end up with that many errors not having tags implemented and using them on mods that do. You end up with way more not using them. If you have mods that don't implement fixes from the UPs then you need the tags to forward the fixes around those mods.

 

Someone will notice the missing tag quite quickly report it to LOOT guys and they will add it. Been that way for year with TES4&5, not as much with Fallout unfortunately.

 

If you use Import Names and Import Stats without bash tags and you're surprised that the names and stats are wrong in the game, you're probably not going to guess "user error." You're just going to blame bashed patches. See the OP.

Not sure how you use one without the other? If you tick Import Names or Import Stats and do not tick any of the mods listed then it is as if you aren't using it at all. It is designed so that picking the subrecords you want forwarded from whatever mods you want.

 

Wrye Bash for Skyrim is not such a patcher. It is defunct and no longer actively maintained. The main developers vanished and, apparently, there is a grand total of two people, generously speaking, in the Skyrim community who know Python and none are willing to pick up the pieces.

It is not defunct and the four tags available work just as should work. There are still bugs being squashed with every release and development has been ramping up the last month or so. When LOOT is farther along I would bet development picks up again.

There are two best practices here:

 

Bash tag every plugin for use with Import Names and Import Stats.

 

-- OR --

 

Leave Import Names and Import Stats unchecked; and create a patch with TES5Edit.

Either way, you're not going to get out from doing more work.

[fireundubh]

No, this is completely wrong. It merges records by basically doing what you do in TES5Edit by dragging a name or stat over from one column to another. It copies the last reocrd in load order, then forwards the sub records from plugins that are tagged. There is no separating names and stats going on, it is copying, but only the at the subrecord level not the entire record. I already explained how it works in my last post and that is exactly how it works.

The term "winning override" is defined as the last overriding record in the load order. You've said twice now that CBash copies the winning override. We agree. Stop arguing with yourself.

 

I don't see how that doesn't also affect leveled lists.

The impact is much less significant since, presumably, you've installed mods whose items you actually want distributed and these mods are ordered properly in your load order. Leveled lists are merged from bottom to top, so you end up with only the winning overrides. In the event that you want to switch things around, you can use TES5Edit to customize the leveled lists and, fortunately, you don't have to screw around with hundreds of records in all but the rarest of circumstances.

 

Not sure how you use one without the other? If you tick Import Names or Import Stats and do not tick any of the mods listed then it is as if you aren't using it at all. It is designed so that picking the subrecords you want forwarded from whatever mods you want.

Hmm, I guess I was misremembering Import Names/Stats working on every mod. In any case, if you have only a few mods bash tagged early in your load order, using Import Names/Stats will revert all of the changes made in between there and the patch. For example:

 

 

Importing Names/Stats from only these source mods in a huge load order would be bad.

 

It is not defunct and the four tags available work just as should work. There are still bugs being squashed with every release and development has been ramping up the last month or so.

Oh, yeah, some new life was breathed into Wrye Bash in the last two months but there were 100 commits in 2013, which is less than 0.3 commits per day. Not exactly "active" development. Edited August 29, 2014 by fireundubh

[DoubleYou]

But leveled lists can cause horrible issues if tagged improperly! Just look at the recent debacle with incorrect tagging of aMidianBorn_ContentAddon.esp! A lot of NPCs were running around naked!

 

And yes, CBash DOES copy the overriding record, BUT it only forwards the subrecord!

 

As always, if you don't know how to work the tool, ask about it. There is the Bash Tags autodetection script in TES5Edit, so it really isn't that hard.

 

Just think what one of the developers of Wrye Bash would have to say if they saw your comment about Wrye Bash development.

[fireundubh]

But leveled lists can cause horrible issues if tagged improperly! Just look at the recent debacle with incorrect tagging of aMidianBorn_ContentAddon.esp! A lot of NPCs were running around naked!

Never heard of it. 

And yes, CBash DOES copy the overriding record, BUT it only forwards the subrecord!

Nobody has said any different... 

As always, if you don't know how to work the tool, ask about it. There is the Bash Tags autodetection script in TES5Edit, so it really isn't that hard.

Or you can write a guide, and add a note to the STEP instructions where you tell readers to Import Names/Stats so you can avoid OPs like this one. 

Just think what one of the developers of Wrye Bash would have to say if they saw your comment about Wrye Bash development.

They'd agree. You can't really split your focus as a programmer.You can put a little effort into a lot of projects, but one project will take up the majority of your time. That one project is not Wrye Bash for anyone. Edited August 29, 2014 by fireundubh

[DoubleYou]

Naked NPC issue: https://forum.step-project.com/topic/5562-step-v229-naked-npc-issue/

 

I suppose we could start a guide on using Wrye Bash more effectively. But then, my focus will be split more than it already is!

[fireundubh]

Naked NPC issue: https://forum.step-project.com/topic/5562-step-v229-naked-npc-issue/

This wouldn't be an issue for Requiem players who delevel the bashed patch's merged leveled lists. ;)Where can I get that .esp? I want to take a look. 

I suppose we could start a guide on using Wrye Bash more effectively. But then, my focus will be split more than it already is!

See! :) Edited August 29, 2014 by fireundubh

[justjr]

Even if development is slow or stopped, bash still merges the subrecords, and the tags are provided by LOOT (and BOSS), so the tags still up to date.

I have 200+ mods and only 2 or 3 had to be manually tagged, oh, then you can submit one tag if you think it needs it, and they will incorporate if it's really it. You can argue as much as you want, and provide us with your vision of the bashed patch, but it still a lot usefull anyway.

 

STEP is not recommending bash tags, and aMidian sometimes can cause naked NPCs because of that (if you add other mods that add armor to the game, like IA7), but SR:LE always did recommended the bashed tags for aMidian (and CRF), and is A LOT better then forward all the records by myself on TES5Edit manually. :P

Then just need some resetinventory and Jon Batttleborn is dressed again!

Edited August 29, 2014 by justjr

[fireundubh]

You can argue as much as you want, and provide us with your vision of the bashed patch, but it still a lot usefull anyway.

Vision? What are you talking about? A "vision" is what you want something to be. I don't have a vision for the bashed patch. I have an explanation of how the bashed patch works because the bashed patch is identical to every other plugin and that explanation never changes, but nowhere did I ever suggest, hint, or propose a vision for the bashed patch. Don't reframe the discussion in a weird way.

[DoubleYou]

I think the point that Fire is trying to get across is that Wrye Bash CAN cause more harm then good if it is not used properly. It has to do with what mods you add yourself.

 

aMidianBorn Content Addon file is from here: https://www.nexusmods.com/skyrim/mods/24909/

[z929669]

I think it would be helpful if we included instructions on tagging for STEP:Core/Extended mods within the mod notes. It would also be good to introduce the instructions on tagging in the WB Guide and supply links to that from all applicable mod notes and STEP Guide.

 

Actually, adding this info to the mod notes template could be a good idea, but then that assumes that all of our users are sticking strictly to the STEP mod lists. Perhaps adding tagging info to the guide itself is better, but I'd have to think about that.

 

I do think that tags are generally applicable to most mods, regardless of the mod build ... it would be wise of us to begin adding recommended tag attributes to mods though in any case ... waiting for LOOT team to do so may not be most prudent (again, I am not sure how fast they do this).

 

At the end of the day, tagging is fundamentally important to BP functionality, so it would seem that we should be adding this info.