[Suggestion] Add player names to ClientboundPartyInfoPacket

[ItsEmpa]

Currently the ClientboundPartyInfoPacket packet returns a map of the members in your party, only giving the role they have and their uuid. Most mods, however, would benefit more on having their ign rather than the uuid, as commands related to party are all done using the player's name, not uuid.

Also while talking about the party info packet, is there a reason for the uuid to be stored both in the party member class and as a key in the map?

[hannibal002]

As a developer of a SkyBlock mod, I believe this addition would be helpful and I would be pleased to see it included in the API.

[ConnorLinfoot]

We have no intention of adding extra information that can be obtained elsewhere to reduce unnecessary data and complexities, thus we have no intention to include player names in the Mod API, and that data should be obtained via the appropriate Mojang APIs.

[ItsEmpa]

that is understandable. out of curiosity, would you mind answering the second question? about why the map contains the uuid both as a key in the map and as a property inside the PartyMember object

[ConnorLinfoot]

So that the value can be accessed via just iterating the PartyMembers rather than requiring iterating/storing a map downstream, its just a convenience thing depending on how you wish to use them

[ThatGravyBoat]

We have no intention of adding extra information that can be obtained elsewhere to reduce unnecessary data and complexities, thus we have no intention to include player names in the Mod API, and that data should be obtained via the appropriate Mojang APIs.

Sadly Mojangs only API for such only allows 1 uuid to username at a time which if multiple mods do it will cause Hypixel players to have their Mojang API calls be rate limited which is far worse imo, even if mods implement a cache this issue will still happen because you can't keep a cache for an extended period of time due to names being able to be changed, and if you join a large enough party and multiple mods try to get the usernames the cache may not help at all.

[ThatGravyBoat]

I would also like to point out even Mojang do send this data instead of the client doing it when the client needs to know of a players name but doesnt already knowingly have it by sending a GameProfile object as the server must already have it when they do the authentication handshake.

[ConnorLinfoot]

If you're pulling enough usernames to hit rate limits you can fallback to a self-hosted caching layer, or utilize a 3rd party to poll that data.

[ThatGravyBoat]

If you're pulling enough usernames to hit rate limits you can fallback to a self-hosted caching layer, or utilize a 3rd party to poll that data.

Mojangs rate limit globally is 600 requests per 10 mins no amount of caching in a custom cache layer will solve this issue if multiple mods do it, because if you do it on the client multiple mods will cause the rate limit to be reached because this is for all apis not just 1 endpoint if you do it on a server your server will reach that rate limit after a few 100 users unless you deploy to serverless with 100s of different ips. This is an issue that you can't bulk do uuid to name only bulk name to uuid

[hannibal002]

When the player name is known to the system that sends the mod API packets, then I assume including this name in the party info packet should be compareable to including the player name field in the SkyBlock profile endpoint. Since every player uuid is already included twice (empas second question) the size of the packet should not be the problem. (just checked the impl again, is the size of the name the issue?)

If the data is not available there, and would need additional internal requests, I understand why you don't want to redesign the backend for this.

Any way, the current implementation sadly doesn't allow our mod to replace the chat message scraping by this.
For our mod, using mojang API is not possible on scale for the reasons gravy mentioned above, and using a third party API is just not reliable enough to not break shortly after a user changes their name. I'm sure other mods have the same problem.