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 is suggested to prevent spamming the console unnecesarilly.
Info should be used to output information to the user that is important, but
not a warning or an error. If I am bundling a bot as a modular package then
it doesn't really make sense to spam their console with every time a coroutine
is subscribed to, as it likely will not mean anything to the user. If they are
interested in this, it would make more sense to just to enable debugging first.
I have made this change, as I am writing a wrapper for this library for a
private project, and that will handle dispatching events, thus, I do not
need a prompt for each event that is subscribed to in this module outside of
DEBUG. Currently, with logging set to INFO, I am getting 47 lines reading:
INFO:discord.client:coroutine has successfully been registered as an event
...being output as my bot starts, and without having to disable INFO logging
altogether, I am currently having to temporarily change the verbosity of the
logger as the events are initialised, which is not desirable as it could
potentially cover up any other INFO messages that would be useful to have
output.
Using a filter seems like a bit of a hacky workaround. If this isn't acceptable
then another alternative would be to add a parameter to the constructor of
discord.Client to enable or disable printing this information.
This should allow an easier way to query the Discord protocol gateway
latency, defined by the difference HEARTBEAT_ACK between and the last
sent HEARTBEAT.
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.
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 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 should prevent asyncio.CancelledError from being propagated more
and suppressed "Task was destroyed but was pending!" warnings when
doing graceful closes outside of using a KeyboardInterrupt.
To make clean up a bit more robust, also add signal handlers
for POSIX systems.
