A way to bypass/ignore 16 character length check in createProfile(String, UUID)

[Andre601]

Is your feature request related to a problem?

Not every place has issues with a player profile with a name that is longer than 16 characters.
As an example, in the multiplayer screen, the player names displayed while hovering over the server's player count are completely fine, even while the text is more than 16 characters.

Describe the solution you'd like.

One of two possible options I can think of:

• A createProfile variant that accepts a boolean to toggle the check on and off (createProfile(String, UUID, boolean).
  The risk here is, that plugin devs may use it wrongly (Where it could cause visual bugs and more)
• A separate Player profile type for the player Samples list.
  The player profile is kind of overkill here because info such as skin data is redundant and not even sent to the player in the context of a server list ping (Why Mojang?), so a separate type with only the necessary info and without the check could work.
  Problem here is possible API issues... Maybe the new type extends the player profile or vise-versa?

Describe alternatives you've considered.

Hacky NMS aproach to bypass the check, which obviously isn't great here.

Other

No response

[kennytv]

Adding separate API for the ping event is probably the best way here, there definitely shouldn't be a way to bypass it in general. As a workaround, you can also implement the PlayerProfile interface in a dummy class only holding a name string

[Andre601]

The downside of making my own implementation is, that it includes a ton of methods not needed at all, so while it may work is it not the best solution either. :/

[Andre601]

I for now added this workaround. Tho I hope some solution can be found here that such an aproach won't be necessary anymore.

[Machine-Maker]

So one solution would be a method on the ping event to create "fake" profiles. Some implementation of PlayerProfile that was just a holder for a string name and uuid. It would have to clear that this is only valid in this event, hence a method on the event to create them. They could throw for all the property stuff. One downside is future listeners to the same event might expect full profiles and check properties for some reason

[electronicboy]

This is probably going to be the best middle ground which works best for people supporting 20 dozen different versions, not that that is exactly our concern; We can probably generally guard against people using these profiles elsewhere, or look towards dynamically converting if we for some reason ever wanted to deal with that

[Andre601]

I also think this could be a good idea...

Perhaps it could be like this: Add a method to set the players for the ServerListPingEvent and when someone is getting the players, try to convert them to full Profiles where possible... Tho, this aproach could have a negative impact on performance...