[MC-86252] Shields can continue to block after entity changes dimensions due to client and server desync

The bug

If the player is blocking when they change dimension via nether or end portal, they will continue to block attacks on the server side but will not be blocking client side.

How to reproduce

Give the player a shield, and block with it:

/give @s shield[minecraft:unbreakable={show_in_tooltip:true}]

Setblock a nether or end portal:
```
/setblock ~ ~ ~1 nether_portal
```
Continuing to block with the shield, enter the portal
Look north (for the sake of the next step)

(In survival) Damage the player:

/damage @p 3 minecraft:mob_attack at ~ ~ ~-2

Notes

If the shield is in the off hand when you replicate this bug, you will be able to interact with your main hand in ways such as eating, attacking, and using other items
This issue used to occur previously if the player opened a GUI durring the brief time that their shield was disabled, but that is since not reproducable as a change in an unknown version made it so that player can interact with GUI containers durring that time period.

Code analysis

Code analysis by @unknown can be found in this comment.

Linked issues

is duplicated by 39

MC-88080 Shield - hitting and blocking at the same time Resolved

MC-88386 Blocking mobs without actually blocking Resolved

MC-88888 Shields will automatically block melee and ranged attacks from hostile mobs. Resolved

MC-90994 Shield Nether Glitch Resolved

MC-93461 Shield Glitch Resolved

34 more links

relates to 3

MC-97527 Eating forever when blocking with shield Resolved

MC-99688 Shield disabling by axes: It doesn't actually disable Resolved

MC-99831 Shield blocking not viewing correctly Resolved

Attachments

MC-86252.mp4

Comments 35

Logical_Cyclops 2016-01-12T22:02:14Z

This bug is still existent in 15w51b, how is this still not fixed yet? It's been there ever since shields came out.

SunCat 2016-02-13T20:58:24Z

Confirmed for 16w06a

Brian McNamara 2016-02-20T15:16:35Z

