[Louise Dennis]

I'm still not getting if I need the orignal Rational Names and Guard Names mod to use their option under Import Names. Are these options just patches or the actual mods?

Ah, I see what you're saying. The rational_names.csv and guard_names.csv are replacements for the mods. You do not need the original mods installed. The .csv files are just a more efficient way to make this kind of change. Moreover, you can go and edit the .csv files if you want to, and put your own names in there : )

[Rik Douglas]

Only one thing : not migrating to a new version but to a new pc/new installl !

Hmm, I guess I'll have to change the backups so that they will adjust to a new install.
Paths might change (System drive, Windows username, Oblivion install path, etc).
Right now the backups record the exact location of the original file. So restoring a backup will only work within the same installation so far. Or at least an installation that uses the exact same paths.

[Stephanie Valentine]

Ah, I see what you're saying. The rational_names.csv and guard_names.csv are replacements for the mods. You do not need the original mods installed. The .csv files are just a more efficient way to make this kind of change. Moreover, you can go and edit the .csv files if you want to, and put your own names in there : )

Cool, that sounds fun. I'm gonna do that now lol. Thanks for the help.

[Nick Swan]

I'm not Entirely Sure about this when it gets to, Primarly "Tweak Actors" as far actual mods... :confused:

[Bellismydesi]

Re : backing up

In short - I think that apart from Saves and Oblivion Mods folders (the second one due to its size) all other files should be backed up.

What I meant here is Bash Installers and Hidden - of course the rest of oblivion mods dir should be backed up

Still no oblivion - I skimmed through the previous thread and I have a couple of comments - why renaming the Bash Installers dir to Bain Installers ? - may cause confusion and break something (backward incompatibility). I understand there are reasons of uniformity so to speak but may be ill advised. Plus I have a special affection for this folder
Second - not moving hidden packages physically from the Installers dir would cause problems - a ) clutter (when there are 100s of installers to have another couple 100s files present makes directory maintenance even more difficult) - b ) in case settings/back up gets corrupted one has to manually separate installers from ex hidden and this should not happen to anybody - c ) hidden packages end up hidden for various reasons - packages used for BFCs, older versions of mods, mods to be tried to name but just a few. I have physical subfolders in the hidden directory with various categories of hidden files and manage them by hand - deleting staff no longer needed rearranging etc. I had once requested to expand the hide menu item like :

Hide > Default       Converted       Old versions       Rejected       To be tried       New folder

where those labels are user defined. Basically the hide functionality is one of the very powerful tools in bash - remember that a lot of people BAIN their installs - or install and uninstall bunches of mods - or create BFCs.
To sum it up - not only hide them physically but take this as a feature request

I have no time now but hopefully soon I'll look more into it - this back up feature really thrills me and I am sorry I was not around when it was proposed. I don't know how you plan on exporting the settings - if at all. An export feature would be great.
I will look in SF and give more feedback asap

Thanks for the great work

[Cameron Wood]

~ snip ~ I skimmed through the previous thread and I have a couple of comments - why renaming the Bash Installers dir to Bain Converters ? - may cause confusion ~ snip ~

O_o +1 agree, forgive me if I mis-understand ( and not just to save me re-writing the Guide ), Bain Converters is a whole different function to Installers, only used one or two of them but I think confusion would reign changing this.

[Flutterby]

I've been thinking a bit about the UI and functionality in the Installers tab. Would it be useful if the installers were hierarchical? That is, what if you could organize the installers in collapsible entries in the installers tab like the "Manage Bookmarks" feature of Firefox or the left-hand pane of windows explorer? If this were the case, would the "hide" functionality still be needed, since you could just create a folder in the tree and move a package out of the way? (we could also make the on-disk directory structure reflect the organization in the UI, so your organization wouldn't be lost if Wrye Bash's data were somehow corrupted.)

