[evelina c]

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

NO. Just dear god no! There's perfectly valid and important reasons why BAIN doesn't handle executables and dlls, mostly to do with security. Yes, it is slightly more work to do it manually, but it's not the massive hardship you are almost portraying it as: just drag 'n' drop from the archive. Yes, you have to use Explorer - heaven forbid you use the system file manager to manage your files! It's not like you can't still store the archives in the BAIN folder, you were talking about that a couple of lines above.

[Madison Poo]

NO. Just dear god no! There's perfectly valid and important reasons why BAIN doesn't handle executables and dlls, mostly to do with security. Yes, it is slightly more work to do it manually, but it's not the massive hardship you are almost portraying it as: just drag 'n' drop from the archive. Yes, you have to use Explorer - heaven forbid you use the system file manager to manage your files! It's not like you can't still store the archives in the BAIN folder, you were talking about that a couple of lines above.

:D
Ok - didn't know there were security reasons - no I do not store them there - I hate this gray - "hey this is not for me (BAIN) to handle" - color
I mean in situations when one wants to test OBSE bugs etc - so one has to manually install each and every plugin etc - and there are some that install other files too (say CSI) - and oops what version is it ? - come on wouldn't it be great to have Bash do this for us ? And have all those 7z neatly packed and accessible via bash - and all notes there. Well damned security :rolleyes:

What about the other issues discussed ?

[Charlie Ramsden]

NO. Just dear god no! There's perfectly valid and important reasons why BAIN doesn't handle executables and dlls, mostly to do with security. Yes, it is slightly more work to do it manually, but it's not the massive hardship you are almost portraying it as: just drag 'n' drop from the archive. Yes, you have to use Explorer - heaven forbid you use the system file manager to manage your files! It's not like you can't still store the archives in the BAIN folder, you were talking about that a couple of lines above.

Thank heavens that idea is being stop-checked.

Imagine user downloads new BAIN from new poster on nexus, throws it straight into Bash Installers, rootkit installed.

[Queen Bitch]

:D
Ok - didn't know there were security reasons - no I do not store them there - I hate this gray - "hey this is not for me (BAIN) to handle" - color
I mean in situations when one wants to test OBSE bugs etc - so one has to manually install each and every plugin etc - and there are some that install other files too (say CSI) - and oops what version is it ? - come on wouldn't it be great to have Bash do this for us ? And have all those 7z neatly packed and accessible via bash - and all notes there. Well damned security :rolleyes:

What about the other issues discussed ?

I use OBMM for this. It's the only thing I use it for, but since it's a DLL there's no concern about ordering. And there's no conflict with WB, which is what I use for everything else. Hope this makes it easier for you.

[Ana]

Imagine user downloads new BAIN from new poster on nexus, throws it straight into Bash Installers, rootkit installed.

Unfortunately, that is the status quo with OBMM.

To utumno's point, though, I think I agree with him that tree-based organization can hide information in unintuitive ways. There is a reason why gmail didn't have the ability to create a tree of folders at its release (though they eventually caved in to pressure from people who were used to organizing their mail that way). Their idea was that everything should be in a flat structure at the top level, and to just make the interface intuitive enough that everything is accessible.

[vicki kitterman]

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

I hope PM changes that, to avoid confusion. By the way, the first thing I though of was the existence of a left over PID file. But turns out it was caused by incompatable versions. Thanks for looking at the issue.

[Nomee]

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.

Ok, Thanks for pointing that out! Now I can continue to test with WB v287.

[Blackdrak]

You mean to tell me that you people (some of you even) actually keep all downloaded mods in the same folder where you have your BAIN archives. What a giant mess that would be.

