-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(discord-rpc): improve the system #4271
feat(discord-rpc): improve the system #4271
Conversation
7cbe17b
to
4214950
Compare
4214950
to
df87bc7
Compare
acb8b98
to
84a4b5d
Compare
This pull request introduces 1 alert when merging 84a4b5d into 1f7ea2a - view on LGTM.com new alerts:
|
dbd3324
to
47bae74
Compare
...ms/DiscordRPC/src/main/java/org/terasology/engine/subsystem/discordrpc/DiscordRPCThread.java
Show resolved
Hide resolved
@iHDeveloper what is the status on this and what is left to be implemented? |
Working on it. I'm debugging the party size commit. And, I'm not sure if the secrets should be implemented in this PR. Or, maybe later. |
@iHDeveloper I would suggest keeping the PRs about as small as could be, for more frequent merges. Can always keep going in additional PRs :-) Every checkbox in the bullets above could pretty much be its own PR, although if multiple finish around the same time anyway and overlap at all then grouping them may make sense. |
e02c616
to
e3b8063
Compare
This PR is ready to be reviewed and merged into the codebase. \o/ 😄 I discussed with @Cervator and decided not to implement the secrets feature in this PR. I tested this PR on both Singleplayer and Multiplayer (Hosting only) with the latest build from the develop branch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good overall, left a few comments. I haven't tested this, though.
.idea/checkstyle-idea.xml
Outdated
@@ -10,7 +10,7 @@ | |||
<entry key="location-1" value="BUNDLED:(bundled):Google Checks" /> | |||
<entry key="location-2" value="PROJECT_RELATIVE:$PROJECT_DIR$/config/metrics/checkstyle/checkstyle.xml:Terasology" /> | |||
<entry key="property-2.samedir" value="config/metrics/checkstyle" /> | |||
<entry key="scan-before-checkin" value="false" /> | |||
<entry key="scan-before-checkin" value="true" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What kind of scans does this include?
@keturn to the rescue? 🙃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly, I didn't notice this file is added into the commit stage. 😅
But, I can assume it happened because I enabled the Checkstyle scan before VCS check-in (aka before commit).
Edit: Should I disable it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes please - while that's possibly a good practice it is probably better if we leave it up to individual contributors for now, not all of whom may even have the Checkstyle plugin installed (I don't remember if that's a default one) :-)
Probably would be a different project to actually get the Checkstyle config and docs to the point where we could consider doing this for real. We'd want to make sure we have good docs on what a false positive is, for instance, or that might confuse contributors and lead to unrelated "fixes" in PRs we then have to ask to have undone 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then we should find a way to ignore these change by default (put .idea
into the git-ignored list?). I think if a user changes this setting, it will automatically reflect in a change in this checked-in config file.... =/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a topic for another venue. For the purposes of this PR, if it's not obviously the right setting, go ahead and revert the change to this file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright I will revert the change and try to avoid adding those unrelated files by accident 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright I will revert the change and try to avoid adding those unrelated files by accident 😅
} | ||
logger.info("Discord RPC >> Disconnected!"); | ||
thread.start(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we log the start of initializing as INFO, should we also load the success when the thread was started (analog to the case where the integration is disabled).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose of the thread is to be alive all the time until the game shuts down. But if the user disabled the RPC the thread will be in the sleeping mode until something changes and notifies it. When the thread gets notified it tries to connect to the IPC server. If it fails to connect 5 times at maximum then the thread will go sleep again.
|
||
public final class DiscordRPCThread implements IPCListener, Runnable { | ||
private static final Logger logger = LoggerFactory.getLogger(DiscordRPCThread.class); | ||
private static final long DISCORD_APP_CLIENT_ID = 515274721080639504L; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a random number or something assigned to us in some way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This random represents the client ID of the Discord application. Discord client needs this ID to fetch information and assets about the application to display it to the rich presence.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think that might be associated with our registered app on Discord, which I originally set up. Nowadays the app is owned by a team with several of us having access 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that sensitive information (like an access token) or more of a global identifier?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an identifier 👍 There's also a secret but I don't think it is needed for anything in this case.
Incidentally you should have access to it via https://discord.com/developers/teams/781638052501520417 although it looks like you might have gotten an invite and not accepted it yet (Nira is in)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep as Cervator said it's an identifier so it's not sensitive information. And, about the secret, it's mostly used in OAuth2 applications which I think we don't need soon.
I agree with what Cervator said. And about the secret, it's mostly used in OAuth2 applications which I don't think we will need soon.
@Override | ||
public void run() { | ||
while (true) { | ||
logger.info("Waiting for auto-connecting..."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How much will this actually log on the INFO level? I'm cautious when I see logger.info
in combination with loops or frequently called methods as this might spam the log.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose of the loop is to keep the thread alive. It's rare for this auto-connect log to appear.
It will appear by one of these conditions below:
- Once on the start
- Every time the player disables the rich presence from the player settings (if the player doesn't have the Discord client)
- When the thread tries to find the Discord client but still couldn't connect to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Likewise a bit concerned here, it doesn't seem overly far fetched that a connectivity issue could appear then suddenly the log is being filled by junk due to a decidedly optional extra that you could play without perfectly fine otherwise :-)
In other words: if the Discord integration breaks or is in a bad state it shouldn't be too loud about it - ideally just log once per "incident" however we define that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what happens if the discord servers are down, or the player just does not have an active internet connection?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Discord client hosts a local IPC server for the applications to connect it.
When the application connects it exchanges information with the server to identify the application.
And then the application can send RPC information every x amount of time to update it.
The Discord client decides which application RPC will be shown depends on different factors.
If something happens in the Discord servers the only affected side is going to be the Discord client.
The Discord Client runs the IPC server when the client starts. And it doesn't stop until the client is being shutdown.
And until that happens it's going to stay listening to application RPCs whether the Discord server is down or not.
It's user-specific file. It shouldn't be shared since each user has its own settings.
Change main menu state from "In Lobby" to "In Main Menu"
The rewrite was necessary to be able to achieve the system to be thread-safe. It gave the opportunity to organise how the subsystem works. This also ensures the subsystem is easy to: - Implement new features! - Fix bugs without breaking stuff - Separated the thread into its own class - Subsystem manages the communication with the thread - Re-organized the system - Fix: disable discord-ipc library logger
Used to set the gameplay name (e.g. Josharias Survival, Metal Renegades, etc...) It will show on discord in this format "Game: <name>" - Improve the buffer change trigger and handler - Ability to change details in the buffer - Apply the new format for the rich presence -- Details -> "Game: <name>" -- Party State -> "Playing Solo" / "Playing Online" / "Hosting" - Fix: Triggering `Thread#setEnabled` with keeping the connection alive - Fix: No safe shutdown to the RPC thread
- fix: can't hide start timestamp
e3b8063
to
dc1c158
Compare
PR ready to be merged 😄 |
😕 Wanted to briefly test this on my Linux machine, ending up with an exception...
Discord integration works in principle, at least Spotify manages to display my activity nicely... Edit: this might be related to having Discord installed via snap or flatpak. See jagrosh/DiscordIPC#16 and flathub/com.discordapp.Discord#29. Seems like the actual socket file on my system is Edit 2: Followed the steps in https://github.com/flathub/com.discordapp.Discord/wiki/Rich-Precense-(discord-rpc) and got it to work with flatpak. |
Contains
This improvement aims to fix bugs in the system.
And, it improves communication between the game and Discord RPC to provide full access to its features.
Source: Discord Developer Documentation
Currently, the system supports
state
that can be changed dynamically usingDiscordRPCSubSystem#setState
.And,
details
is also supported but its value is fixed asName: PlayerName
. It can't be changed.This PR is going to implement other features such as
partySize
,partyMax
, etc...Discussion Points
Turning the
default
to be dynamic to have different details from different gameplay such asCurrently in JoshariasSurvival
, etc...Since the engine has a networking infrastructure I'm thinking that we can implement the secrets (
join
andspectate
)in a way to provide the modules the ability to receive events like
DiscordAskToJoinEvent
andDiscordSpectateEvent
.Instead of each module dealing with it in a raw way.
Comment about what do you think of the points above? 🤔
Bugs
The game assumes the player is in the lobby while in reality, the player is in-game.
The Discord RPC connection is being handled in a separate thread to avoid conflicts with the game.
The system isn't thread-safe which might result in unexpected behavior.
How to test
git fetch origin pull/4271/head:<localBranchName>
git checkout <localBranchName>
Discord Rich Presence
turned on.In Lobby
toIn Game
NOTE:
In terms of unit testing, I'm not sure how I would implement it for this system. 😅
Outstanding before merging
reflections.cache
for subsystems #4274)details
(48d1502)