ProtocolLib

3M Downloads

BLOCK_PLACE and USE_ITEM Packet Types are Switched

biglou36 opened this issue ยท 8 comments

commented

(EDIT): Seems that this issue has already been closed before.
Describe the bug
"Player Block Place" packets are constructed as PacketType.Play.Client.USE_ITEM and
"Use Item" packets are constructed as PacketType.Play.Client.BLOCK_PLACE when passing through ProtocolLib

To Reproduce
Steps to reproduce the behavior:

  1. Create a new plugin and set up a packet listener to listen to packets "PacketType.Play.Client.USE_ITEM" and "PacketType.Play.Client.BLOCK_PLACE"
  2. Override onPacketsReceiving() method and broadcast to client or server when the event is triggered, and print the event type.
  3. Compile the plugin and run the MC server
  4. Connect to the server using a default MC client
  5. Place down a block (in any GameMode), then shoot a crossbow (or bow).
  6. Note that block placements send a "USE ITEM" and crossbow shots send a "BLOCK_PLACE" erroneously.

Expected behavior
Block placements should be sending "BLOCK_PLACE" and item interactions should be sending a "USE_ITEM"

Screenshots
image
Notice that BlockPosition cannot be found in USE_ITEM, which is called when a player breaks a block.

Version Info
Latest development build as of 3/22.

Additional context
Bug was encountered when attempting to determine the coordinates of a block being broken. Would like a temporary workaround if possible.

commented

@dmulloy2 I think you should at least switch PacketType.Play.Client.BLOCK_PLACE back to PacketType.Play.Client.USE_ITEM frist, since is PacketType.Play.Client.BLOCK_PLACE indeed the "use item" packet.

commented

@JasonHK at this point it would break existing implementations. Best thing to do would probably be to just put a disclaimer somewhere

commented

@JasonHK at this point it would break existing implementations. Best thing to do would probably be to just put a disclaimer somewhere

@dmulloy2 Yeah, you're right. It's better to fix it in the next major release.

commented

But this is how NMS deobfuscates, this should not be a problem with ProtocolLib. You should request Spigot to correct the renaming of NMS

commented

I am currently assuming that the USE_ITEM packet is a BLOCK_PLACE packet, just named incorrectly. However, calling the getBlockPositionModifier() function on the packet returns a StructureModifier of size() zero. If the assumption is correct, this is another bug.

For additional information, using getModifier() on the PacketContainer shows that there are three objects, index 0 contains a value of class: "net.minecraft.server.v1_15_R1.MovingObjectPositionBlock". Does this correspond to a BlockPosition?

commented

Update: So it seems that MovingObjectPositionBlock is in fact different than a BlockPosition. I looked in your source code and it seems that you have no support for MovingObjectPositionBlock, so I managed to obtain the position by using reflection on MovingObjectPositionBlock and calling "getBlockPosition()". I can show the code used to get things to work if so required.

commented

I would be interested in seeing the code

commented

https://pastebin.com/dEpC6H0B

The following code takes a USE_ITEM packet and gets the 1st object, which is a MovingObjectPositionBlock. It then invokes a built-in method to return the block position. Converting a block position back into a MovingObjectPositionBlock (to, say, modify the packet) is a much more in-depth process, and is not included in this code. Let me know if you have any questions.