[claire ley]

r981 lots of cheering :celebration::D ...

No errors, successful extraction of the omod http://www.bild.me/bild.php?file=7256738Capture1.JPG keep this open in its own tab to compare with ...

... the original omod extraction (which I used OBMMex to extract for the Vibrant Bain I made earlier http://www.bild.me/bild.php?file=7952593Capture2.JPG 20 files check, size on disk exactly the same check

Edit: And more testing; this lot http://www.bild.me/bild.php?file=1821418Capture1.JPG successfully fed individually through Wrye Bash r981 extraction, no problems. The only thing it didn't like previously (when I used r973) was multi-selecting all omods and dragging them into the Installers Tab ( I didn't mention it because I thought it was a bit early days to expect handling more than one file ) - decided to delete the projects in that last screenshot and go again with multi select - Pleasantly surprised to find r981 just eats them all for breakfast http://www.bild.me/bild.php?file=7670456Capture2.JPG errors = nil

[Emma Copeland]

I vaguely remember this. I don't remember the verdict or if there even was one. I'll see if I can look into it once I've got this omod thing stable.

Thanks

Well it was Gaticus' baby and he even submitted to PM a break down of folder structures - I just tried ot search for it as I recall it being posted ... he was most active October to December last year and advocated an overhaul of a fair bit of the folder structure and where information is stored. A bit of it http://www.gamesas.com/index.php?/topic/1129495-relz-wrye-bash-thread-53/page__view__findpost__p__16602537. Thread 53 is where I see most of the discussion.

I think the issue he found was that by altering the installers dat location it would then screw with the hidden files location or something so that too had to be addressed.

Mostly though I think instead of a full overhaul of folder structures if there was an ini option to change the location where the installers.dat was found then folks like myself could take matters into my own hand and do as requested and it would not mean that one would have to field three threads of bug reports about how BAIN no longer works due the folder structure/location changes. ... So not sure if the ini option is doable, but it would be mighty like Thor if it was.

Unfortunately Gaticus appears to have gone away, so I don't expect grand sweeping changes - but this small bit is what I hold out hope for - seems far more appealing to me than reading omods.

thanks again.

[Lew.p]

Hey guys - I am away from my Ob pc till about tomorrow - sorry to let you down
I have a gut feeling though that my testing won't be needed then

[Mrs shelly Sugarplum]

Small Request:

I'd like bash to make a benchmark.log in the mopy directory if it doesn't exist
And append stuff like bashed patch build time, refresh installers time to it, etc

Format of append to benchmark.log:
Wrye Bash [Version], Time [month-day-year hour:min:sec],Bashed Patch Build [Time to build patch, Cbash or standard]
Wrye Bash [Version], Time [month-day-year hour:min:sec],Refresh Installers Tab [Time taken]

[Melung Chan]

Not sure when you made changes to the INI tab. OR If it always had these features, :icecream: :trophy: :thumbsup:

Being able to see the Oblivion INI in BASH is sixy! I never went to the INI tab (always edited all changes by hand), But had a look tonight . Did we always have the ability to see the INI and Tweak it from BASH? that was fun, I noticed that all the INI tweaks for Fonts were wrong, for what my INI has. So I copied my INI edits and made my own ini tweak. Named it Darn Installed.ini. Opened BASH and it was Green, and checked as installed...thats Nice.

Thank you . Just laugh , as this is probable old news, and been around in BASH versions from 178 and am just REAL slow!

[Jay Baby]

Traceback (most recent call last):  File "C:\Games\Bethesda Softworks\Oblivion\Mopy\basher.py", line 5836, in Execute    patchFile.buildPatch(SubProgress(progress,0.1,0.9)) #try to speed this up!  File "C:\Games\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 17962, in buildPatch    patcher(modFile, record, bashTags)  File "C:\Games\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 20495, in apply    self.scan(modFile,record,bashTags)  File "C:\Games\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 20457, in scan    if master in previousPackages:NameError: global name 'previousPackages' is not defined

Rev 981, CBash enabled. Testing the ActorsAIPackages changes PM added a couple of revisions back.

Also got this one after I realized my standard version patch wasn't disabled, then re-ran another patch build:

Traceback (most recent call last):  File "C:\Games\Bethesda Softworks\Oblivion\Mopy\basher.py", line 5836, in Execute    patchFile.buildPatch(SubProgress(progress,0.1,0.9)) #try to speed this up!  File "C:\Games\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 17984, in buildPatch    patcher(self, subProgress)  File "C:\Games\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 31717, in finishPatch    subProgress.setFull(len(ObCollection.LoadOrderMods) * 2)  File "C:\Games\Bethesda Softworks\Oblivion\Mopy\bolt.py", line 1519, in setFull    if (1.0*full) == 0: raise ArgumentError('Full must be non-zero!')bolt.ArgumentError: Full must be non-zero!

[Chloe :)]