If we did organize installers in a tree, the process or ordering installers would change a bit, since the ordering would now be constrained by how the installers were grouped (does this make sense?). Like, if a user made two groups named "Essential mods" and "New mods", it might not work out so well, since all of one group would have to be installed before any of the other group, and you might want to interleave them to make sure the correct resources are the "conflict winners". It would work much better if groups were named like: "Unofficial Patches", "FCOM", "Body Replacers", etc. since most relevant conflicts that you would want to manage with install order would be within a single group or among entire groups. All the mods in "Unofficial Patches" would come first, followed by all the mods in "FCOM", followed by all the mods in "Body Replacers". Do you think this kind of scheme would work out well? Any alternate ideas out there?

Of course, all this functionality would be for advanced users. If no groups were created, the interface would be identical to what we have now, with everything in a flat list.

[MatthewJontully]

O_o +1 agree, forgive me if I mis-understand ( and not just to save me re-writing the Guide ), Bain Converters is a whole different function to Installers, only used one or two of them but I think confusion would reign changing this.

ooops I meant Bash Installers dir to Bain Installers - apologies

snip

This has already been proposed many times already in many variations - by me also - I proposed the markers to appear with a little cross by them which if clicked would collapse all installers till next marker/end. Do not know if even possible - got the answer that for the moment was not planned - I understand it might be a huge hassle. The Firefox bookmarks scheme is rather rigid for BAIN though methinks - and definitely not reflect this on the drive - would be too complicated implementation wise I think. Just the markers being collapsible would perfectly do - it would be hugely useful when BAINing one's install - instead of scrolling up and down past hundreds of entries. Would be also easy to focus into each group and order it. So for organizational purposes making the markers into collapsible headers would jolly well do - without messing up the internals of BAIN.
Hide functionality would be needed anyway - cf my post

[Melissa De Thomasis]

I've been thinking a bit about the UI and functionality in the Installers tab. Would it be useful if the installers were hierarchical? That is, what if you could organize the installers in collapsible entries in the installers tab like the "Manage Bookmarks" feature of Firefox or the left-hand pane of windows explorer? If this were the case, would the "hide" functionality still be needed, since you could just create a folder in the tree and move a package out of the way? (we could also make the on-disk directory structure reflect the organization in the UI, so your organization wouldn't be lost if Wrye Bash's data were somehow corrupted.)

Folders within Bash installers conforming to this in the Help file......

Ordering
Bain assigns an install order to all packages. When packages are installed and/or uninstalled, the order is considered in determining which files will actually be installed/uninstalled.
? General
? Install order is shown the table in the "Order" column.
? All packages are moved to just before the ==Last== marker when Bain first encounters them.
? Order can be changed by right clicking on a package (or group of selected packages) and selecting "Move To". Just enter the position to which the packages should be moved. If you're moving many packages at once, they'll keep their relative order, with the "oldest" moving to the specified position, and the others following after it.
? You can also use Ctrl-Up and Ctrl-Down to change the order of packages. This preserves their relative load order without moving them as a block.
? You can also re-order packages by dragging and dropping the package where you want in the load order. This will only work if the list is sorted by 'Order'
? A good simple starter ordering would be roughly this sample adjusted as desired:
? DCL <----- This typo needs corrected though DLC
? Unofficial Patches
? DarN
? Sounds
? World textures - expandable
? Environments
? Weather
? Other replacers
? Overhauls - much
? Overhaul Overrides and Patches
? Quests
? Dungeons
? Locations
? Houses
? Unique Landscapes
? Provinces/LOD
? Cities and villages
? Roads and infrastructure
? Races and Bodies
? Companions
? Magic
? Stealth
? Combat
? Scaling and leveling
? errata
? newly acquired and testing mods
? my own projects
? ====
? Unused Mods

Would I think be ideal - After a complete re-install of Wrye Bash and resulting loss of labels ... it would be a bonus for user organisation of BAINs.

Newly acquired and Testing mods - could represent the root of Bash Installers folder (possibly moved to last in this list), Wrye bash moving them from there if moved in the Installer hierarchy of folders, into the relevant on disk folder - Unused Mods renamed Newly acquired - Testing - Unused mods?