I just can't imagine how many times the readme would get overwritten, and that small bits of archives that say main file, alternate file, readme, the second part, body meshes, and so on cluttering up the BAIN folder. Yuck - what lack of organization. What lack of redundancy as well. I hope that is not the case. By creating a well laid out library elsewhere and keeping the bash installers for what it is meant for (managing the data folder) you are going to save yourself a heck of a lot of time and effort. Otherwise that is like mashing together in one folder a library of downloaded archives mixed together with the BAIN packages and totally ruining the reason for BAIN. If an archive is not BAIN friendly it has no purpose being in the Bash Installers folder and I'd think the same goes for archives you are never going to install into the data folder.

Please lets NOT implement changes based on the assumption that this is normal behavior. Bash is NOT a replacement for explorer.

And to be straight to the point - the main reason that Wrye Bash does not handle OBSE plugins, shaders, and originally not ini folders is because Wrye didn't want it to. It was a big drama when everyone said it should and he stood firm. After all the dust settled Wrye stopped posting here altogether and the current maintainers out of respect have not implemented these things -- well now I guess recently the recognition on ini folder. I don't know about shaders but an OBSE plugin seems it would be easy to do and if concerns are warranted then have a pop up window that say WARNING and maybe a link to how it could be detrimental. That would be way more than what OBMM does and as Bash does not handle it then it basically means that people are going to use OBMM or by hand and neither one of those methods give warning either. Providing a warning or check of some kind then turns this into a service not a limitation.

I mean no disrespect to Wrye whose tools I've promoted through thick and thin and use more days than not.

[NO suckers In Here]

You mean to tell me that you people (some of you even) actually keep all downloaded mods in the same folder where you have your BAIN archives. What a giant mess that would be.

I just can't imagine how many times the readme would get overwritten, and that small bits of archives that say main file, alternate file, readme, the second part, body meshes, and so on cluttering up the BAIN folder. Yuck - what lack of organization. What lack of redundancy as well. I hope that is not the case. By creating a well laid out library elsewhere and keeping the bash installers for what it is meant for (managing the data folder) you are going to save yourself a heck of a lot of time and effort. Otherwise that is like mashing together in one folder a library of downloaded archives mixed together with the BAIN packages and totally ruining the reason for BAIN.

Please lets NOT implement changes based on the assumption that this is normal behavior. Bash is NOT a replacement for explorer.

And to be straight to the point - the main reason that Wrye Bash does not handle OBSE plugins, shaders, and originally not ini folders is because Wrye didn't want it to. It was a big drama when everyone said it should and he stood firm. After all the dust settled Wrye stopped posting here altogether and the current maintainers out of respect have not implemented these things -- well now I guess recently the recognition on ini folder. I don't know about shaders but an OBSE plugin seems it would be easy to do and if concerns are warranted then have a pop up window that say WARNING and maybe a link to how it could be detrimental. That would be way more than what OBMM does and as Bash does not handle it then it basically means that people are going to use OBMM or by hand and neither one of those methods give warning either.

I mean no disrespect to Wrye whose tools I've promoted through thick and thin and use more days than not.

I agree with the majority of your post, but I'd like to point out that BAIN does install shaders, there's no problem with them. Editing shaders is a completely different thing, and I'm not so sure it's a real decision not to implement it so much as it just hasn't ever been gotten around to, like BSA stuff. Also, I suppose having a massive WARNING message box when installing a mod involving a dll might be enough, but I'm going to be a stick in the mud and say I still think it should be manual, but there you go.

[Flesh Tunnel]

I agree with the majority of your post, but I'd like to point out that BAIN does install shaders, there's no problem with them. Editing shaders is a completely different thing, and I'm not so sure it's a real decision not to implement it so much as it just hasn't ever been gotten around to, like BSA stuff. Also, I suppose having a massive WARNING message box when installing a mod involving a dll might be enough, but I'm going to be a stick in the mud and say I still think it should be manual, but there you go.

You know what I use OBMM for? What BAIN can't do.

Those that use OBMM are not limited and are as unprotected. Some OBSE plugins even come as OMODs. Exactly what are these OBSE plugins that have caused such damage? Any history at all?

Further, so what if you install by hand? If it is malicious then what protection is there by installing by hand? You won't get a warning then and it really is that you either know or you don't.

