Implement ExtraVFS for extended VFS usage such as redirecting savegames

[Kethen]

For redirecting for example %USERPROFILE%/Documents/Test Drive Unlimited to %USERPROFILE%/Documents/Test Drive Unlimited Platinum

extra_vfs.json producers should be responsible for %USERPROFILE% resolution when writing extra_vfs.json, example extra_vfs.json:

{
  "PathPairs": [
    {
      "Source": "C:\\users\\katharine\\Documents\\Test Drive Unlimited",
      "Dest": "C:\\users\\katharine\\Documents\\Test Drive Unlimited Platinum",
      "DestHasToExist": true
    }
  ]
}

Sidenote: on master, D3D9/D3D9HookManager.cs has issue building due to missing two } at line 88, Net/DNSRedirectionManager.cs also does not build due to missing namespace WS2_32

[MeFisto94]

Sorry for the late reply, I have been thinking a bit about savegame isolation and it's so important because how we solve it dictates how we'd address future features as well.

Like, when I first thought about the feature, I'd have written a plugin that just uses the BasicVfsManager and adds a mapping for SpecialFolders.Documents (or something).
This has a few pros:

• It will always work for the specific game, even if you had to use registry hacks (i.e. the game checks for it's installation location that way)
• It requires no changes (well, maybe support for absolute paths in the manager)
  Con: Needs to be written for every game and thus especially compiled.

Another solution would be having a customized payload dll (we will have those for tdu anyway, e.g. to allow patching bnk contents). That means you don't need to search the plugin, there won't be multiple implementations, it could even be integrated into the generic launcher, so it's very standardized.
That would mean we have the full capabilities AND having it very clean, but the drawback is, if you want to mod a random game and if there is no custom payload yet, you should get quite far with Andraste.Payload.Generic.dll. Especially if you're not a developer, installing VS and compiling is very tedious.

Another solution would be to have some sort of templating and descriptive language in json. That's kind of how you did it. This could also work as an extension to BasicVfsManagers, but then you'd need a plugin again and it would have to break out of it's "sandbox" by placing the savegames outside of it's mod folder (you really want them to be stored as mods/ savegames/ ....).

Risk here, is that the descriptiveness is not powerful enough and/or who is responsible for writing that file. A game specific launcher most likely?

So yeah, so far I don't know what the best solution could look like, especially considering there may be similar challenges still awaiting us.

[Kethen]

I think custom payload/descriptive json would be the best ways for the savegame/userdata use case, given the intent of keeping the VFS api away from mods so that things don't get too complicated, with mods conflicting with each other.

Descriptive json out of the two meanwhile allows it to be generic, while keeping things manageable since there is only one place to look for out of game directory redirects.

As for the way that is implemented in this PR, the intent is indeed for game launchers to write extra_vfs.json, be it a generic andraste launcher that allows user to put in redirects to their heart's content with a GUI, or a game specific one that seeks out registry values and environment variables to perform specific redirects.

I'm not sure about registry hacks done through hooking, that depends on how complicated it ends up compared to extending the current VFS implementation, and which ends up more solid working. Some games probably also just check for environment variables for paths so that might also be needed on top.