[Campbell]

Anyone know if the following from the readme has any meaning (the stuff about Wtxt)? AFAIK Wtxt is a purely Bash thing and books are written in a very simple cut down HTML.

yes it is the case - with the emphasis on the "? Wtxt formatting (applied if first line looks like == title ==" - otherwise similar stuff is done based on the html.
oh yes and I was meaning to ask you, since you're doing a whole ton of readme editing do you want me to do readme edits (ie info about new/missed tweaks)? or wait until you're down so as not to have to go back and forth looking for changes?
Pacific Morrowind

[Sammykins]

yes it is the case - with the emphasis on the "? Wtxt formatting (applied if first line looks like == title ==" - otherwise similar stuff is done based on the html.
oh yes and I was meaning to ask you, since you're doing a whole ton of readme editing do you want me to do readme edits (ie info about new/missed tweaks)? or wait until you're down so as not to have to go back and forth looking for changes?
Pacific Morrowind

Sorry, I was meaning of what use would it be, since Oblivion can't read Wtxt and there's no way of importing books from a text file that's written in Wtxt? I'm trying to get a feel for how someone would use that information. AFAIK it's totally useless, as the only thing that touches books in the Bashed Patch is DarNified Books, which is a preset option that can't be altered.

Other than that, I've only got the Mod Checker and Import FormIDs, Item Data and NPC Levels to transfer. And the Wizards stuff, but I'm going to leave that until I've worked on the formatting a bit, since it's fairly independent.

I'm working off the 295.2 readme, but I probably won't be done in time for the next release, so it's probably easiest if you update the readme as you normally do, then I'll just diff the 295.2 readme with the latest one and apply changes where necessary to mine. So long as you don't make any major changes that should be easy enough.

[victoria johnstone]

In these hard Unicode times I come with a kind of feature rerequest - while waiting for BAIT, I think it would be necessary for BAIN to implement the collapsible markers feature - before the Skyrim load orders get the size of the Oblivion ones - see http://sourceforge.net/support/tracker.php?aid=3127326

And concerning groups - I'd suggest to integrate them into the BAIN tab as well - and make it so that all mods are assigned the group of their marker if so specified - this will be a marker property (create group for this marker). Also maybe - promote them to tags - so many can apply to one mod - this will make sorting into the mods tab impossible though so maybe not a great idea - yes not a great idea at all. Anyway these can wait but I think the collapsible markers feature should be targeted to at most version 297 - at least before the CK comes out.

pleease :implores:

[Samantha Mitchell]

In these hard Unicode times I come with a kind of feature rerequest - while waiting for BAIT, I think it would be necessary for BAIN to implement the collapsible markers feature - before the Skyrim load orders get the size of the Oblivion ones - see http://sourceforge.net/support/tracker.php?aid=3127326

And concerning groups - I'd suggest to integrate them into the BAIN tab as well - and make it so that all mods are assigned the group of their marker if so specified - this will be a marker property (create group for this marker). Also maybe - promote them to tags - so many can apply to one mod - this will make sorting into the mods tab impossible though so maybe not a great idea - yes not a great idea at all. Anyway these can wait but I think the collapsible markers feature should be targeted to at most version 297 - at least before the CK comes out.

pleease :implores:

EDIT: Rewritten to sound a little less harsh.

Regarding groups, I think they're in need of a refocus. They were a part of BALO, but since that is disabled by default and due for removal they've been left hanging, somewhat disconnected from the rest of Bash.

The best refocus I can come up with is to make them a more general feature - like an abstract class that is then used to define other classes. Eg.

Group
- Exclusion Group
- Load Group
- Package Group
- Plugin Group

A group can then be an arbitrary set of plugins or packages (but not both). The contents of the group can be edited (addition or removal) and the group renamed or deleted.

Exclusion Groups display warnings when more than one of their set is installed. (Exclusion Groups already exist, but their implementation is poor - the whole "rename the plugins" thing is a bad idea. It's a Bash-only feature, it shouldn't require filename changes - Bash should be able to store the metadata itself.)

