Additionally, existing payloads and headers have been heavily changed to match the Discord client.
Additionally, existing payloads and headers have been heavily changed to match the Discord client.
Guild Members
Guild members
--------------
--------------
| Since the concept of Intents (mostly) doesn't exist for user accounts; you just get all events, right?
| Since the concept of Intents (mostly) doesn't exist for user accounts; you just get all events, right?
| Well, yes but actually no.
| Well, yes but actually no.
@ -47,7 +47,8 @@ Users
If the Discord client ever needs member objects for specific users, it sends an OPCode 8 with the specific user IDs/names.
If the Discord client ever needs member objects for specific users, it sends an OPCode 8 with the specific user IDs/names.
This is why this is recommended if you want to fetch specific members (implemented as :func:`Guild.query_members` in the library).
This is why this is recommended if you want to fetch specific members (implemented as :func:`Guild.query_members` in the library).
The client almost never uses the :func:`Guild.fetch_member` endpoint.
The client almost never uses the :func:`Guild.fetch_member` endpoint.
| However, the maximum amount of members you can get with this method is 100 per request.
However, the maximum amount of members you can get with this method is 100 per request.
But, you may be thinking, how does the member list work? Why can't you just utilize that? This is where it gets complicated.
But, you may be thinking, how does the member list work? Why can't you just utilize that? This is where it gets complicated.
First, let's make sure we understand a few things:
First, let's make sure we understand a few things:
@ -68,12 +69,11 @@ So, to subscribe to all available ranges, you need to spam the gateway quite a b
You may have already noticed a few problems with this:
You may have already noticed a few problems with this:
1. You'll get spammed with `member_add\/remove`s whenever someone changes ranges.
1. You'll get spammed with `member_add/remove`s whenever someone changes ranges.
2. For guilds with >1k members you don't receive offline members. So, you won't know if an offline member is kicked, or an invisible member joins/leaves. You also won't know if someone came online or joined. Or, if someone went offline or left.
2. For guilds with >1k members you don't receive offline members. So, you won't know if an offline member is kicked, or an invisible member joins/leaves. You also won't know if someone came online or joined. Or, if someone went offline or left.
| #1 is solveable with a bit of parsing, but #2 is a huge problem.
| #1 is solveable with a bit of parsing, but #2 is a huge problem.
| If you have the permissions to request all guild members, you can combine that with member list scraping and get a *decent* local member cache.
| If you have the permissions to request all guild members, you can combine that with member list scraping and get a *decent* local member cache. However, because of the nature of this (and the fact that you'll have to request all guild membesr again every so often), accurate events are nearly impossible.
However, because of the nature of this (and the fact that you'll have to request all guild membesr again every so often), accurate events are nearly impossible.
dolfies
4 years ago