the actual size of the virtual data folder created by mod organizer

[Sycamore]

Background:

Mod organizer and a ramdisk was probably not such a good idea. After using it for a while I noticed some odd behaviors that don't happen without it. I came up with a another idea, got an intel 750 series 1.2TB pci-e SSD drive and restored my whole C: drive to it, enabled superfetch (that's the default setting, I had disabled it back when I was running 16GB main memory) to allow windows to populate what is now 128GB of main memory, and just ran mod organizer normally. The results have been encouraging so far, considering the game data folder is probably closing in on 60GB.

 

Question:

One thing I haven't figured out that would be nice to know is the actual size of the virtual data folder created by mod organizer.

Does anyone know if this information is currently computed and logged?  I'll admit I haven't noticed or looked for it in any log files.

Perhaps some type of code would need to be written to capture it, I don't know.  

 

[Greg]

Mod Organizer's virtual file system isn't really a file system per se. It's more that Mod Organizer hooks various Windows API functions so it can redirect applications trying to open say C:\Steam\SteamApps\Common\Skyrim\Data\Foobar.esp to actually open C:\ModOrganizer\mods\Foobar 3.1\Foobar.esp. This is perhaps somewhat of a simplistic view of how it works, but it should be sufficient to get the idea across.

 

If you need to calculate the size for some unknown reason, right click the ModOrganizer\mods folder and select properties, then right click Skyrim\Data and select properties. Now add both together to get a rough estimate. Another option might be to run a 32-bit command prompt (or some 32-bit Explorer clone) from Mod Organizer and get the size of the Skyrim\Data folder and all subfolders (this includes all the vanilla mods and DLCs). Note that 64-bit applications won't see the virtual file system when run from Mod Organizer.

[Sycamore]

Thank you very, very much for the idea.  I set up cmd.exe as an executable within MO, then used the command:

Dir /a/s   on the data folder in MO and it looks like I'm using about 60.966641938 gigabytes, which is about right:

Total Files Listed:

           386111 File(s)    65,462,433,318 bytes   = 60.96GB 

C:\Games\Steam\SteamApps\common\Skyrim\Data>

 

The MO mods folder shows 68.9 GB (74,022,482,501 bytes), 421292 files when checking its properties outside of MO.  With all the overwrites the net result would naturally be less, so this all makes sense.  That MO mods folder includes all the bsa & esp files from the base game and DLC's too, as I converted them to 7zip files and pulled them into MO as separate files, each one treated like it was a mod.  Skyrim.esm and Update.esm are the only plugins that actually remain in my native Data folder outside of MO.  What I like about that is MO tracks pretty much every file and lets me know if a mod is overwriting a texture from the original skyrim textures, for instance.

 

Again, thank you.  I just started using MO in the last couple months, and it is nothing less than outstanding.

 

Edit: I probably should have mentioned I've expanded all BSA's, so everything is unpacked and ready to go when the game has to load something.   

Edited October 24, 2015 by Sycamore

[Greg]

You don't really gain any benefit from unpacking the BSAs in terms of speed or conflict resolution. If you are manually installing mods or using Nexus Mod Manager to install mods, the loose files always have precedence over files stored in BSAs. Mod Organizer is more intelligent so it allows the scripts, meshes, textures, etc. in the last mod (in the left pane) to win the conflict regardless of whether this is a loose file or a file stored in a BSA.