Traceback (most recent call last):  File "C:\Games\Bethesda Softworks\Oblivion\Mopy\basher.py", line 5836, in Execute    patchFile.buildPatch(SubProgress(progress,0.1,0.9)) #try to speed this up!  File "C:\Games\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 17962, in buildPatch    patcher(modFile, record, bashTags)  File "C:\Games\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 20495, in apply    self.scan(modFile,record,bashTags)  File "C:\Games\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 20457, in scan    if master in previousPackages:NameError: global name 'previousPackages' is not defined

Rev 981, CBash enabled. Testing the ActorsAIPackages changes PM added a couple of revisions back.

Missing

self.

before previousPackages in file bosh.py at line 20457 ?

[ijohnnny]

That would be it. It built 100% to the end. Now to see if it did right with all these AI packs.....

[Georgia Fullalove]

I'm having trouble with Wyre Bash 291. I can't get it to start.

Double clicking on the Wyre Bash Launcher does nothing.

Double clicking on the bash.py opens a command line window for less that a second before it closes again. Never even shows up in task manager.

When I open python and run the bash.py this is what it says

>>> C:\Program Files\Bethesda Softworks\Oblivion\Mopy\bosh.py:15124: Warning: 'with' will become a reserved keyword in Python 2.6
Traceback (most recent call last):
File "C:\Python25\Lib\site-packages\Pythonwin\pywin\framework\scriptutils.py", line 312, in RunScript
exec codeObject in __main__.__dict__
File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\bash.py", line 38, in
import bosh
File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 15124
with open(os.path.join(root, name),"r") as text:
^
SyntaxError: invalid syntax
>>>

I apologize in case this problem has been dealt with already in this thread. I've been reading on the computer all day and my eyes are killing me. I couldn't manage reading all eight pages.

Hopefully someone can help.

Thanks

[Amysaurusrex]

Not sure when you made changes to the INI tab. OR If it always had these features, :icecream: :trophy: :thumbsup:

Being able to see the Oblivion INI in BASH is sixy! I never went to the INI tab (always edited all changes by hand), But had a look tonight . Did we always have the ability to see the INI and Tweak it from BASH? that was fun, I noticed that all the INI tweaks for Fonts were wrong, for what my INI has. So I copied my INI edits and made my own ini tweak. Named it Darn Installed.ini. Opened BASH and it was Green, and checked as installed...thats Nice.

Thank you . Just laugh , as this is probable old news, and been around in BASH versions from 178 and am just REAL slow!

INI Tab has been around for quite a while not, however it did just get a makeover which is what you're seeing now

That would be it. It built 100% to the end. Now to see if it did right with all these AI packs.....

Noticed that too. From a quick test (Vanilla+SI+DLC+UOP+USIP+UOMP+UOPS), I didn't get the same results as the Python version. Looking at TES4Edit, it doesn't look right either, so looks like PM still has some tweaking to get it right.

with open(os.path.join(root, name),"r") as text:
^
SyntaxError: invalid syntax

This is 2.6+ syntax that Python 2.5 doesn't like (unless you enable it specifically). It's been corrected in the SVN, but if you want to get 291 working, you'll need to do a clean install of the python prerequisites, only using python > 2.5. I would just go with Wrye Python 03a. If that's not your cup of tea, and you don't want to use the svn versions, your only option is to manually edit bosh.py. You'd have to add:

from __future__ import with_statement

to the top of the file.

[victoria gillis]

Hi WB team. I've been having a problem with WB 291 lately, and I hope someone can give me a hand.

