Implement party_info version 2 with party role

[ConnorLinfoot]

Implements a version 2 of the hypixel:party_info packet to include member roles.

This is the first attempt at doing a 2nd version of a packet, which will need testing of the implementation on the server. However, once Mod API has a full release, we will likely not support older versions as this is primarily for testing the version system.

[HacktheTime]

I would assume that it would be good to also get the MC Username of the members since not everything from party chat is also based on mcuuid.

Maybe add it to the PartyMember class?

[ConnorLinfoot]

I would assume that it would be good to also get the MC Username of the members since not everything from party chat is also based on mcuuid.

Maybe add it to the PartyMember class?

We have no intentions to offer player names via the Mod API, this can be gained via the Mojang API or even in-game itself depending on player locations.

[HacktheTime]

I would assume that it would be good to also get the MC Username of the members since not everything from party chat is also based on mcuuid. Maybe add it to the PartyMember class?

We have no intentions to offer player names via the Mod API, this can be gained via the Mojang API or even in-game itself depending on player locations.

Am I overseeing something?

For small parties like dungeons that works for sure but parties have a limit of 100 players which for the bingo party at least gets used often enough. I am quite sure that the Mojang API limit is not sufficient for those player counts. Maybe if on-demand is used there instead but even then at max party limit size im not very confident in it. Parties also exist to allow players to communicate even though they are in different lobbies, meaning the player objects in the client can't be used either to obtain the mcuuids. I am aware of a possible solution even in that case though: Scrap mcuuid and user name information from the social options command since it contains the mcuuid and the name is always given in party messages. However, that solution has its own problems. A combination of those options could be sued but those make it a lot more complicated than continuing to use player names and request the mcuuids from usernames since that way also has a bulk API request.

Even if the API limit would be sufficient this would be to Mojang like the old api key system from hypixel which hypixel changed because it was so resource intensive. So I would assume that this might be bad practice to say to do.

So I would assume that most mods won't change over to the current implementations of the packet for party info and instead continue to use /party list. However, the location packet seems useful and is more convenient than the /locraw command.

[ConnorLinfoot]

I would assume that it would be good to also get the MC Username of the members since not everything from party chat is also based on mcuuid. Maybe add it to the PartyMember class?

We have no intentions to offer player names via the Mod API, this can be gained via the Mojang API or even in-game itself depending on player locations.

Am I overseeing something?

For small parties like dungeons that works for sure but parties have a limit of 100 players which for the bingo party at least gets used often enough. I am quite sure that the Mojang API limit is not sufficient for those player counts. Maybe if on-demand is used there instead but even then at max party limit size im not very confident in it. Parties also exist to allow players to communicate even though they are in different lobbies, meaning the player objects in the client can't be used either to obtain the mcuuids. I am aware of a possible solution even in that case though: Scrap mcuuid and user name information from the social options command since it contains the mcuuid and the name is always given in party messages. However, that solution has its own problems. A combination of those options could be sued but those make it a lot more complicated than continuing to use player names and request the mcuuids from usernames since that way also has a bulk API request.

Even if the API limit would be sufficient this would be to Mojang like the old api key system from hypixel which hypixel changed because it was so resource intensive. So I would assume that this might be bad practice to say to do.

So I would assume that most mods won't change over to the current implementations of the packet for party info and instead continue to use /party list. However, the location packet seems useful and is more convenient than the /locraw command.

The Mod API is supposed to be simple without being resource or bandwidth-intensive. If mods would prefer to scrape commands then there isn't much we can do there, but including usernames in all these packets is not something we will be doing.

[IndigoPolecat]

The Mod API is supposed to be simple without being resource or bandwidth-intensive. If mods would prefer to scrape commands then there isn't much we can do there, but including usernames in all these packets is not something we will be doing.

I understand the desire to keep bandwidth usage small, but the Mojang API is severely ratelimited and I assume the player ign info is already available, would it really be that much more resource intensive to add an if else check for the client to request ign vs uuid data?

[HacktheTime]

The Mod API is supposed to be simple without being resource or bandwidth-intensive. If mods would prefer to scrape commands then there isn't much we can do there, but including usernames in all these packets is not something we will be doing.

I understand the desire to keep bandwidth usage small, but the Mojang API is severely ratelimited and I assume the player ign info is already available, would it really be that much more resource intensive to add an if else check for the client to request ign vs uuid data?

Someone ik tested recently and limit seems to be 100 at a time but still took 27 seconds to get all.

I still agree fully though. Having the uuid i nice but i would say those are the addition not reverse

[My-Name-Is-Jeff]

The Mod API is supposed to be simple without being resource or bandwidth-intensive. If mods would prefer to scrape commands then there isn't much we can do there, but including usernames in all these packets is not something we will be doing.

I understand the desire to keep bandwidth usage small, but the Mojang API is severely ratelimited and I assume the player ign info is already available, would it really be that much more resource intensive to add an if else check for the client to request ign vs uuid data?

On the client side the Mojang rate limit (600/10 min) doesn't really affect much. The increased 429 returns are a bug on Mojang's part. IMO I'd rather have the UUID than have the username anyways

[HacktheTime]

The Mod API is supposed to be simple without being resource or bandwidth-intensive. If mods would prefer to scrape commands then there isn't much we can do there, but including usernames in all these packets is not something we will be doing.

I understand the desire to keep bandwidth usage small, but the Mojang API is severely ratelimited and I assume the player ign info is already available, would it really be that much more resource intensive to add an if else check for the client to request ign vs uuid data?

On the client side the Mojang rate limit (600/10 min) doesn't really affect much. The increased 429 returns are a bug on Mojang's part. IMO I'd rather have the UUID than have the username anyways

I am very curious on why.

Uuids are partially useful definitely and you can use them for own checks on the owns player account, however it remains problematic since it has the problem that you cant pair the data for other users. If you for example get a msg you will need to turn it into a mcuuid and check it or check everyone in party first etc. The problem I see is the interactions between them. I do not care which System is used. If you want to use uuids thats fine but then stick to it through out hypixel and give it us everywhere. Even msgs and other Chat messages ( like super rare drop messages with phoenix etc).