[jadie kell]

Just to check, Phyton Bash is still the way to go, yes?

Far as I know unless there is a brave soldier out there that has a liking to coverting bash 100% to the fastest language. Not sure what is that.... C, C++ , I dunno
Don't think so.

Python apps will run on nearly every OS if written right. maybe some minor tweaking.

Also how about spending twice or more the time to develop it.
Python may be slower running, but python is also fast in many other ways and nearly universal.

I'm still learning a bit about programming everyday, but I'm learning fast.

Side thought: Now imagine... if Python was a lathe and was able to reproduce itself.
Out of all the languages available, which would win. In a speed contest...?

Python. Not very slow, is it. or is it? haha Pick your poison. I prefer to be immune.

[daniel royle]

Hopefully by the end of Wednesday I will have a standalone set of code, which imho is slightly better structured than the original code (bolt, balt, some some of basher have been moved over). However, quite a lot of changes have also been made to the core bash files. How would the developers like me to merge it? (I can probably merge and submit some patch files if that would be best :shrug:)

As mentioned, I would prefer to merge as soon as possible when I am happy with my code as I probably have about 4 days of changes to the svn to merge into my code and I don't really want to ever have to merge a month of changes.

[naome duncan]

Far as I know unless there is a brave soldier out there that has a liking to coverting bash 100% to the fastest language. Not sure what is that.... C, C++ , I dunno
Don't think so.

Python apps will run on nearly every OS if written right. maybe some minor tweaking.

Also how about spending twice or more the time to develop it.
Python may be slower running, but python is also fast in many other ways and nearly universal.

(...)

Python. Not very slow, is it. or is it? haha Pick your poison. I prefer to be immune.

Not that I complain. It is a wonderful feature. It took me a couple of years to return to Wrye bash, but now I cannot play without.

However, the devs have dagled the carrot and now I drool over the idea of speeding bashed patches.

Please understand that I have been in the process of finding which one of my 30 or so quest mods is CTDing me but every time I try to take it one by one, I give up because of endless time spent with Bash Patch rebuilts. If and when I have time I will maybe finish it (most probably after Skyrim though).

[April]

got an error with Mod Checker Scan for UDR's
svn ver. 1088
non CBASH mode

Traceback (most recent call last):  File "Q:\Oblivion Tools\Wrye Bash\Mopy\basher.py", line 5384, in CheckMods    scanDirty=(None,modChecker)[self.gScanDirty.GetValue()]  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bosh.py", line 9809, in checkMods    progress(i,_('Scanning for deleted refs...'), info.name.s)TypeError: __call__() takes at most 3 arguments (4 given)

EDIT
with CBASH no problem

[Emma Parkinson]

However, the devs have dagled the carrot and now I drool over the idea of speeding bashed patches.

There is one thing I would drool over, err make that two...
CTux(for all)
and...
Games for Linux.

[Jessica Stokes]

Hopefully by the end of Wednesday I will have a standalone set of code, which imho is slightly better structured than the original code (bolt, balt, some some of basher have been moved over). However, quite a lot of changes have also been made to the core bash files. How would the developers like me to merge it? (I can probably merge and submit some patch files if that would be best :shrug:)

As mentioned, I would prefer to merge as soon as possible when I am happy with my code as I probably have about 4 days of changes to the svn to merge into my code and I don't really want to ever have to merge a month of changes.

Ooh, this one's hard. I think I'll have to defer to PM on this one, but my opinion: after 292 is released. That way we will have more time to deal with any bugs that pop up from merging it in.

got an error with Mod Checker Scan for UDR's
svn ver. 1088
non CBASH mode

Traceback (most recent call last):  File "Q:\Oblivion Tools\Wrye Bash\Mopy\basher.py", line 5384, in CheckMods    scanDirty=(None,modChecker)[self.gScanDirty.GetValue()]  File "Q:\Oblivion Tools\Wrye Bash\Mopy\bosh.py", line 9809, in checkMods    progress(i,_('Scanning for deleted refs...'), info.name.s)TypeError: __call__() takes at most 3 arguments (4 given)

EDIT
with CBASH no problem

Oops, should be fixed now for non-CBash as well. Thanks.

[Erich Lendermon]

Update on BAIT (Bash Asynchronous Installer Tab): I'm working on the filtering/searching logic right now. Things are looking pretty good. When this is done, it will be able to mask out packages in the tree according to their attributes (e.g. hidden/installed/not installed packages can be shown or hidden with the click of a button) and/or via substring (e.g. typing in "Better" will just show all the packages that have the word "Better" in them)

@Yacoby and Psymon: I'm making all this code very modular, so it should be easy to reuse for morrowind/skyrim etc. It will also be able to handle multiple installations (i.e. the metadata will be stored separately from the BAIN archives).

[Antonio Gigliotta]

