Commit Graph

17 Commits

Author SHA1 Message Date
6dcd68b8d7 [commands] Allow passing current to more cooldown mapping methods.
Also adds a CooldownMapping.update_rate_limit helper function.
2019-04-24 23:26:33 -04:00
919dbcafb3 Consistent use of __all__ to prevent merge conflicts. 2019-04-20 17:20:58 -04:00
ec7a701ceb [commands] Allow passing reference time to update_rate_limit 2019-04-14 16:57:47 -04:00
9827d6eeaf [commands] Fix issue with decorator order with checks and cooldowns
Now they're just explicitly copied.
2019-02-23 07:41:25 -05:00
9656a21ebe Bumped copyright years to 2019. 2019-01-28 22:22:50 -05:00
5a585ebf20 Add channel category cooldown bucket type 2018-11-24 22:51:18 -05:00
c8b49d37be [lint] Fix incorrect and inconsistent whitespace
Adjust whitespace to be consistent with the rest of the library.
2018-08-22 21:43:53 -04:00
00a14a46f3 [commands] Added BucketType.members for cooldowns 2018-08-22 21:06:08 -04:00
9b4a2dc7cb [commands] Minor speed-up for the BucketType.guild case.
None case:
344ns ± 24.4ns -> 49.9ns ± 1.39ns

Valid case:
128ns ± 2.76ns -> 42.7ns ± 0.459ns
2017-10-08 07:57:58 -04:00
1bb7b6ff2d [commands] Make CooldownMapping.get_bucket take Message instead.
Requiring a full blown Context might be a bit overkill considering
we only use a single attribute from it.
2017-10-08 07:52:56 -04:00
bae6f80327 [commands] Split Cooldown state processing to two different functions.
This allows us to check if we are rate limited without
creating a new cool-down window for the command.
2017-10-03 03:57:06 -04:00
63fcfa6d02 [commands] Add CooldownMapping.from_cooldown factory classmethod. 2017-08-27 16:59:04 -04:00
ff9f5749e1 Update copyright year to 2017. 2017-01-20 23:19:19 -05:00
d1d54a468a Rename Server to Guild everywhere. 2017-01-03 09:51:54 -05:00
e4b16851bf Slots use tuples instead now. 2017-01-03 09:51:50 -05:00
b7ffbca0c7 [commands] Added a method to reset command cooldown. 2016-09-08 07:02:33 -04:00
cd0de57d13 [commands] Implement a command cooldown system.
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.
2016-07-22 18:05:38 -04:00