The changes made in master, wrinklyninja-bossv3-support and wrinklyninja-fallout-support require the MSVC 2013 redistributable to be installed. This information has been added to the readme, but the installer should be updated to handle it automatically.

sourceforge

Martigen requested a 'Sync to Data' command that works on BAIN archives. It would unpack the archive, sync it with the data folder, then repackage the archive.

sourceforge

Bash's language defaults to your system language when it's started. A specific language can be forced by using the -L switch in the command line (e.g. -L English). Setting the language via the program menu just sets the -L command line switch for the next time; it doesn't get stored. Deleting the translation files also helps. If Bash can't find your OS language, it defaults to English.

I don't think adding a new .dat for this is a good idea. Would be better to have a human-editable bash_boot.toml somewhere central (i.e. probably %LOCALAPPDATA%\Wrye Bash on Windows and ~/.config/wrye-bash/ on Linux) - that way you can edit it if WB gets your language dead wrong.
We should also use that boot INI to store the last launched game for the game select popup, that's been a long-since requested feature (that way you can just hit Enter to launch the last game immediately).

Under #500

This is reported with TTW installed.

This is due to missing fields in the header definition code. Will probably be fixed post-refactor.

I have introduced a bunch of classes which I perpended with A for Abstract. All those classes should begin with _ as they are obviously only used locally and when the patchers are in their module say patchers we should be able to do from patchers import * and have all those classes not being imported. This goes for all those classes including Abstract_Patcher

I've been doing this for ages, and I'm surprised that it's not the default setup (it's not what the installer does, and it's not what's instructed in the readme).

I haven't encountered any problems doing so, but is there any reason why dumping Bash in any old place isn't the default setup? Only thing I can think of is bash.ini not having setting strings to deal with Oblivion and Skyrim settings at the same time, but then I don't use a bash.ini.

Running outside the game folders is preferable, because it means that users don't have several separate versions of Bash installed, leading to possible version fragmentation issues and confusion / invalid bug reports.

(As an aside, why are the BAIN folders not stored in a My Games\game\ subfolder like everything else? Should I open a separate issue for that?)

sourceforge

Being able to browse Oblivion's whole data directory, with an indication for each file of which package it comes from, would be very useful for debugging an install with many mods. Ideally you'd be able to click on the package name and be taken to the correct one in the installers tab.
Use cases:

• you discover a huge texture in some overhaul that causes you memory issues, and you want to know which mod installed it.
• a menu xml file is giving you trouble; you know which one but you don't remember which of your 300 BAIN packages installed it.

Blockers:

• #529
• #265

Right now the installer script is very long (> 3000 lines), and there are a few things that I think it could do better. I'm proposing the following:

1. Split the installer script into several files, using includes. I suggest one file for the installer bit, one for the uninstaller, one for the custom pages, and another for tying them together with the rest of the scripting (vars, helper functions, definitions, etc.).
2. Combine the requirement part with the "components" part - so where there's the checklist with entries for Bash and the Start menu shortcuts, also have a read-only checkbox for prerequisites. Not only does this simplify the code and streamline installation, it also means we can better log the process in the details box that is present during the actual installation part.
3. Use NSIS Unicode instead of plain NSIS. It's the same from our perspective, with the improvement of support for Unicode translations, so it's a painless switch. I'm only suggesting this because I have NSIS Unicode installed for BOSS, but Bash's packaging script is looking for the plain NSIS. (I've already made the change in my bossv3-support branch, it's only one line difference.)

@Wrye-Bashers: I'd like to get this done today, if there are no objections, so please yea/nea ASAP.

I open this to discuss the splitting process - including:

• module names
• games handling (submodules) ?
• helper classes handling
• naming conventions
• the actual splitting

sourceforge

BAIN should:

• Detect readmes that are named similarly to the package they're in (e.g. Manor Roads.txt in Manor Roads-24715-2-0-2-1563673145.7z)
• Install non-readme docs that are placed in the package root (this was always intended, it's just a bug in refreshDataSizeCrc)
• Rename common docs (besides just readme) to avoid conflicts (e.g. credits, CHANGES, etc.)
• Handle some newer docs extensions (e.g. .md, .rst, etc.)

sourceforge

What the summary says. This way if Bash somehow accidentally deletes a file (see here) recovering it is simple.
No idea if Linux has a mechanism for this these days.

lojack5: Partially implemented, need to go through and fix up other cases.

Needs an entry in the installers tab context menu commands table.

Have found no easy way of sharing the git svn config - so anyone can update master from the SVN and so anyone can dcommit from master to the svn

My efforts are described here: http://stackoverflow.com/questions/18006273/how-to-share-the-git-svn-configuration/18541945?noredirect=1#18541945

Related is the difficulties I have dcommit'ing:
http://stackoverflow.com/questions/21713729/dcommit-to-sourceforge-how-do-i-tweak-my-git-config-and-authors-file

Every little bit helps

sourceforge

Now that Bash uses BAPI for load ordering, and Skyrim doesn't use timestamps for load ordering, the ability to set custom timestamps through Bash is useless (correct me if I'm wrong), as changing the load order through drag 'n' drop or the arrow keys would cause timestamps to be overwritten by BAPI on Oblivion, and timestamps are ignored in Skyrim.
Removal of the custom timestamping features involves the removal of the File->Sort (which should never have existed...) and File->Redate plugin context menu commands, and the Timestamp field in the Modified panel. The Modified column in the main list in the Mods tab could also be removed, but I'd argue that it's still got some informational use for Oblivion. Perhaps it could be hidden by default for Skyrim.

sourceforge

To reproduce - on a fresh install of Bash point to a save game folder having existing saves
Go to the saves tab and see the master list - you will see something like this
This is from a fresh install of Skyrim where the only plugins present are Skyrim.esm and update.esm (notice that update displays as current LO 02 instead of 01)

Hint : there seems to be a constant shift of the Current LO - like the real LO plus the number of missing masters up till now - in this case 1+1 =2
For more examples see : here and here
The bashed patch should be unrelated

Classic : http://nvie.com/posts/a-successful-git-branching-model/

I pushed a b304.4 - this corresponds to a hotfix - next-dev is too generic IMO

We must branch from master - for various reasons including git-svn and merges do not play well but not only

Rewriting history is a nono but also wrong commits etc should not reach master. So I suggest we work on our branches. When ready do a rebase in our branch

git rebase -i HEAD~20
20 being the 20th commit before HEAD we need to look into. An editor pops up where we can rearrange commits mark them for editing or skip them altogether etc

When I want to amend a commit I mark it edit and when rebase starts it stops to this commit and I fire up git gui where I can split, it correct it etc

When satisfied then I do a git merge to the current hotfix branch - consider also cherry-pick

Our private branches can and should be put in the repo for anyone to see BUT the rest should not base work on them as we are free to rebase. Whenever anything hits b304.4 it's frozen

Since we have varying degrees of git familiarity if in doubt ask here

I also created some milestones - let's discuss this too - we need to start thinking on dates (in an indicative manner)

See:

