Disclaimer: This is a very WIP feature/overhaul, which is why I marked this as a draft. It is my first major thing built in rust, only my second ever project working with vue and my first time using tauri. If there are any things anybody would like to have changed or advise me about, I very much welcome it, as this is a pretty big opportunity to learn for me.

Here's a short demo of what I've been working on:

video

What I did / am doing here:

• Rework the UI a bit to be responsive and make the window resizable
• Implement the ModDownloader, ModManager and ModInstaller in seperate vue sfc files to keep things organized
• Built a download backend in rust that can do single- and multithreaded downloads and communicate with the frontend based off of https://github.com/mattgathu/duma with modifications and omissions for this project
• Build support for storing game download and mod files somewhere else than in the user's .config directory based off of game specific config files (which could also be implemented as a single large config file as a collection of all game profiles, not sure about that yet)

I also added features and planned features to the README on my branch to reflect the changes I'm working on: README.md

There is no support for Nexus Mod's "Mod Manager Download" yet and I don't know whether it will be easy to implement, but I don't think so, as you need to store user credentials etc. This means the download manager is at best only a commodity right now, but it's a WIP proof of concept.

Any criticism is also welcome, because - like I said - this is a learning opportunity for me :)

This issue refers to this comment on your Reddit post

Basically, MO2 for windows has the ability to overlay the mod files into the game directory only for the Game and various tools. This is really handy for keeping the game folder clean and not breaking the game with mods. It also enables making easily portable profiles.

There's OverlayFS and also others as far as I know that should work for Linux.

Right now this probably won't be a priority, but it'd be something I myself and likely others would like to see as a feature. This would likely also benefit from #2.

This is just a suggestion and Vortex doesn't implement it, but it's a very big nice-to-have and I have grown used to it with MO2.

The Problem:

Currently, Tauri moves files into the target folder naively. This can cause issues if and when a file must be overwritten or changed. Furthermore, it can cause issues of duplication, given that the file is now stored at two locations. It also incurs wear on the drive of the user by multiplying writes. Further, it causes the original installation folder to become "tainted" which makes recovery from unstable mods or improperly installed mods difficult.

The Solution(s):

• Use Linux's built-in OverlayFS. OverlayFS would behave more-or-less like Mod Organizer's VFS. For a more in-depth explanation of it's functionality, it'd be best to see the Arch Wiki. https://wiki.archlinux.org/title/Overlay_filesystem
• Link the mods into the game directory and remove the links when done. This allows files to only touch the original folder, rather than actually modify it. Still creates issues with regards to keeping the original files and folders "vanilla"
• Link the original files to a "staging" folder. This should allow launching the game from the "staging" folder as if that were the original folder, allowing a parallel game install without duplicating files.

The Why:

The reason for the alternatives I've suggested is that they're already implemented in any standard, non-archaic Linux system. Anything from the last decade should support these two features. The fact that they're a part of the Linux system also means it doesn't add dependencies. They are also (mostly) non-destructive. They shouldn't touch the original game files directly at all, ideally. The biggest point is to get parity with the likes of Mod Organizer 2 and Vortex. The biggest hurdle, in my opinion, is the implementation of deployment methods that are more complex than just moving files. For some games it may even be necessary to do just that (such as those that require some degree of hackery to get them modding-read). Any further suggestions for deployment methods would be nice. Though I do want to clarify that this issue is not intended to discuss application specific deployment methods, such as may be the case for something like OpenMW where Tauri could edit the OpenMW modding-related configuration files.

It would greatly benefit from separating the mod manager logic from the GUI itself .

• easier to read
• you can more easily rework the UI without having to move a bunch of mod manager logic which can increase the chances of making a mistake
• you can easily make a cli version ( for launching a game without opening the mod manager GUI for exemple, ... )

Added Bethesda Games that just require Mods in the Data folder

I want to help on the UI as well but I have little experience in vue. But I can Test compatibility for games from both Steam and GOG .

Added mod_manager.rs and moved scanGames and deployMods to rust instead.

Deploy will no longer do anything as i will be working on the VFS logic where instead of actually putting the mods into the games folder, it will create a seperate folder for the game and will overlay the mods on top of it, this way the game folder is never actually changed and always stays like it is when downloaded. this will not only make it easier to mod your game but also prevent modding from breaking your game install.

