[Claire Lynham]

Oh, my bad, sorry Petrus Octavianus. Good thing I did not do that on your load order page (on my site) haha. Oh, I am very conscious of that. I would go by date modified over file difference though. Knowing that they are different does not help you figure out which one is better. Fortunately you can just quickly switch them around and use anneal if need be. I will definitely do that plenty of times with my texture replacers. Switching out meshes and textures will not screw up Form IDs, so look at both versions of the armor once you get it.

Edit: Also, I am sooo not used to typing on a MacBook Pro keyboard. I miss my MX5000 Logitech keyboard. The portable Logitech mouse I have with me is good enough...I love Logitech.

[Rebecca Dosch]

I've got eight in the DATA folder, three in the INI folder, three in special mod named folders, and no Scripts folder at all.

Some consistency would be nice, but I worry it's too late for that. Which means, to me, that Wrye Bash has to adapt to reality rather than trying to establish a rule.

At the risk of reigniting an old war, at the time the argument to get the ini folder properly supported got started, Wrye asked for some hard evidence of how many mods used one method over the other. I downloaded tons of mods that use OBSE, and looked at where they all wanted their ini files ( if they had one ) and of the ones I had, a few used Data, while the rest all used Data\ini. I didn't bother reporting on Streamline or the _tejon stuff because those were already established. The list I ended up with was something on the order of 30+ mods all using Data\ini and *ZERO* using Data\scripts, yet despite this it was simply decided that we'd all waited too long to speak up.

I found that particular attitude rather unsettling at the time, that just because we were "too late" for some arbitrary deadline that the findings I was asked to come up with never got considered. There was nothing then and there is nothing now that would bring about the end of the world if the Data\ini folder is added to the officially recognized list of folders. And given the fact that even more mods these days will support it and mod makers continue to use it, it makes a lot more sense for the leading Oblivion utility to wake up and realize that things didn't go the way one person wanted them to. A whole lot of mods these days would need to be updated in order to support Data\scripts even though I've still never encountered one single mod using it.

Full disclosure - I obviously support Data\ini and voted for it in every chance there was to vote on it. I hate cluttering my Data folder up with more than is necessary.

[Zualett]

And version 281 is out (as probably a fair number of you already know since I left it uploading to Nexus a few hours ago while I was out)... here's the changelog:
=== 281 [05/04/2010] [DJ_Kovrik,haama,Lojack,PacificMorrowind,Waruddar]

• bug fixes:
  • 2 tool launcher icon names fixed.
    
  • error in race patcher eye section fixed.
    
  • error in INI read code fixed.
    
  • fix for when reading absolutely huge cosave (ie .obse) files.
    
  • error allowing a BCF to be applied without all source packages (contributed by Waruddar)
  
  
• Updated Russian translation (contributed by DJ_Kovrik).
  
• Russian version of the ini file (contributed by DJ_Kovrik).
  
• List Structure printout for BAIN packages (contributed by Waruddar)
  • It generates a tree-style report of the files and folders, which can be useful when comparing how packages are structured.
  
  
• Mergeable mods with NoMerge tag are now colour coded (purple) in the mods tab instead of being green like fully mergeable mods or black like unmergeables (depending on version)
  
• taglist updated to Masterlist version 791

A smallish update I know but since it was fixing bugs I thought might as well release sooner than later.
Pacific Morrowind

[Daddy Cool!]

Keep up the good work I just upgraded to 281 and whern i start it I get this error message




Traceback (most recent call last):
File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\basher.py", line 3712, in RefreshData
bosh.modInfos.rescanMergeable(scanList,progress)
File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 8055, in rescanMergeable
canMerge = PatchFile.modIsMergeable(modInfo) == True
File "C:\Program Files\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\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 7288, in getBashTags
tags = self.getRow().get('bashTags')
AttributeError: 'str' object has no attribute 'get'



I don't know what this is. If I revert back to 279 I do not get this error boss doesn't also seem to reload my files correctly when i add new esp.. I will revert back to 279 til it works better. But thanks for alsoo your guys effert and continuing work with wrye

[Rhi Edwards]

http://img405.imageshack.us/img405/1703/bash.jpg

Why is Oblivion.esm being marked with a dark purple bar now?

[Petr Jordy Zugar]

Purple here has well..Reasoning behind this?

[Jason King]

[*] Mergeable mods with NoMerge tag are now colour coded (purple) in the mods tab instead of being green like fully mergeable mods or black like unmergeables (depending on version)

I may be wrong, but it sounds about right. Maybe a bug with his new feature?

[Brandon Wilson]

RE: goblueman