• 9c73530: Abstract base classes should have docs and raise Abstract errors - ofc AbstractError serves as docs. Especially the Abstract_Patcher and Patcher/CBash_Patcher should have extensive docs and be sure they raise the error if their methods are meant to be overridden. I have some TODOs there for easy search
• cc656f4 ("""docs - what's this about ?""" # TODO)
• 730eff0 (why if record.flags.notPlayable: return False ?)
• 3e8abf3 (TODO: is this suposed to be used ?)
• 03b702c (TODO : translate ?)
• 4c21c3e (TODO: move up ? down ?)
• cd389f3 (TODO:weight)
• dbff210
• b717214

It would be to have a column/field in which we can see what date & time we activated a particular mod or installed a particular package, or even have a history of timestamps, etc. It'd make the process of troubleshooting the thing we messed up so we can deactivate the mod much easier.

Originally from svn

sourceforge

An easier way to update mods would be nice. Right now I have to:

1. Download the new file
2. Rename the downloaded file to the same name as the original file (I cleaned up the names of all my mods)
3. In Wrye Bash, uninstall the previous version (to remove any files that are no longer present in the new version)
4. Replace the archive in my Bash Installers folder
5. In Wrye Bash, install the new version

A proposed easier solution to all of these steps would be a “Update from file” or “Replace from file” item in the context menu for Installers, which would 1. remove all no longer present files in the new version, 2. replace the archive and 3. install all missing or changed files.

This would make it easy to quickly update installed mods from the downloaded newer versions. Going beyond that, a “Merge from file” would be nice as well, to merge incremental updates into the source archive.

Related: #595

sourceforge

Requested by bluesks404

There are multiple "setup" steps to installing a package - extracting the files, removing any read-only flag, then moving them into the data directory. We should be able to cancel at any point up to just before files are moved

sourceforge

TODO: See if this is applicable for Fallout 3 / Fallout : New Vegas - not applicable, the whole MGEF system got reworked after Oblivion

Gratis_monsta, on 29 December 2011 - 09:09 PM, said:
Like the Script Effect silencer, how about a script effect icon changer tweak? This mod has a nice selection (or you could use the basic vanilla spell icons)

I'm surprised nobody asked for this before but it would be nice to have support to be able to import regions from a CELL record into the patch so that mods that need to change region data don't get stomped by later loading ones.

sourceforge

• BAIN can hide projects, but can't unhide them right now
• Add a link to open the hiding directory (to all tabs)

Original SVN description:

blusky404 said:

1. Features request: File -> Create New Project...
2. Features request: File -> Open Hide Directory...
3. Bash is able to hide projects, but unable to unhide project

I'd like to move my branches from the SVN to this Git repository so that I can more easily diff against everything else that's going on.

I'm planning on not bothering preserving the SVN history, because there's only a small number of commits I made since this repo's master branch was last synced with the SVN, and I can easily repeat them more tidily.

The question is, @Utumno, which branch should I branch off?

"Cannot Load Plugins before Masters" error obtained whenever trying to manually alter load order with TTW installed.

Some files generated solely for the purpose of running the program / dev scripts are not in the .gitignore, so they can end up being committed.

Add appropriates wildecards/etc to make sure we don't accidentally commit these.

sourceforge

@WrinklyNinja: Wtxt is, as far as I am concerned, a horrible mutant half-breed of HTML and Wiki syntax that Bash uses to display generated formatted text. It's unique to Bash (ie. no tutorials or documentation on the internet) and AFAICT Bash reads in files that are in Wtxt, then converts them to HTML to display in wxWidget's HTML display classes. Why not just write the files in HTML to begin with? Is that not easier than inventing your own language, writing files in that, then writing a converter?
Anyway, I think it would be excellent if Bash got rid of Wtxt and just switched to having its Wtxt files in HTML and generating HTML content straight. One less thing for people unfamiliar with Bash to flounder at.

sourceforge

It would be nice to have a preview of the files that will be removed from the data folder when 'Clean Data' is executed from the Installers tab.
Possibly with an option to either once or permanently exclude some files from cleaning.

sourceforge

When I drag'n'drop a *-BFC.7z file into the installer, it is registered as a package. Would be cool if it could be recognized as a conversion and moved to the appropriate folder.

sourceforge

Make it easier and more visible to do some of the most common actions: Install/Uninstall/Wizard, Anneal. At the very least, move these items to the top of the context menu, probably bolding the Install/Uninstall/Wizard. We could go further and make a column of buttons down the left hand side (it's the place where it'd require the least amount of mouse movement to get at), for these common actions.

Also, having both an Install and an Uninstall command is redundant. Install should change to Uninstall, based on the package's status. Install Last appears to have no real use other than a shortcut to dragging a package to the ==Last== marking and installing. We can probably cut that one out. Install Missing still has its uses though.

@Utumno, @lojack5, @D4id4los: I was just on the wxPython site, and I noticed that they don't have their 2.8 releases listed any more. While the binaries are still available on Sourceforge and through the Wrye Python packages, this might be a good indication that we should move to wxPython 3.0. Is this a goal?

The changelog looks fairly detailed, and so it probably wouldn't be too much work. I'm not familiar with wxPython, but I thought wxWidgets 3.0 was a massive improvement over wxWidgets 2.8 (which I plain refused to use).

While IMHO the ideal goal would be to move to Python 3.x and wxPython's Project Phoenix, AFAIK the latter isn't ready for stable use, but Project Phoenix will still be based on wxWidgets 3.0, so should we ever move to it, this would still be a good first step.

sourceforge

With Unicode, I added the 'Plugin Encoding' option to get to a good compromise: Specifying a specific encoding greatly reduces processing time, as the plugin detection library doesn't have to process every string in a mod file, however, specifying a specific encoding means that every string will be interpreted using that encoding. For 99% of the cases, this is fine, as long as the correct 'Plugin Encoding' is selected.
Selecting the correct 'Plugin Encoding' is the key here. Most users will use 'Western European', as that covers most of the languages used. However Chinese and Japanese users will be left with garbled text. Those users have to use special OBSE plugins anyway, so detection of those plugins and enableing the appropriate 'Plugin Encoding' would be nice.

sourceforge

Original post:

Currently, the only way for a mergeable mod to be separate from the bashed patch is to add NoMerge to the tags list. However, the NoMerge tag currently implies the Deactivate tag. This can be confusing and problematic for an end user, especially if they are unfamiliar with Bash, or if they are trying to track down a problem in the load order. I would like to suggest a tag that, like NoMerge, prohibits the records from transferring into the Bashed Patch, but also allows the mod to remain active if it was to begin with.

sourceforge

Original request:

This will be more useful for Skyrim than Oblivion, but it would be nice if one day BAIN could be used to package loose files in a project folder into a BSA for distribution since the Creation Kit's native handler for this is bugged to the point of nearly being unusable.
Where "package for release" exists, a new option below that reading "package for release using BSA" should be added.
Obviously will require Bash/BAIN to support BSA handling to begin with, but perhaps there's a way to make this work by routing the request silently to BSAOpt if it's installed?

My idea would be much more far-reaching, similar to this MO2 plugin: https://github.com/ModOrganizer2/modorganizer-bsapacker
Basically, there would be two different configurations - one global, and one per installer. If you enable this feature, then you can configure 'rules' for which files will be packed into BSAs/BA2s.
This would be based on folder names and wildcards, with a hierarchical system where the per-installer config overrides the global one. Obviously we should provide a sane default (e.g. excluding FNIS files from the meshes folder).

BAIN would then take those files and write out one or more BSAs (remember, BSAs have a ~2GB size limit) if possible (e.g. in Skyrim, splitting is not possible, since it can only load one BSA per plugin).
That BSA should obviously be cached - our entire 'BSA cache' folder needs rethinking no matter what, this would be a good opportunity.

Blockers:

• #519

The Bash repository is pretty big, and it takes a while to clone, IMHO (5.5 min for me). I think it would be a good idea to split it up into several repositories then we can maybe use something like submodules to link them all up if necessary.

In my mind, the primary candidates for getting split off into other repositories are:

• BAIT and Bash3k (separately)
• The scripts folder
• The Nexus and forum starter thread files
• The screenshots folder? (I have no idea what it's for.)
• The Mopy\bash\compiled folder
• The Mopy\bash\images folder

I choose these because they're either unused by the Bash code, or are used by the code but could be sensibly versioned separately and make up more than 10% of the repository size.

We could then have a main wrye-bash repository, and accompanying scripts and meta repositories.

What do people think?

Edit: Updated based on feedback. I'm now of the opinion that BAIT and Bash3k shouldn't be carried over to Git, since none of us are working on them.

This is a list of all the context menu items that are missing when Bash is run for FO3 or FNV. Not all of the missing items should be present.

Installers Tab

Column Headers

• Auto-name String Translation Files [OK to be missing]

Mods Tab

Column Headers

• File->New Bashed Patch...
• File->New Mod...
• Oblivion.esm-> [Whole menu missing, becomes Fallout3.esm for FO3, becomes FalloutNV.esm for FNV]
• TES4Edit Expert [Becomes FO3Edit Expert for FO3, becomes FNVEdit Expert for FNV]
• Remove Dummy Masters

Plugins

• File->Create Dummy Masters
• Mark Mergeable...
• Mark Mergeable (CBash)...
• Rebuild Patch...
• Rebuild Patch (CBash Beta)...
• List Patch Config...
• Export Patch Config...
• Export-> [Whole menu missing]
• Import-> [Whole menu missing]
• Mod Cleaning-> [Whole menu missing]
• Add Master...
• Copy to Esm/Esp
• Decompile All
• Esmify/Espify Self
• Esmify/Espify Masters
• Version 0.8 [Becomes 0.85 for FO3, becomes 1.32 for FNV]

Saves Tab

Column Headers

• Oblivion.esm-> [Becomes Fallout3.esm (1.0,1.1,1.4) for FO3]

Saves

• Statistics [Present in Flash]
• .obse Statistics
• Delete Spells...
• Rename Player...
• Set Number of Uses for Weapon Enchantments...
• Import Face
• Rename Enchanted
• Rename Potions
• Rename Spells
• Reweigh Potions
• Update NPC Levels
• Remove Bloat
• Repair Abomb
• Repair Factions
• Repair Hair

Settings Taskbar Icon

• Export list of allowed/disallowed OBSE plugins [Should be same but FOSE/NVSE]
• Import list of allowed/disallowed OBSE plugins [Should be same but FOSE/NVSE]

@Wrye-Bashers: Should we support Windows XP users?

I've decided not to in BOSS because in a few months XP will become a security risk, and by supporting it I'd be encouraging the same complacency in XP users that has kept them with it since Windows 7 was released.

However, I acknowledge that Bash is a separate project with separate goals, and if need be I'll rebuild the DLLs I provided so that they support XP (I can't remember if they already do, so I've PMed someone who would be able to test).

For instance in the branch
https://github.com/wrye-bash/wrye-bash/tree/utumno-looking_into_helper_classes
I carefully rename the variables and finally the fields in ActorLevels class

The final result is that the writeToMod methods are almost identical - that's a direction towards further simplification of the code

sourceforge

For Skyrim (and for the two Fallouts) it isn't enough anymore to simply flip the ESM flag on when converting a file to an ESM. Whether this is through the "copy to ESM" function or via the "ESMify Self" function, Bash should generate the needed ONAM subrecords for the TES4 Header so that the file will be fully functional if the user is doing this to play the game with.
Without doing this, a flag-flipped file will have any references it places in vanilla cells completely ignored.
Opposite of this, when flipping back to an ESP, the ONAM subrecords should be stripped from the file as they are not processed by ESP files at all.
Not a major priority at the moment since TES5Edit can do this now, but it would still be nice to have the support be complete.

I'm looking at making a git version of the script we had for generating the Second Post on the forums. So far, it's going well. I found PyGithub which is a Python 2 interface to the Github API. The page says it supports Python 2 and 3, however apparently it hasn't been updated for later Python 3's, as the imports don't work anymore. That's a separate issue, I can always fork it and fix that whenever Bash gets to being Python 3.

Ok, so what I'm looking at is, the script needs good ways to filter out unneeded Issues when generating the second post. So I think we need to come up with a standard means of tagging new Issues. Later today I'll make a wiki page to reference our discussions here (won't have time just now).

My initial thoughts:

• bug - anything that's a bug in Wrye Bash itself only.
• enhancement - Essentially, feature requests.
• git - For discussions/issues directly related to the repository and not the program itself.
• discussion - obvious.
• Game labels: oblivion, skyrim, fallout, fnv - use these if a specific bug/enhancement only occurs in a specific game.
• Other stuff...?

The script will only include bug and enhancement issues. If the issue is labeled with a game label or labels, it will only be included in the second post for those specific games. If no game label is present, it will be included in all second posts generated. Some labels, like git will always be excluded, even if it's also labeled bug or something that would normally be included.

How about TODO and goal? How should we use those? How about other labels? Should we make more labels to tag open bug reports?

Possible suggestions for new labels:

• ready - bug/enhancement is done in a branch, and ready to be merged into develop
• in progress - bug/enhancement has been assigned and is currently being worked on. (maybe we don't need this, just see if the the issue has an assignee?)
• fixed - bug is fixed and merged into develop
• implemented - enhancement is complete and merged into develop
• wontfix - already have this, but for marking a bug when closing it if we're not going to fix it
• rejected - to mark a feature request as something we won't do. Maybe use this in place of wontfix as well?
• accepted - non-dev submitted bug report/enhancement request, been looked over and verified as a bug/etc
• cantreproduce - bug report, but we can't reproduce it

Usage of Milestones. The script will only be including issues that fall under a specified milestone. So say you're generating second posts, the current release is 305 and we're currently working towards 306. Then you'd specify milestone 306 to the script, and only bug and enhancement labels that are also under that milestone will be included under the "For the next release" second. Any other open bug and enhancements will be under the "Other known bugs" and "Other feature requests". Though we'll need a way to label such items as accepted. Also a review process for new (as in, not submitted by us) bug and enhancement requests, so they don't show up in the generated posts until one of us can verify them.

I see other projects do something like
BuildBot or TravisCI for builds.

I guess something like this would be nice further down the line after refactoring.
For example bash could have a seperate repo it dumps daily builds into.
Or triggered manually when needing a build.

Not sure how much work this would be to setup...?
Just opening this for Comments/Ideas/Suggestions on an automated build process.
Does anyone involved have any experience with this sort of thing?

sourceforge

BALO allows users to put plugins into arbitrary groups for load ordering purposes. These groups are also handy for selectively enabling/disabling groups of plugins, as you can deactivate or activate all the plugins in a group at once. However, BALO is deprecated and will shortly be removed.
Exclusion groups are a way for Bash to warn players if they have more than one plugin of an arbitrary group of plugins active at once. This is neat, but it requires renaming the plugins to put them in a group, which is a Bad Idea (TM). Exclusion groups are independent of BALO.
The idea of groups is a good one though, and is a useful feature for Bash. Groups would also be useful for BAIN, where they already have a semi-parallel in the form of marker packages. However, having an abstract definition that can then be made specific to plugins and packages would be neater. Within this abstract group concept, a group could be one of two types: exclusive or inclusive. Exclusive groups only allow at most one item to be active at once (one plugin or package), while inclusive groups allow many items to be active at once (but not necessary all of them). The members of a group could be activated or deactivated with one action, and trying to activate more than one exclusive group item could result in a warning from Bash.
To differentiate the group concept from that of a load order list as found in the mods tab, a load order list is ordered, whereas a group is not, and activation of a load order list deactivates all plugins not in the list. Neither groups nor load order lists are necessarily cohesive (ie. if A and B are in the group/list one after another, then C, which is not in the group/list, could be between them).
These features would replicate the current functionality with better "focus" than is currently present, giving it firmer foundations.

Bash's encoding checker sometimes displays mod header text (author field) in kanji instead of English. This could be due to slightly incorrect header values causing extra bytes to be interpreted as text, so check offsets.

sourceforge

I've recently added a global option "Plugin Encoding", that tries the applicable encoding for that language when reading/writing plugins. This provides a speed improvement over the 'Automatic' mode (which is use chardet to detect the best encoding). Quite a big speed improvement actually, bluesky404 reported a 22 minute patch time with 'Automatic', and a 15 minute patch time with a specific encoding selected.
The idea needs exanding, however. Chances are, the user wont have all plugins only in the specific language. cp1252 is most common (Western European - includes English, Spanish, French, German, Italian, etc. Basically if it has roots in latin, it's probably covered). What I'd like to expand this to is a per-plugin setting of the encoding to use. This will work great for reading usually, but writing is where the problem lies, specifically the Bashed Patch:
Lets say you 'Import Names' from ModA, which has Simplified Chinese names in it, so 'Simplified Chinese' is selected for that plugin's encoding. You have another ModB that is using the standard 'Western European' encoding. We'll need a way for these to seemlessly combine on writing into the Bashed Patch.
Anyway, it shouldn't be too complicated, but will require a bit of planning to make sure everything goes right, so I'll hold off on this until after the 295.3 release.

sourceforge

Suggested by wrinklyninja, my comments below:
Some Bashed Patch options should always be selected when building a patch for the end user. These options shouldn't necessarily be enforced, but to improve the interface (information overload), they should be hidden, and only accessible for advanced users that have opted to do so. These patchers are:
Contents Checker
SEWorld Tests
Cobl Catalogs - only performed if Cobl.esm is present
Cobl Exhaustion - only performed if Cobl.esm is present
Additionally, I (Lojack) would recommend considering other "Always recommended" options to be put under this hidden category of patchers, like the Leveled Lists patcher, which for 99% of end users should be left on Automatic.

I want the isMyType() method in the super class. I had to revert (here) but I do not fully understand why.

isMyType() is only used in bosh

sourceforge

Many of Bash's launchers are to utilities for which it provides no special icon, and no special options. The few that are specially handled include TES4Gecko, TES4Edit, TES4LODGen, BOSS and perhaps some of the other modding utilities also get special icons.
For the utilities without special handling, it would be neater if support for them was not hardcoded into the ini file and the Python, but instead was handled via shortcuts to these utilities in Mopy\Apps. Bash could ship with shortcuts to their default locations, and this would work just as well as it does with the current system, but would involve less code (which is IMHO a good thing).

Often .bsl files are included in mod archives. They are not needed at all, so BAIN should skip them.

Traceback is

Traceback (most recent call last):
  File "bash\basher.py", line 1385, in DoItemMenu
    self.OnLeftDown(event)
  File "bash\basher.py", line 1399, in OnLeftDown
    if not balt.askContinue(self,message,'bash.masters.update',_(u'Update Masters')):
  File "bash\balt.py", line 410, in askContinue
    heading=u'',
  File "bash\balt.py", line 592, in vistaDialog
    result = dialog.show(commandLinks)
  File "bash\windows.py", line 494, in show
    indirect(byref(conf), byref(button), byref(radio), byref(checkbox))
WindowsError: exception: access violation reading 0x00000018