As I edited my post above to point out this could be turned into an extra layer of protection (that could be toggled like expert use of tes4edit) and provide utility.

[Sakura Haruno]

Yet again I uninstalled the reinstalled Wrye Python 0.3a. (this means uninstalling, cleaning, rebooting, cleaning and rebooting again ... then installing, cleaning, rebooting ... etc)
Ran the installer for Wrye Bash 2.75.

Started Wrye Bash. I waited 37:10 (min:sec) for it to refresh installers. Then I installed just ONE project. Closed. Restarted. And it wasn't saved.

That was one time. I've tried everything at least 3 times. Nothing is working.

Never get past this for the debug mode:
Traceback (most recent call last):
File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\basher.py", line 6174, in Execute
deprint(_('Debug Printing: On'))
File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\bolt.py", line 1202, in deprint
stack = inspect.stack()
File "C:\Python26\lib\inspect.py", line 953, in stack
return getouterframes(sys._getframe(1), context)
File "C:\Python26\lib\inspect.py", line 931, in getouterframes
framelist.append((frame,) + getframeinfo(frame, context))
File "C:\Python26\lib\inspect.py", line 900, in getframeinfo
raise TypeError('arg is not a frame or traceback object')
TypeError: arg is not a frame or traceback object

[Marquis T]

Hello again,

I did not wish to bother anyone about this, but I could use some advice or aid with this problem. I have run into a wall with the bashed patch, or at least a particular tweak built into it. I have recently been testing out Slof's Better Bodies pack, and have been weeding out unnecessary character cosmetic mods to ensure compatability. One such mod I wanted to disable (at least temporarily) was Better Redguards and its patches featured in The Race Balancing Project. Disabling those plugins was relatively easy and pain free, and after rebuilding the patch I could run my game without problems. However, what came next was disabling the Redguard FGTS Nuller within the "Tweak Actors" section of the patch.... And this is where things became a little weird. After successfully rebuilding the patch, I started my game up only to find it would freeze at the end of the intro videos. The main menu would not load, and the screen would not load any further, stuck on Bethesda's blurb after the Bethesda Game Studios cinematic ends. Skipping the videos resulted in the same problem, but with a perpetually frozen loading screen instead. I then rebuilt the patch numerous times, regenerated my Oblivion Ini, and finally restarted the computer, but all these attempts were met with no success. I then decided to rebuild the patch again with the FGTS Nuller activated, and lo and behold.... My game could load again to the main menu. Disabling the Patch with the Nuller deactivated also fixed the problem.... But obviously this is not recommended. I have no idea why disabling this tweak would be the cause of such a dramatic effect. Is there a reason why this is happening? On an earlier post PacificMorrowind had mentioned this:

Brozly, on 17 October 2010 - 08:06 PM, said:

I've had a few issues with 290. The first time I build a Patch, it takes ~4 minutes, that's down from 7-8 on previous versions, however, I've Allways left Bash open, but if I Rebuild a Patch now, if I'm lucky it'll take ~8min., maybe 15, 20, or just crash, Unless I close and Reopen Bash...
It doesn't Allways Delete the pidfile.tmp file when it closes...
(running on Python 266)
Tried CBash, thought it was Great, rebuilding Patches consecutivly in ~2minutes, untill I couldn't get the Heads back for the Vanilla NPCs??

The Bugs Are Frustrateing, but It's definatly getting Faster, and I appreciate the New options as well..

CBash shouldn't decapitate anyone but will look into it
Probably a bit of lost memory during Patch build... will see if I can find the leak(s) and plug a few at anyrate.

Sorry for the format of the quote. I know this issue and my own are two different problems and this may be my own false speculation, but could this be the result of lost memory during the build as well? Also, and I know it is a longshot, but has anyone had the same problem? Thank you.

Sealwarrior

[Tyrel]

