Open GladUrBad opened 4 months ago
The first transaction someone receives is actually at the end of the tick, as the login process happens during the tick they cannot receive the start tick transaction
So a quick note to clarify:
The first transaction (-1) can be captured at ClientPinger#onPingSendEnd
because it is sent at the end of the tick.
Ah you're right, though Pledge itself still appears to have issues with this because it calls onPongReceiveInvalid. Through more debug it appears that the vanilla client only responds consistently after the player has fully joined (after PlayerJoinEvent).
For now I have implemented a stupid fix in my Dusk fork
I'm not well versed in these modern versions protocol or Pledge itself so please let me know if I'm being dumb
I'll test 1.20.6 real quick for you, but Pledge should not send ping packets before play state so this hack shouldn't be needed. This is actually the reason why Pledge cannot send the first transaction on the start of the tick
Seems like there is a 1.20.6 compatibility issue, previous versions work fine
This is on 1.20.6, recently tried Pledge with a PacketEvents plugin to send transactions start/end of tick
Here is my configuration. Pledge is sending the pings and the client is responding and the server does recognize the receive (verified using PacketEvents) however Pledge won't handle the pong receive method (start/end) unless an entire cycle of the IDs have been sent first. This was found after using the PingTaskScheduler from Dusk which I used to track player ping by scheduling a task every start of server tick.
With ID range from -1 to -200, the ping is shown as ~5000ms. (200 ids / 2 per server tick 50ms each tick = 5000ms) With ID range from -1 to -2400, the ping is shown as ~60000ms. (2400 ids / 2 per server tick 50ms each tick = 60000ms)
This is how I concluded that it takes an entire cycle of pings in the ID range to be sent first before Pledge actually can recognize receives.