Load Groups list which plugins or packages should be active or installed together. (Currently called Load Lists, but these lack the ability to edit a list's contents.)

Package Groups are arbitrary sets of packages, which are marked in the package list by a marker package.

Plugin Groups are arbitrary sets of plugins. (These are currently known as Groups.)

--------------------------

On an unrelated note, I'd like to question the use of Mod Checker rulesets. The only one present in Bash by default is for Cobl. These rulesets sound useful, but I think they've been superceded by BOSS, so I'd like to request their gradual removal (like BALO).

I know that the whole "competing tools' features" thing might come into play, but BOSS is far more effective than rulesets are at information dissemination nowadays. Also, Cobl isn't reliant on Wrye Bash to function, so while the two go hand-in-hand a lot, there's no reason for the two to have any more of a "special relationship" than WB and BOSS do.

Looking through the functionality of rulesets, there's a couple of things I can see that BOSS cannot currently do: tell if a plugin is active or not, and tell if a plugin is merged into the Bashed Patch or not. However, these are not impossible things. As BOSS steadily mutates away from just being a plugin sorter, they may be added. Active status detection has been on my maybe-to-do list for a very long time anyway. In any case, if the WB team thinks that the functionality is important, but agrees with my assessment, then I can add it to my to do list and have access to the info through the BOSS API added.

The above isn't to say that the information shouldn't be present in the Mod Checker - just that as a common platform for modders to use, rulesets have fallen flat. Heck, I didn't know they existed until I'd got to that section of the readme during my rewrite. It just strikes me that they're one of the things that were put in as a proposal to see where it would go, but it didn't end up going anywhere, and IMHO such things are better off removed, as they detract from the rest of Wrye Bash a little. They're just more code, and more lines in the readme, for a feature that isn't much use.

Heh, the above reads one part sales pitch, one part complaint and one part request to me.

[Harinder Ghag]

Regarding groups, I think they're in need of a refocus. They were a part of BALO, but since that is disabled by default and due for removal they've been left hanging, somewhat disconnected from the rest of Bash.

The best refocus I can come up with is to make them a more general feature - like an abstract class that is then used to define other classes. Eg.

Group
- Exclusion Group
- Load Group
- Package Group
- Plugin Group

A group can then be an arbitrary set of plugins or packages (but not both). The contents of the group can be edited (addition or removal) and the group renamed or deleted.

Exclusion Groups display warnings when more than one of their set is installed. (Exclusion Groups already exist, but their implementation is poor - the whole "rename the plugins" thing is a bad idea. It's a Bash-only feature, it shouldn't require filename changes - Bash should be able to store the metadata itself.)

Load Groups list which plugins or packages should be active or installed together. (Currently called Load Lists, but these lack the ability to edit a list's contents.)

Package Groups are arbitrary sets of packages, which are marked in the package list by a marker package.

Plugin Groups are arbitrary sets of plugins. (These are currently known as Groups.)

Actually this sounds pretty good - I mean the EG and LO group enhancements - but later I guess - as the functionality is already adequate.
What I meant to say was that groups (mod groups) were working fine and they were very useful in checking load order, testing etc (gives a much more clear picture of one's LO - example groups : UOP, UL, FCOM, DLC - then sort by group and suddenly one has a very clear picture of one's LO - I have often been able to single out problematic plugins this way). What I suggested with markers (unclearly) was to be able to create plugins groups by specifying that all mods that get installed and are under the marker UL in BAIN will automatically be assigned to plugin group UL (if one checks create group from this marker) - not mixing packages and plugins in the same group. But that is just an enhancement.
The fact that groups were introduced with BALO and that BALO is (obviously) deprecated by BOSS is true but irrelevant to mod groups' usefulness - personally I know nothing on BALO but have started using groups since the first minute I realised they existed - trying to manage my big LO. Maybe you got the impression they are related to BALO via the Readme you are going through but I hope I gave you an insight of why and how they are useful. Let's say, BALO left something useful behind.

collapsible markers for president

[sara OMAR]

In these hard Unicode times I come with a kind of feature rerequest - while waiting for BAIT, I think it would be necessary for BAIN to implement the collapsible markers feature - before the Skyrim load orders get the size of the Oblivion ones - see http://sourceforge.net/support/tracker.php?aid=3127326

I know, I really do - I seems like it would be very easy to do something like this. Unfortunately, it's not. In fact, it's quite hard - technical jargon: we'd have to change the type of control used to display the data. This in turn, requires a different API for interacting with that control, a different way of adding new items to the control, removing items, selecting items, etc. In short, a very large code rewrite. Then, due to collapsible trees, now Drag'n'Drop has to be reworked, Ctrl+Up/Ctrl+Down, etc. So yes, I can be done, and it would be useful - but at least for me - the amount of work necessary is not worth it, especially when I have more important things in Wrye Bash to work on. And additionally, BAIT already works with this way (whenever myk gets back ) so I hate to have to reproduce work that's already done.

So, I'm just saying, you won't see it from me unless the more important things (in my mind) get taken care of first - Full Skyrim record support, bugs, CBash 0.6 working fully, etc.

On an unrelated note, I'd like to question the use of Mod Checker rulesets. The only one present in Bash by default is for Cobl. These rulesets sound useful, but I think they've been superceded by BOSS, so I'd like to request their gradual removal (like BALO).

I know that the whole "competing tools' features" thing might come into play, but BOSS is far more effective than rulesets are at information dissemination nowadays. Also, Cobl isn't reliant on Wrye Bash to function, so while the two go hand-in-hand a lot, there's no reason for the two to have any more of a "special relationship" than WB and BOSS do.

I'd be fine with this. Also, while true Cobl doesn't require Wrye Bash, it is very useful - for the Filter patch and the II stuff included in it. Anyway, I do agree on the point that there are quite a few things included in Wrye Bash, that look to be an attempt by Wrye to create a useful tool for modders, but just never got off the ground really. I think these things would be:
- BALO
- Rule Sets
- Exclusion Groups
- Probably more things too

All could really be removed without any harm - because no one uses them, or there are better alternatives (BOSS).

[Dewayne Quattlebaum]

I know, I really do - I seems like it would be very easy to do something like this. Unfortunately, it's not. In fact, it's quite hard - technical jargon: we'd have to change the type of control used to display the data. This in turn, requires a different API for interacting with that control, a different way of adding new items to the control, removing items, selecting items, etc. In short, a very large code rewrite. Then, due to collapsible trees, now Drag'n'Drop has to be reworked, Ctrl+Up/Ctrl+Down, etc. So yes, I can be done, and it would be useful - but at least for me - the amount of work necessary is not worth it, especially when I have more important things in Wrye Bash to work on. And additionally, BAIT already works with this way (whenever myk gets back ) so I hate to have to reproduce work that's already done.

So, I'm just saying, you won't see it from me unless the more important things (in my mind) get taken care of first - Full Skyrim record support, bugs, CBash 0.6 working fully, etc.

I had to do this about 3/4 the way through writing the User Rules Editor for BOSS. Not particularly fun.

[Courtney Foren]

Yep, not fun at all

On another note: I'm pretty certain I've tracked down the PBash leveled list merging bug. Could I have those experiencing it retest with the latest svn trunk?

[Rhi Edwards]

On another note: I'm pretty certain I've tracked down the PBash leveled list merging bug. Could I have those experiencing it retest with the latest svn trunk?

Hmm I've got 50'ish more records, but otherwise no change with the leveled lists with pbash. Still broken.

[Yonah]

Trying to apply any of the ini tweaks provided by Bash to the Oblivion.ini fails with the following error. Tweaks for inis other than Oblivion.ini seem to be working, but only have one non-Oblivion.ini tweak to test.
From what I can understand this is not an error caused by permissions but since it seems to apply to Oblivion.ini only, and since that is saved in a different location to the other inis, please note that I am on Win7 (64-bit), and while the ini itself is not write protected, the folder it is in is protected (and I cannot remember how to force the protection off).
Many Thanks!

Traceback (most recent call last):  File "E:\Bethesda\Oblivion\Mopy\bash\basher.py", line 10748, in Execute	iniList.data.ini.applyTweakFile(file)  File "E:\Bethesda\Oblivion\Mopy\bash\bosh.py", line 3609, in applyTweakFile	IniFile.applyTweakFile(self,tweakPath)  File "E:\Bethesda\Oblivion\Mopy\bash\bosh.py", line 3323, in applyTweakFile	self.saveSettings(ini_settings,deleted_settings)TypeError: saveSettings() takes exactly 2 arguments (3 given)

[jason worrell]

Query: What are the forward/back arrows for on the Mod Checker? They've never done anything for me and I can't find mention of them in the readme.

[SamanthaLove]

Trying to apply any of the ini tweaks provided by Bash to the Oblivion.ini fails with the following error. Tweaks for inis other than Oblivion.ini seem to be working, but only have one non-Oblivion.ini tweak to test.
From what I can understand this is not an error caused by permissions but since it seems to apply to Oblivion.ini only, and since that is saved in a different location to the other inis, please note that I am on Win7 (64-bit), and while the ini itself is not write protected, the folder it is in is protected (and I cannot remember how to force the protection off).
Many Thanks!

Usually it's better if you state that you're using the SVN, and what rev. It helps track these things down better. Luckily, I was recently working on that section, so I spotted that fact quickly. Try the latest revision now, that bug is fixed.

Query: What are the forward/back arrows for on the Mod Checker? They've never done anything for me and I can't find mention of them in the readme.

The control used for displaying HTML in the Mod Checker is an ActiveX browser control - the forward and back buttons are true web browser forward and back buttons. Not much use really when navigating the Mod Checker itself (changing options and such don't result in a 'new' page, just the same one refreshed). Only use the really come in is when links get provided in the Mod Checker - you can navigate back to the original page.

[Spaceman]

Usually it's better if you state that you're using the SVN, and what rev. It helps track these things down better. Luckily, I was recently working on that section, so I spotted that fact quickly. Try the latest revision now, that bug is fixed.

Sorry, forgot to mention that I am using the SVN.
Also, I can confirm that ini tweaks for Oblivion.ini now work again. Many Thanks for the quick fix!

[Emma Louise Adams]

Hmm I've got 50'ish more records, but otherwise no change with the leveled lists with pbash. Still broken.

Ok, found where two mistakes in my "fix" were still stopping it from working, but looked fixed in my test case. A made a new test case, fixed those errors, and everything looks to be good now. I'll wait for confirmation, but I'm going ahead and wrapping this into the 295 branch

Also, I can confirm that ini tweaks for Oblivion.ini now work again. Many Thanks for the quick fix!

Great, thanks

Assuming the LL bug come back as fixed - I'm ready for a 295.3 release. Last call for bugs in the 295 branch - I'll fix or at least address those given before making an actual release.

[Jani Eayon]

Ok, found where two mistakes in my "fix" were still stopping it from working, but looked fixed in my test case. A made a new test case, fixed those errors, and everything looks to be good now. I'll wait for confirmation, but I'm going ahead and wrapping this into the 295 branch

Actually have more records now in the latest svn bash patch, that's an improvement. Though the leveled lists is still funky, it's starting to mess with my head. Only the leveled spells are totally fine. For creatures and items, there are a lot of lists that are in the new pbash patch but not the old one, and vice versa as well. No clue which is right. A lot of the lists that exist in both have different records imported, looks like the old one is getting them from the FCOM plugins as intended while the new one is getting them from the original mods. Example:

http://www.darkcreations.org/forums/uploads/gallery/album_12/gallery_19_12_89840.jpg - Old patch importing from FCOM_Convergence.esp and Creature Diversity.esp
http://www.darkcreations.org/forums/uploads/gallery/album_12/gallery_19_12_180063.jpg - New patch importing from OOO's esp and Creature Diversity.esp

Sorry if this is a bit confusing. I'm no expert, just eye-balling the differences.

For the 295.3 release, it'd be nice if the http://www.gamesas.com/topic/1236811-relz-wrye-bash/page__view__findpost__p__18753537 and http://www.gamesas.com/topic/1324506-relz-wrye-bash/page__view__findpost__p__19940664 issues can be fixed. I have to manually edit the bash patch everytime it's rebuilt because of those. Of course since they are both minor it's ok if it's delayed.

[Dezzeh]

Indeed frustrating. Could I ask you to zip up your old bashed patch, new bashed patch, and any plugins modifying that specific record, them PM me a link to it (i really don't want to download the MB's of data required to setup FCOM).

As for the detect life and hungers problem: are those CBash or PBash bugs? detect life looks like PBash is doing it fine, if I read your screenshot right. I'm only really touching PBash problems this release.

[N Only WhiTe girl]

Ok, pm'ing you in a few minutes.

The detect life and hungers are both pbash bugs, the screenie was after I had manually edited the pbash patch. Detect life also affects cbash, tested that at that time.

[ILy- Forver]

Ok, I'll see if it's an easy fix.

Edit: Alright, finally found the source of our LL problems, a really stupid bug - indentation error (pretty easy to miss when reading the code). Leveled Lists Patcher should work fully again now.

As for the detect life bug - I looked over the code and I can't really see what's wrong. As this is something that's been around for a while, it's a lot harder for me to track down, since I don't have a timeframe to go off of for when it was (if it ever was) working right, to when it broke. Similar thing for the Hunger's problem. Both involve the same patcher (Graphics), but I'm still looking at the Hunger's one, since it's a bit simpler.

[u gone see]

295 branch, leveled lists working fine now.

Actually have one more inexplicable bug regarding two specific texture replacers, but that one makes no sense to me and it's been there since forever yet no one else has mentioned it. Could be just me, think I'll leave that until 295.3 is released and I've looked into it some more.

[Kara Payne]

295 branch, leveled lists working fine now.

Actually have one more inexplicable bug regarding two specific texture replacers, but that one makes no sense to me and it's been there since forever yet no one else has mentioned it. Could be just me, think I'll leave that until 295.3 is released and I've looked into it some more.

Well, I've had these bugs, do you have the same issue?
|

[Jesus Sanchez]

Well, I've had these bugs, do you have the same issue?
|

The missing lines with Cobl Book was fixed a few SVN ago, never got the chinese character thingy. Leveled Flag, actually just told Lojack about that. I had that for two leveled lists but it looks like the latest svn is correct in this case, though someone knowledgeable about this should confirm that.

[Brandon Bernardi]

I'll look at the flags bit, see if it makes sense. Cobl Books got fixed, correct (I'll double check that the fix got into the 295 branch though). The Chinese in your example I'm assuming is getting pulled in due to a translation of 'Endurance'. Maybe here it's not a good idea to translate that - since that translated string is used both here and in the UI, I'll have to split it out.

Edit: Also, I'm having a hard time finding the FCOM Hunger's plugin, which download is it a part of?

Edit 2: And, could one of you guys point out which mods are involved in the LL's that end up with different flags? I didn't find any in the test patch built off the stuff omeletted sent me.

[Terry]

Hunger_SI.esp: I think I know how to fix this, unrelated to wrye bash though. That's because MMM-Cobl is mergeable, so Bash merges all records from MMM-Cobl, this makes FCOM_HungerSI's record replaced with MMM-Cobl's one. The way to deal with is to tag MMM-Cobl with NoMerge and other tags (Delev, Invent?) Then Bash will only import leveled list and invent records, the graphics(texture) one from Hunger_SI won't be affected.

Leveled List:
http://www.bild.me/bild.php?file=7320895LL001.png|http://www.bild.me/bild.php?file=8927399LL002.png|http://www.bild.me/bild.php?file=6937228LL003.png

PS: It seems that I still have the Cobl Book error, no time to test now, will test again later.

[Sarah Bishop]

Leveled List:
http://www.bild.me/bild.php?file=7320895LL001.png|http://www.bild.me/bild.php?file=8927399LL002.png|http://www.bild.me/bild.php?file=6937228LL003.png

PS: It seems that I still have the Cobl Book error, no time to test now, will test again later.

Sweet, I tracked down the LL flags bug with those screens, should be fixed now as well. I believe all the LL bugs should be fixed now.

As for the Cobl book - is it the same as in the screens you posted? I had fixed a bug that reulted in the first couple lines or so getting garbled (and I doubled checked - that fix is in the 295 branch as well).

[Christine]

Try again, and found Cobl Book works now. Except some strings are translated. However, I can wait for next release's fix.