[asako]

Well I searched and did not find anyone else reporting this issue.

I've recently had two instances where token rings in mods were made visible, playable and quite valuable.

One was Dungeon Actors have torches the other was the newer enemy actors use powers.

Then it hit me that it was because of the all clothes playable tweak in the bash patch. Changed that and now those tokens are not visible any longer.

Is that what that was!
I noticed the same with AFK_Weye, and The Ayleid steps (I think it was.)

So it looks that perhaps the "all clothes" is erroneously including all tokens as well.

[Sophh]

So it looks that perhaps the "all clothes" is erroneously including all tokens as well.

But since tokens generally are uplayable clothing items, it's not easy for Wrye Bash to exclude them. If so, Wrye Bash would have to look for something in order to exclude them. My tokens have zero weight, zero value and includes "token" in its name. I think that's a good general rule which Wrye Bash could look for in order to keep them unplayable, but evidently some mods add tokens with non-zero value too.

[lolli]

That would be great!

Still repackaging many older mods as I do - I'd like the ability to add those to a text file or wherever they are stored.

yep I'm looking into how I can best code it... probably putting this for not this coming but next version...

Well I searched and did not find anyone else reporting this issue.

I've recently had two instances where token rings in mods were made visible, playable and quite valuable.

One was Dungeon Actors have torches the other was the newer enemy actors use powers.

Then it hit me that it was because of the all clothes playable tweak in the bash patch. Changed that and now those tokens are not visible any longer.

Is that what that was!
I noticed the same with AFK_Weye, and The Ayleid steps (I think it was.)

So it looks that perhaps the "all clothes" is erroneously including all tokens as well.

hint hint: """(betaish... sometimes inadvertantly sets things that really shouldn't be playable - use at own risk... but shouldn't cause any harm, just taking off say a werewolfs head doesn't look good)
""" (from first post last thread)... tokens are almost universally clothes and I have some constraints on it but if you give me the name(s) of other incorrectly set playable items I can easily add in a constraint for those too

But since tokens generally are uplayable clothing items, it's not easy for Wrye Bash to exclude them. If so, Wrye Bash would have to look for something in order to exclude them. My tokens have zero weight, zero value and includes "token" in its name. I think that's a good general rule which Wrye Bash could look for in order to keep them unplayable, but evidently some mods add tokens with non-zero value too.

exactly Currently I have it just checking for 'token' in the name... adding in some other checks for the next version (and suggestions welcome).

[Gemma Archer]

Well In wasn't complaining - just reporting.

I guess it is a bit late in the game to tag for tokens huh?

That one confounded me and I almost got down to editing mods.

[Dustin Brown]

Well In wasn't complaining - just reporting.

yep I understand, I knew you weren't complaining (and as always I appreciate the reports)

I guess it is a bit late in the game to tag for tokens huh?

I'm not quite sure I follow?
Pacific Morrowind

[celebrity]

Oh well I'm not sure I know now either - just woke up.

never mind - I had some vague notion that tagging the mod with tokens would be an answer but that it is too late to start that.

Wow - a little restraint and I may yet make sense.

[Susan Elizabeth]

Haha,
it has taken me several years to get Wrye Bash to work after it quit on me when I tried it the first time.
But now, it actually works an I am able to fully enjoy my mod list to its full extend.

So yeah, a belated thank you for this ingenious mod.

[Marcus Jordan]

hint hint: """(betaish... sometimes inadvertantly sets things that really shouldn't be playable - use at own risk... but shouldn't cause any harm, just taking off say a werewolfs head doesn't look good)
""" (from first post last thread)... tokens are almost universally clothes and I have some constraints on it but if you give me the name(s) of other incorrectly set playable items I can easily add in a constraint for those too

exactly Currently I have it just checking for 'token' in the name... adding in some other checks for the next version (and suggestions welcome).