[Emmi Coolahan]

I'd say no to folders - cf my post above. Got to go now and can't elaborate but feels dangerous somehow. I do not have Ob or Bash now so can't check why - it's a gut feeling
Still making markers collapsible would just do (and also make possible to hide (move) packages to custom dirs inside the hidden folder - also purely via the bash interface)
Folders would also defeat the purpose of bash I think - to not get our hands dirty with explorer lol
No, the change should remain on the interface - and even there would be difficult to implement.

Anyway apparently Unicode support and Cbash need to be perfected first.

[Anthony Rand]

Trying to delete a project in BAIN gives me this error:

Traceback (most recent call last):
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\balt.py", line 1555, in Execute
self.gTank.DeleteSelected()
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\balt.py", line 1443, in DeleteSelected
del self.data[item]
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bosh.py", line 11177, in __delitem__
apath.rmtree(safety='Installers')
File "C:\Program Files (x86)\Bethesda Softworks\Oblivion\Mopy\bolt.py", line 477, in rmtree
shutil.rmtree(self._s)
File "C:\Python26\lib\shutil.py", line 225, in rmtree
onerror(os.rmdir, path, sys.exc_info())
File "C:\Python26\lib\shutil.py", line 195, in onerror
raise
File "C:\Python26\lib\shutil.py", line 223, in rmtree
os.rmdir(path)
WindowsError: [Error 145] The directory is not empty: 'C:\\Program Files (x86)\\Bethesda Softworks\\Oblivion Mods\\Bash Installers\\Cava Obscura'

The folder is not deleted. If I then try again, the folder is deleted with no problems. This bug has been around for ages, I just always forgot to note what the error said.

[Jessie]

Requirements:

• http://www.python.org/ftp/python/2.6.6/python-2.6.6.msi, http://downloads.sourceforge.net/wxpython/wxPython2.8-win32-ansi-2.8.10.1-py26.exe, http://sourceforge.net/projects/comtypes/files/comtypes/0.6.2/comtypes-0.6.2.win32.exe/download, http://www.voidspace.org.uk/downloads/psyco-1.6.win32-py2.6.zip, and http://sourceforge.net/project/platformdownload.php?group_id=78018.
  (Probably best to just download Wrye Python 03 package from http://tesnexus.com/downloads/file.php?id=22368 unless you like to customize your install).
  Older/Newer versions _may_ work but those are probably best and what most of use (and is done the most testing with).

[/list]

I'm confused about the Wrye Python 03a package with regards to this post. The WP03a package includes the following:
Python 2.6.5 / wxpython 2.8.11.0 (ansi not specified) / ComTypes 0.6.2 / PyWin32 2.14 / Psyco 1.6
So it has a lower version of Python and a higher version of wxpython.

[james kite]

Still no oblivion - I skimmed through the previous thread and I have a couple of comments - why renaming the Bash Installers dir to Bain Installers ? - may cause confusion and break something (backward incompatibility). I understand there are reasons of uniformity so to speak but may be ill advised. Plus I have a special affection for this folder

I don't see how renaming Bash Installers to BAIN Installers could cause any issue, other than people being slightly confused at first, but it will be immediately apparent when they try to navigate to the Bash Installers folder.
There is no pertinent reason to change the name but the folder is going to be moved anyways, so renaming to BAIN because it is for BAIN mods, not just any mods, plus then it will compliment the BAIN Converters and BAIN Projects folders will will be at the same level. It will break backward compatibility, but that is going to be broken significantly anyways, which is exactly why these things should be changed now, all in one go.

PS. Bash is actually pretty friendly when it comes to upgrades like this. If you upgrade from an older version where you already have existing folders, Bash will use your legacy directories. So if you really wanted Bash Installers, you could just ensure that the folder exists in the appropriate place. Bash will detect it for you and use that instead of creating the new BAIN Installers folder.
The new folders would only take effect if you completely uninstall Bash (deleting all Bash folders), then reinstall.

Second - not moving hidden packages physically from the Installers dir would cause problems - a ) clutter (when there are 100s of installers to have another couple 100s files present makes directory maintenance even more difficult) - b ) in case settings/back up gets corrupted one has to manually separate installers from ex hidden and this should not happen to anybody - c ) hidden packages end up hidden for various reasons - packages used for BFCs, older versions of mods, mods to be tried to name but just a few. I have physical subfolders in the hidden directory with various categories of hidden files and manage them by hand - deleting staff no longer needed rearranging etc. I had once requested to expand the hide menu item like :

