You know, sometimes they are out to get you. But not this time. They would still have to be activated in some way:
1) They're only "hidden" in the size that they don't look like esps/esms to the game engine, thus the game engine would never see or load them.
2) In bash, all "hidden" mods would be listed just as if they were not hidden -- so they wouldn't be hidden from bash.
3) If you activate a hidden mod in bash, then it would have to unhide it in order for the game engine to see it.
4) But if you used the bashed patch to integrate the mod in same way (merge or import), then the mod could remain hidden so long as the mod isn't activated. And again here, you'd have to merge or import the mod in the usual way in the patch.

One thing to think about... TES4Edit/FO3Edit likes to make lots of .backup and .save files in the /Data/ folder, so that might need some working-with as well.

Thanks Wrye for the detailed information

Screenshots: Psymon reports that you can save screenshots outside the Oblivion directory simply by setting the relevant Oblivion.ini setting correctly. If you're using Bash, you can do that easily by going to screenshots tab, right clicking on column header and selecting "Next Shot..." then you set the screenshot to something like "..\Oblivion Mods\Screenshots\baseName01"

I'm pretty sure that those don't get included in espm thrashing. They're probably best hand-cleaned, since they're backup files that are there for a reason. (Though I suppose that Bash could auto-delete them if they're a month or more older. That would be far down my priority list though.)

I just drag them all into my /Data/backups/ subfolder. I have several thousand in there.

So let me get this straight guys. Anything in the oblivion folder gets scanned by oblivion and increases chance of crashing or slowdown stutter while playing the game? I actually installed OBMM and wyrebash in my d:\games\oblivion So i should move those folders out probably delete every txt file i can find and extra folders left by fcom or other mods in the data folder and i may have a more stable faster oblivion?

It sounds like that is the case.. If so i got a lot of clean up to do. =P

It's not that extreme. Essentially, there are three possible problems:
1) Lots of esps (roughly over 340) in the Data directory. Oblivion seems to do something with these even if they're not active. Too many results in weird behavior.
2) Too many directories and/or tons of files in directories. In this case, there have to be a *lot* of such directories/files for there to be a problem, so just a small or even moderate number of directories/files should not be a problem.
3) Lots of exes, dlls, etc. Oblivion.exe seems to scan them in some way. And this will take longer. So better if they're not present.

So for me that means:
1) Don't put bash installers under Oblivion. Shouldn't be a problem to leave Bash itself in place though.
2) (Optionally) move bash data elsewhere. Probably not a problem anyway, since they tend to not be bloated.

Yeah I don't think anyone should go crazy over it but it's just generally a good idea for people to be mindful of what they put in their game directory and subdirectories and also what's already in there.

Programs I think are fine. I have BASH, BOSS etc in mine and don't seem to have issues.

What I would say is that any non-essential files that can be reasonably moved out of the game directory tree without much effort probably should be. This goes for any currently unused esps, image files, text or document files, backup files etc. It's really not any big deal to find another directory to put those in. At least it wasn't for me.

With Morrowind the game would crash if you tried to load a saved game and had more than about 400 save games in the same directory.
Seems to be a common theme with the game engine processing files it shouldn't process...

Is there any way that Bash might be persuaded to automatically hide unchecked .esp's, for those who run multiple profiles? Many of the extra .esp's in my Data directory come from Bashed patches, for various profiles ... and each character has his own set of checked mods. Since I switch profiles often, hiding the unchecked ones each time I want to play is a prohibitive task. But it would certainly help to keep the number of .esp's down if Bash would not just remember which ones to activate, but also move them to a safe place (out of Oblivion's sight) for retrieval when the user switches profiles.

Mod-ghosting is high on the priority list, but it will be a lot of work to code and I'm pretty tapped out after work on Bain.

Mod-ghosting will rename inactive esms/esps will consist of appending a ".ghost" extension to the filename of mods (e.g. "bob.esp" >> "bob.esp.ghost"), thus hiding them from the game engine. The mods would still show up in Bash as if they had their regular extension. The shifting would be automatic as you activated/de-activated mods.

The main hassle is that this involves changing a lot of code in a lot of places (or at least checking code in a lot of places).

Edit: Renaming to "mod-ghosting".

So leaving the inactive files in the folder if you change the extension will keep the game engine from checking them ? or does it scan all files in the folder regardless of the extension ?

Two separate problems: Espm thrashing and directory thrashing. Espm-ghosting prevents espm-thrashing, but not directory thrashing.

A bit of clarification: The engine seems to load all files whose extensions beging with .esp or .esm. I.e. it will still scan .espmx and .espx, but not something.esp.ghost.

Hmm, so having 150 inactive mods may be affecting my game even though the mod list I am running with is in perfect condition. Seems strange, but I wouldn't put it past this game, I will try moving them into a completley seperate folder to see if it makes any difference. I hope it makes the game more smooth, because that is a major problem in my game.

That makes sense - quess it is time to clean out some of the old .esp's (just checked and I have just over 320 in the folder ! - and lately have been noticing some weirdness at times) - probably should also cleanup the rest of the folders while I'm at it as the OB data folder now has 17.5GB in 99,927 files in 3,676 folders so really needs some house cleaning !!

