SlySven
commented
1 week ago ... In addition, the username is "arRPC" and it does not contain my user info.
I've just discovered that the 3rd party FreeBSD implementation of the Discord Application won't talk to the Mudlet application I'm coding for because it is using this project - apart from anything else when my Application starts up on FreeBSD the callback message it is getting contains the bogus values you can see on lines 42-50 of: https://github.com/OpenAsar/arrpc/blob/main/src/server.js rather than the "real" values - and since my application does cross-check for a user-name match before using it further it is not going any further when I was checking against my actual username.
As it happens not doing that check (or making my application check against the value arRPC) still fails to make the Rich Presence work - so even if this library was sending the correct user details from the 3rd-party Discord application I'm not sure it is usable yet...
I am on the Vesktop Flatpak, using a Discord RPC bridge EnderIce22/rpc-bridge to connect to games running via Proton. It works flawlessly with the official Discord client, but not the Vesktop Flatpak. I have two log files for the game Hades here:
vesktop-flatpak-with-bridge.log official.bridge.log
official.bridge.log is the log file with the official discord client running. The first response from discord-rpc over the pipe is a DISPATCH command with the header
"^A^@^@^@y^A^@^@", and data from my user profile provided.However, the first response from arRPC over the pipe in vesktop-flatpak-with-bridge.log is a DISPATCH command with a completely different header:
"^A^@^@^@E^A^@^@"Notice there's an "E" in the spot where there should be a "y" - In addition, the username is "arRPC" and it does not contain my user info.This breaks the implementation of RPC-bridge by EnderIce as the Unity Game does not know what to do with this different header, so it does not send a response back over the pipe, breaking the rich presence.
Please fix so the headers match.