Cool. Thanks for explaining TheNiceOne and PacificMorrowind.
(And thanks Psymon; at least I won't be scratching my head about where those tokens suddenly came from any more. :clap: )

[BrEezy Baby]

Some feature requests to improve this already wonderful program:

--
1. I think that Bash should combine the lists of bashed patch tags from the mod description and the BOSS masterlist. Currently it ignores the masterlist if there are tags in the file description. A simple syntax to allow forbidding tags from the masterlist.txt would also be very useful, such as an exclamation mark before the tag (i.e. !C.Water, or something more visible such as NOT(C.Water) ).

As an example, here are the current masterlist.txt tags for the Unofficial Oblivion Patch:
{{BASH:C.Climate,C.Light,C.Owner,Delev,Invent,Names,Relev,Stats,Relations}} and remove the C.Water tag.

Instead of a mere suggestion to remove C.Water, I'd be better to have:
{{BASH:C.Climate,C.Light,C.Owner,Delev,Invent,Names,Relev,Stats,Relations,!C.Water}}

(Of course the example is not that good since the UOP is updated often, by people who understand bash tags very well.)

The tags used in the end would be the set of the masterlist plus those in the description, minus whatever has an exclamation point.
The rationale behind this is that BOSS usually evolves faster than mods regarding bash tags and the like.

Scenario: a mod has {{BASH:Delev,Relev}} in it's description and we later discover it would benefit from the Scripts tag, but the mod author has forbidden redistribution. There are only two solutions: everybody manually updates their file, or the Boss team changes one line of text. Guess which one I prefer.

--
2. OBMM allows you to see which OMOD a file comes from; it would be very helpful to see from the Bash mod tab from which BAIN package (if any) an esp/esm has been installed. In case of packages installing the exact same esp/esm, the one lower in the package list would be seen as the origin of the file.

The idea behind this is that, with hundreds of mods and bain packages, you sometimes want to uninstall a mod but you only know its esp name, not it's package, and you waste time looking for the right zip file.

2a. A tool to make a list of every file in your Data directory and see which ones are from some BAIN package and which ones are a leftover of some failed operation, would be nice.

--
3. BAIN should optionally show you a dialog box before every operation, telling you which files it's gonna install, erase, overwrite, etc. There's no undo functionality, so that's the next best thing.

--
4. Being able to export and import to/from a text file your active BAIN packages together with their configured files (the list of configured subpackages and filtered esp/m) would be very useful. Not only as a backup (I lost my database several times; of course the backup got erased as I opened and closed Bash several times to try and identify the problem), but also to share with other people.

--
5. I wish we were able to open readmes, screenshots and so on from the Installers tab by clicking them in the Configured Files list. Or at least show the file in Explorer.

--
6. To manage hundreds of BAIN packages, I think we need something like a tagging/categorizing system. For extra cool points, add a button/menu option to retrieve tags and categories from TESNexus, for files that have a numerical code at the end.

--
7. When you select a BAIN sub-package, it's often hard to see which data files and which .esp/.esm you've just selected, because they're added to lists that can get huge. To fix this, files belonging to the currently highlighted subpackage should appear in red or should stand out in some way, both in the tabs above and in the Esp/m filter.

--
8. When you click around and tick checkboxes to configure a BAIN package, its name in the package list stops being highlighted. Together with occasional scrolling problems and a large list, it makes finding the package again when you want to install annoying.

--
9. The Export Scripts option is nifty, but it doesn't prompt you for a place to save the exported scripts. I finally found out that it creates a subfolder named after the mod in Oblivion\Data\Bash Patches and puts the exported files in there. Unhelpful to say the least, and this didn't seem to be documented anywhere.

Thanks for your hard work; hopefully some of these suggestions will benefit the community.

[brian adkins]

Wow! What a wonderfully thoughtful list of suggestions. 80% of them are thing I've come across and momentarily wished were different, but I never had the time/attention span to think them out, let alone articulate them clearly!

The only item on your list that I either don't understand or don't agree with is

• 3. BAIN should optionally show you a dialog box before every operation, telling you which files it's gonna install, erase, overwrite, etc. There's no undo functionality, so that's the next best thing.

True, there's no dialogue box, but there is a series of tabs that do show exactly what will be installed, what will be overwritten, etc. Also, uninstall/anneal is your undo button. Am I missing what you're describing here?

I would indeed love to see as many of these suggestions implemented as can be. My favorite utility just keeps getting better!

gothemasticator

[Mimi BC]

Some feature requests to improve this already wonderful program:

--
1. I think that Bash should combine the lists of bashed patch tags from the mod description and the BOSS masterlist.

No doubt meant well by this, but I'd be against doing this as it would overrule a mod author who has explicitly added tags to their ESP. Except in known cases (like the UOP C.Water fiasco) these tags should rarely be changed, so auto-merging things from the BOSS list isn't necessarily a good idea.

[Alexander Lee]

Some feature requests to improve this already wonderful program:

--
1. I think that Bash should combine the lists of bashed patch tags from the mod description and the BOSS masterlist. Currently it ignores the masterlist if there are tags in the file description. A simple syntax to allow forbidding tags from the masterlist.txt would also be very useful, such as an exclamation mark before the tag (i.e. !C.Water, or something more visible such as NOT(C.Water) ).

very true... I'll look into it

most I think are good (quite a few are very hard though for my wimpy python skills)... only one that right now just quickly looking that I don't see the need for is the same one as gothemasticator...

9. The Export Scripts option is nifty, but it doesn't prompt you for a place to save the exported scripts. I finally found out that it creates a subfolder named after the mod in Oblivion\Data\Bash Patches and puts the exported files in there. Unhelpful to say the least, and this didn't seem to be documented anywhere.

added in prompt, thanks (in svn and will be included in the next release)
Pacific Morrowind

[Emzy Baby!]

No doubt meant well by this, but I'd be against doing this as it would overrule a mod author who has explicitly added tags to their ESP. Except in known cases (like the UOP C.Water fiasco) these tags should rarely be changed, so auto-merging things from the BOSS list isn't necessarily a good idea.

yes but what about new tags for old mods (for example: example.esp from 2007 and no redist readme and not being updated has tags relev and delev, but was made before the existance of the actor animations tag but could really use it... seems better to Bash combine the two lists... it wouldn't really overrule but rather if not in esp but in masterlist be added, and in esp header be added.
Pacific Morrowind

[Horror- Puppe]

yes but what about new tags for old mods (for example: example.esp from 2007 and no redist readme and not being updated has tags relev and delev, but was made before the existance of the actor animations tag but could really use it... seems better to Bash combine the two lists... it wouldn't really overrule but rather if not in esp but in masterlist be added, and in esp header be added.
Pacific Morrowind

Yep, exactly my thought. New bash tags come out that would benefit old mods that already have a bash tag list in the description, and the best place to add those new tags is in the boss masterlist.

Since the masterlist.txt is updated often, most of the time the suggested bash tags will be the same as in the .esp header anyways, and an accidental overriding should get fixed quickly.

[SexyPimpAss]

(Sorry, double post)

The only item on your list that I either don't understand or don't agree with is

• 3. BAIN should optionally show you a dialog box before every operation, telling you which files it's gonna install, erase, overwrite, etc. There's no undo functionality, so that's the next best thing.

True, there's no dialogue box, but there is a series of tabs that do show exactly what will be installed, what will be overwritten, etc. Also, uninstall/anneal is your undo button. Am I missing what you're describing here?

I think the situation that prompted this idea was when I irremediably lost my BAIN database. I wanted to use "uninstall" on some mods but I wasn't sure of what exactly it was gonna remove: configured files only? all files in the package? whether the CRCs match or not? I remember having a hard time figuring this out from the docs, so I would have liked to see a list of files that were gonna be erased.

[Nathan Barker]

yes but what about new tags for old mods (for example: example.esp from 2007 and no redist readme and not being updated has tags relev and delev, but was made before the existance of the actor animations tag but could really use it... seems better to Bash combine the two lists... it wouldn't really overrule but rather if not in esp but in masterlist be added, and in esp header be added.

Provided you aren't going to lose the existing tags that come with the mod, I suppose it doesn't matter. I just don't think it's appropriate to countermand what a mod author is setting just because the BOSS list says otherwise. Despite plenty of us knowing which tags work best, BOSS is not perfect.

[Soraya Davy]

Provided you aren't going to lose the existing tags that come with the mod, I suppose it doesn't matter. I just don't think it's appropriate to countermand what a mod author is setting just because the BOSS list says otherwise. Despite plenty of us knowing which tags work best, BOSS is not perfect.

It's not imposing anything on the author, since the decision of using BOSS... or not lies with the players. If they do, it seems to me that allowing them to benefit from up-to-date bash tags without having to check their esps one by one is a good feature.
Most of the time the two lists should just be merged; I envision that the NOT(tag) feature [which I admit, is more controversial] would just be used to temporarily fix a big blunder.

And no, BOSS is not perfect, but it's easy to improve. If a mod author comes by the boss thread and says an authoritative word about how and where his mod should appear in the masterlist.txt, the changes will probably be in on the next day.

--
On a very different topic:

I imagine it's there so that the installer packages don't add to the problem of the game bogging itself down looking through all the files in the Oblivion dir. http://www.gamesas.com/index.php?showtopic=941296

If this is true, I've always wondered why Bash doesn't move docs (and "hidden" files) to a directory that's not under Oblivion\Data. Optionally, it could also do something fancy such as automatically moving inactive .esp and .esm files to a different folder, and putting them back in Oblivion\Data when you check them as activated in Bash. Of course it'd have to be transparent for the user. And it might make the situation a bit confusing when also using OBMM, or when Wrye Bash crashes and the poor user who wants to fix stuff manually wonders where his files went.

[Ruben Bernal]

I got this error message when trying in install a mod via BAIN:

Traceback (most recent call last):  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\basher.py", line 5735, in Execute	self.data.install(self.selected,progress,last,override)  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 11025, in install	installer.install(archive,destFiles,self.data_sizeCrcDate,SubProgress(progress,index,index+1))  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 10303, in install	self.unpackToTemp(archive,dest_src.values(),SubProgress(progress,0,0.9))  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 10283, in unpackToTemp	progress(index,_("%s\nExtracting files...\n%s") % (archive.s, maExtracting.group(1).strip()))  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bolt.py", line 1402, in __call__	self.parent(self.baseFrom+self.scale*state/self.full,message)  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bolt.py", line 1402, in __call__	self.parent(self.baseFrom+self.scale*state/self.full,message)  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bolt.py", line 1373, in __call__	self.doProgress(1.0*state/self.full, self.message)  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\balt.py", line 898, in doProgress	self.dialog.Update(int(state*100),message)  File "C:\Program Files (x86)\Python26\lib\site-packages\wx-2.8-msw-unicode\wx\_windows.py", line 2966, in Update	return _windows_.ProgressDialog_Update(*args, **kwargs)  File "C:\Program Files (x86)\Python26\lib\encodings\cp1252.py", line 15, in decode	return codecs.charmap_decode(input,errors,decoding_table)UnicodeDecodeError: 'charmap' codec can't decode byte 0x90 in position 87: character maps to <undefined>

EDIT:
I also got this error when trying to read the Bashed Patch readme:

Traceback (most recent call last):  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\basher.py", line 8184, in Execute	DocBrowser().Show()  File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\basher.py", line 3646, in __init__	self.htmlText = wx.lib.iewin.IEHtmlWindow(self, -1, style = wx.NO_FULL_REPAINT_ON_RESIZE)  File "C:\Program Files (x86)\Python26\lib\site-packages\wx-2.8-msw-unicode\wx\lib\iewin.py", line 57, in __init__	id, pos, size, style, name)  File "C:\Program Files (x86)\Python26\lib\site-packages\wx-2.8-msw-unicode\wx\lib\activex.py", line 103, in __init__	self._ax = cc.GetBestInterface(unknown)  File "C:\Program Files (x86)\Python26\lib\site-packages\comtypes\client\__init__.py", line 103, in GetBestInterface	mod = GetModule(tlib)  File "C:\Program Files (x86)\Python26\lib\site-packages\comtypes\client\_generate.py", line 112, in GetModule	mod = _CreateWrapper(tlib, pathname)  File "C:\Program Files (x86)\Python26\lib\site-packages\comtypes\client\_generate.py", line 153, in _CreateWrapper	fullname = _name_module(tlib)  File "C:\Program Files (x86)\Python26\lib\site-packages\comtypes\client\_generate.py", line 32, in _name_module	(str(libattr.guid)[1:-1].replace("-", "_"),  File "C:\Program Files (x86)\Python26\lib\site-packages\comtypes\GUID.py", line 44, in __unicode__	_CoTaskMemFree(p)  File "_ctypes/callproc.c", line 925, in GetResultWindowsError: [Error -65535] Windows Error 0xFFFF0001

Also, Mart's Monster Mod - Resized Races is tagged with body tags, but isn't being imported into the bashed patch. Let me know what info you need.

[Shae Munro]

I'm getting error with every mod I click on.

EDIT:

Closed Bash and reloaded it and the errors when clicking on mods went away. Still, something is wrong.

[{Richies Mommy}]

If this is true, I've always wondered why Bash doesn't move docs (and "hidden" files) to a directory that's not under Oblivion\Data. Optionally, it could also do something fancy such as automatically moving inactive .esp and .esm files to a different folder, and putting them back in Oblivion\Data when you check them as activated in Bash. Of course it'd have to be transparent for the user. And it might make the situation a bit confusing when also using OBMM, or when Wrye Bash crashes and the poor user who wants to fix stuff manually wonders where his files went.

There's no "if" about it. It's very much true and can be easily verified. That thread I linked to is what gave rise to the ghosting feature in Bash. So something has already been coded to work around it.

[suzan]

I got this error message when trying in install a mod via BAIN:

EDIT:
I also got this error when trying to read the Bashed Patch readme:

I would suspect (but not 100% sure) that that is due to you using the unicode version of wx-python rather than the ANSI as linked/stated required in the first post.

Also, Mart's Monster Mod - Resized Races is tagged with body tags, but isn't being imported into the bashed patch. Let me know what info you need.

it has to be merged as well - race section requires mods to be merged or active to do anything to/from said mod.
Pacific Morrowind

[Deon Knight]

I would suspect (but not 100% sure) that that is due to you using the unicode version of wx-python rather than the ANSI as linked/stated required in the first post.

Well I haven't had any problems at all, until the most recent mod package I added to BAIN. I'm not sure what wx-python version I'm using, but don't you think I'd have other errors before this this if it's the wrong version?

it has to be merged as well - race section requires mods to be merged or active to do anything to/from said mod.
Pacific Morrowind

Ah. Gotcha.

[Alister Scott]

File "C:\Program Files (x86)\Python26\lib\site-packages\wx-2.8-msw-unicode\wx\lib\activex.py

You're using the unicode version. You need to uninstall that and put in the proper ANSI version. Things like this are generally unpredictable so you may simply have been lucky to dodge issues before now.

[Lily Something]

You're using the unicode version. You need to uninstall that and put in the proper ANSI version. Things like this are generally unpredictable so you may simply have been lucky to dodge issues before now.

Yeah, I checked it. You're right, sir. I'm using the unicode. I'll change it.

[Spooky Angel]

There's no "if" about it. It's very much true and can be easily verified. That thread I linked to is what gave rise to the ghosting feature in Bash. So something has already been coded to work around it.

Sorry for insisting, but there's still something that seems contradictory to me.

Which kind of files slow down Oblivion if they are in the game's directory? .esp only? To put things back in context, you said above that the Bash Installers directory was put outside Oblivion\Data to avoid slowdowns.

Therefore it seems that either:
1. Ghosting is useless, because ANY file under Oblivion\Data slows Oblivion down. "Ghosted" files should be moved elsewhere, not renamed, if you want to see any performance gain.
OR
2. Only .esp(/.esm) files slow Oblivion down, therefore putting the Bash Installers somewhere else than under Oblivion\Data was useless: it only contains .zip, .7z and .rar files which shouldn't slow down Oblivion.

Edit: OK, I (re-)read part of that thread you linked to, and it reminded me that there are two separate problems, one with excess .esp files, the other (which seems less confirmed) with ANY file in the Oblivion or savegame directory.
If the second problem is taken seriously, Ghosted files should be moved somewhere else than Oblivion\Data, and BAIN shouldn't put docs under Oblivion\Data\Docs. And we should probably have some king of savegame hiding as well.