Yet again I uninstalled the reinstalled Wrye Python 0.3a. (this means uninstalling, cleaning, rebooting, cleaning and rebooting again ... then installing, cleaning, rebooting ... etc)
Ran the installer for Wrye Bash 2.75.

Started Wrye Bash. I waited 37:10 (min:sec) for it to refresh installers. Then I installed just ONE project. Closed. Restarted. And it wasn't saved.

That was one time. I've tried everything at least 3 times. Nothing is working.

Never get past this for the debug mode:
Traceback (most recent call last):
File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\basher.py", line 6174, in Execute
deprint(_('Debug Printing: On'))
File "C:\Program Files\Bethesda Softworks\Oblivion\Mopy\bolt.py", line 1202, in deprint
stack = inspect.stack()
File "C:\Python26\lib\inspect.py", line 953, in stack
return getouterframes(sys._getframe(1), context)
File "C:\Python26\lib\inspect.py", line 931, in getouterframes
framelist.append((frame,) + getframeinfo(frame, context))
File "C:\Python26\lib\inspect.py", line 900, in getframeinfo
raise TypeError('arg is not a frame or traceback object')
TypeError: arg is not a frame or traceback object

You probably need to set administrator rights...

[Terry]

You probably need to set administrator rights...

Do you mean an administrator account? Or setting python to run as an administrator? Or dropping UAC to zero (since you really can not turn it off)? Or removing read only from all directories and files in 'Program Files'? (share, share, share)

I have done all that. Did I miss something?

Edit: Sorry. I'm a bit pissy. But it is not the first time I set up Bash. I'm going backwards and losing hours doing so. Not your fault though, so I'm sorry about my tone.

[Marguerite Dabrin]

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.

[Elisabete Gaspar]

Miran, I seen you installed to Program Files, and Yes that causes problems with UAC, not sure what else to tell you... :shrug:

Sealwarrior, maybe check for a Missing Master ??

Psymon, I put All my downloads into the Download directory(and Subs), unzip all my Mods there and check them over, Rezip/Repackage them, then drop them into the Bash Installers folder.
I Do tend to leave several uninstalled mods in there for awhile, (after an upgrade, troubleshooting..) I don't see a Problem with Sub-Folders though...

[Kelly Upshall]

But essentially your stating there are no non-BAIN ready archives in there?

I've really got nothing against sub-folders though I think it strange anyone would have non-BAIN ready archives in there. For what reason would they? That would be like leaving all the downloaded archives in the OMOD folder because that is where the OMODs are. I see the BAIN tab as more for managing the data folder not cataloging everything I download.

Anyone who has experience converting to either OMODS or BAIN knows that if can get complex and messy fast - consider the many many mods with updated esp, hotfixed meshes, alternate esp, vaguely named archives. Not to mention the many mods that are just not BAIN ready.

What I do is on about drive (or elsewhere) I have the catalog of downloads with folders for types (quests, overhauls,game tweaks, locations, UI, etc) and then within each folder that will be a package (which is already named what I want the archive to be called) there is a folder called '___Source' that is where I keep the downloaded archives. Then the rest of the folder is laid out like it will be once zipped with 7z. Each update is pure simplicity for adding in the new file, placing the downloaded archive in the source folder (maybe deleting the old version). Then rezip and copy to bash installers (either deleting the old first or replacing with the copy command).

True I have a couple terabytes to play with but even if I had less that would be all the more reason not to keep non-BAIN ready archives in the bash installer directory.

Further repackaging in the bash installers directory is going to be a sloppy procedure with the ever mounting number of archives to wade through already there. Then repacking via BAIN seems even less an ideal situation (if it can be done at all). Besides I'd be about discouraging people from using Projects instead of packages.

Again - nothing wrong with sub-folders - I'm just astounded people would use this directory that way.

[OTTO]

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.

A. A. and B.

[Kate Murrell]

