[Kathryn Medows]

It is broken. Currently it is not possible to have subfolders within the bash Installers folder, because it conflicts with how Bash recognizes BAIN projects. This means that every user has one monolithic folder full of BAIN archives, making it impossible to organize them nicely on the HDD. This is cumbersome and IMO, should be fixed. It's not at all unrealistic to have 100's or even 1000+ archives. It would be very good if they could be more sanely organized.

Organize them via the bash interface for heaven's sake - that is my point. One does not need to organize them on the HDD - actually one should avoid it - for one's working projects/packages. For one's rejected / converted / archived projects it is perfectly possible to have subfolders in the currently Hidden directory. Would be great if those could be created via bash. Keep the organization on the HDD for OBSE plugins/ utilities (actually bash can handle this) / resources / mods developed / pyffi / installation notes, patches etc etc etc

[Tammie Flint]

It is broken. Currently it is not possible to have subfolders within the bash Installers folder, because it conflicts with how Bash recognizes BAIN projects.

I must have missed when it suddenly became important to start making subfolders under the BAIN installers folder. Do people seriously stick stuff in there that's not being actively used by their game? If so, it begs the question of why people are doing that when they probably shouldn't be. The only stuff I ever put in my Bain Installers folder are things I'm either playing or testing. If it's not remaining in the game, I don't leave it sitting there to clutter the list, so it's never grown beyond about 100 archives and about 10 projects.

Honestly, I'd much rather see the time and energy spent on getting real improvements working, like CBash or doing something to improve the speed of the installers tab so that you don't have time to walk away and cook dinner while waiting on it to refresh. Or getting some of the tag requests done. Or fixing stuff that actually IS broken.

[Arnold Wet]

Oh yes it is - an explorer for Oblivion ladies and gents - the sooner you use it like this the better for you. I do not keep all my folders in the installers dir/tab of course - I download them there and use bash's arsenal of tools to set them right - unpack to project - double click to open the project (a granted request of mine) - modify structure - check conflicts - create BCF - pack to archive (not used unfortunately cause I want to set the properties for the archive - a great great addition this would be) - hide
Are you really creating all of your projects outside bash ? And what about all those tools for conflict detection ? In case you didn't know it even has a feature (requested by, well, me and implemented by warrudar who found the code for it laying in his hard drive) to back up conflicts - you can completely dissect the mods using bash.
I think one day I should write a guide - I'd name it advanced bash workflow lol. There is such a thing you know.
Backing up : I do back up
No I would not keep 100 gigs of mods in the installers tab - and frankly I would not want to manage such a monster. Except if I let them lay there. But for moderate collections - say 20 gigs - a combination of the mods I use/try/develop/anolyze in the installers folder (neatly organized - top level - markers instead of folders) plus the Hidden dir for the rest (to avoid clutter) - well thats what WB is about. Maybe try it ?
I remember the relish I felt while transferring my collection in bash - deleting the mess of folders (here goes 06 QUESTS\needs SI a ha ha and here goes this conflicts withUOP.txt)
Please read my posts again for details

Uhh no thanks ... Why do in bash what explorer can do?

Jeez people freak out enough as it with the details in my BAIN thread.

Unpack to projects - that I'd not use? No thanks. I really don't see how what your suggesting at all streamlines anything - just makes it more complex and sloppy than need be. You say you are not packing to archive anyway - so you are taking archives apart into projects then you have to go to explorer to repack with the compression settings (or whatever) you want.

Yes I repack all on a completely separate hard drive and for me adding or updating a mod only takes minutes really. Plus I get an organized backup that goes both ways without needing to make much effort at it. Seeing conflicts before installing is not going to stop the conflicts that is what annealing and install order are for.

+1 to Arthmoors post above.

[Laura Ellaby]

I should mention that all of my ideas are just that. This is all still subject to approval. I will not make any significant changes like this without some serious discussion first.
Even if I do implement the changes, it's still up to PacificMorrowind. I'm not even a part of the Bash team, I'm just a contributor.

I'm glad that people are finally starting to discuss it because it is a pretty significant change.
In fact, I have already completed the needed changes for the Bash restructure, but I have omitted any changes to the directories, specifically because I know it needs to be considered carefully.

I must have missed when it suddenly became important to start making subfolders under the BAIN installers folder. Do people seriously stick stuff in there that's not being actively used by their game? If so, it begs the question of why people are doing that when they probably shouldn't be. The only stuff I ever put in my Bain Installers folder are things I'm either playing or testing. If it's not remaining in the game, I don't leave it sitting there to clutter the list, so it's never grown beyond about 100 archives and about 10 projects.

