| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Increase of RAM and CPU doesn't give me much benefit I feel.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When accessing the latencies property on an AutoShardedClient when none of shards are ready, we get a ZeroDivisionError. An example of this can be seen here.
```py
class StatsBot(commands.AutoShardedBot):
def __init__(self):
super().__init__(command_prefix=None)
self._add_commands()
def _add_commands(self):
'''Adds commands automatically'''
for name, attr in inspect.getmembers(self):
if isinstance(attr, commands.Command):
self.add_command(attr)
```
When iterating through this custom client's it accesses the latencies property when no shards are ready, therefore it raises the error. A quick fix for this would be to return None if no shards are ready.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This time with less bugs. It turned out that the crash was due to a
synchronisation issue between the pending reads and the actual shard
polling mechanism.
Essentially the pending reads would be cancelled via a simple bool but
there would still be a pass left and thus we would have a single
pending read left before or after running the polling mechanism and
this would cause a race condition.
Now the pending read mechanism is properly waited for before returning
control back to the caller.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Some people like to use that variable name apparently.
See #568 and #569.
|
| |
|
|
|
|
|
|
|
|
| |
In 3.5.0 and 3.5.1 asyncio.ensure_future requires a Future or a
coroutine otherwise a TypeError is raised. The issue is that the
websockets.connect call is an awaitable rather than a coroutine.
asyncio.ensure_future did not gain support for awaitables until 3.5.2.
This patch allows 3.5.0 and 3.5.1 to connect regardless of their python
version.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Apparently we should always try to RESUME first and if we get
INVALIDATE_SESSION then we should IDENTIFY instead. This is the
preferred way to do RESUMEs.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
This allows people to run their >2,500 guild bot in a single process
without the headaches of IPC/RPC or much difficulty.
|