OFS makes it so the mod manager never actually touches your games file, it overlaps all of the mods on top of your games directory as a new mounted directory this way the original directory is never changed.

While trying to get mods working using symlinks a while back I ran into the issue of mods expecting the file system to be case insensitive.

There are some solutions to this but most of them have very high performance cost, however ext4 can be formatted to support case insensitivity with very little to no performance cost.

For this to work it requires a supported kernel, the ext4 partition has to be formatted with a special flag and the folder to be used has to set a special attribute.

A guide is available here https://www.collabora.com/news-and-blog/blog/2020/08/27/using-the-linux-kernel-case-insensitive-feature-in-ext4/.

This method would require a user to have a properly formatted ext4 partition but it allows for use of symlinks/hardlinks instead of having a virtual file system.

I think this could be useful for avoiding using virtual file systems which have always had problems with mod managers in general.

A way to handle this would be to have the mod manager ask the user to specify a partition/folder that would be checked for the required flags.

I want to add that symlinks in Windows have a lot of issues but while using the case insensitive ext4 folder with symlinks in Linux I have had no issues running modded games likely due to differences in how Linux handles them.

Edit:

Could also use an ext4 loopback device instead of a separate partition but I'm not entirely sure what the procedure for that is and what kind of performance penalty that might create.

Something like this but with the addition of the casefold flag, https://www.thegeekdiary.com/how-to-create-virtual-block-device-loop-device-filesystem-in-linux/.

I am getting the following error when I run npm run tauri dev:

pkg_config failed: `"pkg-config" "--libs" "--cflags" "dbus-1" "dbus-1 >= 1.6"` did not exit successfully: exit status: 1
  error: could not find system library 'dbus-1' required by the 'libdbus-sys' crate

I recognise the project is still in early days, but I feel like this would be something useful to consider as development moves forwards.

To support a wider range of games and the weird and wonderful communities that make up the modding ecosystem, it would be great to have a means of providing some game-specific hooks in the backend code for providing various pieces of functionality.

(for some background, I maintain Unreal Archive and it's various components and repos - effectively a giant database of Unreal series mods and content - so I'm using this as an example).

So as someone who'd be keen to contribute some functionality to this project to facilitate the installation and management of the above-mentioned content, the capabilities I'd like to have available include:

• metadata query:

  • pass in the file/archive the user selected, and either by interrogating the local file content itself (for games which already support this sort of thing natively, or in commonly used mod packaging formats), or calling out to some sort of web service (in my use case, I'd hash the file locally and attempt to lookup metadata from an online source), and return some basic information like: formal name, author, version, release date, web links, etc, which can be displayed in the UI

• unpacking/installing:

  • in the Unreal example, there's a UMOD format, which is a fairly simple packaging format which a lot of mods were distributed in, intended to provide simple double-click-to-install functionality (Windows only).
  • as such, I'd like the "install mod" functionality to be optionally handed off to some game-specific installer, which again just takes as input the file/archive the user selected, and figures out how to unpack it in whatever game-specific or proprietary format may be required.
    • the unpacked files can be put into some specific directory tree which TMM can then "deploy" using its preferred method (overlayfs, symlinks, copy the files in, etc)
  • this would also go towards unpacking certain mods in certain ways; for example Unreal Tournament 2004 content sometimes unpacks into the standard directory structure, and other times may unpack into it's own sub-directory, depending on the specific mod's requirements (pathing information in this case is available via the UMOD file)

• dependencies:

  • I think this one will always be tricky. I would again suggest the ability to toss the user's selected file/archive/package at function, which has the responsibility of querying that content, either using established mod package formats which provide dependency information, or by other means (in the Unreal case we can do this by querying Unreal Archive to get a list of required files/packages).
  • the implementation of that dependency checking function would likely need to be able to interrogate already installed mods, mods selected for installation, and the actual target game's filesystem contents to see what's there and what's required
  • output from this process might need to feed back something that can be fed to further metadata or perhaps a search API which can resolve the things the user needs to install to solve the requirements

• [optional] search:

  • provide some sort of game-specific search hook that can find things using custom search implementations which query variable backends for results and offers information/download options
  • I'm only really listing this here since it feels like it makes sense within the context of the dependencies API

I think providing this functionality would allow people like myself to implement and extend richer support for somewhat esoteric or "legacy" games and formats beyond just "select zip file and extract file extension .xyz into directory /abc/".