To sum it up - not only hide them physically but take this as a feature request

Icky, I don't like Bash's method of hiding anything at all. It's very unintuitive and hugely prone to confusion.
If you want to physically hide your installers, why not just move those files from explorer? If convenience is your only reason, I'm inclined to say tough luck
Bash does a whole lot of stuff, but it's no replacement for Windows Explorer.

Perhaps you also didn't realize that the main purpose of rearranging the Bash Installers folder is to make it possible to have sub-folders within your Bash Installers, that you can use to organize all your mods.
This will open up an avenue for all sorts of new features that can easily supersede the current wimpy hide feature. Your suggestion for grouping hidden installers for example, could be easily duplicated by creating a sub-folder named hidden, with group folders within, and be collapsible from the list in the installers tab.

[Captian Caveman]

I'm confused about the Wrye Python 03a package with regards to this post. The WP03a package includes the following:
Python 2.6.5 / wxpython 2.8.11.0 (ansi not specified) / ComTypes 0.6.2 / PyWin32 2.14 / Psyco 1.6
So it has a lower version of Python and a higher version of wxpython.

Python and wxPython are two separately developed software components. Their versions don't really relate to each other. Just like the other components listed above aren't all the same version.

[Dan Stevens]

What's with this thing about renaming Bash Installers to BAIN Installers - I haven't followed the discussion, but I'd like to point out that (AFAIK) BAIN is an acronym for BAsh INstallers. Changing the folder to BAIN Installers is silly, because then it would be Bash Installers Installers.

[Siobhan Wallis-McRobert]

Python and wxPython are two separately developed software components. Their versions don't really relate to each other. Just like the other components listed above aren't all the same version.

You missed the point. Look closer. I just installed Python 2.6.6 and it borked everything. Couldn't start WB. Then I ignored the first post, uninstalled all and installed the WP03a package.
Now WB starts, but I get a wxPython: stdout/stderr popup:
# Generating comtypes.gen._99AB80C4_5E19_4FD5_B3CA_5EF62FC3F765_0_1_0
# Generating comtypes.gen._00020430_0000_0000_C000_000000000046_0_2_0
# Generating comtypes.gen.stdole
# Generating comtypes.gen.myole4ax
# Generating comtypes.gen._EAB22AC0_30C1_11CF_A7EB_0000C05BAE0B_0_1_1
# Generating comtypes.gen.SHDocVw

I don't know why I decided to upgrade to Python 2.6.6, anyway. Python 2.5.6 was working fine. If as stated in the first post, you are developing WB using Python 2.6.6 and we are installing Python 2.6.5, that might explain why people are getting these bizarre startup errors lately.
Forgot to mention, I'm running WB 2.85 because although WB 2.87 is stable, rebuilding the patch was much slower.

[LuBiE LoU]

# Generating comtypes.gen._99AB80C4_5E19_4FD5_B3CA_5EF62FC3F765_0_1_0
# Generating comtypes.gen._00020430_0000_0000_C000_000000000046_0_2_0
# Generating comtypes.gen.stdole
# Generating comtypes.gen.myole4ax
# Generating comtypes.gen._EAB22AC0_30C1_11CF_A7EB_0000C05BAE0B_0_1_1
# Generating comtypes.gen.SHDocVw

Interesting. I'm using mTES4 to switch installs and when running the install that uses WB 2.85, I don't get the above errors. And now I can go back to Oblivion! Yay! :foodndrink: :bolt:

[Trey Johnson]

I have no time now but hopefully soon I'll look more into it - this back up feature really thrills me and I am sorry I was not around when it was proposed. I don't know how you plan on exporting the settings - if at all. An export feature would be great.
I will look in SF and give more feedback asap

I've already made the changes to be able to handle restoring a backup to a different install. The patch has been uploaded, it's just waiting to get committed to the SVN.

This has already been proposed many times already in many variations - by me also - I proposed the markers to appear with a little cross by them which if clicked would collapse all installers till next marker/end. Do not know if even possible - got the answer that for the moment was not planned - I understand it might be a huge hassle. The Firefox bookmarks scheme is rather rigid for BAIN though methinks - and definitely not reflect this on the drive - would be too complicated implementation wise I think. Just the markers being collapsible would perfectly do - it would be hugely useful when BAINing one's install - instead of scrolling up and down past hundreds of entries. Would be also easy to focus into each group and order it. So for organizational purposes making the markers into collapsible headers would jolly well do - without messing up the internals of BAIN.
Hide functionality would be needed anyway - cf my post

I agree. (except about the hide functionality )
The idea is that once the folders have been reorganized, it will then be possible to have subfolders within the Bash Installers folder. Just that alone would be a good addition I think. All the installers would still be displayed using a flat list in Bash but you could organize your installers on disk for better management and less clutter. So far, I haven't really explored how the folders could be used in conjunction with display and management within the installers tab.

I'm thinking that the subfolders could be used to create automatic markers. These would just be a default behaviour. EG. when a new subfolder is detected a corresponding marker is created and all installers that are detected within that folder are grouped under that marker. Otherwise, you could still arrange all your installers and markers however you want, just like now.

As far as collapsible markers go, if it's doable without too much trouble I think it's a good idea.

What's with this thing about renaming Bash Installers to BAIN Installers - I haven't followed the discussion, but I'd like to point out that (AFAIK) BAIN is an acronym for BAsh INstallers. Changing the folder to BAIN Installers is silly, because then it would be Bash Installers Installers.

Yes, but that's just semantics
I did also consider BAIN Mods or BAIN Archives, but I think this deviates a bit too much from what people are used to. BAIN Mods might be ok.

Part of my reasoning for this change is not just for conformity but also to help ensure that the BAIN folders remain grouped together since they would no longer be nested.
Currently, I suspect alot of people use the Oblivion Mods folder to store all their downloaded archives, BAIN or not.
When the BAIN folders are mingled with several dozen other folders, it would be good if they at least remain together, if not at the top of the directory list as well.
It's not a big issue of course, so I'm not opposed to leaving the name. There is still going to be the Bash Mod Data folder anyways, so the effort to keep them all grouped is incomplete anyhow.

You missed the point. Look closer. I just installed Python 2.6.6 and it borked everything. Couldn't start WB. Then I ignored the first post, uninstalled all and installed the WP03a package.

I don't know why I decided to upgrade to Python 2.6.6, anyway. Python 2.5.6 was working fine. If as stated in the first post, you are developing WB using Python 2.6.6 and we are installing Python 2.6.5, that might explain why people are getting these bizarre startup errors lately.
Forgot to mention, I'm running WB 2.85 because although WB 2.87 is stable, rebuilding the patch was much slower.

Oh I see. AFAIK, if you use python 2.6.6 you should be using wxPython 2.9 or higher

[patricia kris]

I did also consider BAIN Mods or BAIN Archives, but I think this deviates a bit too much from what people are used to. BAIN Mods might be ok.

Part of my reasoning for this change is not just for conformity but also to help ensure that the BAIN folders remain grouped together since they would no longer be nested.
Currently, I suspect alot of people use the Oblivion Mods folder to store all their downloaded archives, BAIN or not.
When the BAIN folders are mingled with several dozen other folders, it would be good if they at least remain together, if not at the top of the directory list as well.

