I was checking out my bashed patch after correcting the fact that Wrye Bash didn't look for tags in LeveledList.csv/masterlist.txt if the mod had a description with a bash tag.
It added(amongst many other things) added 2 Invent tags to OOO's esp and MMM4OOO's esp.

http://img121.imageshack.us/img121/7137/wryescreen1.png

In the end the troll got 2 blood, 1 from cobl and 1 from MMM4OOO's esp, I guess it's not supposed to happen is it?
Not sure if I should post that question here, the cobl thread or the MMM thread frankly .

edit:
Maybe I should simply not merge inventory with MMM4OOO, hmm I'm not sure...

MMMforOOO does not have a cobl patch, not yet at least,

? so did you repoint the master's on fcom_cobl to MMMForOOO.esm. has that is only way you could have done it, unless using FCOM in which you should not be using MMMForOOO once again..

Cobl Tweak adds the TI leveledst to Azhklan troll which is vanilla creatures,

Use OOO Cobl Patch?

Report in Cobl thread so that we can look into it..

Corepc

Another thread just reminded me of something.

It seems, in my experience, that if a group of mods have the same load time (and therefore are highlighted red) then Wrye Bash won't let you move any of those mods with the arrow keys. You need to either manually change those mods load times, or have Wrye Bash redo all the mods load times in order to separate the matching ones.

Is that something that is fixable.

Wrye Bash changes the load order of two mods when using the Ctrl-Arrow method by swapping their modified time stamp. If the two mods have the same time, the same time will be swapped between them.

Not sure if this was asked before, but is wyre's site down? The other one (not wyremusings.com)

Yes, this was an issue for me too. However, since using BOSS, it's not annoying anymore. For me, at least.

I'm having a little trouble. The program starts up fine. But I'm having problems with the BAIN "Installers" tab. Clicking on it does nothing. Unlike some people it doesn't even try to do anything or ask about doing anything. No pause, just emptiness. It doesn't even seem like my hard drive even scratches. I'm running on Win 7 64 bit.

After re-installing Python and Bash I got an error popup when and only when Bash starts up for the first time:

wxPython: stdout/stderr  # Generating comtypes.gen._99AB80C4_5E19_4FD5_B3CA_5EF62FC3F765_0_1_0 # Generating comtypes.gen._00020430_0000_0000_C000_000000000046_0_2_0 # Generating comtypes.gen.stdole # Generating comtypes.gen.myole4ax # Generating comtypes.gen._EAB22AC0_30C1_11CF_A7EB_0000C05BAE0B_0_1_1 # Generating comtypes.gen.SHDocVw

This error only happened when I first run Bash and the first fresh run after reinstalling Python and Bash. It doesn't happen if I exit Bash and come back in.

I didn't install psyco-1.6 since it doesn't work with 64 bit systems.


Install path for python is C:\Python26
And Oblivion is "C:\Games\Bethesda Softworks\Oblivion" with "C:\Games\Bethesda Softworks\Oblivion Mods" beside it

the old one has been down for a while and wryemusing.com is his new one.
re: your BAIN problem: try setting the folder path to your installers dir in the bash ini.
Pacific Morrowind

WRYE BASH 278 RELEASED
Changelog:
=== 278 [23/02/2010] [PacificMorrowind, Haama, Lojack]
* NoMerge tag now correctly makes mods not show up as mergeable in the main window
* The Mark Mergeable command now shows all reasons for the mod to be not mergeable (and now includes having a NoMerge tag).
* New export/import options; Item Data, Prices
* INI Tweaks tab instead of Ini tweaks menu, showing status of the tweak etc. (contributed by Lojack)
* Bashed patch changes:
* New patchers:
* Actors.DeathItems
* Actors.Animations
* Actors.AIData
* Actors.AIPackages
* Actors.Stats
* Redguard FGTS nuller
* Cell Names importer (C.Name) (added to to Import Cells)
* Changes:
* Import Scripts modified to only import the script record on a record if the script record doesn't match the master's script record for that particular importing mod.
* Import Graphics, Sound, ScriptContents, (Actors.X all built to follow that new system) also changed like Import Scripts (Import Inventory, Relations, Factions already doing a merge rather than straight import so don't need changing)
* Timescale tweaked
* All items() calls changed to iteritems() since iteritems() is (slighty) faster.
* Tool Launchers:
* Artweaver
* Audacity
* DDSConverter
* Fraps
* Notepad++
* Paint.NET
* Custom 1, 2, 3, 4
* All icons now are in either 32*32 or 16*16 - defaults to 16*16, change if desired in the ini ofc.
* Options to show/hide some of them added to the INI
* NEW! Wizard based install system (contributed by: Lojack)
* Updated 7z dll & exe to latest version
* Various small fixes and code cleanups
* A few memory usage optimizations when building the bashed patch
* Bash tags list now looks in all of header description, tags list, BOSS masterlist, LLPatch list (instead of stopping and returning the tags from the first of those that had tags).
* A new ini setting to determine whether or not to autocheck new items in the bashed patch dialogue (previously was determined per patcher in the code).

Pacific Morrowind
(Archive up on Nexus, uploading on Sourceforge... but dialup being bad tonight)

Great news, downloading.

EDIT: First download. B)

thanx!

278 is released. Woohoo!

gtm