I only put mods I want to install in the Bain Installer directory, like Psymon I have over a hundred gigs of mods saved in a highly organized mod catalog on a second hard drive, my BAIN tab would be virtually unusable if I had them all stored in Bain Installers directory. I also use this second hard drive as backup, mods are only ever copied into Bash Installers, never moved, so I always still have another copy if something goes wrong.

I support the idea of adding dll support to BAIN, just slap on a huge warning saying like "This mod contains a dll file. It is possible for a file of this type to contain malicious code, so you should only install this mod if you trust the author." True it's not that hard to install obse plugins manually, but the same could be said about many mods, and what is BAIN about if not to provide users with convenient and user-friendly mod installation?

[David Chambers]

Pysmon, I think you are slightly confused.

My statement earlier (that I think you have misconstrued) was about speculating that alot of users would place all their downloaded archives in Oblivion Mods\ not Oblivion Mods\Bash Installers\

Bash Installers\ should only be used to store BAIN archives as a matter of practice. Bash doesn't enforce this of course and should not, but I don't think anybody is suggesting that it should be used for general storage of all mod archives.

Being able to have subfolders within the Bash Installers folder is a separate topic and is merely for the users own organization on disk. Bash would still see it all as if everything were in a single folder.

[Daddy Cool!]

Hmm yes maybe I did jump to a conclusion based on a misunderstanding - apologies on that.

So with this system you are proposing/designing - if a person installs a package - can they then hide the package? Or move to a subfolder?

No I don't keep any mods in the Oblivion Mods\ directory as that would create no back up in case of drive failure. Truthfully though it never crossed my mind to use it that way because of the lack of redundancy + I want to have things just so before installing. This means esm/esp cleaned, meshes optimized, folders organized. I want what is in the the BAIN folder to be ready to go and all BAIN ready.

So sorry if I went on a tangent there - thanks for reality check.

[Rachael]

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.

No it is not. If you have adapted to using it that way, that has nothing to do with what Bash is intended for.

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 !?!

To be short, yes. But I think you have missed part of the plan. The hide functionality would be replaced not removed. You would still be able to hide your installers from Bash, they just would not be physically moved.

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.

That is your opinion, I don't agree. Bash is a fantastic tool, but there is still plenty of things that can be made even better.

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.

This is not what the hide feature was intended for. The hide feature is meant for temporarily hiding BAIN installers and the whole idea of dumping everything in an obscure and hard-to-find folder is an issue of concern that has been discussed for a quite a while.

I agree with the majority of your post, but I'd like to point out that BAIN does install shaders, there's no problem with them. Editing shaders is a completely different thing, and I'm not so sure it's a real decision not to implement it so much as it just hasn't ever been gotten around to, like BSA stuff. Also, I suppose having a massive WARNING message box when installing a mod involving a dll might be enough, but I'm going to be a stick in the mud and say I still think it should be manual, but there you go.

A toggle setting in the bash.ini to enable to ability to installed dangerous file types would be a solid way of ensuring the user knows what they are doing.
A toggle setting in the r-click menu of the installers tab would be a less stringent way. I would probably still have bash warn the user on install, but I would want a checkbox or setting to disable the warnings.

[edit]

So with this system you are proposing/designing - if a person installs a package - can they then hide the package? Or move to a subfolder?

Yes. The hide functionality is actually a separate issue altogether, unrelated to if we can have Bash Installers subfolders or not. I should point out that the ability to have subfolders is still later on down the road and is not part of the plan to restructure the bash folders. More thought still needs to be put into it. The restructure will just make it possible. The change to the hide functionality will also not be a part of the restructure, to be clear.
One step at a time.

[Matt Terry]

Forgive me for not wanting to wade in detail through the last 4 pages. What's all this hooey about renaming folders? What's WRONG with the existing folder names as they are now? I think someone in this mess said "if it ain't broke, don't fix it". Perhaps they should ponder those words more carefully before going off to restructure everything about where stuff goes?

As for the OBSE plugins issue - I agree with the logic of not allowing BAIN to install DLL and/or EXE files into the game's Data area. Things of that nature really are something the user should be doing manually, and if OBMM is doing it blind, shame on it for ignoring the potential for disaster. Let's not be like that.

