discord.py: on_ready doesn't fire when bot=False

This library supports what the API supports. If the gateway isn’t sending the READY event then…again, that sucks, but what do you want us to do about it? The library dispatches the events that are received, it’s not gonna go “hey discord you forgot to send us READY for something that’s not allowed! You should do that!”

I don’t know what on_ready is, why do we even need it? If i’m getting messages and reactions etc over the websocket then i’m happy…

I have attempted and failed to reproduce this issue on my end. However, it is apparent that the Discord websocket flow for chunking guilds has changed for users. It’s possible you are not getting the on_ready event because these chunking differences cause the lib to fail to detect that everything is loaded.

Support for userbots in this library has been low priority ever since Discord staff made strong stances against their usage, and for the most part development on this feature of the library has been stopped ever since Discord officially released a statement on it.

The guild chunking flow is also projected to change for bots - if the changes made closely resemble the ones currently applying to users, it may be the case that this bug will get tangentially fixed when the fix for full bots is made, whenever that update to the websocket happens. However, the guild chunking flow for bots is already vastly more complicated than the flow for users, taking into account sharding and the much higher guild cap - so it’s not guaranteed the changes made on Discord’s end will be the same, nor the fix on the library’s end.

For the most part, continued support for userbots by this library has mostly been third party (that is, individual people have been reverse engineering functionality and PRing it in - see #2254, #1768). As such, this is probably the most likely way this will get a fix, if at all. Since the user API has no official documentation (since its use is discouraged), the best way to go about this if you want to take this on yourself would probably be to set up logging and use a websocket inspector to figure out how the new flow works - Firefox Developer Edition and new versions of Chrome have tools that can help with this.

The only real closing note I can give on this is, well, don’t use userbots. Discord has an official stance on them now, and the reasons to use them besides for nefarious purposes decreases day by day. We only support them here mainly as a remnant of when it was the only option. Modern bots get a lot of privileges over user accounts nowadays - it’s a good idea to use them!

Thank you for stating the obvious consensus amongst those who haven’t spoken to any staff member on the subject. If you’d like to be useful instead of hostile, feel free to provide citations.

The Terms of Service are generalized for legality sake, it isn’t a representation of how the company will react in every circumstance. I’ve heard from others that, after having spoken to a staff member, they were informed that those who use self-bots for what they consider nefarious usage would risk having their accounts terminated, and those who don’t simply would not.

“The Company reserves the right to refuse any user access to the Services without notice for any reason, including but not limited to a violation of the Terms.”

“You agree not to (and not to attempt to) (i) use the Service for any use or purpose other than as expressly permitted by these Terms; (iii) use data mining, robots, spiders, or similar data gathering and extraction tools on the Service.”

I’m aware of what “DiscordChatExplorter” as you call it, does. I’d also point out that the Terms of Service aren’t “irrelavent” to it either - it counts as scraping, or does it? I think you’ll find that these questions could be answered by a staff member with much more clarity. The only information I’ve been able to gather as to WHY self-bots are forbidden are that they bypass the normal rate limits imposed upon bots and they are capable of automating user activities (i.e. adding friends). “DiscordChatExplorter” attempts to abide by the rate limits, and does not automate the user insofar as it doesn’t cause any changes to anything.

I don’t know what on_ready is, why do we even need it?

If you don’t know what on_ready is, then why does this issue even matter?

Can this not be a discussion of the legality of selbots, and just be…a bug? A bug that should be squashed, or, if not, at least noted in the documentation?

this is discord. literally nothing is consistent

It is irrelavent as to what you consider to be nefarious usage and your awareness to the actual statements is outdated. Discords stance against self bots is very clear and all encompassing, simply stated “Not allowed”.

As for what DiscordChatExplorter accomplishes, that is mostly provided through Channel.history(fetch=None)

This library supports what the API supports. If the gateway isn’t sending the READY event then…again, that sucks, but what do you want us to do about it? The library dispatches the events that are received, it’s not gonna go “hey discord you forgot to send us READY for something that’s not allowed! You should do that!”

Thats where your wrong. Discord selfbots are agains’t the ToS, but they ignore them as long as they don’t turn into UserBots (Bots on user accounts, accessible by everyone). Discord also ignores selfbots if they don’t stress the API too much.

To anyone reading this later, use fetch_offline_members=False to have on_ready fired after successfully connecting.

A note in the documentation seems to be the most apt solution especially as this isn’t a bug in the first place. The Discord.py events closely follow the ones dispatched by Discord. Deviation from this to support a usecase disallowed by Discord themselves is just silly

If you’d like a response from staff, how bout https://cdn.discordapp.com/attachments/381963689470984203/382387651162144779/unknown.png