An easy way to set this up is to rig a dispenser filled with arrows to a tripwire hook (I've attached a screenshot). Just start blocking, then step through the tripwire while looking at the dispenser. Arrow fires, shield blocks it, dispenser GUI opens, then release the right mouse button. Now you're perma-blocking, but you can still sprint, swing your weapons, etc.

Mithey 2016-02-29T18:30:15Z

There is a bug very similar to this one that exists which makes your character block permanently until you die or reload the world. Even getting rid of the shield completely doesn't stop your character from blocking everything and basically being immortal. I don't know how to recreate that bug though, all I know is it's happened to me every single time in the final areas of my map.

I really hope they fix this bug soon as it's rather quite game breaking combat wise and the bugs have been there for ages and still exists in 1.9 itself.

Thomas Hall 2016-03-31T00:05:01Z

Bug extant in 1.9.2

25 more comments

marcono1234 2016-04-03T10:42:30Z

Please link to this comment in the description

The following is based on decompiled version of Minecraft 1.9 using MCP 9.24 beta. All method and class names are the names used in the decompiled version.

It looks like this is a general problem Minecraft has. Cooldown of button presses and preventing the player from using multiple actions at once is only done client-side. This specific bug could be probably partwise solved by having the method net.minecraft.server.management.PlayerInteractionManager.func_187251_a(EntityPlayer, World, ItemStack, EnumHand, BlockPos, EnumFacing, float, float, float) call the method net.minecraft.entity.EntityLivingBase.func_184602_cy() (makes the player stop using the item) if the player is using an item (method net.minecraft.entity.EntityLivingBase.func_184587_cr()).
It looks like the reason why the GUI opens is because the method net.minecraft.entity.EntityLivingBase.func_184608_ct() detects a difference between the stored item in use and the item in the slot that is currently used (client side only). I could not find the reason for it, the only thing I noticed is that a different ItemStack is set as item in the used slot, but I could not find the method doing this.

Updated comment for 1.10

The following is based on a decompiled version of Minecraft 1.10 using MCP 9.30.

When the shield is damaged a SPacketSetSlot packet is send by the server. The problem is that the client has still the old shield item stored as net.minecraft.entity.EntityLivingBase.activeItemStack. When the method net.minecraft.entity.EntityLivingBase.updateActiveHand() is called then it detects this difference and causes the player to stop blocking. One way to fix this would probably be to have the method net.minecraft.entity.player.InventoryPlayer.setInventorySlotContents(int, ItemStack) update the activeItemStack as well if only the damage value changed or to change the method net.minecraft.entity.EntityLivingBase.updateActiveHand() to not reset the activeItemStack but to replace it. The items could potentially specifiy if a changed damage value should cause the player to stop using the item.

Note: Calling the method net.minecraft.item.ItemStack.areItemsEqualIgnoreDurability(ItemStack, ItemStack) could cause problems as it does not test for the tag tag.

Brian McNamara 2016-04-03T12:54:37Z

@unknown wow, is it possible that same cause of click-cooldown client-v-server is what causes MC-12363 / MC-95720?

marcono1234 2016-04-03T15:36:36Z

I don't think so, but I might have understood you wrong. The cooldown is done by just not testing if a button is pressed. If the game tests if a button is pressed client and server should act correctly. The bucket bug could be caused by something similar to MC-29318.

Brian McNamara 2016-05-11T18:32:27Z

Note also that while perma-blocking, if you try to eat food, it will just appear to attempt-to-eat infinitely (for as long as you hold right-click), until you stop and then try again.

MalbaCato 2016-05-11T20:13:47Z

Similar things are also sometimes happening to me with bows and food, but only in the off hand.

Sonicwave 2017-04-27T23:42:17Z

Confirmed for 17w17b.

Remin 2017-04-29T11:29:13Z

As Sonicwave says, still happening to this day. I happened across this post and played around with the bug for a while, and figured I'd add some details, which I suppose could possibly be considered a slightly less technical version of what Marcono already wrote about now that I think about it.

Basically, if you let go of right click precisely the moment after your shield durability changes (or after you lower the stack amount by dropping a shield if for some reason commands were used to give more than one in a single slot, and are also using your main hand for it since you can't hotkey drop offhand items), the game will still think you're right clicking with the shield (causing awkward situations such as what Brian McNamara wrote in regards to food). So whenever the durability changes, it seems to briefly desync your block for about 1 game tick client-side, which is why the bug is most easily replicated via blocking an attack while aiming at things that open a GUI on right click (chests, crafting tables, villagers, etc.), or anything at all that has right click functionality (doors, redstone comparators, even placing a block or throwing snowballs, etc.). The key words are "most easily replicated" though, meaning you can also trigger the bug if you just have really good (or "lucky") timing, including when you pick up XP with a mending-enchanted shield. You have to let go of right click very shortly after a blocked attack (or XP orb repair), which is around when you see your shield "unblock" to your side for about a single frame (or maybe it's more accurate to say about 1 game tick or 1/20th of a second?). It doesn't actually stop blocking server-side, but client-side it briefly returns normal control to you, allowing you to right click on/with anything that normally takes priority over blocking, so any instant-use right click item or action during that brief desync easily causes it to stay desynced. As long as you don't resync your bugged block by re-blocking/unequipping/moving it to a new slot, the bug will persist until a new non-instant right click item gets used (well, attempts to be used, since even then the game will think you're right clicking with your shield rather than whatever you're trying to use, whether that be a bow, potion, or as mentioned, food, or whatever else that has a usage delay (if anything)). Once desynced, you can continue to do other things normally (aside from eat/drink/shoot a bow, all of which will sync you back up as soon as you press and let go of a right click), and things like sprint mechanics will all work as usual.

Shields that don't lose durability from a blocked attack (Unbreaking enchant procs, or Unbreakable NBT tag) won't suffer from this bug because it's not updating the item, and thus, won't desync you at all. Seems to me like the game is doing something kinda similar to the /replaceitem or maybe /entitydata command (I know /entitydata can't be used on players, just mentioning it as an example) whenever an item's durability changes... For example if you hold something with a mending enchant and repair it with some XP, you can see that the item sort of lifts up from the bottom of the screen as if you just equipped something new. I'm guessing whatever that item update is is probably what Marcono is referring to with updateActiveHand, and that it's also probably what makes items "re-raise" up whenever their durability/stack amount changes (once again, almost as if it were a new item).

Oh! Another extremely similar issue I just now remembered is stacked consumables using up an extra consumable, which follows the exact same principle as this bug... and I had a whole paragraph here dedicated to that, but just found out that it has like 25 duplicates already, and the main one (MC-849) links to Marcono's comment here (I wonder if that was added literally yesterday? Because that is when that issue was apparently last updated...), yet it's been 5.5 years since it originally opened... That's... very unfortunate to see... Does that mean problematic desync issues like the +1 consumables used, the especially bad easily abusable perma-block bug, and the also especially bad sprint desync when holding the sprint button during a sprint attack bug (sprint-related things other than movement all fail during desynced sprints) aren't gonna be fixed for many, many more years? Hopefully not the case! D: All that aside though, I feel like this issue should be marked as related to that 5.5 year old consumable items post, especially since it does indeed seem closely related and even directly links Marcono's comment in this one now (though, again, I dunno how long that link's been over there).

Koi YTP 2017-07-30T14:28:50Z

The closing sentence to the description "while the effect of blocking persists, you can attack normally as if you weren't blocking." seems to be missing a not between the can and the attack.

marcono1234 2017-07-30T14:43:20Z

@@unknown, no that is exactly the point of this report. You should not be able to attack while you are blocking, however this bug allows you to do that.

Logical_Cyclops 2017-07-30T15:13:29Z

And how come the effected versions of this bug report hasn't been updated to minecraft 1.12?

Thomas Hall 2018-02-05T04:34:44Z

Bug extant in 18w05a

Thomas Hall 2018-02-21T09:31:38Z

Affects 18w07c

Brenden Smith 2018-04-04T01:21:12Z

If anyone is wondering, yes, this is still in 18w11a.

Block twenty-eight 2018-04-05T14:03:11Z

Confirmed for 18w14a

Block twenty-eight 2018-04-05T22:36:48Z

Affects 18w14b

Block twenty-eight 2018-04-19T19:50:21Z

Affects 18w16a

Block twenty-eight 2018-06-04T20:37:30Z

Confirmed for 1.13-pre1

Jon1337 2018-07-05T15:37:51Z

Confirmed in Minecraft 1.13-pre6

Jon1337 2018-08-18T15:46:39Z

Confirmed in Minecraft 1.13.1-pre1

Loek van Vucht 2018-08-25T14:07:12Z

Confirmed in Minecraft 1.13.1
You can also activate this bug when attacking and blocking with your shield at the same time. Try it out, you'll keep blocking when doing that as well as when hovering over a container.