TheBloke

1.2.6 seems to fix the most major, unavoidable issues. My understanding of Tannin's changelog is that, while using 1.2.6, we'll be fine as long as we don't extract the Unofficial Patch BSAs, and we have the following priority list at the top of the mod list (first 10 entries, Prio 0 -> Prio 9): I've asked Tannin for 100% confirmation that that's the right order, and that it's fine to have USKP at the top at Prio 0. But that seems to be what his a) rule in the Changelog requires. As soon as 1.2.6 is available - hopefully not much more than another hour or so - I'll do some tests based on that, confirming that the right files in the right conflict order are getting into the VFS.

Indeed :) By the time Nexus has updated, he'll have 1.2.7 ready..

Thanks for the heads-up!I see Tannin put out 1.2.6 already. So looks like it's no huge issue, until 1.2.7 we just have to observe the a) and b) rules above.

This issue of applying updates with BSA extraction enabled is a little convoluted, so I thought I should write a summary: With MO 1.2.5: If you do not extract BSAs: You have no problem; this issue does not apply to you. If you do extract BSAs: You must not install any incremental mod update - any install done using MO's "Merge" installation option - if this is a mod that contains BSA files. If Tannin implements the proposed feature change detailed in my bug report: If you do not extract BSAs: You have no problem; this issue does not apply to you. If you do extract BSAs: It will be safe to apply an incremental mod update for mods containing BSAs, but only if:The mod contains no fomod installerThe mod does contain a fomod installer, but you are certain that this installer does not conditionally install loose files which are also contained within the BSA.Examples which are safe, because they have no installer: Interesting NPCs, Inconsequential NPCs, Immersive College of WinterholdExamples which are safe, because their installer does not install duplicate loose files: I need to check this actually, it requires some careful checking of mods!It is NOT safe to apply an incremental mod update for mods containing BSAs, which use a fomod installer to apply conditional loose files that are also in the BSA:Example of a mod that does this: Expanded Towns and Cities.There's quite possibly many more examples, too.Therefore the safest advice, if Tannin fixes the current issue, will be to only apply incremental updates to mods that have BSAs if they have no installer.

Check out my bug report that I linked above. It doesn't work like that, at least not any more. Tannin made a change in Beta 1.2.1 that meant that files would not be extracted from a BSA, if an identically named file already existed in the mod folder. This was done because there were reports of mods that contained identical files both as loose files, and in the BSA. In that case, the mod author would expect the loose file to always win, because that is Skyrim's default behaviour. But BSA-extracting users were breaking this expectation, because the BSA was extracted after the loose files were installed, and thus the BSA copy overwrote the local copy. So Tannin changed the BSA extraction method such that it did not extract any file in the BSA if that file already existed locally. That solves the case of a single mod containing duplicate files, BSA vs loose. But now consider the case where you install a mod and extract the BSA, and later install an update that also includes a BSA: You install Interesting NPCs. This includes a few thousand loose files, and a 125MB BSA file containing a few thousand more files. You choose to Extract the BSA. You now have many thousands of loose files, and no BSA - the loose files being the combination of original loose files + extracted-from-BSA loose files. All is fine at this point. Later, you install an incremental update to Interesting NPCs. This update includes a few more loose files, and a new copy of the entire BSA. You choose Merge in the MO installer. The loose files in the update are written into the mod directory, and correctly overwrite anything already there. The BSA is written into the mod directory. Now MO asks you if you want to extract the BSA. Of course, you say yes - if you didn't, that BSA wouldn't be used, because you have all the loose files there from the previous install. Now MO extracts the BSA - except, it doesn't extract any file that already exists in the local directory! And, nearly all files in the BSA do already exist in the local directory; because the BSA contains all the original files, some of which have been updated. You already extracted that BSA once, in the original mod install, so you already have nearly all of the BSA's contents as loose files. The end result is that the only updated files from the BSA that you will get, when you install the update, is any brand new files in that update. Any changed files (files that were previously in the BSA, and were then changed in the new mod update) will not be unpacked, because MO sees that they already exist. Now that problem is solvable, if Tannin changes how MO handles mod extraction and BSA extraction. I wrote a proposed feature change in my bug report, that would fix the issue. Unfortunately, there's a second issue, that probably can never be fixed. keithinhanoi described that, so I'll just quote him:

Yeah you may be right - but I had made that exact point earlier: Then he responded again that that MO 1.2.5 had a change that changed how loose and BSA files were being handled, and he said again that therefore extracting BSAs was never necessary any more. It's that second part that I have been questioning throughout the thread. SRB has said a couple of times that the changes in MO 1.2.5 mean we shouldn't extract BSAs any more. But in fact, MO 1.2.5 changed nothing with regard to whether or not we should extract BSAs. In fact, the changes in MO 1.2.5 were in part to resolve a problem caused by extracting BSAs. In other words, if the advice pre-1.2.5 was "extact BSAs", then MO 1.2.5 has changed nothing about that advice: because in MO 1.2.5, it's safer to extract BSAs than it was before; in particular, with regard to the unofficial patches and their interleaving with official content. I do agree that in fact always extracting BSAs is not a good thing, and that much more care than that should be taken. But I don't agree that anything has changed in MO 1.2.5 with regard to whether we do or don't extract BSAs. All that has changed is that, after the long Ramifications thread, we all understand the issue better now. If SRB is referring purely to the handling of non-MO mods, then I apologise for misunderstanding; a lot of what I said in my previous post was therefore unnecessary. But I still don't understand his original statement: The new install order changes nothing about whether we should extract BSAs; in fact, it means it's now safe to extract Unofficial content BSAs where it was not before. Maybe he means "As a result of the discussions in the Ramifications thread, the current accepted wisdom is that extracting BSAs is not generally a good idea, and we will need to review the STEP guides and find all the places where per-file conflict resolution is being done and decide if those mods should still have BSAs extracted, or if the conflict resolution is not that important." That I could understand totally, and agree with.

I'm not really sure how to respond to this, especially the part about electron speed.. Suffice to say that SSDs perform significantly better than HDDs on every possible metric (besides, perhaps, longevity in write-heavy workloads). In my personal case, CrystalDiskMark shows figures of 350MB/s on sequential reads, and I think around 300MB/s on random 4Kb reads (4KB being significant as it's the filesystem blocksize.) This compares to a maximum of 120MB/s sequential reads I get from my RAID-10 of 4 x 1TB HDDs. Crucially, the random reads on the HDD array is something ridiculous, like 2MB/s. Note also that my SSD isn't even particular good - it's four years old. Modern ones get 550+ MB/s easily. In more practical terms: moving my Skyrim + 60GB MO mod installation from HDD to SSD reduced my shortcut-to-Skyrim-menu startup time from several minutes, to 30 seconds. That was with all extracted BSAs. Then changing a significant number of my mods from extracted to non-extracted BSAs gave me at most a 1 or 2 second further reduction; 5% maybe. And no in-game performance difference (as measured via FPS and Papyrus script lag time.) If you believe that I could encounter problems that cause no measurable performance change, then I'll need you to elaborate on exactly what problems can be caused and why. What do you mean by some BSAs? Which ones are you saying would not be loaded according to install order? (Besides the vanilla/official BSAs of course, the load order of what is what changed in MO 1.2.5.) Could you please point to the specific change(s) in MO that you are referring to when you say this has changed in 1.2.5? Here's the full changelog: I will say again that there is no recent change in MO that affects how BSAs are loaded, based on load order. Prior to 1.2.5, MO always resolve conflicts based on the mod list order. If ModA at priority 100 provided FileX as loose, and ModB at priority 110 provided FileX in a BSA, then ModB's file would be the one used in the game. You could see that in both the Conflicts tab, and the Data pane. In fact, Tannin confirmed that during the lengthy Ramifications thread. I think at the start of the thread, some people had the misapprehension that there were some special rules involved, but in fact it's very simple: with regards to mods managed by MO (i.e. that are not just loose in the Data folder), and where the BSAs are ticked in the Data pane, mod list order ruled all, and that is not new. Here are some quotes: And here's a nice summary from DoubleYou: In other words: MO has always resolved conflicts based purely on mod list order, regardless of whether BSAs or loose files or both are used. This has very much NOT changed in MO 1.2.5! If you are in further doubt, please re-read the Ramifications thread from the start - at the start of the thread, many users had the same misunderstanding that you have now. Tannin and DoubleYou then cleared those up, and I quoted parts of that above. Final point: there is one change in 1.2.5 that changes things with regard to load order: there's a new tickbox on the Archives tab, "Have MO manage archives". If you untick that, then mod order no longer applies; MO then operates like the other mod managers, and loads BSAs according to plugin order. That's new, but that change does not apply by default, nor would most users (and no STEP users) want to enable that change. It would turn MO into a more normal mod manager, where the mod list is mostly irrelevant. We don't want that! Basically, that tickbox turns off the "MO magic", and makes it just load everything according to Plugin order alone. Yeah I agree that there's no need to just extract every BSA, for the sake of it - at least not for most users; personally, I do often dig into mod folders in Explorer, and appreciate the ability to do so. Actually there's a further problem that we've not mentioned as yet, which relates to the specific case of installing (large) mods and then applying incremental updates. In the case of always-extracting BSAs, then applying an update that itself contains a BSA, current versions of MO will not properly apply the update. I raised that as a bug, here: Beta 1.2.1: New BSA extraction handling never overwrites existing files, therefore breaks the Merging of patch updates that include BSAs. That issue can be fixed, and I proposed a solution in that issue report. But then there's a further issue that potentially can't ever be fixed - it relates to mods that supply different sets of loose files according to fomod installer options, which are duplicates of the same files provided in a BSA. keithinhanoi detailed that issue, here (scroll down 60% until he quotes me). Therefore I would definitely agree with advice that users should not extract BSAs without prior knowledge, and that they should not extract all BSAs for no reason. Furthermore, there needs to be specific advice warning users who have extracted BSAs for certain mods that they must not apply incremental updates to them. This only applies to very large mods which both use BSAs and provide incremental updates, for example Interesting NPCs. But nor do I agree with advice to never extract. Doubly so because it's the exact opposite of the advice in the current STEP guides, and there are number of mods within STEP that require per-file conflict resolution which is impossible if BSAs are not extracted. Clearly some thought needs to be given to how those STEP guides change, and what advice is given. But there are definitely a number of mods in the guide which are going to need to include the message "Extract the BSA for this mod, so that you can make the following conflict resolutions..."

Yeah that order looks fine with regard to the official content and unofficial patches. Well, I don't know about Director's Cut, I guess that's a German only thing? But I'm assuming you know that you need to put that before the between DB and the HiRs DLCs? It's treated like official content? Note that I still wouldn't recommend extracting the BSAs for the Unofficial Patches - simply because there's no reason or benefit in doing so. You have them nearly at the top of your load order, they will be overwritten by all other mods anyway. Here's mine, FYI:

I've benchmarked and found no noticeable performance delta between having all extracted BSAs and not extracted BSAs, when using fast SSD storage for my Skyrim + mod installation. I agree that on HDDs, the performance benefits may be worthwhile. On SSDs, file fragmentation is not an issue, and random reads are almost as fast as sequential reads, where on HDDs random reads are orders-of-magnitude slower than sequential. Hence on HDDs, packing all your files together in contiguous archives can be a big win. The downside of not extracting BSAs is the inability to resolve conflicts on a per-file basis, and the inability to easily browse and read files within a mod (e.g. through Explorer.) The latter won't be a disadvantage for most people, just maybe modders. The former though can be a bigger issue, at least for advanced users. Regarding "MO allows the BSAs to overwrite loose files so install order rules over all now." - I think you are misunderstanding the changes that happened in 1.2.5 BSAs could always overwrote loose files from other mods, in accordance with mod order list, in MO. This has not changed in MO 1.2.5! What has changed in MO 1.2.5 is that we can now interleave the official vanilla/DLC content, with its unofficial patches. That was the sole issue that extracted BSAs was causing: because MO always loaded all mod content after the vanilla content, rather than loading BSAs according to Plugin ESM/ESP order like in other managers, it meant that some content from the unofficial patches was not being applied as the designers of the unofficial patches intended. For example, the Unofficial Patch designers expected that USKP would load before Dragonborn, but in MO, Dragonborn (and DG and HF) would load before any mod was loaded. That is fixed in MO 1.2.5 because now official vanilla/DLC content is treated like a mod. We can move it in our mod list. Therefore we can ensure that we have the order: Skyrim, USKP; Dawnguard, UDGP; HearthFires, UHFP; Dragonborn, UDBP; HiRes DLC, UHRP; other mods... That is why I asked you earlier why you were saying that one should never extract any BSAs, when in fact the STEP guide features some examples of per-file conflict resolution, which can only be done if you extract the BSAs for those mods (unless they are mods that don't use BSAs.) Nothing has changed in MO 1.2.5 that affects that. If you want to put Mod B below Mod A in your mod order, but have a couple of files from Mod A take precedence over Mod B, you still need extracted BSAs. There is no option to "Hide files" if those files are contained within BSAs. At least there isn't at the moment; as I mentioned earlier, I am working on a feature proposal for Tannin which, if implemented, would allow us to do per-file conflict resolution even with mods that provide all files as BSAs. If that is implemented, then your statement "never extract BSAs" might be correct for all users. At the moment, it is not. (Though I agree that, by default, users should not extract BSAs, and there is no reason to extract a lot of BSAs from a lot of mods. It's only when you want to do more finely grained file conflict management.)

Yes there's definitely no need to unpack the unofficial patches. Though the changes added by 1.2.5, allowing the interleaving of official/DLC content with unofficial patches, means that there's also now no huge reason not to unpack them. Before, it caused a bug. That is now fixed in 1.2.5 because we can interleave the official content/DLC with its unofficial patch. However some users do find better peformance when not extracting BSAs. I have not noticed much difference, when running the game from a fast SSD. Running it from slow HDDs would likely show a big performance improvement if you use all BSAs instead of all extracted.

This goes some way towards dealing with it, and makes life manageable at least. But I do agree with the OP, the ability to remove mods from profiles completely would be extremely helpful and help keep things much neater. Keeping the Checked filter on works quite a lot of the time. The problem comes when you have some mods that you consider part of your current profile, but for whatever reason you have unchecked for now. Maybe you downloaded a new mod that you plan to try out in a day or two, when you can be bothered to go through the install procedure. Or maybe you suspect a recently installed mod is causing problems, so you uncheck it to do some tests, but hope to re-enable it later. I often find that I need to turn off the Checked filter, to review my unchecked mods. When I do that, the problem returns - huge amounts of clutter to sort through. Similarly, I sometimes want to download mods speculatively. I use SkyRe, but have never tried Requiem. Sometime I might decide to give Requiem a quick go, so I'll download a bunch of mods for it. It might happen that I only play with Requiem for a short while, and stop using it. But I don't then want to delete all those new mods, because maybe I'll come back to them later. The more that sort of stuff happens, the more messy the mod list gets, and while the Checked filter helps a lot of the time, it's not the final solution. I have had exactly the same thought, for the reasons you mention & I elaborate on above. I have been working on a feature proposal for Tannin, which would entail (in brief): [*]A new, "Master mod" view; a list of all mods installed on the system. No checkboxes, no priority. Just a list of all available mods. [*]Right-click menu on "Master mod" view, "Add to profile.." allowing you to add selected mods to selected other profile [*]Right-click menu on Profile mod view, "Remove from this profile", allowing you to completely hide a mod from the current profile [*]Configuration option(s): "Newly installed mods are installed to... (o) All profiles () Current profile only"; so by default, when you install a mod it goes to all profiles (as now), but user can easily change it to just current profile. This is mostly - or entirely - a UI change; the underlying data is already arranged appropriately. Each profile has a modlist.txt which shows which mods are installed, and the order of those mods. In fact right now the user could go and remove some mods from some profiles by editing the Modlist.txt. The problem is that MO would automatically add them back in on load and refresh. So I think the change could be acheived fairly easily - no major internal changes, it's just a different UI presentation. I then wanted to propose a second, followup idea, which would make multi-profile even more awesome: per-profile mod and file management. This would allow the user to hide files within a mod only within a single profile. Ideally, it would even allow the user to install the same mod multiple times, using different installer options, and have the different versions go to different profiles. Significantly, it would also allow different sets of Optional ESPs. So for example, you install mod NeedsModX. This comes with a SkyRe patch and Requiem patch, and you choose to install both. Then in your SkyRe profile, you mark the RequiemPatch.esp as 'Optional', meaning it's hidden from the Plugin view and the Data view, and will not be seen by any external tools. Vice versa in the Requiem profile. This second change is likely quite a bit more work, and is definitely not only a UI change. But it would be the complete solution, make multi-profile management, with varying mods, mod order, per-file mod conflict resolution, and patch choice selection, all variable between different profiles. It would all be so much cleaner to manage. Avoiding for example - with regard to multiple patches, each applying only to one profile - the Plugin Load Order clutter you would get today if you installed both SkyRe and Requiem patches at once, but only had some enabled in some profiles and some in others. Also would generally avoid the need to install the same NeedsModX twice or more, once with SkyRe options, once with Requiem options, and thus end up with two mods: "NeedsModX - Requiem version" and "NeedsModX - SkyRe version", both of which have to be updated independently when a new release comes out. I haven't had a chance to raise these ideas formally to Tannin, yet. At the moment I'm working on a feature request regarding in-BSA per-file conflict resolution, and a much improved Conflicts & Filetree view for mods. I wanted to finish and raise that first before doing the per-profile suggestion. So if you want to go ahead and formally raise the central "different mods visible in different profiles" idea, I can add my further thoughts later. Or otherwise I'll get my suggestion up in the next few days, and you can add your thoughts to it once it's there. In case you're not familiar with it, the place to raise feature suggestions is the Issue Tracker, here: https://issue.tannin.eu/tbg/modorganizer

Not more complicated than that. no. Easiest way to think about it: Priority 0 is being treated like priority 999,999. It's like it's below every other mod, and so it wins any conflicts it has with other mods. If it has no conflicts, then it doesn't matter.

Or just a mod that has no conflicts. I have Appropriately Attired Jarls in position 0. It has no conflicts, so no problems. Can you elaborate? Do you mean the new install order in MO 1.2.5? Or has STEP been updated? Because previously STEP had some examples where it said "Only use the following files from mod X", or "Hide the following files from mod Y". Maybe all such mods are provided as loose files? But if they're provided as BSAs, then this kind of per-file conflict resolution is not possible unless you extract those BSAs. You cannot currently hide individual files if they are provided within a BSA - though I have discussed with Tannin asking for that ability to be added, which I will be putting into an official Feature Request shortly (today or tomorrow.) I've moved to not extracting all BSAs, and if I never have to do per-file conflict resolution on a mod I'll likely leave its BSA unextracted. But I do have several mods where I've done per-file conflict fixing - e.g. Mod A is before Mod B in the mod list, but I want one or two files from Mod A to overwrite Mod B. Note I've not checked the STEP guide thoroughly to remind myself on which mods it says "only use these files" or "hide these files", so maybe it does not say that for any mod that provides BSAs? But my point is, I did not think that it could just be said "never extract any BSAs any more", because there may be some cases where per-file conflict resolution is necessary or desired?

Ah yeah, that sounds very plausible

That's strange. My first question was going to be - does this mod use BSA files? When you look at the file in the Data tab, does the Mod column say "aMidianBorn Solstheim Landscape (SomeFile.bsa)" ? Because you can't hide conflicted files that are within a BSA. However I realised I also have this mod installed, and I just checked and it is all loose files - and there's no option on the mod page for a BSA version (at least there isn't now?) Is it possible that this file, that you think of as part of aMidianBorn Solstheim, is actually a conflicted file, and is also being provided by another mod, which is overwriting aMidianBorn? In the Data tab, does the file show in red? In which case, does the Data tab entry show that the file is contained within a BSA? Here's an example - the file I've highlighted and right-clicked on is conflicted (in red), and the winning conflict file is provided by a BSA (Unofficial Dawnguard Patch.bsa), hence I have no Hide option on my right-click menu: So maybe you have this file in aMidianBorn Solstheim, but it's also being provided by another, conflicting mod, which is lower down in the modlist and therefore takes priority. And that other mod has the file contained within a BSA, which means it can't be hidden. You'll be able to see that clearly by double-clicking on the aMidianBorn Solstheim mod, and checking the Conflicts tab - see if this file appears in the section "Files provided by other mods" (the second list of files.) If this file is not conflicted - is only provided by aMidian Solstheim - then that's very odd. Unless you somehow have an aMidian Solstheim version that uses BSA files? But I don't think he ever uses BSAs, so that seems unlikely. As EssArrBee said, you should be able to go to the Filetree tab and hide the file there. But that shouldn't be necessary, so do report back on the above stuff, because maybe there's a bug.

Yeah OK turns out I was exaggerating :) I did some timings before when I switched from extracting all BSAs to not extracting the biggest ones. The 15 seconds i remembered was for the Skyrim window to first appear, not for menu. In my test just now, it took a further 12 seconds for menu items to appear. So 27 seconds total, click-to-usable-menu. Though I was also under-exaggerating the MO-SKSE time, which was less than a second when I just tried it. With ENB (both graphical enhancements and ENBoost.)

Beta 1.2.1 was a massive improvement over the previous 1.1.2. Not sure if you'd count 1.2.1 as a recent beta - it's been on the MO Nexus page for 6 weeks (since 5th May). When I first installed 1.2.1 I still had my 50+ GB Skyrim + Mod installation on HDD rather than SSD. With those slow disks, my startup time - specifically the time it took from when I hit Run in MO until I saw the SKSE window first appear, which is the part of the process where MO is building its virtual filesystem - went down from 60+ seconds, to around 15. Huge improvement. (Now on SSDs, and with 60GB total in active mods alone, my MO->SKSE time is perhaps 2 seconds, and I get to the Skyrim main menu in 15 seconds.) This thread refers to the second round of betas, versions 1.2.2 -> 1.2.4 which then became final release 1.2.5. They did not have any particular performance improvements that I can recall. So probably you were already using beta 1.2.1? Hm, I've noticed the same. I never bothered making an out-of-MO shortcut until Beta 1.2.4. Then I tried it for the first time, and it didn't work. I forgot to report it, and in any case figured that maybe it was a local issue because others were talking about using them. What symptoms do you see? I just tested it again in 1.2.5, and see the same as I had in 1.2.4. Specifically: I make a shortcut in MO to SKSE, to my Desktop or Start Menu I close MO I double click the shortcut I get the "Mod Organizer" loading screen graphic (the one with the lightning on it) appear middle of the screen. It then just stays there, and nothing further happens. When I check Task Manager, I see I have a single Mod Organizer process running idle. SKSE / TESV.exe never appears in Task Manager. It stays like that permanently until I End Process in Task Manager on the Mod Organizer.exe process. Note that exactly the same happens even if I use the external shortcut when I still have Mod Organizer open - this triggers a second Mod Organizer.exe process appearing in Task Manager, and nothing further. Given it's clearly not just a local issue for me, I have raised this as a bug: https://issue.tannin.eu/tbg/modorganizer/issues/684 If you have any different symptoms, you might want to go to that bug ticket and add a comment with your experiences.

Can you confirm you've exactly followed the steps described on the BodySlide mod page, under Troubleshooting -> #1 "How to use the program with Mod Organizer"? Specifically: I would add a point 8 to that list as well, which is pretty obvious but I'll mention just to be completely safe: 8. Whenever you want to run Bodyslide, do so through MO, by selecting Bodyslide from the executable dropdown (top right of the MO window) and clicking Run (same way you execute SKSE, Boss, etc.) If you've followed their 7 steps, then when you run Bodyslide.exe through MO, it will have access to all mods installed through MO and therefore should see any custom armour mods you've installed in MO. Note: I haven't used BodySlide or CBBE armours before, nor have I checked if the STEP guide provides its own instructions for CBBE/BodySlide. But I just checked the mod page, and the list of instructions it includes for MO sound exactly right to me, and the problem you describe sounds like it could well be caused by not running BodySlide in the correct way. If you followed a different guide to using BodySlide in MO, could you a) link me to that guide b) cross-reference it against the instructions on the Bodyslide page, that I mention above, and see if there's any difference in what you did compared to what they suggest.

Ah thanks for the link! Sorry, I had not thought to check the MO wiki again; it's been a little while since I read it and while I must once have read that detailed Overwrite info, it was probably when I first started using MO and it was mostly over my head! Should have known better than to not check it again before posting :) So OK, now I've read it - this is quite interesting. So that explains why Bashed Patch always goes to Overwrite - Bash must delete the existing file, then create a new one. It takes 20 seconds to create the Bashed patch, which is longer than the 5 second rule, hence always in Overwrite. And reading the list of examples reminded me of another example from my own experience that I forgot all about - Tes5edit. That's another example of where I don't get files in Overwrite, at least when I make changes to existing plugins. As you say, ReProccer takes much longer than 5 seconds - a couple of minutes in fact, way longer than Bash. So if it's deleting & creating, it should go to overwrite. Therefore, it must be one of two possibilities: either ReProccer is not in fact deleting and then re-creating the file, and instead it zeroes the current file and overwrites its contents. Or - perhaps more likely - it's writing its results to a new, temporary file, and then moving it over the original file in one single very-fast operation. That's probably also what Tes5edit does; writes to a temporary file then moves it over the original if you confirm you want to save changes. Whereas Bashed Patch most likely deletes the existing file at the start of the operation, and then doesn't re-create it until the end - 20 seconds later. Yes I do use Sync to Mods - every time I run my Bash Patch, I right click on Overwrite and choose to sync "Bashed Patch, 0.esp" into my "Bashed Patch" mod. That's pretty easy to do. I just thought that as there was one example where I didn't have to (ReProccer), maybe there was some way I could get that to happen for Bash too. It's no big deal if there isn't. Though it would be nice if that "5 second rule" was exposed via an (advanced) configuration parameter. As I said it takes only 20 seconds to make my Bashed Patch, so I'd like to try changing that 5 seconds to 21 seconds. I can't think of any reason why that would be bad for other mods, but I'd need to test it of course. Thanks a lot for the quick response! I now understand the inner workings much better. I think I will raise a feature enhancement requesting that 5 second parameter is exposed for config, as it would be nice to be able to tweak it and play about with the result. But it's very low priority.

I run a few different executables through MO which can create files. Generally, any such file created will always go to Overwrite. I often wish that there was a way to tell MO to always put certain files back into specific mods, so I don't need to keep manually deleting them from Overwrite, or run Overwrite->Sync all the time. But I'm confused about what the exact rule is, because I know of at least one instance where a file that is created/updated by a process run from MO does not go to Overwrite, and instead goes into its original mod directory. Specifically, I use the ReProccer, provided by T3nd0 for Skyrim Redone (SkyRe). This is a Java SkyProccer, which writes to the file ReProccer.esp. ReProccer.esp itself was provided as part of the SkyRe mod. Every time I run ReProccer, it updates ReProccer.esp and the resulting, new/changed file does not go in Overwrite (although a bunch of other files created by ReProccer do - such as log files and backup files.) After running ReProccer, I can go check my "T3nd0s Skyrim Redone" folder, and see the ReProccer.esp with an updated Modified timestamp. So what's different about ReProccer.esp? Why does this get written back to its originating mod when, for example, the Bashed Patch does not? I thought that maybe the difference was that ReProccer.esp was provided originally by an installed mod - whereas the Bashed Patch I created new the first time I ran Bash. So I took my "Bashed Patch, 0.esp" file, and made a new mod out of it - putting it in an archive, and installing that archive into MO like a mod. I then ran Wrye Bash to update the patch, but it made no difference: the new "Bashed Patch, 0.esp" ended up in Overwrite again, and my own "Bash Mod" got the little lightning symbol against it to indicate its version of the file was redundant. So every time I run Bash to make a new Bashed Patch, I need to go to Overwrite and choose "Sync to Mods.." and choose to sync it to my own "Bash Patch" mod. Until I've done that, I get the MO warning triangle. Oh, and regarding those other files created by ReProccer - log and backup files. I once tried moving all those from Overwrite into the ReProccer mod, hoping that once they were in there, future updates to them would sync back there and not keep going to Overwrite; i.e., that they would behave the same was as ReProccer.esp does. But no luck; like most other files, besides ReProccer.esp, all those files always go to Overwrite. This is certainly not the end of the world. But I'm really confused as to why I never have to do this with ReProccer.esp, when I do with seemingly all other files - even other files created by the same ReProccer process, at the same time. Is there some change I can make that could result in other files - in particular the Bashed Patch ESP file - also auto-syncing to a mod, like ReProccer.esp does? Or is there some fundamental difference in how ReProccer is creating ReProccer.esp that results in this difference, and is outside of my control for other files? For the future, as a feature enhancement, it would be great it if it were possible to set up "Overwrite auto-sync rules", to handle files like the Bashed Patch which are regularly written to Overwrite but which the user wants to reside in a specific mod. I'll raise a Feature Enhancement for that soon. Of course t's not that important or urgent, just a nice to have.

Bug: Mods with BSAs: Conflict tab shows Hide menu, but Hide fails on any BSA-contained file. Tracker link: https://issue.tannin.eu/tbg/modorganizer/issues/665 Description: I don't think this is a new bug in the latest betas, and it's not related to the new features added by these betas. I'm mentioning it in this thread regardless, because it is relevant to our recent discussions regarding BSA extraction and the pros and cons of doing so. In brief: the Conflicts tab displays a right-click menu showing the option to Hide files. It displays this for all (conflicted) files, including those that are contained within BSA files. However, the Hide operation fails when attempted on a file that is within a BSA. It displays a Windows error message, indicating that MO attempted to rename the file as if it were a loose file, stored discretely on disk. My thoughts: At the bare minimum, the Hide option needs to be removed for files contained within BSAs. But I am planning to talk to Tannin to ask him whether it might be possible to extend per-file conflict resolution to files contained within BSAs. In other words, whether he can find a way to either a) rewrite the BSA header, renaming files or b) implement some kind of on-the-fly hiding of files within a BSA, at the time of creating the virtual file system. I was really disappointed to find that per-file hiding of conflicted files is not possible for BSA-contained files. I was nearly sold on the growing consensus that extracting all BSAs may not be the best idea. I was sold on it because I thought I could still handle per-file conflicts - mislead because I saw the right-click -> Hide option, even for files in a BSA. Sadly I didn't actually try it until today, and have now found there's no special implementation of file hiding for BSA-contained files. I'm now thinking that I will go back to extracting everything, which should be safe as of the latest MO which can interleave the Unofficial patches. Nonetheless, it would be awesome to have the ability to keep BSAs (e.g. for the performance benefits, particularly on non-SSD storage), and maybe that could be possible if Tannin can find a way to extend file Hiding/renaming to files contained within BSAs as well.

I'm pretty sure the OP isn't asking about Overwrite. I agree it's a bit unclear. If he does mean Overwrite, then Overwrite does have an obvious delete option. Just double-click on Overwrite at the bottom of the Mod List, then you can right-click any file or folder and choose Delete: So you can browse to MO's overwrite folder, but it shouldn't really be necessary. However, he referred to a file visible in the data tab. This makes me think that this file was provided by a mod, and he wants to hide it from that mod. If so: Find the file skeleton_female.hlx in the Data tab (right-hand-side pane). Right click on it, and see if you have an option called Hide. If you do, then you can choose Hide, and the file is name renamed to skeleton_female.hlx.mohidden - and will not be loaded by anything. However, you might find that you don't have the Hide option. This happens when the file is provided by a BSA. In which case, it seems like you can't Hide it, ever; or rather, you can't hide or delete it while it's part of a BSA. Now if the OP is following a recent STEP guide, he may well have followed advance to extract all BSAs. In which case he can definitely hide any file. Or it may be that skeleton_females.hlx is provided as a loose file anyway. But if not, his only option may be to extract the given BSA for this mod, and operate this mod as Loose Files, such that he can hide individuals. That can be done by finding the BSA file in the Archives tab, right clicking and choosing Extract, browsing to the appropriate mod folder for this mod and extracting there, then deleting the BSA file. Now that mod will operate as loose files only, and files can be hidden individually. PS. Actually, if the OP finds that he does have the Hide option (i.e. this is a loose file), then he does actually have the option to Delete it - rather than renaming it. In that case, double click the mod in the mod list, click Filetree, and browse to the file's location. Now you can right-click and Delete that file. Hiding it might still be preferable, though, as it's reversible.

Yes, MO ignores the request to disable a BSA when there's a matching ESP. In fact, in the latest version of MO (currently in beta, 1.2.4), you can't even disable them. When there's an ESP with the same name, MO 1.2.4 won't let you uncheck the BSA in Archives. To be honest, I don't quite understand why it's like that. It does have to be like that for BSAs in the /data folder, because Skyrim will always load those. And it's true that if Skyrim seems SomeMod.bsa when there's a SomeMod.esp as well, it will auto-load SomeMod.bsa. What I don't quite get is why MO can't translate "untick SomeMod.bsa in Archives" into "don't show SomeMod.bsa to Skyrim; remove it from the virtual filesystem." That would achieve what you want, and be more intuitive. But it's possible that Tannin felt that, if you don't want the BSA there, you could just Hide it yourself. Which of course you can. So if you want a BSA there after you extract it, another thing you could do is to double-click on the mod, click on the Filetree tab, right-click on the BSA, and choose "Hide". That will rename it: SomeMod.bsa -> SomeMod.bsa.mohidden. That way you can have the BSA still there physically, but never be loaded. It's perhaps not quite as convenient, because as it doesn't have the .bsa extension it won't be automatically seen by tools like BSAOpt, nor will it appear in any *.bsa listings. But that will basically achieve what you want - keeping the BSA file alongside the loose files. And any time you want that BSA back as a BSA, you can right-click it again in MO->Filetree, and choose Unhide. If Tannin reads this thread, maybe he could comment on why "Untick BSA in Archives tab" couldn't translate into "Don't add that BSA to the virtual filesystem, such that it doesn't matter if there's an ESP with the same name." If he doesn't see this, I might raise that as Enhancement request for him.

You can't disable a BSA that has a matching ESP file. E.g. SomeMod.bsa cannot be disabled if you have a SomeMod.esp active in your load order. Because the game will load it anyway. When you're manually extracting BSAs as you describe, you have to then manually delete the BSA after you extract it. Note that there's a plugin, called bsaExtract. Go to Settings -> Plugins, and click on bsaExtract. Check the settings window on the right; if it has enabled=false, change that to enable=true, and click OK. Now, whenever you install a mod, if that mod contains a BSA file you will be prompted "Do you want to extract this BSA?" If you choose yes, then it will extract to the mod folder, and auto delete the BSA afterwards. If you find that the bsaExtract plugin is already enabled, but you're not being prompted to extract BSAs on mod install, then that means that you once clicked "Remember answer" and then chose No, so the dialogue is never appearing any more. If that's the case, go to Settings and click Reset Dialogs. Or, if extracting BSAs is something you do only rarely, such that you don't want to be prompted each time, then ignore all that. Just carry on extracting manually as you did, but remember to delete the BSA afterwards. Extracting all BSAs is not necessarily generally recommended any more. For the reasons why, see the (somewhat lengthy!) Ramifications of BSA Extraction thread, in this forum. The OP has been updated by z9 to contain all the general findings of the whole thread. It doesn't sound like you're wanting to generally extract many BSAs anyway; I mention this just so that if you do turn on the BSA extraction plugin, you're made aware of the ramifications before you start extracting many more BSAs.

Change request: provide enable/disable checkbox for pseudo-mods: Tracker link: https://issue.tannin.eu/tbg/modorganizer/issues/663 Description: It's great to have the new pseudo-mods, allowing precise positional control of vanilla/DLC content. But I was hoping that this could also provide the ability to enable and disable the pseudo mods. At the moment, if I want to play a game without, say, Dawnguard - or create a no-Dawnguard profile, for example for testing compatibility of my own mod in various configurations - I have to first manually untick the ESP in the load order, and then manually untick the BSA in archives. This isn't a vast amount of work, but it's a different process required than for all normal mods. So what I would like: Pseudo-mods display the normal enable/disable checkbox in the mod list (left pane) Unchecking a pseudo-mod works the same as unchecking a normal mod; the ESP(s) and BSA(s) for that mod disappear from MO's view, no longer appearing in the Load Order and Archives tab.