ProtocolLib

3M Downloads

cancelling a use_entity packet?

dniym opened this issue ยท 3 comments

commented

Make sure you're doing the following

  • [x ] You're using the latest build for your server version
  • [x ] This isn't an issue caused by another plugin
  • [x ] You've checked for duplicate issues
  • [x ] You didn't use /reload

Describe the question
I am attempting to cancel a use_entity packet. Specifically the packet sent when a player equips a chest on a donkey/llama etc. This appears to work fine on older versions, however in 1.14/1.15 (maybe 1.13) even after the event is cancelled it seems that the client still renders the chest on the animal.

This is probably a clientside bug, evidenced by if the player attempts to open the inventory it crashes the client. I have had to resort to setting the animal to chested then immediately setting it to chested = false. This does cause the chest to blink but does remove it clientside. Is there something I can do to prevent this step?

ALSO, if I change the packet type to a different type i get a warning in the console:
11.05 16:25:53 [Server] Netty Epoll Server IO #0/WARN [ProtocolLib] [PacketEvent] Plugin IllegalStack changed packet type from USE_ENTITY[class=PacketPlayInUseEntity, id=14] to DISCONNECT[class=PacketLoginOutDisconnect, id=0] in packet listener. This is confusing for other plugins! (Not an error, though!)

Should this be appearing if the packet is indeed cancelled? Wouldn't other plugins/spigot never receive the packet at this point since its cancelled?

Expected behavior
when cancelling the packet, it should never reach the server and other plugins should never see it.

Code

https://hatebin.com/tfzhotocsi

commented

you are not supposed to change the packet type, you should cancel the packet and send a new one (not overriding the existing packet)

am not sure what the client changed here, but this is in line with how other modifications are handled client side. do modification first, server sends new packet to revert if needed. this is a form of lag compensation.

commented

I agree, just really need to make sure that packet is not hitting the server hence why I tried changing the type after upon cancelling the packet I was not getting the expected result.

My question is why would it matter if the packet type was changed on a cancelled event, shouldn't it never reach the server?

commented

it doesn't reach the server, it may reach other handlers tho, which will not be happy since they expect a different packet type. thats why that warning is there.