If a command or a group raised a CommandError derived exception it
would be wrapped into CommandInvokeError. This fixes this case so it
raises the original exception instead.
This is to support people who want to clean up some external resource
that the extension is maintaining outside of a cog, where __unload
should be used instead.
The callable is the antipode of 'setup' and takes the same sole
parameter, the bot, after all commands, events, and cogs have been
unloaded.
Fixes#405.
Help formatter was not checking global bot-level checks, resulting in
showing commands a user did not have permission for with
show_check_failure disabled.
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.
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 allows you to strictly require a number of arguments. The default
behaviour in this case is still `True`, since it would be a breaking
change otherwise and is a sane default. However if someone would want
to set this to `False`, they would receive an exception of type
`TooManyArguments` if too many arguments are passed to a command.
Hopefully this removes the uses of `ctx.message.content == 'stuff'`
inside commands.
Rapptz
PapyrusThePlantandRapptz
khazhykandRapptz
Max KampsandGitHub
Dan HessandRapptz