Discord can sometimes send integer 0 as the emoji id instead of
null to signify a non-custom emoji, which was causing a crash due
to a 'is not None' check assuming the reaction was for an emoji
with id 0. Probably a discord bug, but preferable to handle here
rather than crash users.
This changes the event signature to be (reaction, user) instead of
(message, reaction, user) since the reaction data class already has
the message being reacted to as a member.
The name was shortened from on_message_reaction_ to on_reaction_ since
the message prefix was deemed redundant.
Reaction objects with custom Emoji are partial. If we know of this Emoji
(can find it on this client) then inject it. Otherwise, leave it as a
hollow Emoji. We can still react with a hollow Emoji, but can't get other
metadata about it.
Reactions can be be standard emojis, or custom server emojis.
Adds
- add/remove_reaction
- get_reaction_users
- Messages have new field reactions
- new events - message_reaction_add, message_reaction_remove
- new permission - add_reactions
Bug was caused to the shallow copy not copying over the VoiceState
information embedded into the copy. This would mean that when the event
is called, before and after voice state information is essentially
equivalent.
The solution to fix this is to also copy the VoiceState objects.
This was a two-fold problem. The first of which involved the overwriting
of members during a GUILD_SYNC. Since we are requesting a chunk anyway,
we have all the member references we need without actually chunking. The
second problem came from the order. We were doing a GUILD_SYNC and then
doing the chunking requests. We should do the GUILD_SYNC after the
chunking in order to just update presences.
This should hopefully cover all cases where members are added.
There was a bug where an array of chunks received would get entirely
processed if only a single chunk was received. This was fixed by
explicitly bailing early if we're requesting for chunks.
When we don't request offline members, members that are going from
offline to online in the server will become available via the
PRESENCE_UPDATE event. This should be transparent to the user since
technically the member exists in the server and thus on_member_update
is used instead of on_member_join.