Background: I just converted all my old mods to BAIN suitable archives, and switched entirely to BAIN. I've been installing them in batches and testing them as I go, and for a long time this was fine. Now I have about 140 packages installed with about 211 esp's and using a bashed patch. This is an FCOM install, and everything works fine actually (Hooray!) -- except for this one problem.

Problem: When I quit the program, or when it crashes, sometimes it will load up and the most recent mod packages installed in the Installers tab are cleared out and appear to be uninstalled. I confirmed that they are not in fact uninstalled though, they just are reported as uninstalled. If I reinstall them, it doesn't take long to reinstall (I guess it recognizes that they are installed already and quickly adjusts?) They appear to be unchecked grey boxes with unchecked sub-packages. Sometimes it quits and starts up fine, other times it does not. I haven't found a pattern yet -- it happens with a crash or natural quit about 25% of the time but it's difficult to deal with because I can't always remember everything I just installed (i don't mod every day so it can be some time before I get back to it).

What I've done: Reinstalled WB 291 and the components for python, didn't really know what else to do.

Issue: A few times so far when I open Wrye Bash, some of the most recently installed mod packages appear to be uninstalled. However, they really are still installed -- I verified the paths and the esp's, and they really are installed. In my Installers tab, they show as an unchecked grey box with no sub-packages checked.

System: Windows 7 64bit, UAC off, Python 2.6, wxPython 2.8.1, PyWin32 216, Comtypes 0.6.2, Psycho 1.6, Wrye Bash 291. No cbash, no bash.ini used.

Any suggestions? Thank you for your time and for your work on this great tool.

[Lisha Boo]

That would be it. It built 100% to the end. Now to see if it did right with all these AI packs.....

well as noted in the commit log:
I suddenly discovered I'm somehow missing dx9 on here so can't run tes4edit until I dl the stupid 97mb package so its not actually examined yet but it er appears to be working - at least no fatal errors, I'll see what kind of crud it is writing out soon though. (like tomorrow night).
didn't get downloaded while I was out today so that'll ahve to be delayed until tomorrow night... but getting closer.
Pacific Morrowind

[Rachel Hall]

Right, but the problems I reported weren't related to tes4edit

The one Baphometal suggested a fix for worked, it was missing "self." in front of "previouspackages".

I haven't gone through a full examination of the patch that was built yet, although I have found at least one problem so far: http://img148.imageshack.us/img148/3940/badform.jpg

That was using the standard Python version and not CBash, so it's a new bug that didn't exist before. Still on r981.

The CBash side fared better but was leaving a few things out, I'll know more once I've looked through the whole thing but it's definitely an improvement over not existing

All the other CBash patchers appear to be functioning properly. Very neat to see a substantial chunk of worldspace patches all marked mergeable.

EDIT: http://img202.imageshack.us/img202/9924/ignoredai.jpg is typical of the AI pack errors I'm seeing when more than one mod is tagged. In this particular spot, the UOP is tagged, TIE is not, and ABR is tagged. The patch ignored ABR and is apparently asserting the UOP's AI pack list even though that really should be ignored as identical to Oblivion.esm.

[Ellie English]

Any suggestions? Thank you for your time and for your work on this great tool.

Funny you should raise this - I started seeing the same type of problem on my new installation. Are you installing packages and then running OB while WB is still running? For me, closing WB before running seemed to stop the problem happening, although I have not done any extensive testing to verify that this is the connection or that once done, you can run OB while WB is running.

I am using WB v291.

Edit: Typo corrections

[Mrs Pooh]

Hi WB team. I've been having a problem with WB 291 lately, and I hope someone can give me a hand.

Background: I just converted all my old mods to BAIN suitable archives, and switched entirely to BAIN. I've been installing them in batches and testing them as I go, and for a long time this was fine. Now I have about 140 packages installed with about 211 esp's and using a bashed patch. This is an FCOM install, and everything works fine actually (Hooray!) -- except for this one problem.

Problem: When I quit the program, or when it crashes, sometimes it will load up and the most recent mod packages installed in the Installers tab are cleared out and appear to be uninstalled. I confirmed that they are not in fact uninstalled though, they just are reported as uninstalled. If I reinstall them, it doesn't take long to reinstall (I guess it recognizes that they are installed already and quickly adjusts?) They appear to be unchecked grey boxes with unchecked sub-packages. Sometimes it quits and starts up fine, other times it does not. I haven't found a pattern yet -- it happens with a crash or natural quit about 25% of the time but it's difficult to deal with because I can't always remember everything I just installed (i don't mod every day so it can be some time before I get back to it).

What I've done: Reinstalled WB 291 and the components for python, didn't really know what else to do.

Issue: A few times so far when I open Wrye Bash, some of the most recently installed mod packages appear to be uninstalled. However, they really are still installed -- I verified the paths and the esp's, and they really are installed. In my Installers tab, they show as an unchecked grey box with no sub-packages checked.

System: Windows 7 64bit, UAC off, Python 2.6, wxPython 2.8.1, PyWin32 216, Comtypes 0.6.2, Psycho 1.6, Wrye Bash 291. No cbash, no bash.ini used.

Any suggestions? Thank you for your time and for your work on this great tool.

Strange !
Anyway - till someone else more adept maybe gives some insight could you download the latest beta from the SVN (see OP) and see if still present in 292 ?

[sam westover]

I have a question - At what point does Wrye Bash apply BSA Redating, does this happen as soon as you load Wrye Bash, or does the user have to go to the Installers Tab before it happens?

Just made up a few new screens for the Pictorial Guide which spawned the question.

Anyway also request Wrye Bash team have a nosy at the following screenshots and see if there is anything you would like re-worded....

This one is in http://www.bild.me/bild.php?file=7881108WBI-1.jpg screen 1, particularly have a look at the box-out on the right

This one is in http://www.bild.me/bild.php?file=2114714WBIA-16.jpg additional screen 16

Request also the new abilities be added to the Wrye Bash Help file. (Which also needs updating for the new wxPython 2.8.12.0)

[Jeffrey Lawson]

I would say as soon you goto Installers tab if BSA Redating isn't active, but when you're open Wrye Bash if BSA Redating is active.

[Bigze Stacks]

And one very serious issue in CBash with worldspace edits: http://img98.imageshack.us/img98/1387/brokenworldspaces.jpg

In that pick, index AD is the index for the bashed patch itself, when it should have retained the formID of the CELL the reference belongs to.

[Anna Kyselova]

Got an error when enabling the 'Installers' tab.
svn. ver. 983 (same 981)

Spoiler

Traceback (most recent call last):  File "Q:\Oblivion Tools\Wrye Bash\Mopy\basher.py", line 4720, in OnShowPage    self.GetPage(event.GetSelection()).OnShow()  File "Q:\Oblivion Tools\Wrye Bash\Mopy\basher.py", line 3233, in OnShow    if data.refresh(progress,what,self.fullRefresh):  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bosh.py", line 11921, in refresh    settings['bash.installers.removeEmptyDirs'], fullRefresh)  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bosh.py", line 10461, in refreshSizeCrcDate    crc = apFile.crcProgress(bolt.SubProgress(progress,done,done+apFile.size))  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bolt.py", line 1552, in __init__    raise ArgumentError('BaseFrom must be >= 0 and BaseTo must be > BaseFrom')bolt.ArgumentError: BaseFrom must be >= 0 and BaseTo must be > BaseFrom

[james kite]

I have a question - At what point does Wrye Bash apply BSA Redating, does this happen as soon as you load Wrye Bash, or does the user have to go to the Installers Tab before it happens?

Just made up a few new screens for the Pictorial Guide which spawned the question.

Anyway also request Wrye Bash team have a nosy at the following screenshots and see if there is anything you would like re-worded....

This one is in http://www.bild.me/bild.php?file=7881108WBI-1.jpg screen 1, particularly have a look at the box-out on the right

This one is in http://www.bild.me/bild.php?file=2114714WBIA-16.jpg additional screen 16

Request also the new abilities be added to the Wrye Bash Help file. (Which also needs updating for the new wxPython 2.8.12.0)

BSA redating occurs during the 'Mods' tab refresh, at the same time it's checking plugin dates for changes. As for readme updates and such, another on my TODO list.
EDIT: also the screens look great :foodndrink:

Got an error when enabling the 'Installers' tab.
svn. ver. 983 (same 981)

Spoiler

Traceback (most recent call last):  File "Q:\Oblivion Tools\Wrye Bash\Mopy\basher.py", line 4720, in OnShowPage    self.GetPage(event.GetSelection()).OnShow()  File "Q:\Oblivion Tools\Wrye Bash\Mopy\basher.py", line 3233, in OnShow    if data.refresh(progress,what,self.fullRefresh):  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bosh.py", line 11921, in refresh    settings['bash.installers.removeEmptyDirs'], fullRefresh)  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bosh.py", line 10461, in refreshSizeCrcDate    crc = apFile.crcProgress(bolt.SubProgress(progress,done,done+apFile.size))  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bolt.py", line 1552, in __init__    raise ArgumentError('BaseFrom must be >= 0 and BaseTo must be > BaseFrom')bolt.ArgumentError: BaseFrom must be >= 0 and BaseTo must be > BaseFrom

Ok, I'll get a fix for that real quick
EDIT: Fixed now

[N3T4]

Next error, when enabling the 'Installers' tab.
svn ver. 984

Spoiler

Traceback (most recent call last):  File "Q:\Oblivion Tools\Wrye Bash\Mopy\basher.py", line 4720, in OnShowPage    self.GetPage(event.GetSelection()).OnShow()  File "Q:\Oblivion Tools\Wrye Bash\Mopy\basher.py", line 3233, in OnShow    if data.refresh(progress,what,self.fullRefresh):  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bosh.py", line 11921, in refresh    settings['bash.installers.removeEmptyDirs'], fullRefresh)  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bosh.py", line 10461, in refreshSizeCrcDate    crc = apFile.crcProgress(bolt.SubProgress(progress,done,done+max(size,1)))  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bolt.py", line 495, in crcProgress    progress.setFull(size)  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bolt.py", line 1519, in setFull    if (1.0*full) == 0: raise ArgumentError('Full must be non-zero!')bolt.ArgumentError: Full must be non-zero!

Calculating crc from ? (bolt.py line 495)

[Gavin boyce]

Next error, when enabling the 'Installers' tab.
svn ver. 984

Spoiler

Traceback (most recent call last):  File "Q:\Oblivion Tools\Wrye Bash\Mopy\basher.py", line 4720, in OnShowPage    self.GetPage(event.GetSelection()).OnShow()  File "Q:\Oblivion Tools\Wrye Bash\Mopy\basher.py", line 3233, in OnShow    if data.refresh(progress,what,self.fullRefresh):  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bosh.py", line 11921, in refresh    settings['bash.installers.removeEmptyDirs'], fullRefresh)  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bosh.py", line 10461, in refreshSizeCrcDate    crc = apFile.crcProgress(bolt.SubProgress(progress,done,done+max(size,1)))  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bolt.py", line 495, in crcProgress    progress.setFull(size)  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bolt.py", line 1519, in setFull    if (1.0*full) == 0: raise ArgumentError('Full must be non-zero!')bolt.ArgumentError: Full must be non-zero!

Calculating crc from ? (bolt.py line 495)

Ok got that one too. Silly me didn't think there would ever be a 0 sized file to 'calculate' the crc of

[Marilú]

Installers tab and Mods tab
Is it possible to lock the size of the columns (in relation to or ...)?

[priscillaaa]

Installers tab and Mods tab
Is it possible to lock the size of the columns (in relation to or ...)?

I'm not sure what you mean:

• If you mean remember columns sizes from the last time you ran Bash, then yes it already does
  
• If you mean how to make it autosize the columns to expand big enough to show items that have '...' in them, press Ctrl+Numpad(+)
  
• If you mean have Bash automatically do #2, then no, it doesn't

[Victor Oropeza]

I'm not sure what you mean:

• If you mean remember columns sizes from the last time you ran Bash, then yes it already does
  
• If you mean how to make it autosize the columns to expand big enough to show items that have '...' in them, press Ctrl+Numpad(+)
  
• If you mean have Bash automatically do #2, then no, it doesn't

1. yes this would be perfect, but this doesn't work