Feature request: Option for sync incoming packet listening just before minecraft handles the packet
Janmm14 opened this issue ยท 3 comments
Reasons:
- Easy and safe access to bukkit api
- Previous packets already completely processed, so no need to listen to other packets when needing the client's state
- Upcoming packets not yet processed
Would this provide substantial benefit over say wrapping your listener code in a sync bukkit runnable?
Runnables run before packet processing in a tick (see for example MC 1.8.8 MinecraftServer.B()V ), causing previous packets to not be processed yet. A sync bukkit runnable would not solve reason 2.
I don't know how much work it would be to add this option. I hope it is not so much.
It might not be a problem for many applications, but there are some problems.
Additional general improvement: Better plugin compatibility / less bugs in some cases where authors take advantage of this.
In case of AAC this type of listening would improve and ease handling, for example of recieved player movements. There are two reasons, mc 1.8 and movements which don't cause an event, that force AAC to listen to movement packets. It already schedules recieved movements onto move events, but matching recieved packets with move events didn't really work out when I tested that in a separate project (I don't code on AAC). So currently some moves might be handled too early by AAC, causing problems / needing to create workarounds with other interactions like blocking/eating/placing/digging blocks and maybe also other actions. Problem get larger with lag spikes in the connection. Not using move events and simply scheduling causes the server to be in an uncontrolled state, which could potentially allow stuff like teleport(hit).
Listening to more packets to keep track of those inconsistencies with bukkit api in such cases is something which involves doing even more work and basically doing the same stuff vanilla already does.
That would also cause less plugin compatibility.
This type of sync listening would allow AAC to either directly cancel the packet or cancel / use setTo on the upcoming move event, having checked with all variables correct and not leaving the server in a short uncontrolled state.
I'm sure other anticheats would like this as well.