Honestly, I'd much rather see the time and energy spent on getting real improvements working, like CBash or doing something to improve the speed of the installers tab so that you don't have time to walk away and cook dinner while waiting on it to refresh. Or getting some of the tag requests done. Or fixing stuff that actually IS broken.

Why shouldn't the Bash Installers folder contain all of your BAIN installers, whether you are actively using them or not? This makes more sense to me.
The reason that people don't is because Bash makes it inconvenient, in more than one way.

Consider also people who have multiple Oblivion installs. With the new restructure (regardless if any directories are changed), it will be possible for people to use the same Bash installers folder shared by all of their Oblivion installs. This is the main thing I am addressing. As it is, every Oblivion install must have it's own Bash Installers folder and this is extremely wasteful of disk space. Often having to duplicate a lot of archives.
Maybe the user has Nehrim installed and they want to have a subfolder to separate all of their Nehrim mods from their Oblivion mods.

There must be a friendlier way of managing all of our BAIN archives. I think that both the on-disk and GUI management need attention. I'm open to suggestions.

utumno:
The hide functionality is also a problem for multiple Oblivion installs that share the same Bash Installers folder, which is the main reason I propose it should be changed.

[Matt Bee]

Put that way then I'm totally on board with what you are saying.

All this talk of storing downloaded mods and and repacking within BAIN is just confusing the issue with taking BAIN (I think) out of scope of purpose. This suggestion really colored the whole debate (for me) and had me thinking it was going in this direction for that purpose - should have read closer.

Yes to being able to have hidden archives provided they are only in relation to the current version of bash that is installed and if the hiding does not mean moving.
Yes to having markers as collapsible (if possible). Or sub-folders where what is in the subfolder can be installed.

Hiding I don't care as much about as everything in my folder is either usable or it is not there. I do have mods installed in the various bash installers directories that I have now that are not currently being used but are 100% ready to be used. Things like mods yet to test, quests for later in character life, tools for troubleshooting, etc. This would be more so the case if I had a unified bash installers directory - which I really want.

What about an option to insta hide/collapse or insta unhide/expand so that all is seen at once, as well as, at each instance?

[Joanne Crump]

The multiple installs thing I can see. How would Bash be able to tell one from the other in that case though? It sounds like all the BAIN archives will be in the same folder, but somehow it's going to know which mods go with which installs.

[Makenna Nomad]

Yes, exactly. That is another reason why I would like the hide functionality to be changed, because then you could hide all the Nehrim mods from your Oblivion install and vice versa. With the existing hide functionality, you can't do that. Because the archives are physically moved, it causes a race condition (sorry technical term).

[Sanctum]

The multiple installs thing I can see. How would Bash be able to tell one from the other in that case though? It sounds like all the BAIN archives will be in the same folder, but somehow it's going to know which mods go with which installs.

Well that is what Gaticus has been working that I understand - moving the bash installers info to the game profiles and out of the bash installers directory so when game profiles are swapped then each profile will read the bash installers directory differently. Then add in these changes of being able to hide the packages meant for other installs and this saves a lot of space and effort in the need to maintain multiple bash installers directories.

[^_^]

Maybe "hide" and "unhide" aren't good terms to apply to what's being proposed then. What about "active" vs "inactive" for a given profile?

[Nicola]

Maybe "hide" and "unhide" aren't good terms to apply to what's being proposed then. What about "active" vs "inactive" for a given profile?

On the contrary, I think it makes even more sense.

The current functionality for hiding installers only works that way because it was a convenient way of implementing it, being derived directly from the same mechanism used to hide plugins.
Worse, the hidden installers are dumped into the same folder as all hidden plugins.

Why does the ability to hide things exist? When you think about that question, then I think my proposal make more sense.
Why hide plugins? To prevent Oblivion from seeing them.
Why hide saves? To prevent Oblivion from seeing them.
Why hide installers? To prevent Bash from seeing them. Not because we need to be able to reduce the clutter in our Bash installers folder.

[Kyra]

Some good discussion and idea proposals being generated ... But I have a request

