This served a good purpose when I used macOS as a primary development system, but those days are gone (I use Linux now). The spirit of multiple variants is preserved by our special Java 11+ optimized compression.
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.
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.
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.
