large guilds that recieved GUILD_CREATE events prior to READY would
never dispatch guild_available/join. This is inconsistent with
smaller guilds and makes these events unreliable. Dispatch the
"delayed" guilds after they've been chunked, prior to ready.
This allows for internal changes in Discord to not cause a breaking
change every time something changes.
Also implements #1214 which adds guild_id to every event where
applicable.
This is a breaking change.
This is a massive breaking change.
* All references to "game" have been renamed to "activity"
* Activity objects contain a majority of the rich presence information
* Game and Streaming are subtypes for memory optimisation purposes for
the more common cases.
* Introduce a more specialised read-only type, Spotify, for the
official Spotify integration to make it easier to use.
This adds:
* CategoryChannel, which represents a category
* Guild.by_category() which traverses the channels grouping by category
* Guild.categories to get a list of categories
* abc.GuildChannel.category to get the category a channel belongs to
* sync_permissions keyword argument to abc.GuildChannel.edit to sync
permissions with a pre-existing or new category
* category keyword argument to abc.GuildChannel.edit to move a channel
to a category
This setting configures how long before a timeout event is emitted
internally and disconnects the websocket. Since some users were
experiencing issues with the gateway not responding, this should help
mitigate the issue for those with poor PCs.
New API change[1] will make it so CHANNEL_CREATE will keep getting
sent for private channels, so might as well avoid the overhead of
constantly creating the channel if we can avoid it.
[1]: https://github.com/hammerandchisel/discord-api-docs/issues/184
Not entirely sure why it was exposed in the first place. Most uses with
it essentially boiled down to mis-usage when they meant to use the
/messages endpoint (via Client.logs_from or Messageable.history) or
complaining about the partial data woes that came from it.
This is a breaking change.
1. Change on_guild_emojis_update to have 3 arguments.
- The first parameter is now the guild object
2. Remove on_channel_create, on_channel_delete, and on_channel_update
- They are now split into two.
- on_guild_channel_[create|delete|update]
- on_private_channel_[create|delete|update]
3. Change on_member_ban to allow User.
- (member) -> (guild, user)
- user can also be a Member
This now sort of respects "Awaiting Endpoint..." waiting. I haven't
actually tested out this case since it's hard to get it. However this
new code does work with the regular connection flow.
This is a complete redesign of the old voice code.
A list of major changes is as follows:
* The voice websocket will now automatically reconnect with
exponential back-off just like the regular Client does.
* Removal of the stream player concept.
* Audio now gracefully pauses and resumes when a disconnect is found.
* Introduce a discord.AudioSource concept to abstract streams
* Flatten previous stream player functionality with the
VoiceClient, e.g. player.stop() is now voice_client.stop()
* With the above re-coupling this means you no longer have to
store players anywhere.
* The after function now requires a single parameter, the error,
if any existed. This will typically be None.
A lot of this design is experimental.
This shows the Shard ID in more places, along with a gateway trace and
session ID. Also helps show the RESUME/IDENTIFY/RESUMED/READY flow a
bit more instead of it looking like the connection has zombied out.
WeakValueDictionary cleans up too late and brings too little benefit.
Also clean up the state when the first READY is encountered for
AutoShardedClient and when any READY is encountered in regular Client.
There is potential that when recreating the Emoji list in the
GUILD_EMOJIS_UPDATE event would just fetch from cache and the element
in cache having an out of date Guild reference. This Guild reference
will be kept alive for longer than it should be.
By always overwriting the Emoji reference, this problem goes away.
The library had a memory leak in the case using the global emoji cache.
When the bot would leave the guild, the Emoji would maintain a strong
reference to the Guild keeping them alive along with the entire state
associated with it.
Hopefully this means when the bot has some lingering object for
whatever reason, the memory doesn't double due to it having a strong
reference to an outdated connection state.
Hornwitser
Rapptz
khazhyk
Gorialis