Gero

I guess this has something to so with the fix for ProtocolLib we added in ViaVersion. Could you try without ProtocolLib?

Could you provide the your code to send the particles? A vanilla /particle command would be even better.

The new unsigned command packet should be handled correctly now

I think there is currently no way to know to which server the player is currently connecting to when PlayerFinishConfigurationEvent or PlayerFinishedConfigurationEvent are called. Should probably add the ServerConnection to...

Currently the current server isnt set until after ServerConnectedEvent has been called which is done when handling the join game packet.

Blocking the ``PlayerFinishConfigurationEvent`` for more than ~30 seconds was not possible because the backend server would experience a timeout. I fixed this with the latest commit by not disabling auto-reading...

The event should include the intention of the connection. Also instead of blocking you should disabled auto-reading while the event is being fired ([like here for example](https://github.com/PaperMC/Velocity/blob/2bd2c692ea0294aaa77b8e5653d9d3344c30e487/proxy/src/main/java/com/velocitypowered/proxy/connection/backend/TransitionSessionHandler.java#L111-L161)).

Pretty sure that this does not make a difference. The code in question runs on the event loop of the server connection, so no packets from that connection can be...

This seems to be somewhat of a vanilla client issue. The client fetches public key of the used Minecraft profile asynchronously and then sends it to the server. The key...

> Try without Via* or contact their support, as Velocity does not support protocol hacks. This probably isn't caused by ViaVersion. I suspect that the player is being sent to...