Actually I have the downloaded archives on a whole other hard drive where I also format the archives into BAIN archives. I've read several others do the same. This creates some redundancy but in a good way.

I think BAIN archives make the most sense.

but that is just my 2cents and likely it is all going to be a giant step forward and yeah naming is semantics.

[Jaki Birch]

You missed the point. Look closer. I just installed Python 2.6.6 and it borked everything. Couldn't start WB. Then I ignored the first post, uninstalled all and installed the WP03a package.
Now WB starts, but I get a wxPython: stdout/stderr popup:
# Generating comtypes.gen._99AB80C4_5E19_4FD5_B3CA_5EF62FC3F765_0_1_0
# Generating comtypes.gen._00020430_0000_0000_C000_000000000046_0_2_0
# Generating comtypes.gen.stdole
# Generating comtypes.gen.myole4ax
# Generating comtypes.gen._EAB22AC0_30C1_11CF_A7EB_0000C05BAE0B_0_1_1
# Generating comtypes.gen.SHDocVw

I don't know why I decided to upgrade to Python 2.6.6, anyway. Python 2.5.6 was working fine. If as stated in the first post, you are developing WB using Python 2.6.6 and we are installing Python 2.6.5, that might explain why people are getting these bizarre startup errors lately.
Forgot to mention, I'm running WB 2.85 because although WB 2.87 is stable, rebuilding the patch was much slower.

That is actually normal. From the Readme (Contents -> Installation -> Common Problems):
? Generating comtypes

? The very first time you run Bash after installing ComTypes, you may get a popup with six lines similar to: # Generating comtypes.gen.stdole

? Close the popup and ignore it. It shouldn't appear again unless you reinstall ComTypes.

[carrie roche]

Bash takes a while to read all the data under the Installers tab, but it's gotten ridiculous.

Quick summary of what I've been doing: I''ve been reworking my setup (who doesn't?) and decided to try PyFFI-ing files, so I unpacked the bsa files and wanted to try them as projects (or is it packages?) so I don't have to delete all those files by hand in case I decide to repack them as bsa files at a later time. So I've got them as big directories, unarchived, and I'm only working on the OB & SI ones so far.

But it takes forever to load up. I figured it would the first time, but every time I click it's as if it starts over. And it only takes a command every other time I click so it's two load cycles per single action. And after every single click it reloads, seemingly from scratch.

Attempted fixes: uninstalling and reinstalling, both Bash and Python.
The debug doesn't generate a file. (I'm used the system from the readme, is there another way to active debug?)
UAC is at 0, and I just use the defaults for the installs.
Installers.dat, etc. all update so writing should be ok.

[Alexxxxxx]

Bash takes a while to read all the data under the Installers tab, but it's gotten ridiculous.
...
But it takes forever to load up. I figured it would the first time, but every time I click it's as if it starts over. And it only takes a command every other time I click so it's two load cycles per single action. And after every single click it reloads, seemingly from scratch.

I'm actually planning something out that would make the installers tab immediately usable without the lengthy preload. But in the meantime, it sounds like you have "auto-refresh" checked. It would probably make things better for you if you uncheck it. Just be aware that Wrye Bash will no longer be monitoring changes to projects made from outside Wrye Bash (e.g. in windows explorer) that happen while Wrye Bash is open.

[Steeeph]

I'm actually planning something out that would make the installers tab immediately usable without the lengthy preload. But in the meantime, it sounds like you have "auto-refresh" checked. It would probably make things better for you if you uncheck it. Just be aware that Wrye Bash will no longer be monitoring changes to projects made from outside Wrye Bash (e.g. in windows explorer) that happen while Wrye Bash is open.

That sounds like an ambitious but useful project.

Thanks for the suggestion. I had forgotten about that setting and (after waiting through about 3 cycles) was able to de-select it. It did help while WB was up. But after I closed it, it stopped working ... meaning it won't start again. I think it's pythonw.exe. Python.exe will start, and then WB starts, but it doesn't really function anymore. So something is 'more wrong' than I had thought.

I'm going to sleep and ponder. Cheers.

