* Local Fixes & Client UserUpdate Gateway Event
- Changed 'READ_MESSAGES' to 'VIEW_CHANNEL' to keep with Discord's API Docs
- Defaulted Guild.premium_subscription_count to 0 to stop error
- max_presences to 5,000 as Discord's API Suggest
- Added UserUpdate event for when the Client user is updated.
* Flake8 Spacing
* Update state.py
* Remove undocumented OPCode
This is not documented in the Discord API docs, and is claimed not to usable by (or useful to) bots.
* Add missing ChannelType
* Resolve dictionary changed size during iteration while converting levels mapping and remove non-converted entry to avoid duplicate entires (str and int index).
Add default for premium sub count.
* Update disco/bot/bot.py
Co-Authored-By: Andrei Zbikowski <[email protected]>
* Patch get_icon_url
Nice try, but don't copy+paste without testing whomever PR'd this 😉
* Patch status in update_presence payload
No more Enum, no more `.value`
This will not undergo a regualar deprecation cycle since the schedule
provided by discord (see discordapp/discord-api-docs#967) is less than
the amount of time it would take to fully deprecate this field. Instead
we will just consider this a v1 breaking change.
Clients on previous versions should continue to work regardless of
Discord's planned changes for this field, although the data provided
from the field may be invalid or empty.
* Added end points + fixed typo
* mixup fixed
* oauth user add
* typo
* removed "return User.create(self.client, r.json())" from guilds_members_add due to lack of json response when user already in guild and switched name to mandatory arg in guilds_create
* formatting + removed roles/channels in guilds_create
* formatting 2.0, with even less random spaces
* remove guild.create on guilds_delete as no content is returned by Discord's api + reinstate roles and channels in guild_create
* spaces v tabs... FIGHT
* disco/api/client.py:410:9: F841
* Update client.py
* naming and create guilds args
Previously any keyword arguments passed into the `Plugin.command`
decorator that didn't match a keyword argument inside of `Comman.update`
would be collected into the `metdata` for a command.
This can cause fairly severe bugs in your code if you make typos when
passing keyword arguments into the decorator since they will be blindly
accepted. For example consider a situation where a user (lets say me)
creates the following command:
```
@Plugin.command(..., permissions=CommandLevels.TRUSTED)
```
While this looks perfectly valid and the code will run without issue,
this command actually has a permissions level of '0' since the correct
keyword argument is `level`.
This commit changes the behavior to require all metadata passed in to be
within a `metadata` kwarg. Any unknown keyword arguments passed will
throw a traditional Python error.
* Adding RP Support
* Fixing Space Issues
* Needed an indent
* Fixing the last of the spacing errors.
* Readded list field to import
* Adding @cached_property to Timestamps
* Imports are a thing, sorry.
* Fixing line length issue.
* flake8 fixes
This commit cleans up a mess I created when I originally added the
`Guild.sync` functionality. The original intention of this function
was to provide a simple interface to ensuring the local state of a
guild was "up to date". This abstraction turned out to be a bad idea
for the following reasons;
- Its completely unclear what "sync" means in the context of a Guild.
Hiding the way syncing guild members works (which is a pretty "developer
unfriendly" as it is) just results in more confusion for very little
value.
- Discord technically supports sending multiple guild ids in a single
`REQUEST_GUILD_MEMBERS` op which this interface didn't support or
handle. Using this function as it was intended on a largeish bot would
result in your gateway client getting rate limited for quite a bit on
startup (which is lame).
- This implementation of guild member syncing resulted in a `synced`
flag on guilds, which is basically completely useless and doesn't mean
anything much at all (since REQUEST_GUILD_MEMBERS is purely async and
there is no correct way to confirm a request was fulfilled.
To cleanup this mess I've made the following changes;
- Entirely deprecate `Guild.sync`. This is just a bad function name and
should die in a fire to save our future children from pain and
frustration.
- Add `Guild.request_guild_members`. This function now properly conveys
what it does and provides a more correct interface to this Discord
functionality (nb: Guild.sync now calls this function, which does not
prevent multiple calls from firing requests).
- Add `GatewayClient.request_guild_members`. This function provides an
alternative interface for sending the request guild members op without
low-level GatewayClient interfacing. Ideally users who need to avoid
being rate limited and/or want better guild member syncing performance
can use this function which accepts multiple guild ids.
TL;DR;
- If you don't call `Guild.sync`; you don't need to worry about
anything.
- If you call `Guild.sync` anywhere at all and you don't really care
about the performance impact of syncing guild members one-by-one; just
change your code to call `Guild.request_guild_members`.
- If you call `Guild.sync` in a `GUILD_CREATE` handler or you care about
the performance impact of syncing multiple Guilds; move to using the
underlying GatewayClient interface and sync multiple guilds at once
(likely in batches).
* initial voice
* some updates
fixed it
* some style updates
replaced the speaking when joining with an actual client_connect event
* please pass
* replaced channel with client in VoiceData and VoiceSpeaking events
Also changed some voice sending stuff
* added more debug logs
* fixed version not being set on the voice gateway
* added voice_clients in state
Removed making a listener for voice state/server update for each voice connection, instead have only one listener and use the voice_clients in state to update based on that
Added priority speaking flag, also added some rtcp stuff, like a new event called 'RTCPData'
This update fixes some issues if you connect to another voice channel, instead of making a whole new voice connection, it just reuses one in the state.
* flake8 error fix
Discord is inconsistent here and doesn't emit a VoiceStateUpdate for the
old session_id when a user connects to voice from a different device
(thus disconnecting the first device). To avoid corrupting our voice
state cache, we need to remove any of the users old sessions (they
should have at most one).
I included tests on this one because its esoteric and undocumented, so
there is a high chance I'll break it in the future.
Luke
Justin
Andrei
Dooley_labs
Luke Mathew-Byrne
Andrei Zbikowski
KevTheGame-Dev
James Lu
genesis-root
a00git
Tiemen
Jaimyn Mayer
Dan
Noah Hendrickson