-
Bug
-
Resolution: Unresolved
-
None
-
1.19.2, 1.19.4, 24w12a
-
None
-
Confirmed
-
Networking
-
Normal
-
Platform
(Apologies that this bug has been reported before, but this ticket actually describes the 1-line solution, so please don't close my ticket)
Bug
If a client finishes/aborts breaking a block, then starts breaking a block at the same position, the client will fail to send START_BREAKING_BLOCK. This results in client/server desync - the client is breaking a block but the server doesn't realize it.
Vanilla Reproducer
The easiest way to see this bug in action (using a vanilla client/server), is to make a command block that continually sets a block, then break it while in survival: https://youtu.be/u4nn48TTpkE
Code Analysis / Fix
The fix for this bug is very simple:
The check `this.sameDestroyTarget(var1)` inside the method `MultiPlayerGameMode#continueDestroyBlock` should be replaced with `this.sameDestroyTarget(var1) && this.isDestroying`
This simple change will make the client send START_BREAKING_BLOCK, informing the server that the client intends to start breaking a block.
Addendum
This bug occurs very frequently and is the root cause of a lot of "breaking animation" glitches, some of which date back to Jan 2013:
MC-8472 (adventure mode CanDestroy)
MC-19676 (survival -> adventure mode breaking)
MC-69865 (refocusing same block)
MC-157404 (breaking block behind insta-break block)
... and over 50 more
- relates to
-
MC-19676 Breaking particles, sounds, and block cracks can be created in adventure mode
- Reopened
-
MC-157404 Placing/breaking instant-breaking blocks slowly breaks block behind them
- Reopened
-
MC-73786 Static breaking cracks using specific tools and consumables
- Open
-
MC-8472 Block cracks remain on blocks in adventure mode when losing focus of them
- Reopened
-
MC-69865 Block breaking is not canceled when losing focus of a block
- Reopened