[Roanne Bardsley]

Forgive me for not wanting to wade in detail through the last 4 pages. What's all this hooey about renaming folders? What's WRONG with the existing folder names as they are now? I think someone in this mess said "if it ain't broke, don't fix it". Perhaps they should ponder those words more carefully before going off to restructure everything about where stuff goes?

As for the OBSE plugins issue - I agree with the logic of not allowing BAIN to install DLL and/or EXE files into the game's Data area. Things of that nature really are something the user should be doing manually, and if OBMM is doing it blind, shame on it for ignoring the potential for disaster. Let's not be like that.

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.

[Laura Cartwright]

To utumno's point, though, I think I agree with him that tree-based organization can hide information in unintuitive ways. There is a reason why gmail didn't have the ability to create a tree of folders at its release (though they eventually caved in to pressure from people who were used to organizing their mail that way). Their idea was that everything should be in a flat structure at the top level, and to just make the interface intuitive enough that everything is accessible.

:goodjob:

You mean to tell me that you people (some of you even) actually keep all downloaded mods in the same folder where you have your BAIN archives. What a giant mess that would be.
I just can't imagine how many times the readme would get overwritten, and that small bits of archives that say main file, alternate file, readme, the second part, body meshes, and so on cluttering up the BAIN folder. Yuck - what lack of organization....Bash is NOT a replacement for explorer.

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 (edit:) in the installers tab and my brain) - 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

My statement earlier (that I think you have misconstrued) was about speculating that alot of users would place all their downloaded archives in Oblivion Mods\ not Oblivion Mods\Bash Installers\

Bash Installers\ should only be used to store BAIN archives as a matter of practice. Bash doesn't enforce this of course and should not, but I don't think anybody is suggesting that it should be used for general storage of all mod archives.

Being able to have subfolders within the Bash Installers folder is a separate topic and is merely for the users own organization on disk. Bash would still see it all as if everything were in a single folder.

:goodjob: (highlight mine) - apart for the folders on disk helping organization :rolleyes:
Or as I use it 2 (main) folders - Bash Installers (working) and Hidden (with subfolders).

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.

No it is not. If you have adapted to using it that way, that has nothing to do with what Bash is intended for.

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 !?!

To be short, yes. But I think you have missed part of the plan. The hide functionality would be replaced not removed. You would still be able to hide your installers from Bash, they just would not be physically moved.

This is not what the hide feature was intended for. The hide feature is meant for temporarily hiding BAIN installers and the whole idea of dumping everything in an obscure and hard-to-find folder is an issue of concern that has been discussed for a quite a while.

Now - please - I insist they should be physically moved - and I gave you some reasons for it http://www.gamesas.com/index.php?/topic/1129495-relz-wrye-bash-thread-53/page__view__findpost__p__16600065 - how about renaming the hide to move ? Does it make sense ? And no it is not an obscure and hard-to-find folder - right click > unhide for god's sake ! It is as obscure and hard-to-find as Installers.
Important : You keep repeating to me that this was not intended for that or not meant for this etc - yes but it works now. Like a charm. Please take some time to consider my proposals on the way I use bash - surprising as it may be for some it is really efficient. And as you say - bash should not enforce us users using it one way or another - no good program should, ever.

As for the OBSE thing - maybe a code patch for the daring ? Complete with warnings ? After the initial are you craaazy reaction I think some people went hmmm well maybe in some cases mutatis mutandis
Ok off topic really - or maybe we should learn python lol

A toggle setting in the bash.ini to enable to ability to installed dangerous file types would be a solid way of ensuring the user knows what they are doing.
A toggle setting in the r-click menu of the installers tab would be a less stringent way. I would probably still have bash warn the user on install, but I would want a checkbox or setting to disable the warnings.

Definitely an ini tweak - still i respect wrinklyninja's concerns - hadn't thought of security.