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
This also introduces the concept of the after function taking a single
parameter, the current player. This is useful for error handling, e.g.
checking Player.error.
Fixes#291
This adds a new enum named VerificationLevel to denote said verification
level. This enum will also be used in the Client.edit_server calls
instead of the undocumented int parameter.
The bug was due to the fact that the way overwrites work is by doing
a loop of all the values and then applying deny first and then allow.
That way the overwrite is defined if role A and role B deny a
permission but role C allows it (and said member has A, B, C roles)
then the resolution should allow it rather than deny it regardless of
the order of the data it is received in.
leovoel
Rapptz
khazhyk
Max Kamps