Elemend
Assigned
Reported
MC-217718
Pick-Block (middle mouse button) doesn't work on filled cauldron
Duplicate
MC-209714
Advancement reward function creates ghost item
Duplicate
MC-156197
Using Shears with 1 Durability remaining drops nothing or wrong drop
Fixed
MC-135492
Clone destroys blocks that are dependent on support blocks
Confirmed
MC-128079
Statistic for using shears doesn't increase when mining certain blocks
Fixed
MC-125914
data get entity ignores specified slot
Invalid
MC-124314
setblock replace gives an unexpected error
Duplicate
MC-123032
Tags overwrite, don't append
Fixed
MC-122819
Changes to the hitbox of hoppers makes them unable to pick up items
Fixed
Comments
Oh, I made a mistake. The 1 at the end of the command is read as an item modifier. This makes this command fail, of course. If the 1 is removed it works as it should. So nevermind, this issue isn't one and can be closed.
There is an Issue still here, however. I mentioned the commands being executed as an advancement reward. This changes things. There is a bug here, need to rewrite that report
and this is in some way a duplicate of MC-187281
This Issue can be closed, thank you.
Can confirm for 19w46b.
It's important that the hitbox of the boat has to extend over the edge of the block. If the boat is just at the edge but not over it, the falling block drops on the torch as an item.
This Issue is a duplicate.
The Problems described are fixed via MC-151962, please close, thanks.
Happens in 19w42a
Can this be closed as "works as intended" ?
The reason for this is that "align xyz" exists. It floors the executing position so it won't find the armor stand named "positive" if you do this:
/execute at @e[type=armor_stand,name=center] align xyz run say @e[dx=0,dy=0,dz=0]A potential fix to this bug would mean that the execution position is floored as a built in feature. I would advise against it, it would be detrimental actually. No functionality is lost if this would be resolved as WAI.
This is still an Issue in 1.14.4 and the 1.15-Snapshots.
This seems forgotten, as it wasn't updated in a long time and might be resolved as "invalid" or "won't fix".
Whatever, I hope we can get a way to store the id of a block somewhere. Right now in the game you would use hardcoding to relate scoreboard value to block (hardcoding) or use the loot command to store the drop of a block somewhere. If you're using "/loot" in your datapack it can potentially be unreliable because of block loot tables from other datapacks.
If the content of this report was in the game you could pair this with the upcoming storage (in 1.15-snaphots). Then you could have the id stored directly without hardcoding anything and with no potential conflicts between datapacks.
Hey, so I'm pretty sure I'm experiencing this Bug with crafting in a datapack. It's happening with chuckchuks tables and chairs datapack, but I also have an example datapack here, where you can craft two sticks diagonal over each other to get a knowledge book. This triggers an advancement in which you get a function reward, and in that you get the knowledge book cleared and are given a wooden sword. That works no problem, and the item shows up, but if the hotbar of the player is full, the sword gets given as an invisible item and only shows up by clicking into the seemingly first empty slot.
[media]
This happens in 1.14.2 and the latest 1.14.3-prerelease 1, but I'm 100% sure it's happening in every version that released after this Bugreport last got updated.
Affects 1.14.2-Pre-Release 3
Happens in 1.14.2-Pre-Release 3
Happens in 1.14.2-Pre-release 3
Happens in 1.14.2-Pre-release 3
Happens in 1.14.2-Pre-release 3
Happens in 1.14.2-Pre-Release 3 (Be sure to have /gamerule doWeatherCycle true)
Happens in 1.14.2-Pre-Release 3
This Occurs in 1.14.2-Pre-Release 3 as well.
Happens in 1.14.2-Pre-release 3
I experience the same Issue using the same advancement trigger and a reward in which the item gets switched from offhand to mainhand with the new /item command.
[media]