I would like to see at this time a version which does not venture into further development, but rather polishes all the recent plethora of changes into a good stable bug free release, and possibly with an installer (although just a complete bug free 291 not requiring a previous version would be good). Wrye bash has recently lost a bit of street cred in this regard and the current upgrade path is even more confusing than usual for some, especially if they decide to use either 288 or 289 as the "also requires a 286+" version, and they run it causing more problems before overwriting with the latest

[Amber Ably]

Honestly, I'd much rather see the time and energy spent on getting real improvements working, like CBash or doing something to improve the speed of the installers tab so that you don't have time to walk away and cook dinner while waiting on it to refresh. Or getting some of the tag requests done. Or fixing stuff that actually IS broken.

I would like to see at this time a version which does not venture into further development, but rather polishes all the recent plethora of changes into a good stable bug free release, and possibly with an installer (although just a complete bug free 291 not requiring a previous version would be good). Wrye bash has recently lost a bit of street cred in this regard and the current upgrade path is even more confusing than usual for some, especially if they decide to use either 288 or 289 as the "also requires a 286+" version, and they run it causing more problems before overwriting with the latest

These. I've already said my bit on a few of the proposals being passed around, but I think it's more important to refine what we've already got, and to implement requests that have been made before these proposals were put forward, than to focus on the proposals. (Though I realise that this focus perception is probably being weighted by the discussion) I also strongly agree that WB really, really needs an up-to-date stable release. It's had a spate of what can best be described as dodgy releases, and this isn't doing WB's reputation any good.

Forget about adding new stuff for now, just get a stable release that hasn't got anything broken that was working before. Then build again off that, starting with the real improvements (fixing of bugs, and I don't mean 'this feature doesn't work it the way I think it should' but 'this feature doesn't work'), and then implementing old requests, before finally looking to add new proposals.

The userbase is suffering, you see.

[Nims]

These. I've already said my bit on a few of the proposals being passed around, but I think it's more important to refine what we've already got, and to implement requests that have been made before these proposals were put forward, than to focus on the proposals. (Though I realise that this focus perception is probably being weighted by the discussion) I also strongly agree that WB really, really needs an up-to-date stable release. It's had a spate of what can best be described as dodgy releases, and this isn't doing WB's reputation any good.

Forget about adding new stuff for now, just get a stable release that hasn't got anything broken that was working before. Then build again off that, starting with the real improvements (fixing of bugs, and I don't mean 'this feature doesn't work it the way I think it should' but 'this feature doesn't work'), and then implementing old requests, before finally looking to add new proposals.

The userbase is suffering, you see.

I agree, but that is not my department. I can't pretend to know enough about Bash's internal workings to try to solve some of the more ingrained issues, so I will not address them.
PacificMorrowind and others still are. None of this is diverting their focus.

v290 is already pretty close to being as stable as v287 from my experience.
v291 is also going to be mostly a bug fix release from what I can see. Other than the new backup feature which is mostly all new code, so is unlikely to break anything and I think the sooner we can backup our bash settings, the better.
I also want to ensure that the backup feature gets put through it paces and we are sure it's stable before these other changes are implemented, since the backups will be very handy in case there are bumps in the road with future releases.

My time to be able to offer assistance with Wrye Bash is also limited, so I'm doing what I can, now.
The issue of restructuring the bash files and folders is an old request and should be done. It is also required so that Wrye Bash will play nice with multiple installs, which is my main incentive.

The restructure is not slated for any release yet, but it definitely won't be in v291. And if directories will be rearranged, that probably won't happen in the same release as the general restructure. The proposed change to the hide feature for installers would probably not come until after that, so this is all still a little way down the road anyhow.

[sexy zara]

I think it would be really REALLY good then to get 291 out the door, and not have it be dependent on an existing install to be in place. Though it may seem trivial, that pidfile.tmp issue NEEDS to get fixed. It's generating bug reports all over the place. Telling people "just delete it" isn't a fix - that's ignoring the issue, and doing so it at the expense of the program's good name.

I think that's the only actual bug left, everything else has been working properly as far as I can tell - other than the oddities I'm still having with BAIN not properly understanding that I have several mods sharing resources.

[Lalla Vu]

My 2 cents, for what they are worth:

Perhaps a survey/poll thread asking the following types of questions about BAIN practices would be helpful. That is if you want to get at how it is most often used. I can accept that the way I use it may be different and my method might be unusual.

When adding to the Bash Installers folder you most often:

• add only BAIN ready packages and will package/repackage until they are ready.
  
• Add any archive you download and repackage once in the BAIN folder

