Checkstyle fixed a bunch of false-negatives; linting errors in the source that should've been caught according to our settings. Rather than updating `checkstyle.xml` to work around these, this commit also properly fixes these checkstyle errors.
* Added 'ALLBUTVERSION' option for ping passthrough.
* Added more configuration options for ping passthrough.
* Updated default velocity.toml
* Add support for the legacy ping passthrough.
* Removed legacy ping passthrough & added config migration
- Bumped config-version to 2.8
- Updated comments and grammar
- Removed legacy ping passthrough in the config
* Cleaned up code to match code style
* Update to latest
* Move ping passthrough into its own section
* Reorder migrations so they occur in the right order.
* Clean up ping passthrough related code.
* Update file dates and cleanup/consolidate ping-passthrough code.
* Update proxy/src/main/java/com/velocitypowered/proxy/config/PingPassthroughMode.java
* Update proxy/src/main/java/com/velocitypowered/proxy/config/PingPassthroughMode.java
* Remaining nits
- Read a string instead of LegacyPingPassthroughMode
- Update `announce-forge`'s comment in `PingPassthroughMigration`
- Consume `Config` instead of `CommentedConfig` in `PingPassthroughMode#fromConfig`
---------
Co-authored-by: TheMiningTeamYT <loanisamazing@outlook.com>
Co-authored-by: ButterDebugger <34288129+ButterDebugger@users.noreply.github.com>
Co-authored-by: Wouter Gritter <wouter@gritter.nl>
During configuration, a ServerboundCustomClickActionPacket arriving
when connectionInFlight is null falls through to handleGeneric, which
writes it to the connected backend without retaining. The encoder
releases the packet, then MinecraftConnection.channelRead's finally
block releases again - double-free.
Two fixes:
- handle() now uses getConnectionInFlightOrConnectedServer() so the
packet is properly retained before being written
- handleGeneric() retains any ByteBufHolder packet before write, not
just PluginMessagePacket
Closes#1841
* Small optimization to prevent blocking netty threads on UUID.randomUUID()
* Change FastRandomUuid to be a valid uuid v4
* Update javadoc for spotless
* Migrate method to VelocityTabListLegacy and add notice that it is insecure
* Bring back deleted override
* Strip pre-java-9 version check in `Metrics` as Velocity targets 21+
* Simplify Java version check by using `Runtime.version()` (entry still needs the system property to produce the same bStats metrics)
* Reconstruct `java.version` system property through `Runtime.Version`
* Update `javaVersion()` javadoc
* Newline while we're here
The 26.2 login success session ID is purely a metrics identifier. Mint
one shared UUID per proxy, regenerated when the proxy empties, mirroring
the vanilla server, instead of a random UUID per connection.
Older versions of the game, and creative mode, send itemstacks to the server
when dealing with itemstacks, annoying, the compression algo used is good at
backreferencing, which means that compressed data can balloon pretty well.
64 should more than cover most cases of legit data, we could probably be more
harsh here, but this is likely a fine balance between avoiding bombs and not
erring out on legit data.
Wouter Gritter