Add an butlerd endpoint to get the game's executable path(s)

[hagabaka]

Butlerd has a Launch method, which will use dash to figure out the best way to run the game, however it doesn't provide an API to get this information. Knowing the executable path could help butlerd clients implement running with compatibility tools, or customize command arguments like Steam's "set launch options" feature.

[hagabaka]

Here's a list of proposed API changes:

• Add method Launch.GetCandidates: get the launch targets for an installed game

  Parameters:

  • caveId: string
  • nonNativePlatforms: Platform[] (optional, a list of platforms which can be supported by compatibility tools. For example, if on Linux and wine is available, this list can include windows)

  Returns:

  • candidates: Candidate[] (Candidate happens to be already documented)

• Extend method Launch

  Add parameter:

  • nonNativePlatforms: Platform[] (optional)

• Add server request NonNativePlatformLaunch: sent if there is no best launch target for the current platform, but compatibility tools may be used to run the game

  Parameters:

  • candidate: Candidate

[fasterthanlime]

I'm going through this right now and wondering what the best approach really is.

Right now, there's a single Launch endpoint, and butler is responsible for launching games, except when they're HTML5 games, in which case it does a server request. If there's several candidates to disambiguate from, it uses PickManifestAction.

Adding NonNativePlatformLaunch expands the API surface in a way I'm not sure is great.

Eventually, I'm going to want to support Wine (and maybe Proton) in itch itself, and I don't want TypeScript code running in Electron to be in charge of calling wine.

Would it be enough if it was possible, for each non-native platform, to specify:

• a wrapper (wine, etc.)
• environment variables
• extra arguments

So for example, you'd do pass this to Launch:

{
  "caveId": "XXX",
  "wrappers": {
    "windows": {
     "wrapper": "/path/to/wine",
     "env": { "WINEPREFIX": "/foo/bar", "HOME": "/tmp/blah" },
     "args": ["--foo", "--bar"],
    }
  }
}

This seems like it would work fine for Wine, but I'm not sure how Proton, DosBox & others do it. (Note that butler has no way of identifying, say, ROMs, so RetroArch is probably out of scope at the moment).

One thing you haven't covered here is that butler will simply ignore non-native uploads at the moment (when queuing install) - have you already find a way past that or should we consider this as well ?

[hagabaka]

I think the wrappers approach would work for wine and proton, and GameHub should be able to use it (@tkashkin correct me if I'm wrong). DosBox has its own command line parameters, and sometimes it's necessary to run additional DosBox commands to mount things before running the game. But it should be possible to write a shell script wrapper to do that.

So far, specifying the upload.id seems to allow butler to install most Windows games on Linux. It doesn't work for games that come in an "installer.exe" of course. To handle that, should the wrappers parameter be passed with Install.Queue too? Another possibility is to have a server call of GetWrapper, which passes the platform information, and expects the path, env, and args for a wrapper program. This could be used for running both installers and games.