at least I seem to have an empty oblivion folder of unused mods, but I have a Question: what about the unused meshes and textures?
Suppose I install a large mod, then find that I do not want it, then remove the esp. the files are still in there, in the data folder and
these meshes and textures are not attributed to any esp/esm. Are *they* also "looked at" by the oblivion exe, and
then thus maybe confusing the program much in the same way unused esps/esms seem to be?

recently I installed MMM, then I Discovered the Wonder of T.I.E. my MMM meshes and textures are still there in the data folder.
"sense" would tell me that all that these files would do is to take up space; but now i am not so sure after reading this
thread.

I Have to ask this, of course: in an old morrowinf thread post I actually asked "does the morrowind fps counter, when activated
in the ini file, does it use up fps cycles itself as the program displays the fps"?! the consensus is "no"!

hey!!
how much affect would the oblivion fps indicator have on fps, when activated in the console?!! probably
Zilch, but I have to Ask, knowing the weirdness of this all.

probably the next Big Discovery might be.....that *any* esp/esm, in *any* folder on one's hard drive, or even on another hard drive
that is "used" by the same operating system, might affect the stable-ness of the game!!

freestone

The situation you describe in the first paragraph is exactly why you should use OMODs or BAIN, so you can easily remove those files.

I'm extremely non-technical, but I've recently (as in, the last day or so) run smack into a problem that I wonder might be a product of this. Essentially, at rather annoyingly regular intervals (though not, so far as I can tell, in any predictable pattern. It's not like 'every five minutes, like clockwork' but fairly regular) my entire game will seize up. It's not a complete freeze, though it can seem like that, but more like all of my available RAM is instantly tied up, for no conceivable reason. It will be like this for anywhere between two to five minutes or so, and then it'll clear up like nothing at all happened, with no lag at all. The weird thing is, near as I can tell, my RAM usage remains pretty steady. The game itself seems to be having seizures. I haven't recently installed any mods or made any significant changes that I can point to as being potential culprits either.

I think I'm going to try removing my inactive esps and see if that somehow helps.

http://www.gamesas.com/bgsforums/index.php?s=&showtopic=929386&view=findpost&p=13678066
This option will "ghost" automatically ghost inactive mods. Somewhat betaish. See bash topic for more info/discussion.

I tested it briefly and my game did not implode. Actually, I kind of had the feeling that it was more stable, but I couldn't swear to it. If's a bit betaish, but if you think you may have espm thrashing problem, it's probably worth a try.

In my experience this sounds like File Directory Thrashing .

Auto-Ghosting, wheee!

Thanks for all your hard work in identifying and testing these issues! I have one quick question regarding the Auto-Ghosting functionality;

I have a few mods (such as COBL Races.esp and COBL Tweaks.esp) that I have left as inactive but have merged into the Bashed Patch. Now, I assume that if these are 'ghosted' rebuilding the bashed patch will not find them so is it possible to have Wyre's functionality enhanced to treat inactive / merged plugins as normal? Or would we have to manually un-hide these plugins before rebuilding the bashed patch?

Thanks again!

[Edit] Ahh, the power of the internets!

Awesome!

New Version: 248: Fix some updating bugs
Profile and oblivion version switching should work correctly now.

Windows PreFetching: Okay, I'm just going to note this as a warning to folks. I'm not sure what impact (if any it has).

So I was testing Bash's new auto-ghosting process... And really oddly TESCS was continuing to search for files that weren't there. After beating on the directories for quite a while, If found that windows was http://en.wikipedia.org/wiki/Prefetcher a listing of files in the directory that was in fact, out of date (thank you microsoft!). I deleted the relevant .pf file from \windows\prefetch, restarted TESCS, and the erroneous file getting was gone.

I have not yet checked to see if the this affects Oblivion.exe as well, but I imagine so.

I really don't know what impact this will have. E.g. will Oblivion or TESCS fail to recognize additions to the data directories?? Dunno. Would this explain some other weirdness? (Files not appearing even though they're there?) Dunno.

Might it be a good idea to disable prefetch for TesCs and/or Oblivion.exe? Dunno. There are plenty of warnings about the myths of tweaking prefetch settings. So, changing prefetch in general seems to be a bad idea. But maybe it would be okay to disable prefetch for just these two applications. Is that even possible? (Even if there's not a direct way of doing it, it seems that deleting the .pf file has that effect.)

Prefetch files are never something I've been too keen on, but in my experience with cleaning and optimizing general corporate PCs, I always included purging the prefetch files from their locations since they're known to harbor outdated information. I don't know to what extent the OS uses it but we always felt it was best to err on the side of caution and only delete the .pf files and not try and find ways to disable it on an application basis.

Well... Checking a bit further... I think that the searches for the files that no longer exist are coming from the pre-fetching system itself, not from TESCS. Theyr'e notably different (file names are always upper case). And from the test that I just did, TESCS doesn't seem to miss any files due to prefetch.

I suppose that it's something to keep in mind as possible, and I haven't beaten it to death, but it just doesn't seem likely to be a problem. More like an oddity if you're messing around with procmon, that you may end up seeing references to mods that don't exist anymore.