The 1.7 tablist packet only contains three types of information:
- Name of the tablist entry (limited to 16 characters including colors)
- Ping of the entry
- If this entry needs to be added or removed (client accepts duplicates
as 'ping update')
The previous logic was trying to preserve parity with
GameProfile#getName returning a stripped down name to have a 'real'
username.
That is fundamentally broken, because entries with duplicate content,
but different colors are very common, especially with custom tablists.
For packets coming from a native 1.7 server we just won't define the
displayname anymore, as there is no such thing as a 'displayname',
because tablist entries are not bound to any player.
Using the Velocity Tablist API to modify existing entries will work, though
the backend server will completely loose control over the entry. Custom
entries added over the Velocity Tablist API will work, but are cut off
by the 16 character limitation.
This commit only fixes the bug, where entries are incorrectly handled
with their stripped name, a lot of the things explained above were
already implemented correctly.
VelocityTabListEntry#setLatency calls the update method, which
constructs a new packet and sends it to the client.
The backend packet we are processing also reaches the client, therefore
we are sending the same packet twice.
VelocityTabListEntry#setLatencyInternal is the correct method here.
This is a niche setup, however if your network is 100% dynamically configured, this is a handy feature to have available.
To support this functionality, a new PlayerChooseInitialServerEvent event was added to allow the initial server to connect to be changed as desired.
This commit absolutely does not change our support policy on this: this
is a completely unsupported setup. In any event, there is an existing
forwarding check in Velocity that covers this case quite well.
I am making this change to make the login process less "chatty" for
higher-latency links and 1.13+ servers.
All AES implementations being used are 'copy safe', where the source and
destination arrays may be the same. Lets save ourself a copy and reap
the performance wins!
Using the fact that the Java Deflater/Inflater API now supports
ByteBuffers as of Java 11, we can provide performance benefits equivalent
to the Velocity 1.0.x native compression on servers running Java 11+ on
non-macOS and non-Linux platforms (such as Windows).
