Feature Request: Support launching alternative binaries from the heroic:// protocol.

[Sewer56]

Hello again, Heroic team! 👋

I'm back again, as focus shifts towards Cyberpunk 2077 support, I figured I'd throw another feature request this way. Since I overlooked a small requirement for future games last time. Oh nooo >.<

For the unfamiliar, I'm one of the folks working on the Nexus Mods app (a Cross Platform, GPLv3 Mod Manager) built in house, for the community.

We currently support managing, modding and launching GOG games installed via Heroic, in order to make modding easy and accessible to everyone; (this means us folks on Linux included!).

And to make the both the next and future games tick just right; we have a unique requirement.

What's missing?

We can currently run binaries with command line parameters by specifying multiple instances of
the arg commandline parameter.

However, there is not a way to explicitly state which binary (executable) is currently ran from the handleLaunch entry point. This is not currently supported by the protocol.

Why we need this

There are cases where we may need to run a non-default binary for a game.

Some examples include:

• Cyberpunk 2077: We need to launch REDmod (CDPR's 1st party modding tool) from tools/redmod/bin/redMod.exe if the user decides to install a REDmod.

• Mount & Blade II: Bannerlord: If the user has Bannerlord Software Extender (GitHub); which is required for some mods, then we need to launch the game via a wrapper executable (Bannerlord.BLSE.Standalone.exe)

While the first case is a bit less common, as you can usually recompile/port modding tools, the second case is a somewhat common one. In modding, it is fairly common practice to use a wrapper executable; to launch a game. The idea is that you start the game in a suspended (paused) state and use DLL Injection to load a mod loader into a game, before unpausing it.

Given that a wrapper is the form that some mod authors expect their software to be ran, we try our best to match their expectation; hence this feature request.

Current Situation

Currently when we launch mod tools and games from within the App, we request the user's store (installation method) to start the process whenever possible. Right now, that's the heroic://launch/ protocol.

The idea is that by launching via the launcher (Heroic in this case), we can ensure that the end user's GUI preferences for things like Wine/Proton version, WINEPREFIX, ESync, FSync, MangoHud etc. are respected. We want booting games from the App to be just like booting it from the launcher; for those cases where we need to launch a wrapper.

From a compatibility point of view, this is also good. If the game has some Windows dependency, such as Visual C++, that's also used by the mod tool(s); we'll likely already have it installed out the box, avoiding potential problems.

However, it's not currently possible to launch a tool that's not the game.

What we're thinking

It would be helpful if it were possible to override the started binary via Heroic's protocol.

Currently launching a binary looks something like:

heroic://launch?&appName={idAsNeutralString}&runner=gog&arg={arg1}&arg={arg2}

It could be extended to something like:

heroic://launch?&appName={idAsNeutralString}&runner=gog&arg={arg1}&arg={arg2}&binary={exeOrElfPath}

With either a relative or absolute path.

Technical Details

Extremely quick look reveals there already is an API for launching binaries in a given WINEPREFIX, named runWineCommand (main.ts). Caveat is however, it seems that this API does the minimal amount of work, meaning that it does not sync saves; may not activate presence etc.

Given that sometimes we want to boot a full game via wrapper, it would appear that extending the existing API of launchEventCallback instead would be an alternative way. That would in turn mean extending GOGGameManager class and the other game launchers; but that may involve some extra effort.

And there's also the whole inner launchGame API, that has different setup/teardown logic.

I would like to hear your thoughts.

Once again, we're happy to help out with this if you need any support from us - just let us know!
And of course, thanks for your time 🤞