HTTP POST with cmd SET_ACTIVITY Only Updates Once

[danielfewster]

I've been implementing Discord RPC with a Garry's Mod Gamemode of mine, but I'm having an issue where after setting the initial post request, all post requests following that one would not update the RPC info. So, I would send the first POST request, and it would work.

See here: https://dingubear.com/media/06-2018/Discord_2018-06-06_10-55-46.png

However, I'll send another one, with the following successfully returned: 200 {"cmd":"SET_ACTIVITY","data":{"state":"Lobby | 1/100","details":"Mystic Games | Cinema","timestamps":{"start":1528245984000},"assets":{"small_image":"453699594996678656","large_image":"453699121132601344"},"name":"Garry's Mod | MG","application_id":"453690161948000277"},"evt":null,"nonce":"18453.883081315"}

And another one: 200 {"cmd":"SET_ACTIVITY","data":{"state":"Lobby | 1/100","details":"Mystic Games | Cinema","timestamps":{"start":1528246026000},"assets":{"small_image":"453699594996678656","large_image":"453699121132601344"},"name":"Garry's Mod | MG","application_id":"453690161948000277"},"evt":null,"nonce":"18495.261550573"}

But my RPC would not be updated, at all. (200 is the HTTP Status, The JSON is the body)

[Lachee]

+1 Occurs with my implementation too. You can send the first presence via HTTP, however a Discord Client restart is required before any more can be set. The new ones are not visible to other people either (tested with my alt).

[cracyc]

Same here https://github.com/mamedev/mame/pull/3635

[Tenrys]

Same here: https://github.com/discordapp/discord-rpc/issues/97#issuecomment-394845512 https://github.com/Tenrys/gmod_discordrpc/issues/5 https://github.com/Tenrys/gmod_discordrpc/issues/6

[CubitsDev]

Same with me, but I'm stuck on Initializing

[msciotti]

Hey everyone,

Unfortunately, I've been informed that we are no longer able to support Rich Presence over HTTP.

Previously, Rich Presence was tied to a process id, the pid in the SET_ACTIVITY command payload. While it worked (sorta), depending on the existence and accuracy of that pid caused issues, including dropped Rich Presence, presence getting stuck if a game crashed unexpectedly, and other highly stateful issues.

We've moved to depending upon the actual RPC/IPC connection to know when we should or should not show presence. Since HTTP doesn't maintain a connection, it's broken by this change, and we unfortunately cannot support it.

I'm sorry to say this, and understand that there wasn't a fair warning given. My fault for not being more in the know about these changes. Rich Presence via HTTP was not something """"officially"""" supported; it just worked by accident due to changes we made for SET_CERTIFIED_DEVICES.

Moving forward, RPC/IPC connections will be the only supported way to use Rich Presence.

[Tenrys]

This doesn't seem to concern only the HTTP API actually.

It still said I was playing Warframe even though I quit it, so that raised a question. This is on Stable.

[msciotti]

@Tenrys may not be rolled out to stable yet. Canary will have the change, and probably PTB.

[Codingale]

I'm opposed to this, in some of my environments I've only used HTTP. In fact some situations might mean you are sand-boxed into just using HTTP unless you somehow have complicated instructions to users.

[Lachee]

The HTTP endpoint was a super convenient and super quick way to add Rich Presence support. By removing this you are making developers have less initiative to implement it as its more complex and takes more of their time.

For my games for example, they are massive code bases with platform specific limitations already, so having a simple HTTP way of sending Rich Presence allowed me to avoid messy platform import rules and specific implementations of pipe streams (which Unity3D for one cannot handle without a native wrapper). I could just use WWW class within Unity3D and send a simple pre-formatted payload. Doing it correctly one didn't even need a JSON Serializer.

I understand the technical limitations and why there is no easy way of working around of this. A simple solution is to force the game to send a null activity before close, but that doesn't handle crash cases. Another solution is to auto expire HTTP rich presences after 15 minutes or so, and force HTTP implementations to keep it updated with regular updates. This wouldn't be too hard for most implementations as the frequency of the updates is relatively quick anyways.

[ImPerzz]

@msciotti I'm wondering what advice you give to those who can't determine the PID due to game limitations, like Garry's Mod and Lua, you created a big problem for developers without even warning about the changes, and most of the developers have thought about the bug from Discord, but here you state that it's not a bug, I'm wondering how to get out of a situation where you can't determine the PID, and Discord RPC then generally blocks HTTP support. Haha, it's fun.

[Lachee]

@ImPerzz its not necessarily getting the Process ID, its that they cannot accurately determine if the Process ID has ended or not as many process can have child-processes or create new instances. Think League of Legends which creates a new game client after every match, or Unity3D which runs games within the Unity process. Using socket connections allow them to determine that the connection has closed reliably as the socket would have been terminated.

They could have potentially done a timeout system with the HTTP, but it seems like they determined to drop it entirely as it was "by accident" that the HTTP method was working to begin with.

I would still like to see a HTTP base implementation however as a easy-of-implementation and increased userbase of Rich Presence.

[msciotti]

I will bring up more robust HTTP support internally. I cannot promise the efficacy of my message, but I will make concerns known.

My personal biggest qualm with HTTP is that you are entirely unable to make use of what makes Rich Presence meaningful—the ability to Ask to Join your friends, or send chat invitations to play, or spectate directly. If you don't have a persistent connection, you can't subscribe to those events, and therefore cannot implement those pieces.

Having fancy presence is nice. It's nicer than just Playing <Game>, 1000%. But it's a far less interesting, actionable, and meaningful thing without the ability to easily play with friends.

[OmarAssadi]

@msciotti I would considering adding a timeout to HTTP-based RPC. It should solve the issue of getting stuck without totally breaking RPC support for lots of games.

I agree that it would be great if we could also add things like join requests. And, unfortunately due to being stateless, HTTP makes that kind of difficult. But, it's still significantly better than 100% no-RPC support.