[Damned_Queen]

So building my patch gave no errors. It now takes about 2-3 times longer though and I'm not sure if it is because of all the new tags.

Yes, the new tags take quite a bit of processing. This was mentioned in an earlier thread.

Well I'm not sure if reporting which esp are purple but it interested me that unlike above my Oblivion.esm is not purple ... hmmm?

[edit] so I'm glad I did that as the purple ones are all tagged with NoMerge - so there is a pattern.

This is not a bug, but rather a requested feature. Some users found it confusing that otherwise mergeable mods that have the "NoMerge" tag were still colored green. The new purple text is supposed to differentiate these mods. The bug where the first mod may incorrectly get a purple background (already fixed for the next version, btw) is a separate issue.

My rig is not really sweating either during the bashing process - but moderate use or all 4 cores and about 30% of my 8 gigs of ram.

Wrye Bash is single threaded. It is using 1 core at 100% and leaving the other three idle.

[Roy Harris]

I can't rebuild my bashed patch. Just get this error and a fail.

Traceback (most recent call last):
File "C:\Games\Bethesda\Oblivion\Mopy\basher.py", line 8427, in Execute
unfiltered = [x for x in bosh.modInfos.ordered if 'Filter' in bosh.modInfos[x].getBashTags()]
File "C:\Games\Bethesda\Oblivion\Mopy\bosh.py", line 7288, in getBashTags
tags = self.getRow().get('bashTags')
AttributeError: 'str' object has no attribute 'get'

Apparently I need to clean save Duke Patrick's Near Miss mod, and I can't do that because it's in the bashed patch, so deactivating it deactivates the bashed patch, and then I can't build a new one.

Anyone know of a fix for this?

[Cash n Class]

Those were not rhetorical questions. "-not new" answers nothing for me. Only the last one answered.

and as for ini ... My game is not in the default location - or do you mean some install it outside the Oblivion directory?

All of the answers were in that bashed patch page. The "not new" comment was not supposed to answer your "questions." I added those comments because you said something about BOSS and the treads being inconsistent or something.

[Francesca]

Whats wrong with the new Version of Wrye Bash?

I updated to 2.81 and get

Traceback (most recent call last):  File "D:\Programme\Bethesda Softworks\Oblivion\Mopy\basher.py", line 3712, in RefreshData    bosh.modInfos.rescanMergeable(scanList,progress)  File "D:\Programme\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 8055, in rescanMergeable    canMerge = PatchFile.modIsMergeable(modInfo) == True  File "D:\Programme\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 13704, in modIsMergeable    if 'NoMerge' in modInfos[GPath(modInfo.name.s)].getBashTags(): reasons += "\n.    Has 'NoMerge' tag."  File "D:\Programme\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 7288, in getBashTags    tags = self.getRow().get('bashTags')AttributeError: 'str' object has no attribute 'get'

