Ability to switch between open clients of Discord

[spthiel]

So I've been using the Discord Integration for IntelliJ which uses the Discord rpc but I experienced a problem with which cannot be fixed by the plugin author himself.

At the moment I'm simultaneously running Discord (alt account) and Discord PTB (main account) and the rpc will always connect to the main Discord window. The problem I have with this is that I want the rich presence to be displayed on my main account (the PTB).

With that in mind, I'd like it if the rpc would detect if there are multiple clients open (e.g. normal, ptb, canary) and add the ability to chose which to send the presence to if not multiple of them.

[Lachee]

+1 this is a basic feature that is super easy to implement.
Basically you just pass a target pipe number and start scanning from that number onwards in your for loop here: https:/discordapp/discord-rpc/blob/master/src/connection_win.cpp#L37

[msciotti]

You'd need more than that, because the port number/pipe of a given Discord client will always be the first available in a range, and not always the same, depending on the order in which you open multiple clients.

So the client would need to return its build type—Stable, PTB, Canary—in the ready payload. Then, you would need to prompt the user as to which client they'd like to have connected.

There's a little more here than just passing a pipe number. I think it's also safe to say that the vast, vast, vast majority of Discord users have only one client open on their machine.

It seems like the easier solution for your case is to open the client you want first, connect, and then open the second client.

[SlySven]

Hang on though - isn't having more than one version of the Discord application open an advertised method of testing Discord related application code/libraries? Not being able to connect to/choose the right Discord instance could be getting in the way of things there - though I agree it would be a minority issue!

[Lachee]

From a technical standpoint its relatively easy. My library implements it already. I wouldn't bother having the prompts like Mason suggests for which version as this is really a debug only feature. Normal end-users have no need for this as in theory they should only have one client. Developers however will find this very useful for testing their Rich Presence and can have secret/developer access to the internal works of their applications, so they should be allowed to access more advance and non-user friendly ways of debugging.

Like I said before, my library implements it by literally letting the developers to set where the for loop starts when I scan for discord named pipes. This will allow them to offset by 1 just for testing purposes. I cannot see this feature being opened up to end-users to select their client as they should only ever have 1.

[msciotti]

It's a reasonable short-term idea to simply allow users to pass a pipe number offset to the Initalize() function. It still isn't terribly ergonomic, as if you open clients in a different order, the pipes will bind different. I'm not sure if re-starting your app and changing the pipe offset number in your code is a simpler solution than quickly closing and reopening your two discord instances so the right one opens first - though I freely admit that's also not a great solution.

Perhaps it's...good enough? Maybe it's a safe assumption that a user of this feature would always have their "main" discord open on pipe 0, and pipe 1 would be connected/not connected depending on if they're actively developing.

[msciotti]

I'm sorry that this took so long. The update has been merged and should be all set. I can roll a new release in the morning.

[msciotti]

Reopening this as the commit has been reverted.

[msciotti]

This commit was reverted in this PR, but it is supported in our GameSDK using environment variables.

https://discordapp.com/developers/docs/game-sdk/sdk-starter-guide#testing-locally-with-two-clients

[SlySven]

Am I missing something here? My project has to use the Discord-RPC as it is a GPLed F.O.S.S. project (on macOs 64-bits / Windows 32-bits {and soon 64-bits but that is another story} and Linux 64-bits platforms) so cannot use the GamesSDK - so what is the current state with the discord-RPC library? 😟

[msciotti]

The same as it has been since April 29 of this year. This SDK has been deprecated, though the underlying RPC functionality has not been broken. You're free to use this repo, but we will not be officially supporting it, as it doesn't make sense to support two SDKs that accomplish the same goals for the same platform.

Discussion was here: #290