[Bones47]

Hi, I am looking for help.

I tried to install python and wrye bash several times, but it never works.
The first time, I downlad the wrye python 03 and wrye bash on "wiwiland" cause I'm french, after I tried with the TES nexus version, same problem.
When I downladed python, I installed it with the default settings. I installed wrye bash correctly (like the installer from TES nexus do it) with data and mopy in the oblivion folder.

I tried to look at the bugdump but I never found it. I tried this:

? chdir to the Mopy directory. "chdir" means "change directory". E.g.: chdir C:\Program Files\Bethesda Softworks\Oblivion\Mopy

? Type: c:\python25\python.exe bash.py -d

Of course I used my own directory (I checked several times, there was no mistakes) and the result was "no such files or directory"
I chdir the good directory (I did it several times, tried changing the name of the directory by removing all accents for example -my folder is named "jeux vidéos"- Of course I also changed the name "pyghon25" by python 26

After that, I find out that I already had a version of python (I was unsing wrye mash) so I deleted it. The launcher of wrye bash reacted by opening a python window with two bloc note windows (instead of the wrye bash interface) with text and lines of codes inside. I tried deleting python and reinstalling it and my first problem reappered, nothing happen when I launch wrye bash.

I don't understand what the problem is, so if someone can help me to figure out (I use Windows 7) thanks to him.

[Sammygirl500]

Okay. I'll use the Wrye Python you get at Nexus.

After installing Wrye Python 03a found at nexus I get this box as I launch Bash:

# 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

Bash launches fine, and I haven't run into any troubles with it yet. But I haven't done much.

[Jade MacSpade]

@Any_ILL
Are you absolutely sure you have installed all the python components and you have typed exactly the right commands into the command prompt? The command is this:
chdir
bash.py -d

So in my case, the command is this (and yes, I just tested it and it works perfectly):
chdir C:\Games\Bethesda Softworks\Mopy
C:\Python26\Python.exe bash.py -d


@Malonn
That is what always appears when Comtypes is initialised for the first time. I really think this should be noted somewhere because I think this question is asked a bit too often.

[Trista Jim]

So I noticed the other day there is a tweak option to wear all amulets and rings, MAN talk about a pretty big temptation to cheat. I see how it would work. Before I knew it I was pretty much a one person death machine.

[Andres Lechuga]

@Malonn
That is what always appears when Comtypes is initialised for the first time. I really think this should be noted somewhere because I think this question is asked a bit too often.

Oh okay. Thanks. This question is asked often? I didn't read through the posts. Thanks again.

[Penny Wills]

@Malonn
You're welcome.

Isn't isn't asked that often but occasionally someone posts that message here asking for help (I'd estimate 4 or 5 per thread). The last one was http://www.gamesas.com/index.php?/topic/1109736-relz-wrye-bash-thread-49/page__view__findpost__p__16320056 in the previous thread.

[Marlo Stanfield]

@ JdeRau: I am a 99% sure (you're never 100% sure ^^)
I installed the bash python 03 (the pack with everything needed) with default settings and the good version of python to go with.

For the bugdump I typed

chdir D:\Jeux Vidéos\Bethesda Softworks\Oblivion\Mopy (I saw you wrote you type chdir C:\Games\Bethesda Softworks\Mopy. You install wrye bash in the bethesda folder??? Is this my error?)
C:\Python26\Python.exe bash.py -d (exact same line for me since I installed with default settings)

[Nienna garcia]

I hate to post this again but I don't think anyone saw my last post. Basically, can anyone help me make sense of this?
Happens when I'm attempting to use BAIN to open any file, whatever the format, even an uncompressed folder.

Edit: The error results in no change to the installer tabs, thus rendering BAIN completely unusable. I have no idea when or why BAIN broke, as I used to use it just fine. A full (completely clean with nothing but Bash) reinstall of Oblivion didn't help any, so I'm convinced the error is part of Python. Unfortunately, I know nothing about Python, and I've reinstalled it too, to no avail.

wxPython: stdout/stderr

Traceback (most recent call last):  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\basher.py", line 4041, in RefreshData    self.notebook.GetPage(self.notebook.GetSelection()).OnShow()  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\basher.py", line 2562, in OnShow    if data.refresh(progress,what,self.fullRefresh):  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 10970, in refresh    if 'C' in what or changed: changed |= self.refreshConverters(progress,fullRefresh)  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 11305, in refreshConverters    self.addConverter(archive)  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 11330, in addConverter    newConverter = InstallerConverter(converter)  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 10149, in __init__    self.load()  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 10176, in load    values = cPickle.load(ins)EOFError

[Cat]

Can't believe I missed the new thread :facepalm: Anyways, I'd like to know if the tags 'Filter' and 'Import Inventory' can produce adverse effects when used on mods that don't have unique leveled lists. The mods in question are distributed amongst vanilla npcs, but with FCOM, they don't see much action. One of the mods supposedly shares a leveled list with OOO and can be merged, but the mod is quite old compared to FCOM at this point. So can using said tags to better distribute the mods be bad in any way?

not that I can think of (Filter likely wouldn't (as in I don't think it could) increase distribution at all... Invent would certainly be what you'd want)

Some of the discrepancies between the the mods descriptions (as viewable in the 'Descriptions' box in the upper right of WB's 'Mods' tab), the BOSS suggested tags and then the actual tags (as viewable in the 'Bash Tags' box in the lower right of WB's 'Mods' tab) are driving me crazy. :banghead: Some mods have all three sets of tags, and all are different: one set that's already tagged, one set from BOSS and one set from (I'm assuming) the mod creator in the description.

An example: the aforementioned TamrielTravellersItemsNPC.esp is tagged with: Deactivate, Delev, Filter, NoMerge, Relev. BOSS suggests: Filter, Delev, Relev, Deactivate. The mod Description indicates: Delev, NoMerge, Relev. The tags in question seem to be NoMerge and Deactivate.

Another example with just a basic discrepancy is FCOM_SaferRoads.esp, tagged with: Delev, Relev (also the BOSS suggestions). The mod description indicates: Delev, Merge, Relev. So should it have the Merge tag added?

Is there a hard & fast rule which can be used when Descriptions, BOSS suggestions and actual tags all conflict? What if there's just a conflict between Descriptions and actual tags?

Thanks in advance to anyone who can help sort through some of the confusion! :foodndrink: I've been re-doing my OB installation for a week now after not having played in 16 months - downloading mod updates, wading the waters of FCOM again, trying to go BAIN with everything, etc. I feel like I'm in the home stretch, but these Bash Tag issues have me flummoxed.

(Also, I've decided that flummoxed is my new favorite word!)

TTItemsNPC: the NoMerge was an incorrect tag (and is noted in the BOSSlog to remove it).
FCOM_SaverRoads: the Merge tag has been deprecated in favour of automatic Bash mergeability checking
the bash tags box is (if set to automatic which it is until/unless you tell it otherwise for that particular mod) all of the tags from the description and from the BOSSMasterlist/taglist.
In general presume that the BOSS Masterlist/taglist is correct... ofcourse there is a chance it isn't but the tagging in there is done/looked at by very experienced Bash users (and or Bash programmers -- ie me).

Is it just me, or does Wrye Bash have a memory leak? I left it running yesterday for a while and noticed it was nomming up about 900mb of RAM. I've left it running for a few hours now and have come back to find it using almost 500mb of RAM now.

Using Wrye Bash 287 on Windows 7 x64

never noticed any increase in memory unless using it to do massive things (like installers/building the patch with massive mods active etc.)

Seems Bash 287 is unnecessarily copying duplicate records: http://img841.imageshack.us/img841/351/bashpotions.jpg

All of those potions listed in green appear to only have the path information to the meshes listed in lower case rather than with capitalized words. It's not really hurting anything but would be nice if it ignored situations like this.

I abhor that in Tes4Edit (may be my only pet peave with that gift of a program)... and yet it is in Bash... ack!... fixing... ... ... fixed!

Python 2.7 also will not work with Bash. So you can drop those too.

python 2.7 will work however no Pysco so slower... and way way less tested (as in hardly at all so there may be some features that won't work but if so I don't know of them)

I have a strange situation.
My archive, Bashed Delayers.7z, doesn't show up in the installers tab.
If I change the archive name to something else, such as abashed delayers.7z or aellis delayers.7z directly in the Bash Installers folder, it shows up under the new name when I go back to the installers tab.
I haven't tested other "Bashed" names, but maybe this is the same sort of problem that was happening with the DLC a few versions back.
I recently installed the latest wrye bash and python 2.6, so I don't know if that has something to do with it.
No big deal, I can just leave my archive renamed. But I thought this might be something you'd want to look at.

there's nothing codewise that I can find that would explain that... however I can certainly confirm that it is doing that... I've narrowed it down to a minimum of starting with the word 'bash'... working on it and will definitely try to get that fixed asap.

hello guys,
don't know am i at the right place,
but can i do any new feature request here?

first of all,is it possible to add a option to bashing data for only male/female NPC?
for example, the MAO skeleton Tweaker,
i'm using some very feminine animation,
and want to keep other female NPC using the same skeleton with me.
for another example, some beauty mod makes female NPC looks cool,
but also makes male NPC looks GAY.
it would be awsome if i can choose to only bash female's Face gen data.

i would also want to request a RNAM Bash Tag,
there is few mods that chance the race of some NPCs,
but i really don't want to cover them over other mods like the Unofficial Patch.
i did add alot of Bash Tag for the Unofficial Patch,
but i guess there is few things are still missing.
oh,and it would also be cool if i can choose to bash only male or female NPC's RNAM data.


sorry if i did wrote a unnecessarily long post,
i see some folks here using bullet-point form,
just incase if my english grammar were too bad D:

• option to bash Male/Female only (Mao Skeleton, Face gen, eye,hair etc)
  
• New Bash Tag (RNAM Female/Male)

oh great, i guess i should use the bullet-point at the first place...

RNAM importer added (under Import Actors, tag is NPC.Race)
MAO Option added to only impact male or female or all NPCs.
RNAM/fagegen/eye/hair male/female specific not yet... going to have to carefully consider how best to implement that... slightly more difficult - but a good idea and certainly still doable, most difficult thing is deciding how best to implement that; adding to my list of things to code.

Yet again i've managed to break something in a way that i can find absolutely no examples of having been done before..

My problem is upon starting Wrye Bash it flashes up the cmd window, then goes no further.
So i follow the steps of creating my own bugdump file and boom.. this happens:
http://img38.imageshack.us/i/wryebroken.jpg/

There's no process running even related to Wrye, so i'm stumped.

Anyone with any insight to my problem? I want to rebuilt my bash patch!

delete the file pidfile.tmp (the reason for the error: PID (Process IDentifier) numbers are AFAIK randomly assigned and there was a process with an identical PID to Bash last time you launched it...) - also make sure to always properly exit Bash and that shouldn't happen either.
Pacific Morrowind

[Jason King]

I abhor that in Tes4Edit (may be my only pet peave with that gift of a program)... and yet it is in Bash... ack!... fixing... ... ... fixed!

Heh, thanks. In Windows it literally makes no difference since filenames aren't case sensitive. For people gaming in Linux environments, it WOULD matter. So it's probably debatable as to which is the actual bug here.

python 2.7 will work however no Pysco so slower... and way way less tested (as in hardly at all so there may be some features that won't work but if so I don't know of them)

Odd. I wasn't able to get Bash to even start under Python 2.7 when I tried it. Nor will it start with Python 2.6.6, though Python 2.6.5 works perfectly fine.

[Cedric Pearson]

Just wanted to let you know you missed an indent in the basher.py. Sorry forgot to mention this is on the latest SVN you just commited

[FITTAS]

Heh, thanks. In Windows it literally makes no difference since filenames aren't case sensitive. For people gaming in Linux environments, it WOULD matter. So it's probably debatable as to which is the actual bug here.



Odd. I wasn't able to get Bash to even start under Python 2.7 when I tried it. Nor will it start with Python 2.6.6, though Python 2.6.5 works perfectly fine.

well since OB is designed to run only on Windows (though I've heard Wine works as well with some work) it seems to me that it should follow the windows convention.

I'll see what's up with 2.6.6 shortly (downloading today actually)... 2.7 I last tried a few months ago so I could be forgetting something I had to do... ofc you do have to install the Python 2.7 version of wxPython as well as the 2.6.

Just wanted to let you know you missed an indent in the basher.py. Sorry forgot to mention this is on the latest SVN you just commited

ah ouch... fixed, thanks.
Pacific Morrowind

[James Shaw]

New random bug with your lastest commit, installer tab still shows some mods as unrecognized after full refresh, and I can't right click on any mod at all nothing pops up.

I do get this in the error output though.

Traceback (most recent call last):  File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\balt.py", line 1430, in DoItemMenu    item.AppendToMenu(menu,self,selected)  File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\basher.py", line 7260, in AppendToMenu    if self.isSelectedArchives():   File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\basher.py", line 6582, in isSelectedArchives    for selected in self.data[self.selected]:  File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\bolt.py", line 685, in __getitem__    if self.data.has_key(key):TypeError: unhashable type: 'list'

Also this error whenever I try to build a bashed patch, with cbash or without.

Traceback (most recent call last):  File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\basher.py", line 4954, in Execute    raise  File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\basher.py", line 4913, in Execute    patchFile.buildPatch(log,SubProgress(progress,0.8,0.9))#no speeding needed/really possible (less than 1/4 second even with large LO)  File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\bosh.py", line 15119, in buildPatch    patcher.buildPatch(log,SubProgress(subProgress,index))  File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\bosh.py", line 16783, in buildPatch    if record.__getattribute__(attr).lower() != value.lower():AttributeError: 'NoneType' object has no attribute 'lower'

[FITTAS]

I'll see what's up with 2.6.6 shortly (downloading today actually)... 2.7 I last tried a few months ago so I could be forgetting something I had to do... ofc you do have to install the Python 2.7 version of wxPython as well as the 2.6.

2.6.6 despite being a fixes release with no mention of backwards incompatibility nor mention of changes in the subprocess module made a minor change that meant that Bash was trying to call smething that didn't exist anymore... fixed so it'll work with either 2.6.5 (or lower ofc) or 2.6.6.

New random bug with your lastest commit, installer tab still shows some mods as unrecognized after full refresh, and I can't right click on any mod at all nothing pops up.

1st problem not sure... could you see if it still happens
second, fixed (same problem as next error)

I do get this in the error output though.

Traceback (most recent call last):  File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\balt.py", line 1430, in DoItemMenu    item.AppendToMenu(menu,self,selected)  File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\basher.py", line 7260, in AppendToMenu    if self.isSelectedArchives():   File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\basher.py", line 6582, in isSelectedArchives    for selected in self.data[self.selected]:  File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\bolt.py", line 685, in __getitem__    if self.data.has_key(key):TypeError: unhashable type: 'list'

yes I hadn't meant to commit that because I wasn't done it but hadn't realized I'd clicked save halfway through writing it... finished it up now and working nicely

Also this error whenever I try to build a bashed patch, with cbash or without.

Traceback (most recent call last):  File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\basher.py", line 4954, in Execute    raise  File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\basher.py", line 4913, in Execute    patchFile.buildPatch(log,SubProgress(progress,0.8,0.9))#no speeding needed/really possible (less than 1/4 second even with large LO)  File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\bosh.py", line 15119, in buildPatch    patcher.buildPatch(log,SubProgress(subProgress,index))  File "E:\Oblivion Mods\Utilities\Wrye bash svn\Mopy\bosh.py", line 16783, in buildPatch    if record.__getattribute__(attr).lower() != value.lower():AttributeError: 'NoneType' object has no attribute 'lower'

ah that... no doubt my most common error... fixing, thanks.
Pacific Morrowind

[DAVId MArtInez]

I'll download the SVN right now and take a look and see if it fixed anything. Am I correct in assuming I need the unicode wxpython now instead of the ansi one?

Okay, well your latest changes deff fixed all my problems except the first one where some mods aren't showing up as readable after a full refresh. I assume that's cause I have ansi installed instead of unicode.. I remember hearing that we were going to need it for the new bash, but I wasn't sure if it was needed yet

[patricia kris]

Any idea why the Mayu Skeleton tweak makes the game crash with version 287 but not the preceding one?

Any way to import ownership on items in a cell? C.Ownership only works on the cell itself. If not, possible to implement in next version?

[Angus Poole]

I'll download the SVN right now and take a look and see if it fixed anything. Am I correct in assuming I need the unicode wxpython now instead of the ansi one?

Okay, well your latest changes deff fixed all my problems except the first one where some mods aren't showing up as readable after a full refresh. I assume that's cause I have ansi installed instead of unicode.. I remember hearing that we were going to need it for the new bash, but I wasn't sure if it was needed yet

yes unicode is needed now... the changes of the last er dozen commits or so require it (not fatally so just some string oddities will result AFAICT) and it (should) work with all non-english characters in file names (so far has worked on all my test cases of even really funny files - had to try half a dozen codecs for one really really funny one before I found a codec that could read it (a file in SOVVM Meshes)).
Glad to hear that fixed all the other problems, thanks for the feedback.

Any idea why the Mayu Skeleton tweak makes the game crash with version 287 but not the preceding one?

Any way to import ownership on items in a cell? C.Ownership only works on the cell itself. If not, possible to implement in next version?

nill... hasn't changed the pathing at all... 285 was fine? (I haven't tested that in game since I don't use MAO)

C.ItemOwnership: already planned... however it can only be done in the CBash version (well it could be done in the python version but it'll take hmm probably ten-twenty times as long as the rest of the patch to build... and might run into memory problems too... not worth the trouble IMO)... anoother CBash only tags that I'm thinking of: C.ItemPosition (self explanatory I should hope).
Pacific Morrowind

[Steph]

nill... hasn't changed the pathing at all... 285 was fine? (I haven't tested that in game since I don't use MAO)

Yes, using the excact same settings a Bached Patch works fine with 285, but the game crashes when using a BP built by 287.
It seems to be connected to certain mods though, since only a few players (I only know of one other) have the problem. Oh well, I'm not even sure what the Mayu tweak does, so it's not very important to me. But still weird, if there has been no code change. :huh:

[Breautiful]

Yes, using the excact same settings a Bached Patch works fine with 285, but the game crashes when using a BP built by 287.
It seems to be connected to certain mods though, since only a few players (I only know of one other) have the problem. Oh well, I'm not even sure what the Mayu tweak does, so it's not very important to me. But still weird, if there has been no code change. :huh:

Doesn't the Mayu's tweak require additional resources??, http://tesnexus.com/downloads/file.php?id=19796

[Mr. Ray]

yes unicode is needed now... the changes of the last er dozen commits or so require it (not fatally so just some string oddities will result AFAICT) and it (should) work with all non-english characters in file names (so far has worked on all my test cases of even really funny files - had to try half a dozen codecs for one really really funny one before I found a codec that could read it (a file in SOVVM Meshes)).
Glad to hear that fixed all the other problems, thanks for the feedback.


nill... hasn't changed the pathing at all... 285 was fine? (I haven't tested that in game since I don't use MAO)

C.ItemOwnership: already planned... however it can only be done in the CBash version (well it could be done in the python version but it'll take hmm probably ten-twenty times as long as the rest of the patch to build... and might run into memory problems too... not worth the trouble IMO)... anoother CBash only tags that I'm thinking of: C.ItemPosition (self explanatory I should hope).
Pacific Morrowind

No problem, anything to help out bash. Probally the single most useful program for oblivion out there.

Edit: Forgot to ask, is there anything wrong with using cbash now. By that I mean anything majorly game breaking. It's just so much faster then without.

Second Edit: On full refresh all mods are installable except rar files. Ever .rar is all black and gray and says format not recognized

[Charity Hughes]

So in some recent testing of my constant work in progress called my Oblivion installation I regenerated my ini.

I then went about with my usual tweaks of the ini and thought "hey these would be great additions to the ini edits tab of wrye bash."

The first was to change iShadowMapResolution to 1024 as per http://www.uesp.net/wiki/Oblivion:Technical_Support. There are a few other ini tweaks recommended for trouble shooting on that page too that might be worth having as ini edits.

Another I often do is to turn off music (that would be a great edit for the tab) and then also to turn off all the intro movies.

those my requests!

[gemma king]

Yes, using the excact same settings a Bached Patch works fine with 285, but the game crashes when using a BP built by 287.
It seems to be connected to certain mods though, since only a few players (I only know of one other) have the problem. Oh well, I'm not even sure what the Mayu tweak does, so it's not very important to me. But still weird, if there has been no code change. :huh:

hmmm just did some testing with that (as in down to hexedit mode) and not a difference I could find (except for newer isn't writing out the player record which isn't processed except on new games anyways afaik) .. expect a PM shortly (ie to avoid cluttering this thread with going back and forth until (hopefully) finding and fixing the buginess.)

Doesn't the Mayu's tweak require additional resources??, http://tesnexus.com/downloads/file.php?id=19796

doubt it is lack of that causing (though that could cause it)... since it was working with 285 and not with 286/7.

No problem, anything to help out bash. Probally the single most useful program for oblivion out there.

Edit: Forgot to ask, is there anything wrong with using cbash now. By that I mean anything majorly game breaking. It's just so much faster then without.

Second Edit: On full refresh all mods are installable except rar files. Ever .rar is all black and gray and says format not recognized

CBash... it is working great... still a couple things to implement (that I've been supposed to do for a while), and one bug that is annoying; it will only handle 255 mods (including merged and imported) - basically as soon as that is fixed it'll be widespread test request... but any advance testing you want to do is always welcome (just for any bugs make sure to mention that it is with CBash or not - and if using the SVN source the revision is nice to know too).

hmm that is odd... working fine for .rar archives here... er no they *looked* fine and then I decide oh why not do a real test - do an action to one and bang... even refresh... so I'll try to figure that out in the next couple days because that is very odd (I suspect it may be from some of the ANSI->Unicode changes.), thanks.
Pacific Mororwind

[Marquis T]

Hey, on your latest revison found a couple bugs, some really small others look to be a bit bigger.

This is an error I get weather with cbash or not whenever I shift click all of my mods. Well more then anymore then 20 or 30. I think it may even have to do with the filename cause I've gotten pretty long shift clicks before that pops up but it does always pop up if I select them all at once.

E:\Oblivion Mods\Utilities\Wrye bash svn\597\Mopy\basher.py:1645: UnicodeWarning: Unicode unequal comparison failed to convert both arguments to Unicode - interpreting them as being unequal  def OnTextEdit(self,event):

I haven't really seen any adverse effects from it other then that message popping up.


Second bug I noticed without cbash active is when making a bashed patch with Races. Wheenver races is ticked, reguardless of mods actually being checked inside of it. You'll get this error message

  File "E:\Oblivion Mods\Utilities\Wrye bash svn\597\Mopy\basher.py", line 4959, in Execute    raise  File "E:\Oblivion Mods\Utilities\Wrye bash svn\597\Mopy\basher.py", line 4918, in Execute    patchFile.buildPatch(log,SubProgress(progress,0.8,0.9))#no speeding needed/really possible (less than 1/4 second even with large LO)  File "E:\Oblivion Mods\Utilities\Wrye bash svn\597\Mopy\bosh.py", line 15122, in buildPatch    patcher.buildPatch(log,SubProgress(subProgress,index))  File "E:\Oblivion Mods\Utilities\Wrye bash svn\597\Mopy\bosh.py", line 26630, in buildPatch    raceHair = ((defaultMaleHair,defaultFemaleHair)[npc.flags.female]).get(npc.race)  File "E:\Oblivion Mods\Utilities\Wrye bash svn\597\Mopy\bolt.py", line 629, in __getattr__    raise AttributeError(name)AttributeError: female

Other than that the bashed patch appears to work fine with everything else. I could rebuild the patch just fine with everything else selected and got no error. But not with the race box checked.

Edit: Just thought I'd let you know both of those were done without cbash.

Now onto the real reason I made this edit with cbsah theres a pretty big bug happening
Any mod you click on and select Mark Mergable you get this

Traceback (most recent call last):  File "E:\Oblivion Mods\Utilities\Wrye bash svn\597\Mopy\basher.py", line 8833, in Execute    canMerge = bosh.CBash_PatchFile.modIsMergeable(fileInfo)  File "E:\Oblivion Mods\Utilities\Wrye bash svn\597\Mopy\bosh.py", line 15172, in modIsMergeable    for master in modFile.TES4.masters:AttributeError: 'NoneType' object has no attribute 'TES4'

Another is when you right click and rebuild the patch you get this

Traceback (most recent call last):  File "E:\Oblivion Mods\Utilities\Wrye bash svn\597\Mopy\basher.py", line 9526, in Execute    bosh.modInfos.rescanMergeable(bosh.modInfos.data,nullProgress)  File "E:\Oblivion Mods\Utilities\Wrye bash svn\597\Mopy\bosh.py", line 8183, in rescanMergeable    canMerge = CBash_PatchFile.modIsMergeable(modInfo,verbose=False) == True  File "E:\Oblivion Mods\Utilities\Wrye bash svn\597\Mopy\bosh.py", line 15172, in modIsMergeable    for master in modFile.TES4.masters:AttributeError: 'NoneType' object has no attribute 'TES4'

I was peeking around the code just looking at stuff seems like it might have something to do with the if else statment you added recently to cint.py. Where you changed how cbash was defined
Only mentioning that cause I took out the if statment you put there for cbash and put it back to cbash = None with the lines on top commented out and that problem when away.
Probally wrong on that though.. I really don't knwo what I'm doing lol I just like to look around code it's fun and you know you pick up as you go along.

I did do a small test with that tweak to the cint.py to see if was disabling cbsah or something. With that tweak I built a bashed patch in 3 minutes with the cbash.dll named cbash.dll.
Then clsoed wrye renamed teh cbash dll and ran the same test again and it took me 4 minutes 27 seocnds to build. So I assume that means cbash was still being used

[Yvonne]

hmmm just did some testing with that (as in down to hexedit mode) and not a difference I could find (except for newer isn't writing out the player record which isn't processed except on new games anyways afaik) .. expect a PM shortly (ie to avoid cluttering this thread with going back and forth until (hopefully) finding and fixing the buginess.)


doubt it is lack of that causing (though that could cause it)... since it was working with 285 and not with 286/7.


CBash... it is working great... still a couple things to implement (that I've been supposed to do for a while), and one bug that is annoying; it will only handle 255 mods (including merged and imported) - basically as soon as that is fixed it'll be widespread test request... but any advance testing you want to do is always welcome (just for any bugs make sure to mention that it is with CBash or not - and if using the SVN source the revision is nice to know too).

hmm that is odd... working fine for .rar archives here... er no they *looked* fine and then I decide oh why not do a real test - do an action to one and bang... even refresh... so I'll try to figure that out in the next couple days because that is very odd (I suspect it may be from some of the ANSI->Unicode changes.), thanks.
Pacific Mororwind

well no rush on that really not a big deal to turn then into 7z. That seemed to fix the unrecognixed thing

[Anna Watts]

I'm having a problem with Wrye Bash not organizing my load order properly using boss. Please check out the thread below and respond there.
http://www.gamesas.com/index.php?/topic/1115463-wrye-bash-load-order-issues/page__p__16376944&#entry16376944