@Lojack: Everything works great now for the All Natural wizard. One question though. For some reason in the INI tab where I can view in the far right window in green the places the ini file changes, the color tints variables display in green but remain all at 1.00, despite the fact they are actually changed if I open the "All Natural.ini" and they are listed in the tweak file as shown in the middle window. All the rest of the changed variables show up in the far right window showing "All natural.ini". Sorry if that was confusing. Just curious why these aren't showing up. Not a big deal but maybe a bug.

[megan gleeson]

@Lojack: Everything works great now for the All Natural wizard. One question though. For some reason in the INI tab where I can view in the far right window in green the places the ini file changes, the color tints variables display in green but remain all at 1.00, despite the fact they are actually changed if I open the "All Natural.ini" and they are listed in the tweak file as shown in the middle window. All the rest of the changed variables show up in the far right window showing "All natural.ini". Sorry if that was confusing. Just curious why these aren't showing up. Not a big deal but maybe a bug.

Not entirely sure what you mean. I screenshot would be helpful to describe it further. From what it sounds like though, you're saying the 'All Natural.ini' vew in the far right pane shows lines that are green, with their variables set to 1.00. The corresponding tweak file entry is something other than 1.00 (meaning it shouldn't be green, but yellow instead), however, if you open the file manually, you can verify that it does in fact match the tweak file. Is that what you're seeing?

If so, sounds like a UI refresh problem, so it shouldn't be too hard to fix.

EDIT: Took a look around, it seems that is what you were talking about, so...fixed!

[teeny]

I do think there needs to be a bit more added to the License section of the readme.

This is about images and authors content.

Anyway... GPL doesn't cover images, which could highly irritate some folk, but make the legal folk happy they still have a job.

For example, a lot of the icons, screenies, and sutch I have donated to the project have been used elsewhere or modified without my consent.
Now having said that, let me explain a bit further, as to educate some of the less uneducated folk.

Valda has included a good bit of the images in WryeFlash.err.whatever.
Or let's say a picture needs corrected... noticed the quality diff(cough)(beat me to it)

It's not that I mind so much about the whole making bash universal thing or improvimg upon my work, but what if other people think that the whole DL is free reign, then that I could see that getting nasty someday...
probably not with bash, but still...
Anything I have donated to the bash project is free for the use in improving upon.(public domain/creative commons/etc)
Of course everyone likes a credit, but art is a sticky deal sometimes.

Many a starving artist isn't so starving anymore, if ya know what I mean....

What is needed is a few extra lines to the License section of the readme.
sutch as
any images included/donated/elsewise with this program are in the public domain/Creative commons/etc...

That way there is a simple effort to address these issues. Most people don't exactly realize this problem. Or that images aren't covered in the GPL.
They are Images, by an author, which has a choice as to what their content is licensed as.
Not EmbeddedPyFiles which can be compiled into [ code ](which the GPL covers)

Comments?

[Antony Holdsworth]

There's also something else we need from users:

Post a link to a screenshot of your PM Tab(if you use it)
And explain how you got it there...Does it still Work with the new...?

Well.....

[BlackaneseB]

From my most recent BOSS log:


With these tags WB completely ignores TamrielTravellersItemsVendor.esp which, with my limited understanding of tags, is to be expected as Delev and Relev only work on active or merged esp's (?) or am I missing something?

In the meantime I've reverted to those recommended by the author: Delev, NoMerge, Relev

Amazingly enough, I worked this out on my own. The original tags in the Description field of the mods tab - {{BASH:Delev,NoMerge,Relev}} - were the problem. Deleting them allows everything to work as expected.

[GLOW...]

http://img689.imageshack.us/img689/6195/eyehair.jpg

Using CBash.

In this, TIE is tagged with NPCFaces, Eyes, and Hair. Oblivifall is only tagged with Hair. So the eye record should have come through regardless, and since the hair record is identical to Oblivion.esm, it too should have been ignored. It's pretty minor, but would still be nice to get right.

[Curveballs On Phoenix]

This is probably a silly question, but I've just begin the installation of the WryePython 03a package and after a while I receive this message in Windows 7, 64-bit version.

There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.

Is this something that I need to fix first or can I ignore it? :unsure:

[Matthew Aaron Evans]

Hi, when I set the "toggle item prompt" amount in the bash options and rebuild, it no longer seems to work. I now always have to click on the arrows, etc. for each one I take. I had it set to 10 before the last time i saw it working but no more. I will try the stand alone prompt mod next to see if that one "sticks".

Also, I was reading the pages at TESIV:POSItive and in the Bash settings it say to not "show rings" because it can cause crashes... just wondering about some of those instructions I saw there.

Leonardo2, I use W7-64 and my install of WryePython 03a went fine. No errors. Perhaps try a fresh download of it?

[Karl harris]

Hi, when I set the "toggle item prompt" amount in the bash options and rebuild, it no longer seems to work. I now always have to click on the arrows, etc. for each one I take. I had it set to 10 before the last time i saw it working but no more. I will try the stand alone prompt mod next to see if that one "sticks".

Also, I was reading the pages at TESIV:POSItive and in the Bash settings it say to not "show rings" because it can cause crashes... just wondering about some of those instructions I saw there.

