discordjs / discord.js

A powerful JavaScript library for interacting with the Discord API
https://discord.js.org
Apache License 2.0
25.2k stars 3.96k forks source link

Activity.ApplicationID set to Null regardless of value #2103

Closed favna closed 6 years ago

favna commented 6 years ago

Please describe the problem you are having in as much detail as possible:

Regardless of whether the applicationID is set to a valid snowflake ID it is read as null when the bot is actually running. This can be seen when requesting it after the bot is running by looking at message.client.user.presence.activity.applicationID. When getting the URL through the assets it is also returned as https://cdn.discordapp.com/app-assets/null/352512111177498644.webp and in here replacing null with the actual ApplicationID that should be there (thus creating the url https://cdn.discordapp.com/app-assets/352511502210695168/352512111177498644.webp) it shows that this URL does actually direct to an image on discord's CDN.

I have asked if anyone else was experiencing this in the #lib-questions channel on the server (messageID 379402297823985664) but I got no responses, therefore I cannot fully confirm the issue also occurs with other people. That said, I have tried different otherwise valid applicationID/ImageID combinations such as https://cdn.discordapp.com/app-assets/355326429178757131/355327858534645760.webp

Note: All imageIDs in the section above belong to large images, for an example smallImage please see code snippet below.

Include a reproducible code sample here, if possible:

client.user.setPresence({
    activity: {
        applicationID: "352511502210695168",
        name: "RWBY with Pyrra Nikos",
        type: "LISTENING",
        url: null,
        details: "Season 5 Episode 5",
        state: "Too many feels",
        timestamps: {
            start: 1508371200,
        },
        assets: {
            largeImage: "352512111177498644",
            largeText: "Pyrrha Nikos",
            smallImage: "352514799856517120"
        },
        party: {
            size: [1, 2]
        }
    }
});

Further details:

I have chosen for high priority because this prevents me from pushing my entire "migrating to DiscordJS 12.0 (master)" work to my GitHub repo as I am of the strong opinion then when I deliver something I ensure it is properly and thoroughly working. Having everything working but the RichPresences due to something like this is in my book unacceptable. There are many people who use my selfbot and I've had a multitude of requests to migrate over the past few days since Discord had Rich Presences go out of private alpha so I want to deliver to my users as soon as possible.

Note: As is clearly stated above, yes this involves selfbots. Yes I am fully aware of the rules and concerns around them and I also thoroughly warn all users of these things in my installation guide therefore everyone only has themselves to blame if they get kicked or banned from a server or worse.

devsnek commented 6 years ago

you should send application: '...' not applicationID

favna commented 6 years ago

Well... Okay then. That should be made clear in the docs in that case because nothing whatsoever points to it and even back on 11.2.1 when rpc's were in private alpha it was "application_id"

iCrawl commented 6 years ago

Is this resolved then?

favna commented 6 years ago

I'd say no, and there are two solutions you guys could choose from

  1. Accept #2104, then we use applicationID and so de code reflects the docs.

  2. Change .appllicationID on the docs to .application and so the docs reflect the code

Personally I would say go for option 2 as it is probably the least work since if I understand your JSDoc well enough it's just changing it at 1 location and not potentially multiple locations.

vladfrangu commented 6 years ago

This can be solved by documenting the whole activity part of PresenceData and setActivity, which I can do, but I don't know if the data is supposed to be documented yet.

vladfrangu commented 6 years ago

CC @iCrawl, should I make a PR documenting the new PresenceData, and all its subtypes