AHL

Hi, still present in 24w45a for 1.21.4, 6 years after the initial report.

When is this gonna be fixed? With Mojang putting a "minecraft:" in all requirements of vanilla advancements, it has become totally impossible to target players with a specific criteria...

Still in 1.21, and also affects the "movement_affected_by" predicate in data packs which doesn't consider these blocks as "affecting the movement".

In this version, the command becomes as following:

/give @p diamond[attribute_modifiers={modifiers:[{operation:add_value,amount:10d,type:"generic.movement_efficiency",id:"a"}]}]

Still in 1.21-RC1, with an even stronger effect I just found: if your enchantment adds a high enough negative value, you can one shot (or rather, two shots) a warden by hitting it twice quickly.
Absolute nonsense.

{
	"description": "Negative Damage",
	"supported_items": "#minecraft:enchantable/weapon",
	"weight": 1,
	"max_level": 1,
	"min_cost": {
		"base": 0,
		"per_level_above_first": 0
	},
	"max_cost": {
		"base": 0,
		"per_level_above_first": 0
	},
	"anvil_cost": 0,
	"slots": [
		"mainhand"
	],
	"effects": {
		"minecraft:damage": [
			{
				"effect": {
					"type": "minecraft:add",
					"value": -999
				}
			}
		]
	}
}

I've already reported the critical hit issue too, but it's already tracked in MC-272004 and at this point we can't state that both issues are related.

Can confirm for 1.21 Pre-Release 3.
Note that it happens for all enchantments, not only sharpness.
And I don't think MC-271888 is a duplicate of this issue, maybe related but I'm not even sure of that.

The problem is that you can't summon an entity and calculate it's motion in the same tick it's been summoned to let it have a nice trajectory. The summoned entity must have it's trajectory already set in it's summon command or it will be completely messed up if changed afterward. But since we can't put variables as values in commands, we have no other choice.
Besides, Searge's answer about the non-resolution of thig bug is from 2014. Maybe their mind has changed since then?

Indeed, I was giving myself a head with a raw note_block_sound tag instead of including it in a BlockEntityTag tag. Thanks for the correction.

I can confirm for 1.19.

I can confirm for 1.19-rc2, and very likely for 1.19 since I believe they won't fix it today before the release.

I can confirm for 22w15a.

How the hell is it "working as intended" ?

1. It's totally legit to check if a player doesn't have an item anymore in their inventory: for example you can refill some blocks when they have used all.

2. There is a workaround to achieve the same behavior but with a lot more complicated and resource consuming method, so why not let the possibility to do it with the simplier, more resource friendly one?

3. This is not logic: 0 is a possible count for an item, for example by running « execute store result storage test count int 1 run clear @s minecraft:stone 0 » you may get a value of 0.

I understand that it may not be very urgent, but why just reject it?

By the way, I didn't receive an email saying that the ticket was closed while I'm surveying it.

JSON files updated again, since grimstone has been changed to deepslate.

Since grimstone slabs and stairs were added to the tags in 21w07a, I updated the JSON files.

Updated with the new block IDs and tag files of the 21w05a, since they are not in the tags yet.