EDIT: Ummm... Had 277 working 10 minutes ago, unzipped 278 to Oblivion folder, overwrote everything... Now Wrye does not open at all. No error message. Just no response. Hmmm...

Reverting to 277 works fine. Reinstall of 278 still won't launch. Something go wrong with the upload? Got mine from Nexus.

gtm

EDIT: wryemusing.com seems to be down.

gtm

Seconded. 278 does not launch for me either. Reverting to 277+Alpha 4 patches works. Similar issue, no response. Click and nothing. Watching task manager, PythonW.exe fires up but disappears almost immediately.

Try http://www.wryemusings.com/

I had this same problem during testing, reported it but I don't know if PW had a chance to fix it. If you're using your old shortcut, try pointing it toward the launcher, like so: "...\Bethesda Softworks\Oblivion\Mopy\Wrye Bash Launcher.pyw"

New release, new features, and new bugz! Seriously PacificMorrowind the new features list looks awesome, can't wait until the few post-release bugs have been ironed out. Here's a little diagnostic info, since v.278 won't start here either.

d:\jeux\Oblivion\Mopy>%SYSTEMDRIVE%\Python26\python.exe bash.pyTraceback (most recent call last):  File "bash.py", line 56, in <module>	import bosh, basher  File "d:\jeux\Oblivion\Mopy\bosh.py", line 13960, in <module>	class ListPatcher(Patcher):  File "d:\jeux\Oblivion\Mopy\bosh.py", line 13965, in ListPatcher	defaultItemCheck = inisettings['AutoItemCheck'] #--GUI: Whether new items are checked by default or not.KeyError: 'AutoItemCheck'

edit: BTW I have Python 2.6 (32-bits) and I'm under Windows 7 64-bits, and of course v.277 was working just fine.

ALso have the same problem. Tried recreating the shortcut, but still doesn't work. Also tried opening the launcher directly from the Mopy folder, but it still doesn't work.

Anything else to suggest?

We should all try to run it from the command line with python.exe (not pythonw.exe) so we can actually see the error it reports and post it here. See what I did above...

It seems that Wrye Bash is struggling to find one of its INI settings, but even though I created a brand new bash.ini from the new bash_default.ini, I still get the error I reported above.

Not at the moment... from the bugdump Gabba posted, it looks like the original issue with my alpha version was resolved but another cropped up. So my temporary 'workaround' doesn't anymore. :shrug:

Same issue here, won't load.

Thanks, I'll try that, but I already did move *.7z files to both the "installers" and the "Oblivion Mods" directory (defined in the ini), and neither location worked. I guess that python startup error doesn't matter?

I might have something. Try adding AutoItemCheck=1 somewhere in bash.ini (maybe in the [settings] section). I'm just taking a guess at what is needed based on Gabba's post.

As for me, I don't think I will DL the latest Wrye Bash until this problem is fixed.

Actually the bash_default.ini has "sAutoItemCheck=False" which is supposed to be read in initDirs...
Anyway it's defined to False by Default in this function.

I think it's used in class definition before the value is defined so it bugs.
To fix(HACK!):
In bosh.py after:

inisettings = {}

Add:

inisettings['AutoItemCheck'] = False

so it looks like this:

#--Settingsdirs = {} #--app, user, mods, saves, userAppinisettings = {}inisettings['AutoItemCheck'] = FalsedefaultExt = '.7z'

edit:
Ok apparently even fixing that there are other issues, apparently this version needs some serious bug fixing.
2nd bug fixed:
In bosh.py replace(around line 8965):

			for tag in self.patchesLLTag:

By:

			for tag in self.patchesLLTags:

Won't load for me either.

Nope, that won't help. Actually I got it "working" with some heavy handed code commenting, but I won't propose it as a workaround, since it's not a proper solution and would cause worse problems. Rather I'm gonna do my best to explain the problem.

Python is not my specialty, but the issue seems to be that there are many classes in bosh.py that have a "static initialization" block at the beginning, that is, a section of code that's run as soon as the program loads and bosh.py is imported.
There are 14 instances of that, and they all try to do:

defaultItemCheck = inisettings['AutoItemCheck']

This bit of code means: "fetch me the value in inisettings that's named (i.e. whose key is) 'AutoItemCheck' ".
The problem is that "initsettings" hasn't been initialized yet since the program hasn't "started" (run its main function, which in turn call the ini-reading procedure) yet. In other words the right setting is in the ini file, but it's not accessible since it hasn't been read in program memory yet.

There's exactly the same problem at the start of basher.py: bosh.inisettings['enablewizard'] is called before the ini settings have a chance to load.

I'm gonna rant a bit here, but I think this is a good case for refactoring and improving the encapsulation. It would be better to disallow accessing bosh.inisettings['AutoItemCheck'] directly, and replace that by a method such as bosh.getIniSetting('AutoItemCheck'). The big difference is that this method can check every time it's called whether the ini file has been already read or not. If not, it loads it first and then returns the value you asked for. This way the ini data is read "just-in-time", the first time it's needed. This is a technique called "lazy initialization", and it's one of the cases where being lazy really pays off .

Edit:

Well, it seems there are more errors besides the one I spotted, so I would advise you people NOT to hack on your copy of Wrye Bash if you haven't made a full backup of everything Oblivion-related. Better to wait for a fixed version.