I'm fairly sure where the error is coming from, but not sure how to fix it. It's probably from one of PacificMorrowind's patches where he was trying to "(hopefully) permanent fix to possibility of calling a non-existant record from the table.dat". If the record doesn't exist, he returns an empty string instead of a record. This empty string then halts the code above because it doesn't know what to do with ".get('bashTags')". I'm not familiar at all with that part of the code (not sure what is stored in table.dat), so PacificMorrowind will probably have to fix this.

[cassy]

http://img405.imageshack.us/img405/1703/bash.jpg

Why is Oblivion.esm being marked with a dark purple bar now?

Run BOSS Worked for me...

[Michelle Chau]

Purple background color seems to affect whatever mod is first in the mods pane. For me, that happened to be Oblivion_1.1.esm. Checking it, then unchecking it cleared the purple.

The patch seems to be referring to text color, not background color. Not sure what's causing the purple background.

[Amie Mccubbing]

RE: goblueman

I'm fairly sure where the error is coming from, but not sure how to fix it. It's probably from one of PacificMorrowind's patches where he was trying to "(hopefully) permanent fix to possibility of calling a non-existant record from the table.dat". If the record doesn't exist, he returns an empty string instead of a record. This empty string then halts the code above because it doesn't know what to do with ".get('bashTags')". I'm not familiar at all with that part of the code (not sure what is stored in table.dat), so PacificMorrowind will probably have to fix this.

Thanks for the reply I instaslled it it gave me taht error and even boss wouldn' t reload my new esp.'s so I just revert back to 279 and I'll wait for a fix

[Soph]

Purple color seems to affect whatever mod is first in the mods pane. For me, that happened to be Oblivion_1.1.esm. Checking it, then unchecking it cleared the purple.

That fixed it

Edit: If you shutdown and restart bash it become purple once again, you have to untick and retick..

[Ridhwan Hemsome]

This is a great tool, got even better with the Mayu's animation tweak feature. HOwever, some of the custom animations/pose no longer works. Is there a way to remedy this?

[Thomas LEON]

This is a great tool, got even better with the Mayu's animation tweak feature. HOwever, some of the custom animations/pose no longer works. Is there a way to remedy this?

Do you have any specific details that they can check out?

edit: If you mean that other animation mods no longer work on NPCs once the MAO tweak is added, this is because they are no longer looking in the same place for those animations. It's the way that MAO works, but separating the player and NPC animation folders.

You can fix it by moving the animations you are adding to the new folder MAO creates. That should allow the NPCs to find the animations again.

[Juanita Hernandez]

Tried new version. So far all is good. Lot of things changed from 279 to this one . All My saves went to Orange! Even the Bash Patch changed to orange. Got worried For a second thinking Great now my Stable Obliviobash Game wont ever start. Had major Problem Going from 279 to 280. Had to revert back and reinstall everything. any way . Got the Newest BOSS ran it Noticed a few changes in the Log so I knew the patch was needing a throu looking at . Checked off about 8-10 new things in the bash patch and Ran it.

Game Loaded Fast and played like usual. Saved ..Open Bash and I have ONE purple save. So all is good but thats a lot of wrong colored saves, time to weed out and just keep maybe 10?

Love the New Icons across Bottom..I have 32 size set in INI. They Look Good.

New color helps For the Deactivated or what ever the Square/dot one is. Any Chance the RED with +(Intended cause its a Filter) Could be say ...Orange /w +_ And Keep the REAL missing master ones RED. Just a thought ..the RED scares me...lol

Great Job. Off to play . Thanks For all the Hard Work.

[Stryke Force]

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

Traceback (most recent call last):
File "C:\Games\Oblivion\Mopy\basher.py", line 1355, in OnItemSelected
self.details.SetFile(modName)
File "C:\Games\Oblivion\Mopy\basher.py", line 1467, in SetFile
tagsStr = '\n'.join(sorted(modInfo.getBashTags()))
File "C:\Games\Oblivion\Mopy\bosh.py", line 7288, in getBashTags
tags = self.getRow().get('bashTags')
AttributeError: 'str' object has no attribute 'get'


In addition, even though BOSS appears to work properly, Wrye Bash 281's mod screen doesn't seem to be updating like previous versions. I will report any other error messages and/or bugs I encounter with this version.

EDIT: When I restarted Bash 281 after running BOSS, it displayed the proper load order.

EDIT 2: I get the following wxPython error when I try to rebuild my Bashed Patch:

Traceback (most recent call last):
File "C:\Games\Oblivion\Mopy\basher.py", line 8439, in Execute
patchDialog = PatchDialog(self.window,fileInfo)
File "C:\Games\Oblivion\Mopy\basher.py", line 4402, in __init__
patcher.getConfig(patchConfigs) #--Will set patcher.isEnabled
File "C:\Games\Oblivion\Mopy\bosh.py", line 14074, in getConfig
self.getAutoItems()
File "C:\Games\Oblivion\Mopy\bosh.py", line 14043, in getAutoItems
if autoRe.match(modInfo.name.s) or (autoKey & modInfo.getBashTags()):
File "C:\Games\Oblivion\Mopy\bosh.py", line 7288, in getBashTags
tags = self.getRow().get('bashTags')
AttributeError: 'str' object has no attribute 'get'

