Activity.ApplicationID set to Null regardless of value

[favna]

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:

• discord.js version: 6254490
• node.js version: 8.9.1
• Operating system: Windows 10 Fall Creators Update
• Priority this issue should have – please be realistic and elaborate if possible: high

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.

• I found this issue while running code on a user account
• I have also tested the issue on latest master, commit hash: 6254490

[devsnek]

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

[favna]

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]

Is this resolved then?

[favna]

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

1. Accept Fixed applicationID #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]

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]

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