Shield blocking is delayed

Duplicate of MC-97772

Forward resolving MC-97772 to here.

Still affects 1.12.2, although the Minecraft Wiki at the very least treats this as intended behavior; there was .5s after raising shield before it was effective in early 1.9 snapshots, but this was reduced to .25s before 1.9's release. If the delay is longer than this, and isn't due to some form of lag, then it's a definitely a bug.

But even if it is intended, it shouldn't exist

What the wiki states is irrelevant. It only states the current behavior, not intended behavior. And as such is not a relyable source regarding if it's intended or not.

Still an issue in 18w21b

@unknown, ticket is yours now.

It is actually a feature. It is unknown why they would have such a stupid mechanic but thats how the mojang works

Source that this is intended?

Please do not mark unreleased versions as affected.
You don't have access to them yet.

I don't know if it's intended, but have no sense. 

The main problem is that there is a desynchronization between what the player sees and what happens in the game. The player is seeing that he raised the shield in time to block that arrow, but the arrow hits him and makes him lose life points. 

If the player is seeing that he is protected, he must not lose the points of life.

There is already a delay since the player presses the button until the shield rises (the visual animation time)

This feels completly wrong. As Dídac said, the animation should be synced with the intended action in-game. Also, having this feature fixed would feel rewarding for the skills of the player; defending in the last second is an act of reflexes, and the gaming community when rewarded for their skills gives back to the game whichi finally means, a better image for the game itself.

Probably the younger players wont care about this and keep playing as pretended by the limitations, but the more adult community will turn away from a game that displays and ignores this "spaghetti code" behaviour. By the end of the day, this means advertising and finally, a bigger and more mature community.

This affects especially the PvP and PvE players, which makes up the fighting and adventure sides of the game.

Confirmed to be fixed in a future version 😃:
https://twitter.com/jeb_/status/1136935340827127813

Affects versions 20w20a and 20w20b as well. This is the one bug I want to be fixed, I literally don't use shields because of this bug and it's beginning to really frustrate me.

Affects 1.16.1

In 20w27a

The way i play the game, this bug seems like it should have far more ubiquity. That reaction time is pretty much pointless when blocking, that you're effectively punished for doing something to the same effect as parrying, is pretty dumb. But fix it on your own time, Mojang! 🙂 🙂 🙂 🙂 🙂 😉

Can confirm in 20w51a.

Can confirm in 21w03a.

Can confirm in 21w05b.

Can confirm in 21w06a.

Can confirm in 21w07a.

I thought this was an intended feature

Can confirm in 21w11a.

Can confirm in 21w14a.

Can confirm in 21w18a

Can confirm in 1.17.

Can confirm in 21w38a

Not sure if developers intended for shield blocking to be instantaneous or if they intended for there to be a delay. Either way, current functionality is insufficient because with the delay we have right now, it is not shown to the player, therefore the instantaneous shield blocking we see is misleading – a potential fix if developers wish to keep a delay functionality is to maybe make an animation that shows the delay, and the animation only ends once the delay is over and the shield is in blocking position. If this is the route we go, it would also be essential for pvp that this animation and its timing is correctly visible to other players as well.
Just attached 2 more vids recorded in 1.17.1, latest release at time of typing this, which show this happening in melee cases as the existing vids were with projectiles.

Can confirm in both 21w39a and 21w40a. 

Also Megalodab in this video that does code analysis of this issue I assume it is intended. In short, there is an arbitrary 250ms delay after you hold up a shield until it is permitted to block attacks. I don't know how you would add this to the description like how other reports have a Code analysis section but maybe someone else knows how. 

In any case I feel like the delay should be removed entirely (which from what I can understand would involve just changing a 5 to a 0) rather than syncing the animation to the delay because it just adds unneeded jank to the shield and makes you play arbitrarily slow with it, not just with pvp, but also with pve fighting multiple skeletons, for example.

Yeah I agree zeta I’d prolly want the instantaneous option

In 22w15a and in 1.18.2

Affects 1.19

Can confirm in 1.19.2.

yes finally

To the people who say this might be intended, Mojang can easily clear that up by marking this issue as "Works as Intended".
However they keep it open for unknown reasons (as far as we know), which leads me to believe it was intended.

Can confirm in 23w05a

Confirmed in 1.20

This should be WAI, in the combat tests this was intentionally changed and discussed by Jeb. It will not be changed for the current combat system, as it is intended there.

@SeaOfPixels If this is WAI then it should not play the pull up animation until after whatever time it can start blocking attacks so it doesn't just lift up the shield to find out it won't work right away.

Confirmed in 1.20.2.

If you guys didn't know, shields have a cooldown of 0.25 seconds before blocking damage so unfortunately, it does not block instantly.

Can also confirm in 23w42a

There's nothing more annoying than blocking a skeleton arrow only to still get hit by it, and it gets annoying having to pre emptively block and wait for the skeleton to shoot

Confirmed in 23w43a and 23w43b

Confirmed in 23w44a

Also confirmed in 23w45a

Confirmed in 23w46a

Confirmed in 1.20.3-pre2

Confirmed in 1.20.3

Can confirm in 1.20.4 Release Candidate 1

Confirmed in 24w05b

Confirmed in 24w14a

Confirmed in 1.20.6-rc1

Confirmed in 24w18a

grab a shield in your non-dominant (or dominant) hand and try to block instantly

In 25w04a shields now have a component which determines how long it takes for the shield to start blocking, and the default is 0, however, that doesn't seem to actually work and shields still have the delay.

This should probably now be marked as intended as despite the tag existing, a spawned item with a set delay of 0 works.

/give @p diamond_sword[minecraft:blocks_attacks={block_delay_seconds:0}]

This item can block damage and reflect noticeably faster than a vanilla shield, which means the shield should have a specified value of 0.25 in the block delay seconds property. Assuming this item works properly and can be verified, that would mean that the way shields work is considered intentional.

Shields are intended to have a block delay of 0.25 seconds, as can be seen now in the default components of the item:

"minecraft:shield": {
    "components": {
      "minecraft:attribute_modifiers": [],
      "minecraft:banner_patterns": [],
      "minecraft:blocks_attacks": {
        "block_delay_seconds": 0.25,
        "block_sound": "minecraft:item.shield.block",
        "bypassed_by": "#minecraft:bypasses_shield",
        "disabled_sound": "minecraft:item.shield.break",
        "item_damage": {
          "base": 1.0,
          "factor": 1.0,
          "threshold": 3.0
        }
      },
 ...

This seems like it should be marked as intended.