[Alina loves Alexandra]

Not sure if it will help anyone, but my install history for Wrye Bash...
Wrye Python 01 installer
Wrye Bash 275 installer *(<-edit)
Wrye Bash 279 archive *(<-edit)
Wrye Bash 281 archive - Just copy/paste data and mopy into Oblivion over-writing all.

= Smooth as a babies derriere here. Briefly on first load had the purple oblivion.esm, but since then no problems at all.

* Edits above: See following post - erm oops, yes

[Cedric Pearson]

Not sure if it will help anyone, but my install history for Wrye Bash...
Wrye Python 01 installer
Wrye Bash 279 installer
Wrye Bash 281 archive - Just copy/paste data and mopy into Oblivion over-writing all.

= Smooth as a babies derriere here. Briefly on first load had the purple oblivion.esm, but since then no problems at all.

You mean the 275 installer, don't you?

[Lizzie]

Investigating the purple background issue, and found out that the bug has existed for quite a while. In previous versions it manifested as a gray background. Looking through older releases atm to see when it crept in.

Edit: Confirmed it has existed at least since v271. Can't load the older versions atm since I have python 2.6 installed.

Edit2: Looks like it may be a bug in the wxPython library...not fun. Might be able to make an ugly work-around, or might need to migrate to a newer wxPython version. Ugh.

Edit3: Wasn't a bug in wxPython. Fixed for next release.

[Brad Johnson]

I recall Pacificmorrowind once mentioned there was a problem with the new comtypes for python 2.6.4, I tried at one point that setup with Wrye bash v279 when it was released. After Pacificmorrowind gave that information I reverted to the Python 01 installer as above ( slightly edited ) and have not seen anything to suggest differently since, considering the current files listed for download on Tesnexus, I presume those top three main files are Pacifficmorrowinds recommended setup?, or is the 2.6.4 python + wxpython 2.8.10.1 + comtypes setup now stable?

[Ymani Hood]

I only use the 2.6.4 python + wxpython 2.8.10.1 + comtypes setup, and I did not even see the v280 eye bug. I do indeed use RBP.

Feature request: Okay, the load orders are getting bigger these days, and there is more Wrye Bash usage. However, somehow there is a trend for using the BOSS Log to post, if they post a load order at all. The first thing I have to say is, use Wrye Bash to post (to the WB users.) Fine, WB list is there, and what do I see...no merged plugins are deactivated. Okay, scenario two is someone's load order looks...almost okay, but the user does not know what in the world they were suppose to import into the bashed patch. What is the next request I would like to ask?...post the bashed patch ReadMe?...no...I do not want to scroll through that huge thing, but size aside that still does not show me what options the user selected in the bashed patch. Now that would be useful. How difficult would it be for an additional doc to be produced alongside the read me that only listed each section and what plugins were checked under each, maybe available and checked. This is my http://sites.google.com/site/oblivionpoinfo/utilities/wrye-bash/bashedpatch, for those who may want a guide of some sort...

Bashed Patch
.
.
.
Factions
+ MMM ESP
+ OOO ESM <--- OOPS! Needs to be unchecked
+ OOO ESP <--- OOPS! Needs to be unchecked
.
.
.
Import Names
+ LAME ESP
+ OOO ESP
- SM ESP
.
.
.

[louise hamilton]

I recall Pacificmorrowind once mentioned there was a problem with the new comtypes for python 2.6.4, I tried at one point that setup with Wrye bash v279 when it was released. After Pacificmorrowind gave that information I reverted to the Python 01 installer as above ( slightly edited ) and have not seen anything to suggest differently since, considering the current files listed for download on Tesnexus, I presume those top three main files are Pacifficmorrowinds recommended setup?, or is the 2.6.4 python + wxpython 2.8.10.1 + comtypes setup now stable?

Found an ugly work-around. I have no idea why it works (it shouldn't), but it does. Going to poke around and see if I can figure out what's going on, but there will be some sort of fix for the next release.

alt3rn1ty, I'm using python 2.6.4, wxpython 2.8.10.1, and comtypes 0.61 as listed in the first post as the alternate requirements. Works fine for me (other than this background coloring bug...haven't tested to see if it exists with the older recommendations).

Edit:
Found the proper fix. Will be present in next release.

[Kat Ives]

Does the purple background have any significance? (I have not been able to investigate v281 yet.)

[Antony Holdsworth]

Does the purple background have any significance? (I have not been able to investigate v281 yet.)

It is purely cosmetic.

[Lou]

Huh, what kind of purple?