This is a work in progress wiki that will contain guides on how to use the manager and all use all of its functions

• When deploying, this folder keeps all of the vanilla files/Files already present in the target location as a sort of backup to prevent user error. If we were to hard link all of the modded files into the Data directory without this then we would end up with a mix of non hard linked files and hard linked mod files.
• If someone were to manually delete their staging folder, the hard links in the Data folder would "collapse" and now every file in the data folder would not show up as a hard link. This would make removing the modded files tedious. This _core folder means in such event you can delete the data folder and rename Data_core back to Data and modded files will be removed and vanilla files restored.
• This doesn't happen with root deployed games like Cyberpunk and Witcher 3 as well as Ue5 games. Any replaced vanilla files are backed up to the staging directory but if you manually delete the mods folder while deployed then you're going to end up with modded files mixed with vanilla files. The manager would no longer be able to remove these modded files as the hard link has "collapsed" and no longer reports as a hard linked file. Always run restore first if you need to manually delete mods from the staging folder.

• On linux we are able to have 2 folders called SKSE and skse, This would cause problems if we launched the game with both these folders. The solution is trivial. Just rename every folder to have the same casing. The exception to this is Stardew valley (Linux build) which must preserve the casing the mod author set their mod to.

For games like cyberpunk which already has a lot of the folders mods go into, the destination casing is kept.

Some mods like compass navigation overhaul also require specfic folder casing. Some special stuff happens to make sure these mods work. But if any don't, report it as an issue as a special exception may have to be hard coded for that mod

• In simple terms. Start from the bottom of modlist.txt > add that mods files to a filemap > do the same with the next mod > if the same file and filepath has appeared previously then remove the previous entry > Do this with the rest of the mods.

• Any game that already has a competent native linux mod manager, For example Elden Ring has Me3 manager which has an appimage. Elden ring has a fairly complex modding system and authors package their mods around this manager anyways. I'm not trying to reinvent the wheel here.
• Older games / Games with low mod counts. Unless people specifically request it, there's no point putting in the work for a game that only has a few mods available or one that no one is really playing. If it can quickly be added with the define custom game handler, then sure I'll add it.
• Games that I personally cannot get to work. I test every game I add. I'm usually not satisfied until it works and won't add a game unless im sure it does

• You don't need to. For bethesda games, the original launcher is backed up and the script extender gets renamed to whatever the launcher was. Which means you can just run the game with the normal launcher via the mod manager or on steam to launch the game via script extender. This is useful for steam deck gaming mode as it means you don't have to set up script extender as a non steam game or use any command line arguments to launch script extender in gaming mode. The exception to this is Oblivion Remastered, This game throws an error if you rename the original launcher.

• They all achieve the same goal but each comes with downsides
• Hard links can be loaded fast and take up no space, However when the source file is removed the hard link is removed which can cause issues. The hard linked file must also be on the same drive as the source file. They also look like normal files and report as taking up space which can cause confusion
• Symlinks can be created between drives and are distinguishable from normal files. Removing the source file stops the symlink from working but the symlinked file still shows as a symlink and can be easily removed. The downside of these are they much worse than hard links when playing with large modlists as they take longer to load. The manager allows you to freely swap between both methods and symlinks may be fine for smaller modlists.
• Mo2 style vfs (FUSE and overlayfs): These have the benefit of not moving any files to the game directory. I have added both of these to a test build, Neither provided any real benefit over hardlink/symlink and caused more issues than it was worth.