This bug was kind of a long one to figure out, as per #1918 documents
the issue had to do with subcommands but the actual adventure in
finding this one was a long one.
The first problem was that Command.cog was for some reason None, which
indicated that a copy was happening somewhere along the way. After some
fiddling I discovered that due to the copies of `Cog.__cog_commands__`
the groups pointed to out-dated versions that got overriden by the new
copies.
The first attempt at fixing this was straightforward -- just remove the
subcommand from the parent and replace it with the newer reference that
we just received. However, this ended up not working due to a strange
mystery where the subcommand being invoked was neither the original
copy nor the new copy residing in `Cog.__cog_commands__`.
Some more investigation later pointed out to me that a copy occurs
during the `Group.copy` stage which calls `Command.copy` for all its
subcommands. After spotting this out I had realised where the
discrepancy comes from. As it turns out, the subcommand copy that was
being invoked was actually a stale one created from `Group.copy`.
The question remained, how come that one was being called? The problem
stemmed from the fact that when the subcommand was copied, the parent
reference pointed to the old parent. Since the old parent was the one
that was getting the new reference, it went practically untouched. This
is because the calling code fetches the child from the parent and the
old parent is nowhere in the call chain.
To fix this issue we needed to update the parent reference, and in
order to do that a temporary lookup table is required pointing to the
latest copies that we have made.
Thus ends a 3.5 hour bug hunting adventure.
Added a coro, `remove()` which takes in a sole parameter, `member`.
This new coro will remove the reaction by the provided member from the reactions message.
`message.remove_reaction(reaction, member)` was not removed as to not introduce breaking changes.
This adds the following information.
* `PartialInviteGuild` to replace `Object` patching
* `PartialInviteChannel` to replace `Object` patching
* Invite.approximate_member_count and Invite.approximate_presence_count
The new partial objects provide better documentation on what is
expected when you fetch random invites.
Fixes#1830
When trying to check if a specific permission overwrite is already set on a channel, it can be done by fetching the already existing overwrite and comparing it with a one you want to set. Comparing them directly wasn't possible before, and this small change allows for that.
Could be expanded for other comparison operators, not sure how it would work though.
Add warnings for when the heartbeat is blocked for a long time and when
the websocket latency is excessively high. These indicate problems with
blocking the event loop and/or insufficient computing resources to keep
up with the demand.
Add long_description_content_type in setup.py, fix incorrectly
matched up title underlines in README.rst, and fix incorrect entry in
MANIFEST.in that was forgotten when the README was renamed in 06296bf.
- Update internals to be compatible with v4
- Adds multiple encryption mode support. Previously only `xsalsa20_poly1305` was supported. Now `xsalsa20_poly1305_suffix` is also supported.
Note: There is no (nice) way to manually select a mode. The user needn't worry about this however.
- Fixed speaking state bug. When you disconnected from a voice channel while a bot was playing, upon reconnect you would be unable to hear the bot. This was caused by bots not sending their speaking state while transmitting. Bots will now set their speaking state properly when transmitting.
Note: This does not account for sending actual silence, the speaking indicator will still be active.
Rapptz
NCPlayz
cod
DerpyChap
CraftSpider
slice
Myst(MysterialPy)
Bryan Forbes
Pedro Cunha
Liam H
BluePhoenixGame
Skyweb
Toby Harradine
stuarth
Xua
Benjamin Mintz
Harmon
Chris
DevilXD
Hornwitser
Imayhaveborkedit