Possible Extreme Bug

[FireController1847]

When I had called an UpdatePresence (DiscordRPC.INSTANCE.Discord_UpdatePresence) and then the shutdown (DiscordRPC.INSTANCE.Discord_Shutdown), it took me off my game for a split second and then re-put me on the game, which I can't now get off without re-launching the game. I don't know if this is a bug with Discord Rich Presence or DiscordRPC, but I thought I'd bring it to your attention.

[MinnDevelopment]

I don't see how this could be caused by either the discord-rpc SDK or this binding. I believe this is rather your application than this library or binding target.

[FireController1847]

The issue is, I'm currently using this in Minecraft and I'm not sure how to prevent this issue. What happens is when a user leaves a server and then quits the game quickly, it sends the update on the menu load but that arrives AFTER the shutdown. If you could point me in the right direction, that'd be awesome.

[m-sterling]

This kind of thing happens whenever you don't properly shut RPC down. If you exit your program before calling it (or before it finishes executing, since it seems like it takes a few seconds), you get the bug as described.

IMO I think the fact that the client can't self-update if the app is closed makes me think it's an issue with the SDK, as I don't really see a workaround to the user closing it too quickly.

[msciotti]

I'm having a bit of trouble understanding exactly the steps you're describing, but it sounds like what's happening is:

1. Push Update_Presence() call
2. Call Shutdown()
3. Status disappears
4. Status reappears

As mentioned via email, Discord determines status by the process ID of the program sending it presence updates. If you have Minecraft running and sending presence updates, and then call Shutdown() but don't close Minecraft, we still see the process id and think "Hey, they're still playing, keep showing whatever they sent us last".

Am I correct that the above steps are what you are describing?

[FireController1847]

I believe the steps are correct but what you're describing doesn't sound correct, um..

Here's the steps that happens:

1. User leaves a Minecraft server and returns to title screen, causing presence to update to "Main Menu"
   • Sends an Update_Presence()
2. User quits the game before the Update_Presence() has finished sending
   • Sends a Shutdown() before Update_Presence() has finished
3. The shutdown arrives before the Update_Presence(), causing the game to disappear (like you quit).
   • The Shutdown() arrives before the Update_Presence()
4. The Update_Presence() arrives to Discord, returning the game to your profile.
   • The Update_Presence() arrives

In the end, Minecraft is actually closed, while the presence is still showing.

[m-sterling]

So I did a bit of testing and found out that although the Minecraft modding library (Minecraft Forge) doesn't actually have an "on game shutdown" event, you can still achieve this by using Runtime#addShutdownHook. An example with the RPC library being instantiated as lib can be done as Runtime.getRuntime().addShutdownHook(new Thread(lib::Discord_Shutdown));.

[FireController1847]

@kkirigaya That's exactly what I have and that is what causes the issue.

[FireController1847]

Okay so for everyone participating in this thread, here's a video explaining exactly the issue I'm having.

And here's my presence file & the events that cause these to happen.

package com.firecontrol.minecraftdrp.RPC;

import com.firecontrol.minecraftdrp.MinecraftDRP;
import com.firecontrol.minecraftdrp.Reference;
import com.firecontrol.minecraftdrp.Handlers.RPCEventHandler;

import club.minnced.discord.rpc.DiscordEventHandlers;
import club.minnced.discord.rpc.DiscordRPC;
import club.minnced.discord.rpc.DiscordRichPresence;

public class RPCClient {

    private Thread callback;

    public void initialize() {
        DiscordEventHandlers handlers = new DiscordEventHandlers();

        handlers = RPCEventHandler.setupEvents(handlers);

        DiscordRPC.INSTANCE.Discord_Initialize(Reference.CLIENT_ID, handlers, true, null);

        if (callback == null) {
            callback = new Thread(() -> {
                while (!Thread.currentThread().isInterrupted()) {
                    DiscordRPC.INSTANCE.Discord_RunCallbacks();
                    try {
                        Thread.sleep(2000);
                    } catch (InterruptedException ignored) {
                    }
                }
            }, "RPC-Callback-Handler");

            callback.start();
        }

        MinecraftDRP.logger.info("Created new client.");

        Runtime.getRuntime().addShutdownHook(new Thread() {
            @Override
            public void run() {
                DiscordRPC.INSTANCE.Discord_Shutdown();
            }
        });
    }

    public void setPresence(DiscordRichPresence newPresence) {
        DiscordRPC.INSTANCE.Discord_UpdatePresence(newPresence);
    }

}

Here's the event.

@SubscribeEvent
@SideOnly(Side.CLIENT)
public void disconnectFromServerEvent(ClientDisconnectionFromServerEvent event) {
    Reference.serverPresence = null;
    DiscordRichPresence presence = new DiscordRichPresence();
    presence.state = "Main Menu";
    presence.largeImageKey = "crafting_large";
    presence.largeImageText = Display.getTitle();
    MinecraftDRP.DRPC.setPresence(presence);
}

[FireController1847]

Okay so @kkirigaya and I have decided the simplest way to fix this would just be adding a "queue"-like system into the module that prevents multiple calls being sent at once.

[FireController1847]

This looks very similar to discord/discord-rpc#61 and they're saying it's fixed. Is this similar or no?

[FireController1847]

Closed via discord/discord-rpc#85