This is to allow people to set temporary local variables by injecting
them directly into the context via some decorator or some other
mechanism. Contexts are not kept alive long enough to warrant being
slotted.
Allow for easier use when trying to "reuse" the same discord.Embed
object by providing new methods such as Embed.clear_fields,
Embed.set_field_at, and allowing you to set things to Embed.Empty to
clear out an attribute.
For ease of use, things are automatically casted to ``str`` to prevent
the user from having HTTP 400 errors if they forgot to do so. The new
embed builder also supports "fluent-style" interface to allow you to
chain methods in a single line if necessary.
Certain parameters were removed since they were ignored by Discord
anyway such as `width` and `height` in Embed.set_image and
Embed.set_thumbnail.
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.
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.
The library worked with the assumption that whenever the recv call for
the websocket would lead to a closure, the close method would be called
to signal closure and as a result our close method would be called.
This assumption turned out to be false as the websockets library would
instead call an internal function named close_connection instead. So to
solve our problem we need to override this function instead of close.
This seems to be a very common question regarding the docs so might as
well document exactly what this means rather than using cryptic and
confusing wording.
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.
The way the command cooldown works is using a windowed way of doing it.
That is, if we have a cooldown of 2 commands every 30 seconds then if we
do a single command, we have 30 seconds to do the second command or else
we will get rate limited. This more or less matches the common
expectations on how cooldowns should be.
These cooldowns can be bucketed up to a single dimension of depth for
a per-user, per-guild, or per-channel basis. Of course, a global bucket
is also provided. These cannot be mixed, e.g. no per-channel per-user
cooldowns.
When a command cooldown is triggered, the error handlers will receive a
an exception of type CommandOnCooldown with proper information regarding
the cooldown such as retry_after and the bucket information itself.
This is for exceptions that are inherently based on user errors and not
permission based. e.g. passing incorrect number of arguments, too many
arguments, or an invalid argument. CommandNotFound is not classified
under this since it isn't inherently a user input error in all cases.
Some invalid commands can simply be due to an odd bot prefix. It would
also diminish the usefulness of the new parent class if CommandNotFound
was included.
This change allows users to more easily create their own formatters
without having to reinvent the pagination logic themselves. Hopefully
this makes it less of a pain for people to create custom help pages.
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.
Rapptz