libdeflate is significantly faster than vanilla zlib, zlib-ng, and Cloudflare zlib. It is also MIT-licensed (so no licensing concerns). In addition, it simplifies a lot of the native code (something that's been tricky to get right).
While we're at it, I have also taken the time to fine-time compression in Velocity in general. Thanks to this work, native compression only requires one JNI call, an improvement from the more than 2 (sometimes up to 5) that were possible before. This optimization also extends to the existing Java compressors, though they require potentially two JNI calls.
If the player unexpectedly disconnects after ServerConnectEvent is
fired, but before the connection transitions to the new player, Velocity
would throw an exception thinking the connection was not present. This
is the correct behavior, but the behavior is very surprising. Instead we
will double-check to ensure the connection has not been lost before we
continue with transitioning to the new server.
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.
