Weird thing has started happening to me. I set up a breakpoint in Decoda, that is hit everytime a player spawns in a world (HOOK_PLAYER_SPAWNED), and when the breakpoint is hit, Decoda pauses MCS, but it still manages to mis-parse the protocol, producing weird packet errors. I have no idea what's going on here, I'm suspecting a threading issue which could manifest in normal gameplay, but it hasn't yet, and the breakpoint amplifies it. But still, it's plain weird.
Yup, threading issue, a complicated one. Finally I untangled the mess.
1. The player connects
2. The client handle is created and added to cServer; the cServer's TickThread handles the packet processing for the client
3. The player logs in and spawns, the packet handler moves the client handle from the cServer to the specified cWorld and calls the OnPlayerSpawned hook.
4. Decoda breakpoint causes the cServer's TickThread to pause.
5. cWorld's TickThread is now in charge of handling the packets for the client handle; the thread is not paused by Decoda, so it runs and receives next packet
6. The next packet is stored in the ByteBuffer after the initial login packet
7. The next packet is processed and the ByteBuffer resets to the beginning of the "currently parsed" packet, to skip the PacketSize bytes of the packet correctly. However, because the login packet hasn't still been committed as processed, the ByteBuffer resets in front of the login packet instead of the next packet.
8. Bam, protocol error!
The question now is, how to handle this mess. And it doesn't need to be caused just by Decoda, it could be anything in a plugin taking a bit longer in the OnPlayerSpawned hook.
Yup, threading issue, a complicated one. Finally I untangled the mess.
1. The player connects
2. The client handle is created and added to cServer; the cServer's TickThread handles the packet processing for the client
3. The player logs in and spawns, the packet handler moves the client handle from the cServer to the specified cWorld and calls the OnPlayerSpawned hook.
4. Decoda breakpoint causes the cServer's TickThread to pause.
5. cWorld's TickThread is now in charge of handling the packets for the client handle; the thread is not paused by Decoda, so it runs and receives next packet
6. The next packet is stored in the ByteBuffer after the initial login packet
7. The next packet is processed and the ByteBuffer resets to the beginning of the "currently parsed" packet, to skip the PacketSize bytes of the packet correctly. However, because the login packet hasn't still been committed as processed, the ByteBuffer resets in front of the login packet instead of the next packet.
8. Bam, protocol error!
The question now is, how to handle this mess. And it doesn't need to be caused just by Decoda, it could be anything in a plugin taking a bit longer in the OnPlayerSpawned hook.