After deleting and reinstalling Wrye Bash it`s still the same.

[Jennifer Munroe]

Thanks Waruddar for keeping up with the bugs. Hopefully Pacific will have some time this week to look at them too (because I know I won't)

On Tes4Edit/View/Trans - The issue is a matter of versions (at least, hopefully it's that easy). Old versions were distributed as "Tes4View.exe" and could use a flag to switch to Edit or Trans. The most recent version (2.5.3) changed this - it was distributed as Tes4Edit and you had to make a separate file for each of Tes4View/Trans to get those running (and I'm 99% sure I tested "Tes4View -Trans" and got View). I tried to handle for both cases, but never made a full check for the files because it would also require testing the version. Making copies would be much easier, though, and would only take up a small amount of room (if anyone is complaining about 14 MBs to manage a 4 gig game with mods that easily surpass 500 MBs...) so that seems the best method.

Edit: People who renamed their default_bash.ini to bash.ini should make a new bash.ini. The older version had some typos, it seems.

Err... no, they shouldn't. The ini wasn't the source of the error, and people can leave it as is.

[Nicole Kraus]

Thanks Waruddar for keeping up with the bugs. Hopefully Pacific will have some time this week to look at them too (because I know I won't)

On Tes4Edit/View/Trans - The issue is a matter of versions (at least, hopefully it's that easy). Old versions were distributed as "Tes4View.exe" and could use a flag to switch to Edit or Trans. The most recent version (2.5.3) changed this - it was distributed as Tes4Edit and you had to make a separate file for each of Tes4View/Trans to get those running (and I'm 99% sure I tested "Tes4View -Trans" and got View). I tried to handle for both cases, but never made a full check for the files because it would also require testing the version. Making copies would be much easier, though, and would only take up a small amount of room (if anyone is complaining about 14 MBs to manage a 4 gig game with mods that easily surpass 500 MBs...) so that seems the best method.

Err... no, they shouldn't. The ini wasn't the source of the error, and people can leave it as is.

Okay. Thanks for saving me some extra work too.

[Cash n Class]

ok, I am making a stupid mistake somewhere.

I esmify self on an esp
I go to make a mod of the esmified esp and save and feezes
make a normal mod off of the obliv esm, and saves fine. what am I missing?

[Crystal Clear]

However, if you have all of the mods for any set of your profiles installed (which is determined by dependencies of the save files in said profiles) then switching between profiles will activate/deactivate the correct plugins for each set. If you use multiple bashed patches, you really can achieve that affect (because if you did not use separate bashed patches, every profile that had a bashed patch would load the current bashed patch's dependencies, screwing things up.) Also, since profiles often have saves with varying sets of mods, and Wrye Bash only associates the dependencies of a profile's most recent save with the profile, to load the dependencies of other saves in the profile, simply right-click on the target save and choose "load masters."

So Tommy, if I want to maintain several ESMified mods in one profile for work on a mod, and another profile that doesn't convert those "normal" mods into masters--can I do this? And switch between them easily?

Sitll running 279. It sounds as though 281 is a tad buggy.

[Lauren Dale]

ok, I am making a stupid mistake somewhere.

I esmify self on an esp
I go to make a mod of the esmified esp and save and feezes
make a normal mod off of the obliv esm, and saves fine. what am I missing?

Has nothing to do with Wrye--probably has to do with the master. I've successfully been working several times a day with ESMified mods on a new mod, saving without problems. But when I tried copying a face from Apachii's Heroes Store mod as a template to do interesting variants for an NPC record, saving froze. Without fail. Every time. No other mod I'm using does this.

[Da Missz]

Has nothing to do with Wrye--probably has to do with the master. I've successfully been working several times a day with ESMified mods on a new mod, saving without problems. But when I tried copying a face from Apachii's Heroes Store mod as a template to do interesting variants for an NPC record, saving froze. Without fail. Every time. No other mod I'm using does this.

I am using
obliv.esm
ooo.esm
ooo.esp

thats it

[C.L.U.T.C.H]

@fable2: No. The esmify/espify property of the ESP is "built-in" you could say. It is associated with the plugin, not a program. It is like changing the plugin's description in Wrye Bash. It is a direct edit to the plugin.

[Miranda Taylor]

I just upgraded to version 281. When I fired up Wrye Bash, I got the following wxPython error message:

tagsStr = '\n'.join(sorted(modInfo.getBashTags()))
File "C:\Games\Oblivion\Mopy\bosh.py", line 7288, in getBashTags
tags = self.getRow().get('bashTags')

Are you using Automatic Tagging

Yeah, the purple is nasty. Cant hardly read the line. A light green on black text would be much better.

Anyhow

***When I click on the UOP in the mods tab I get this:

Traceback (most recent call last):
File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\basher.py", line 1355, in OnItemSelected
self.details.SetFile(modName)
File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\basher.py", line 1467, in SetFile
tagsStr = '\n'.join(sorted(modInfo.getBashTags()))

Metallicow

turn off Automatic tagging on uop, shut down and restart bash, and then turn auto tagging back on the uop see if that make a difference.

No idea what's going on with your UOP. Can't reproduce it, and a quick glance in the code didn't reveal anything.

Either can I no problem with uop here either.

It could be something with automatic bash tagging that is causing the problem has most of the error I have seen posted with 281 are point to bash tag settings.

I will look over taglist.txt and see if there is anything wrong with that. Also check your pm has well..

Corepc

[Josh Lozier]

Thanks Waruddar for keeping up with the bugs. Hopefully Pacific will have some time this week to look at them too (because I know I won't)

On Tes4Edit/View/Trans - The issue is a matter of versions (at least, hopefully it's that easy). Old versions were distributed as "Tes4View.exe" and could use a flag to switch to Edit or Trans. The most recent version (2.5.3) changed this - it was distributed as Tes4Edit and you had to make a separate file for each of Tes4View/Trans to get those running (and I'm 99% sure I tested "Tes4View -Trans" and got View). I tried to handle for both cases, but never made a full check for the files because it would also require testing the version. Making copies would be much easier, though, and would only take up a small amount of room (if anyone is complaining about 14 MBs to manage a 4 gig game with mods that easily surpass 500 MBs...) so that seems the best method.

Err... no, they shouldn't. The ini wasn't the source of the error, and people can leave it as is.

"Tes4View.exe -translate" works, as does "Tes4View.exe -edit". Made sure of that before my last post

Perhaps Bash shouldn't bother at all with the command line switches, and treat Tes4View / Edit / Trans as completely separate applications (just like the rest of the launchers). If the user wants Tes4Trans, they make the copy themselves and (if needed) change a path variable in bash.ini. This would simplify the code, and require adding "sTes4ViewPath" and "sTes4TransPath" to bash.ini. This is probably the best way to go...

Speaking of the ini, I'm going to go through and double-check all of the variable names. Most of the launcher bugs that I fixed were variable mismatches between the code and ini file (code looked for sTES4EditPath, variable was sTes4EditPath, or the code looked for sSomething, and the variable was sSomethingPath, etc). Case sensitivity can be painful at times. I've been choosing to change the code rather than the ini so that people don't have to go make new ini files if they already have a custom one. Unfortunately, this means that the variable names aren't all consistent. Some end with Path, others don't, etc.

Just to be clear, there won't be any reason to recreate the ini file with the next release. People that used the work-around I posted that deleted/commented part of the ini might want to add that section back though.

[Marquis deVille]

I agree on the users copying the files for themselves. Not everyone cares about TES4Trans (or TES4View, for that matter.) I only really use TES4Edit and TES4View, but I have TES4Trans as well. Let the user decide to eat up more space in their Oblivion folder.

[Symone Velez]

Error message on startup in 281:

Traceback (most recent call last):
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\basher.py", line 3712, in RefreshData
bosh.modInfos.rescanMergeable(scanList,progress)
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 8055, in rescanMergeable
canMerge = PatchFile.modIsMergeable(modInfo) == True
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 13704, in modIsMergeable
if 'NoMerge' in modInfos[GPath(modInfo.name.s)].getBashTags(): reasons += "\n. Has 'NoMerge' tag."
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 7288, in getBashTags
tags = self.getRow().get('bashTags')
AttributeError: 'str' object has no attribute 'get'

[EDIT] And when I try to rebuild my Bashed Patch. The Patch dialogue won't even come up.

[EDIT again] Also, my NoMerge mods aren't purple anymore.

[Amy Melissa]

Are you using Automatic Tagging



Corepc

I am using Automatic Tagging, Corepc. Is that feature broken in 281?

[Mandi Norton]

I am using Automatic Tagging, Corepc. Is that feature broken in 281?

It is working fine here, but, it always works for me. I cannot duplicate the error message that everybody is getting but once again I am only using 62 out of 218 mods in this config. I need to switch over to fcom config and see what happens..

it was just my suggestion to turn it off, restart bash, then turn it back on.

Content Checkers may be broken..has I am not getting results like I should with mods that I know that have error's.

Edit: Correction, Contents Checkers is not broken, has I just run my ufcom throught it and got the same results has last bash version was reporting. Creatures Leveledlist entries only three or four them which are empty so contents checkers report them ..

[Sophh]

Are you using Automatic Tagging

turn off Automatic tagging on uop, shut down and restart bash, and then turn auto tagging back on the uop see if that make a difference.

Either can I no problem with uop here either.

It could be something with automatic bash tagging that is causing the problem has most of the error I have seen posted with 281 are point to bash tag settings.

I will look over taglist.txt and see if there is anything wrong with that. Also check your pm has well..

Corepc

Nope. But turning it on then off, fixed the uop problem. Strange.
Funny I just defragged my HDD and now I'm getting the other error everyone is posting.
Anyhow I will just save my 281ini and revert back to 279 until 282 is out to torture test.
I've had about enough fun for one day...

[tannis]

All of the icons and launchers have been fixed. I enabled the 32 pixel size icons for the OBSE and Auto-Quit boxes. I had to make some new icons for them that were missing; the 32 size red/green/blue off versions, and the 32 size red x version.

For the TES4Edit/View/Trans issue, I just made them all entirely separate. If you want them, you'll have to copy the file over and rename it on your own. I've added sTes4ViewPath and sTes4TransPath to the ini, and removed bShowTes4View, bShowTes4Edit, and bShowTes4Trans.

Next, I'm going to add ctrl-a as a keyboard shortcut for selecting all mods / installers.

If I can get the bashTags: AttributeError: 'str' object has no attribute 'get' error to occur, I'll take a stab at it. Otherwise, it'll have to wait for PacificMorrowind.

[Scott Clemmons]

Of note the purple background on the oblivion.esm is there for me now as well, but it was not there until after the first time I bashed the patch with 281.

I had opened and closed Wrye Bash several times using BAIN prior to ever running the bashed patch and it was not dark purple. Now it is. In fact it is only there when the bashed patch is active. So it has a kind of functionality.

I have a feature request if possible ... Bash now gives warnings that a mod may be active when it should be deactivated when you click to bash the patch.

Is there any chance it could do that with delinquent/missing masters? So that way you don't spend time bashing the patch (10-15 minutes now) only to learn that you made a mistake.

thanks for considering it.

[Ricky Rayner]

I did a fresh install of Oblivion GOTY last night.
I then installed Wrye Bash v280
Everything ran fine.

Today I installed v281 which I downloaded a few hours ago.
I extracted and overwrote the existing installation.

When starting Wrye Bash I get a window with this error (same as has been reported earlier).

Traceback (most recent call last):
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\basher.py", line 3712, in RefreshData
bosh.modInfos.rescanMergeable(scanList,progress)
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 8055, in rescanMergeable
canMerge = PatchFile.modIsMergeable(modInfo) == True
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 13704, in modIsMergeable
if 'NoMerge' in modInfos[GPath(modInfo.name.s)].getBashTags(): reasons += "\n. Has 'NoMerge' tag."
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 7288, in getBashTags
tags = self.getRow().get('bashTags')
AttributeError: 'str' object has no attribute 'get'

Trying to right+click on bashed patch to rebuld does not even bring up the window, does not do anything.
I have Python 2.6 (installed from the python setup file on the same download page as wrye bash).
I only have Vanilla, Knights, SI, and bashed patch installed, no other mods.

I have tested by creating bash.ini and modifying the paths to the add-ins (TES4files, TES4gecko, etc) and they worked fine.

I then copied v280 back over v281 and everything worked fine again (had to delete the custom paths for the bash.ini to work).
Hope this information is usefull to you.

[Darian Ennels]

Great, another everybody has the problem except for a few issue...I guess it is nice to see all of the Wrye Bash support...No one has posted about dropping it over the errors yet.

Edit: Thank you for working around the clock Waruddar. I mean I have seen you really keep up the crazy responsive mode these past few days.

[sally R]

I did a fresh install of Oblivion GOTY last night.
I then installed Wrye Bash v280
Everything ran fine.

Today I installed v281 which I downloaded a few hours ago.
I extracted and overwrote the existing installation.

When starting Wrye Bash I get a window with this error (same as has been reported earlier).

Turn off automatic taggin, shutdown bash, and restart bash , turn auotagging back on see if that helps any..

Great, another everybody has the problem except for a few issue...I guess it is nice to see all of the Wrye Bash support...No one has posted about dropping it over the errors yet.

and I am one of those few that do not have any issue myself, can't duplicate the problem people have posted, my only problem so far is purple oblivion.esm ..else everything is working correctly in load order.

[Music Show]

I will try to get to my computer tomorrow. I need someone at home to turn it on, and then I can finally give feedback with experience again.

[Petr Jordy Zugar]

How do you turn off automatic tagging altogether? The readme only explains how to do it on a per-mod basis :huh: