This repository is mostly deprecated, as this patchset will fix USVFS under wine: https://gist.github.com/qsniyg/ec21d68f9407991a1043a71fa6ffd4cf .
Wine 4.21 includes both patches in the above patchset.
movfs4l (Mod Organizer Virtual FileSystem For Linux) is a workaround for using MO2 under Linux, until USVFS is properly supported under Wine.
Please note that Mod Organizer 1 (and older versions of MO2) work fine under Wine. This tool is only meant as a way to be able to mod Bethesda games with later versions of MO2, which feature significant performance improvements as well as new features that can significantly improve the experience of modding Skyrim/Fallout.
Right now, there are 2 supported methods:
Some of the cons (especially for winevfs) might be resolved later, but this is the current state of the project.
Older versions of this script had paths hardcoded into the script. This meant you had to have a separate copy of the script for every Bethesda game you wanted to mod.
Newer versions use an automatically generated configuration file, which you can manually edit later if needed.
In order to determine which games you have installed, it needs to find the Mod Organizer local
data path (--mo_gameroot
). It might be able to detect this automatically, if WINEPREFIX
is set
correctly, and if MO2 is installed to C:\Modding\MO2 (the default installation location). If not,
you will need to specify the installation root manually.
To generate the configuration for the first time (i.e. if config.ini
does not exist), simply run:
python3 movfs4l.py
If you want to automatically update the configuration, for example if you have another prefix with
ModOrganizer, or if you have added a new game to an existing prefix, ensure you have specified
the variables correctly (WINEPREFIX
, --mo_gameroot
, etc), run:
python3 movfs4l.py --generate_config
To setup a symlinked "VFS", run it specifying the game (not needed if running from the game's directory)
and profile (not needed if Default
, or whatever value default_profile
is set to):
python3 movfs4l.py --game "Skyrim" --profile Default
Do not run MO2 while the symlinked "VFS" is active, this can cause issues with your profile.
When you want to run MO2 again, run the same command again, this time with --unvfs
:
python3 movfs4l.py --game "Skyrim" --profile Default --unvfs
This will remove the symlinks, allowing you to run MO2.
Should you experience slowdowns with the usage of symlinks, there is an option to create hardlinks instead. Please note that this only works if both, MO2 and your game, are on the same drive. To create hardlinks, add this parameter to the first command above:
--hard_links
Then, by default, when you unlink your mod files, all changes made to them by e.g. BodySlide, FNIS or similar will be lost - you will need to re-run these tools after linking your mods again. In order to preserve those changed files, add this parameter when unlinking:
--keep_modified_files
In addition, when you relink your mods where you have kept the modified files, you need to add this parameter when you do the linking:
--overwrite_existing
The reason is, that by default this script will backup any file that is going to be overwritten by a mod file. This makes sure that, after unlinking, the game files are like they were before you used have this script. By nature this will also backup any existing file that you have kept when you unlinked your mods, like files modified by BodySlide, FNIS or the like. By using this parameter it will disable creating these backups. While this should not cause problems, please use both, --keep_modified_files and --overwrite_existing at your own risk.
Compile winevfs as shown in the project's description, then
specify the location to bin/winevfs
in config.ini, for example:
[general]
...
winevfs = /home/username/winevfs/build/bin/winevfs
Then for running an executable in the game's top-level directory (such as the game itself):
python3 movfs4l.py --game Skyrim --profile Default --run wine Skyrim.exe
Replace wine
with proton's wine (e.g. --run ~/.steam/steam/steamapps/common/Proton\ 4.11/dist/bin/wine Skyrim.exe
),
if needed. Any linux program can be run (with varying degrees of success), think of --run
like using sudo
.
If running an application not in the game's directory, you will need to set the CWD (current working directory)
through the --cwd
option:
python3 movfs4l.py --game Skyrim --profile Default --cwd ~/Downloads/Bodyslide --run wine Bodyslide.exe
A few important notes regarding winevfs:
If you don't have any issues with using an older version of MO, then there is no need for you to use this tool. Personally, I found that using older versions made the experience of adding and removing mods significantly more cumbersome as the amount of mods I used increased.
I am still investigating why USVFS doesn't work under Wine, but I have spent time maintaining this project (and created winevfs) as a workaround, until a proper solution is found and implemented.
USVFS works by replacing various low-level filesystem related functions provided by Windows, some of which are not exposed to any public API. Wine has been increasingly implementing these functions, and organizing its codebase to match the way Windows works. Since USVFS only replaces a few key functions (other functions under Windows internally call these functions), Wine has to match the way Windows works internally in order for USVFS to function properly.
Even if I were to find a solution, it can take a relatively long time for the changes to land their way into Wine. Thankfully however, there have been improvements in this area. It is now able to properly load USVFS and some elementary apps (such as explorer++, included in MO 2.2) are able to run, although directory listing doesn't appear to work yet.
Hard/Sym links could be integrated into MO, if the devs were interested in working on this.
Developing for MO under Linux is quite difficult due to the entire way it's built. Not only would their build system have to be significantly modified, multiple subprojects have to be patched as well. In other words, there's pretty much no way a Linux user can make any code contributions to it, unless using a Windows virtual machine with Visual Studio installed.
Winevfs cannot be integrated, as wineserver itself has to be hooked, which requires MO to be closed. It could be possible to hook Windows calls, similarly to how USVFS works, but at this point we're just creating a version of USVFS that temporarily works under Wine, but likely not under Windows.
Hopefully it's easier now, but non-standard paths can always cause headaches in usability.
There are plans to create a GUI that will simplify using this, but it could take a relatively significant amount of time to implement it.
I'd definitely appreciate some help with this one :)