Edit/Update: Ah. I started searching this morning using different words (because I was looking for a different problem now) and found there may be a problem with the latest verstion of WB. Sorry for the wasted posts. (Hate the search, I never find what I need except by accident!!!!!)

[sam westover]

You can select everything and mark mergeable.

Gaticus,

THX awfully. Looks like this solved my problem.

Regards, Haldir

[Hayley Bristow]

Icky, I don't like Bash's method of hiding anything at all. It's very unintuitive and hugely prone to confusion.
If you want to physically hide your installers, why not just move those files from explorer? If convenience is your only reason, I'm inclined to say tough luck
Bash does a whole lot of stuff, but it's no replacement for Windows Explorer.

Again in a hurry - please do not make Bash a worse program
I have used it a lot with installations of hundreds of files and believe me it is a replacement for explorer. And it should remain so. You are not suggesting seriously I should fire up explorer and start looking around for the file I want to hide (amongst 100s of others) and then cut it and then navigate to another folder and then paste it - and this some dozens of times in a session maybe - when at present I can just right click and select hide !?!
Seriously - have you worked with bash, installing a huge collection of mods ? It is a very beautiful program - its only two drawbacks being the markers not being collapsible (probably cause nobody had foreseen those huge collections) and the limited hiding options. With those 2 additions it reaches perfection - if it ain't broken (far from it) do not fix it.

Currently, I suspect alot of people use the Oblivion Mods folder to store all their downloaded archives, BAIN or not.

Yes we do - we are using Bash to manage our Oblivion install - and apart from people that launched Ob via bash in their first gaming session (which are few if any) this means that most of us migrated a huge collection of mods to bash - I really cannot explain what this entails and how well bash stood to the challenge. When I first did BAIN my install there were more (minor) annoyances which were all fixed as per my requests - thanks again here for this :goodjob:
Take this scenario - someone hears about BAIN and dumps a couple 100s archives in Bash Installers - including mods one wanted always to try and not Bain ready mods and whatnot. Took me weeks and hide saved my day - one of my requests was the ability to hide multiple packages at once - granted. Say one wants to try say the music mods out there - downloads a few in the bash installers and starts trying them - right click > hide the ones he rejects (but does not want to delete). One creates BFCs and wants to keep the original archives - right click > hide. One rejects a mod but wants to keep just in case - right click > hide. So if the user can create default hide destinations - perfection.

I agree. (except about the hide functionality )
The idea is that once the folders have been reorganized, it will then be possible to have subfolders within the Bash Installers folder. Just that alone would be a good addition I think. All the installers would still be displayed using a flat list in Bash but you could organize your installers on disk for better management and less clutter. So far, I haven't really explored how the folders could be used in conjunction with display and management within the installers tab.

I'm thinking that the subfolders could be used to create automatic markers. These would just be a default behaviour. EG. when a new subfolder is detected a corresponding marker is created and all installers that are detected within that folder are grouped under that marker. Otherwise, you could still arrange all your installers and markers however you want, just like now.

As far as collapsible markers go, if it's doable without too much trouble I think it's a good idea.

So I find this idea of folders really unnecessary : why ?
I used to have hundreds of folders with various mods in my hdd and it was a hell to maintain - that's why I switched to Bash ! Now I have an interface listing the mods I use / try / develop and the hidden folder which has all the rejected/converted/curiosities/etc. Instead of folders manually created and nested in other folders (yiick) - markers in bash. The notes are in the comments section - no more stray txts. True I have to manually organize the folder with the hidden packages - but this will change soon no ?
I really find this whole folder affair a step backwards - huge step at that- maybe nice for people with 20 mods to have a tree view but not for any serious modder - and it is us using bash - I still may be wrong :shrug: - I wonder what people have to say.

I would suggest instead of spending your energy in this - try to make OBSE plugins BAIN installable ! This would be grant ! No more digging with explorer - renaming the dlls - moving readmes around - etc (etc)
And one less folder outside of bash needing maintenance