I assume you mean the "Inventory Quantity Prompt" under "Tweak Settings" of the Bashed Patch? Also, what do you mean by "doesn't stick"? I'm guessing you mean you've set it to like 6 or so, but if you try to pick up some stack of items less than 6, it still shows the popup menu asking how many? If that's the case, maybe someone more versed in GMSTs can tell us if this one is also stored in the save game file :shrug: Oh, and what version of WB are you using?

@Leonardo: works fine for me as well, but it 's hard to tell with windows (even the same versions). Maybe one of the installers it's running isn't installing correctly? I would check to make sure all of the components are installed.

@Arthmoor: I'll take a look at that one.

[lauren cleaves]

I have encountered a problem I hope can be salvaged. Basically my computer crapped itself, and the next time I loaded up WryeBash, the bottom half of my installers were shown as not activated. All of the resources of those mods were still present and accounted for, and the installer packages were all green, just without the plus sign. I chose 'install' and 'install missing', rebuilt my Patch, and everything seemed ok. Now Oblivion crashes whenever I load or start a game. If anybody has ideas, I'm open to suggestions.

Edit 1: I uinstalled Darnified UI, removed my Oblivion.ini, and launched Oblivion to make a new one. I quit out, and now Wrye Bash crashes when I launch it. Am I now royally screwed?

[Nick Jase Mason]

I have encountered a problem I hope can be salvaged. Basically my computer crapped itself, and the next time I loaded up WryeBash, the bottom half of my installers were shown as not activated. All of the resources of those mods were still present and accounted for, and the installer packages were all green, just without the plus sign. I chose 'install' and 'install missing', rebuilt my Patch, and everything seemed ok. Now Oblivion crashes whenever I load or start a game. If anybody has ideas, I'm open to suggestions.

Edit 1: I uinstalled Darnified UI, removed my Oblivion.ini, and launched Oblivion to make a new one. I quit out, and now Wrye Bash crashes when I launch it. Am I now royally screwed?

Try getting a bugdump from Wrye Bash (directions in the readme, or use the .BAT file provided, you may have to edit it to point to the right path). Also, as far a BAIN not remembering what was installed, try restoring your 'Installers.dat' from it's backup: rename 'Installers.dat.bak' to 'Installers.dat', default location is in your 'BASH Installers\Bash' directory.

@Arthmoor: Looking further, the only tag that should affect those records is the 'NPCFaces' tag, and that should only import changes. The Hair and Eyes tags wont actually make changes to the NPC_ records, just the RACE records. But yeah, since TIE has 'NPCFaces', and it changes the hair, hair length, and eyes, those should all get imported into the patch. Nothing from Oblivifall should be getting in, since it's not tagged 'NPCFaces' or 'NPCFacesFullImport'. I'm assuming the non-CBash version works fine? Either way, I'll take a crack at it.

[Kayleigh Williams]

Lojack, I already tried those solutions At least my archives and Pyffi'd BSAs are backed up, so reinstalling won't take more than 3-4 hours :brokencomputer:

[Oscar Vazquez]

Lojack, I already tried those solutions At least my archives and Pyffi'd BSAs are backed up, so reinstalling won't take more than 3-4 hours :brokencomputer:

Ok, but what does the bugdump give you?

[Maeva]

Sorry for the delay. Bugdump gives me a text file wherein all the characters are tiny boxes :facepalm: I have since resigned myself to spending this evening reinstalling. Thanks for the suggestions though.

[matt]

http://img689.imageshack.us/img689/6195/eyehair.jpg

Using CBash.

In this, TIE is tagged with NPCFaces, Eyes, and Hair. Oblivifall is only tagged with Hair. So the eye record should have come through regardless, and since the hair record is identical to Oblivion.esm, it too should have been ignored. It's pretty minor, but would still be nice to get right.

Ok, finally figured this one out. A good thing too, because the bug that caused it actually could cause problems with a LOT of other CBash patchers. I'm surprised it wasn't caught sooner.

[Jhenna lee Lizama]

The face/hair/eyes issue has been fixed.

There's still one old problem left that's not been addressed yet: http://img4.imageshack.us/img4/6349/scriptsissue.jpg

In that one, UOP has the scripts tag, as does TIE, but again, TIE has no change to carry.

[Cody Banks]

Where can I find documentation about the "bash.ini"? Specifically, what are valid values for text style?

[Becky Palmer]

The face/hair/eyes issue has been fixed.

There's still one old problem left that's not been addressed yet: http://img4.imageshack.us/img4/6349/scriptsissue.jpg

In that one, UOP has the scripts tag, as does TIE, but again, TIE has no change to carry.

I'm not sure what to say about this one. I've stuck in a bunch of debug prints, and everything seems to be working fine in the scripts patcher. I even tried reproducing the situation http://imageshack.us/photo/my-images/233/scriptso.png/.

So maybe I'm doing something wrong here in my testing, or there's something else going that I don't see. I'm assuming you already compared it in TES4Edit with your whole load order loaded up so I'm confused.