Do you view the Bash Installers folder as:

• A place to store only BAIN ready archives (the BAIN folder is for managing the Data folder installations)
  
• All archives (the BAIN folder is for cataloging all downloaded mods even if not BAIN ready)
  
• Both but more option A (a catalog that is BAIN ready)
  
• Both more option B (BAIN ready is preferred but I will add archives that are not BAIN ready)

Do you want the the ability to have the BAIN folder have branching trees and the ability to hide packages? (or maybe better words to get at the issue).

• Yes (because the BAIN folder is my storage area for all mods)
  
• No (because if it isn't BAIN ready and going to be used then it shouldn't be in that folder).

Just thinking that since some of us are in disagreement that this might clarify the issue some.

For myself I have many BAIN packages that are BAIN ready in that folder so that they can be used later or if needed but never a package that is not BAIN ready. I therefore see no need for hiding or branching trees.

Having learned everything about BAIN usage, organization and installation from Psymon and Tomlong's excellent guides, I have listed my votes above underlined. FYI, I find having the systems set up as Psymon indicated makes it really convenient and clean. I have a separate holding/unzipping folder for mods/OBMM archives (which I avoid now).

I too support OBSE plugin installaion through BASH (with a warning for dll files) - thought that is Wrye's and the WB team's decision.

Regarding the subfolder issue - Gaticus clarified that it does not matter to Wrye Bash installers tab as it would all appear in one view. So frankly I don't care one way or another on this. If it helps WB somehow, I say go for it. I might not use it, but I am not opposed to it.

As an aside, I would request CBash implementation be made a immediate goal for Wrye Bash...

[Laurenn Doylee]

Hey! I'm not a bash team member, and barely a contributor, but I want to keep my 2 cents.
I think rearranging folder structure is good. Changes towards collapsible BAIN installers are good but better to wait for 292
So it will be good to do the major part of rearrangment but leave place for collapsible folder structure at least just in place.
Yes there are things more needed than collapsible headers/dirs, but it's a great thing too.
and if somebody don't like collapsible markers/folders it would still be able to make only one folder/maker
No, I'm not saying there have to be all thingies, but that it's nice too have some bain arhives separate of another bain archives for various reasons (multiple oblivion instals, subgrouping into structure the hundreds of packages or whatever)
And then we could have not only select various packages and install, but for example install all packages inside category/folder at once with some few clicks
I'm voting yes for organised active instalers folder and yes for organised hidden folder

