The ThreadPoolExecutor API is confusing with *very* common pitfalls, one of them being a setup like the one before completely blocking task execution while core task executors are working, not actually starting new threads.
This is a more realistic (generalized) solution for #943. Fundamentally, a plugin should not be spawning an unbounded number of asynchronous task execution units on demand from the user - an invariant Velocity itself enforces. However, since this practice is so commonplace, it makes sense that we would need to have some upper cap to at least make the practice safer than it currently is.
Spiritually indebted to #518 and @alexstaeding.
There's a minor break - we're going up to 3.2.0-SNAPSHOT as the API now compiles against Java 11. But this is more academic in practice.
* Reduce Spam from the TabList by not sending every package multiple times
VelocityTabList#processUpsert called entry.setX which will create a package and send it to the client.
BackendPlaySessionHandler doesn't return true for those packages, therefore the package for tab list updates will be send two times.
* Cleanup TabList#buildEntry, added listed status to Entry builder
* Fix "pointers" for players never being used lol
* Added Platform Facet API to add Type pointers
* Remove duplicate
* Fix some connection things
* Make checkstyle happy?
* Implement chat queue for ordered chat.
* Update system to handle spoofed chat as well.
* Fix checkstyle erroring on bad indentation.
* Fix ChatQueue to use whenComplete instead of thenRun
* Merge upstream.
* Checkstyle
* Deny denied commands.
* 1.19.1-rc1
* More signature changes
* Further 1.19.1 changes
I also started on the checkstyle update, see the developers notes
for the rest I haven't gotten around to fixing yet.
* Fix checkstyle
* Checkstyle imports
* Fix logic error
* Changes 1.19.1-pre2
* 1.19-pre3
* Progress, some parts still WIP
* Overlooked changes
* Fix ServerData
* Fix ServerLogin send check
* Workaround the broken behavior of "No Chat Reports"
Note that if we ever choose to enforce chat signatures, then the mod will just break again... not our fault if we do that, you get what you pay for.
* more
Co-authored-by: Shane Freeder <theboyetronic@gmail.com>
Co-authored-by: Andrew Steinborn <git@steinborn.me>
* Implement the ServerData packet by firing ProxyPingEvent
Mojang introduced the enable-status server property with Minecraft 1.19, which if enabled causes servers to close the connection when a client tries to ping them. Mojang wants to show the MOTD and favicon on the server select screen for those who manage to log in, so we need to implement this packet as well.
The good news is that we can send this packet as many times as needed on the same connection
This matches the behavior of pinging the server. This is a minor, but completely backwards-compatible, API breakage: Player inherits from InboundConnection so we do not have to change ProxyPingEvent, however plugins not expecting a Player might get confused.
* typo
This change helps ensure player signatures are propagated correctly.
Signatures should never be removed, so to compensate for legacy plugins and for the
proxy api function we have to enforce this.