as to dlls i think general option "enable install of all executables from all archives" is still unsafe
i think it's better to check that for every archive separatelly as we have "has extra directories entry", and have warning once per package when trying to check this
so we could have OBSE plugins in BAIN archives and don't have "WOOT? [enter name] texture replacer has included an obse plugin? I didn't know!"
so it will beenough security and well organised security (if security is not well organised it alway fails because there have to be a human near the security system - look the UAC in vista doesn't help, because users wants more to disable this than have extra security)

well I taught a lot - maybe before i write anything more I need to sleep with them

EDIT: ah well my problem from previous thread - the cause was the routine for "lock load order" fired too soon - and my data folder was get from the backup so giving the rights to the folder hadn't given it to some loose files (no rights derivation) - and unprivileged user was not able to change the date hence crash on security violation.
I prefer that routine would be called after bash is fully loaded, so a failure wouldn't kill bash itself
as I saw the routine were called at first 3% of loading bar, so it's defineately too early
also perhaps the date changing routines should be in try{}catch block so the exception wouldn't fire to system but will be caught by bash itself so it could provide nice info and continue to work

[Jason Rice]

I think it would be really REALLY good then to get 291 out the door, and not have it be dependent on an existing install to be in place. Though it may seem trivial, that pidfile.tmp issue NEEDS to get fixed. It's generating bug reports all over the place. Telling people "just delete it" isn't a fix - that's ignoring the issue, and doing so it at the expense of the program's good name.

I think that's the only actual bug left, everything else has been working properly as far as I can tell - other than the oddities I'm still having with BAIN not properly understanding that I have several mods sharing resources.

The pidfile issue should be resolved for v291. It probably should have been released as a hotfix or something.
From what I understand, v291 MIGHT ship as an installer version. PacificMorrowind has mentioned that he does plan to add an installer, though he hasn't said quite when.

I'll try to remember to have a look into that issue with shared resources for you. That might be something I can tackle.

On a side note. It would be in your benefit (I'm speaking in general to everyone) to try to report any bugs or feature requests on the SVN where they can be properly logged.
Things are easily lost and/or forgotten in these threads and people who help on the SVN side often come and go and will not be familiar with all the informal bug reports and feature requests that they weren't around for. Like myself.
There is currently only a small handful of bug reports that are pending. Virtually none have anything to do with the issues that people are bringing up. Half are new reports that I have added on behalf of posters here since the time I starting chipping in.
Stuff that is posted on the SVN bug tracker is also far more likely to be addressed, just because it's more convenient.

You can also submit a bug report or feature request on behalf of another novice user if you want to chip in and contribute to Wrye Bash development in your own way.

Bug reports go https://sourceforge.net/tracker/?group_id=284958&atid=1207901
Feature requests go https://sourceforge.net/tracker/?group_id=284958&atid=1207904

As an aside, I would request CBash implementation be made a immediate goal for Wrye Bash...

I don't think anyone but Waruddar has access to the CBash source so hands are a bit tied in that regard. He has updated the CBash dll though for v291 (A fix for OBME support). I really don't know any more than that, just what I see on the SVN.
PacificMorrowind or Waruddar would have comment on this.

[Emily Martell]

Maybe it would be an idea to separate the Installers tab from Wrye Bash and make it a add-on for Wrye Bash.

That way people can use the latest stable release of Wrye Bash and BAIN. Without having unstable updates to one, keep people from updating and get the benefits from the other.

[Dawn Farrell]

It is broken. Currently it is not possible to have subfolders within the bash Installers folder, because it conflicts with how Bash recognizes BAIN projects. This means that every user has one monolithic folder full of BAIN archives, making it impossible to organize them nicely on the HDD. This is cumbersome and IMO, should be fixed. It's not at all unrealistic to have 100's or even 1000+ archives. It would be very good if they could be more sanely organized.

Changing the name of the folder itself is really a moot point compared to moving the BAIN projects into their own designated folder, and moving both the projects and bcf's out of the Bash Installers folder.

Is this not acomplished by complex BAIN projects? I have an archive called Texture replacers which has folders for the different textures. I just check the ones I want (they start with a number so if I need to change order I renumber it, but that is rare as I have a stable setup I use. If I want to try a new texture I just add the archive separately). So for 20 textures I just have one file in the installers tab.

Yes, more work, but unless you change mods all the time then this works.

[matt white]

This dicussion has made me realize that for the past year Oblivion has been a game about managing mods more than playing, for me. I got caught up in managing my mods and BAIN installations more than about actually starting a game and playing it through. I understand that once you play it through once, then a few more times as a different character, it gets old. So then I look for mods to change the gameplay, like TIE, FCOM, ROM, realism mods. So I try these and after 15 hours of gameplay something new comes along or gets upgraded, and I switch to that, reorganizing my mods (takes just as long as I played).

So now I remember why I started using Wrye, and it was to make my mods work together. And now I know why I use BAIN, to make it easy to install a new mod or troubleshoot a load order.

I would think there is niche of players who just want the tools to setup a game with mods, bash it, and play it from start to a possible end (I think 200-300 hours?) before starting again, or adding a mod to try something new. That group does not have 4 player profiles, 5 install orders, switches mods often, they just play. Don't need new ways to manage 800 mods, new directory names, new folder structures, new terminology, just need functionality and ease of use. Lets not forget those players.

Not realistic request, but if at all possible, having a Wrye Bash Classic and Wrye Bash Expert would be something

[herrade]

This dicussion has made me realize that for the past year Oblivion has been a game about managing mods more than playing, for me. I got caught up in managing my mods and BAIN installations more than about actually starting a game and playing it through. I understand that once you play it through once, then a few more times as a different character, it gets old. So then I look for mods to change the gameplay, like TIE, FCOM, ROM, realism mods. So I try these and after 15 hours of gameplay something new comes along or gets upgraded, and I switch to that, reorganizing my mods (takes just as long as I played).

So now I remember why I started using Wrye, and it was to make my mods work together. And now I know why I use BAIN, to make it easy to install a new mod or troubleshoot a load order.

I would think there is niche of players who just want the tools to setup a game with mods, bash it, and play it from start to a possible end (I think 200-300 hours?) before starting again, or adding a mod to try something new. That group does not have 4 player profiles, 5 install orders, switches mods often, they just play. Don't need new ways to manage 800 mods, new directory names, new folder structures, new terminology, just need functionality and ease of use. Lets not forget those players.

Not realistic request, but if at all possible, having a Wrye Bash Classic and Wrye Bash Expert would be something

A niche? I would say the majority. If you look at the download numbers and compare that to the number of people who actually sign on the forums and participate, you realize that there are a lot of people out there who really don't want to mess around with this stuff. Have a look at the other forums here - how many of those users do you see in this forum? I get bashed (pun intended) for not using BAIN, but I really have no reason to. I still use OBMM and for the most part it suits me fine. I don't have an enormous mod list. My current game is almost 400 hours in length.

Anyway, just piping in to say that I would also ask you not to forget the casual user. We're forced to use Wrye Bash because some of the mods we want to use require that the plugin is imported or merged (TNR, All Natural and the Harvest Containers filter for mods for me). I just started using mTES4 (TES4 Manager) and it was funny to see the shock of a couple of the folks there that I wasn't using BAIN.

Not sure two different versions are necessary, but I do ask that you guys don't get too carried away. If you want to add all these features, go ahead, but just give us a nice stable version that we can use without all the bells and whistles. I will have to create a BAIN package with a wizard for one of my mods, it remains to be seen if I ever use BAIN myself

[Alisha Clarke]

What exactly is unstable about Wrye Bash? v287 was pretty solid.
Just because there were issues with v288+? I think that is an extremely unfair judgement for the sake of a pretty simple mistake.

If there are serious bugs predating v287, then what? Because there is nothing on the bug tracker that is very significant at all.
It's pretty certain that if it's not in the bug tracker and PacificMorrowind didn't already say it would be fixed, then it's not going to be fixed.

[jess hughes]

No, I'm only referring to 288+ and I wasn't making a general comment about WB. I just find in scanning this thread that there is talk about revamping the entire structure of WB and I'm suggesting that a nice solid release is put out before you go through and overhaul it. I'm running 287 and it's still unclear to me if 290 is solid enough for me to upgrade. What's the deal with this temp file? Sorry but I had too much trouble getting 287 working under Windows 7 to upgrade to a release that still has issues.

[Samantha hulme]

You can also submit a bug report or feature request on behalf of another novice user if you want to chip in and contribute to Wrye Bash development in your own way.

Bug reports go https://sourceforge.net/tracker/?group_id=284958&atid=1207901
Feature requests go https://sourceforge.net/tracker/?group_id=284958&atid=1207904

Can I suggest that you inlcude the comments and links on the OP - will help encourage people (like me ) to follow this procedure for bugs and requests.

Edit: Just tried it and it was pretty simple to do (except I had not registered so my request was marked as anonymous) - will either get an account or just sign my requests in future (should I come up with anything)

[Dalley hussain]

No, I'm only referring to 288+ and I wasn't making a general comment about WB. I just find in scanning this thread that there is talk about revamping the entire structure of WB and I'm suggesting that a nice solid release is put out before you go through and overhaul it. I'm running 287 and it's still unclear to me if 290 is solid enough for me to upgrade. What's the deal with this temp file? Sorry but I had too much trouble getting 287 working under Windows 7 to upgrade to a release that still has issues.

290 is pretty solid I was uncertain too and skipped 288-289. Just import the launcher over from 287 and that pidfile thing (a one time fix if it occurs). Otherwise it runs great.

If you all want classic then 287 seems to be the one, but that is how it is - we update for the new features and as we do we find issues that perhaps the developers can't themselves foresee. Why do we find them? Because we play the game and mod it a lot. Something that the developers don't seem to do (as much). So having classic versus expert seems to be a proposal to fork the development and then it would result in requests to have classic get some of those new features. Better to take a survey of what have been the most stable versions in the last year or so. I recall Wrye Turning out up to 4 versions in one night.

Actually since Wrye left 288-289 was the most unstable I've seen - and that is quite a few versions. This program gets a lot of love.

The changes that Gaticus is proposing makes Wrye Bash more economical and less 'all over the place' plus allows people who use total conversions and multiple installs to have bash - yeah big changes but for the good of all. Multiple installs is a boon for modders because it allows for having vanilla/modding load orders and modded ones so they don't have to worry about trying out other mods for worry of soiling their pallet.

And BAIN - hey it is all about choice (its yours) - but BAIN really does offer more control - the more you see the more you know. The transition at first is a pain but I've yet to read anyone anywhere who said it wasn't worth in the long run.