Can't use the NBT tags with testforblock to detect items
/setblock ~0 ~1 ~0 154 0 replace {Items:[:{Count:1,Slot:2,id:35,Damage:15}]}
can spawn a hopper with items inside just fine, however
/testforblock ~0 ~1 ~0 154 0 {Items:[:{Count:1,Slot:2,id:35,Damage:15}]}
will return:
The block at x,y,z did not have the required NBT keys.
Linked Issues
is duplicated by9
MC-36606/testforblock does not work with chests that have NBT tags. I want this feature badly.DuplicateMC-38644NBT datatag for items in chest not acceptedDuplicateMC-44588Testfor BugDuplicateMC-48012Testforblock not working in 14w06bDuplicateMC-48074'testforblock' Command not working with 'Items' datatagDuplicateMC-49053Data tags not working on AnimalsDuplicateMC-50508NBT keys of chests do not work properlyDuplicateMC-51226/testfor /clear /testforblock don't work correctly with TAG_LIST with TAG_COMPOUND inside NBT TagDuplicateMC-51476/testforblock tagsDuplicateAttachments1
Created Issue:
Can't use the NBT tags with testforblock to detect items
/setblock ~0 ~1 ~0 154 0 replace {Items:[:
{Count:1,Slot:2,id:35,Damage:15}]}
{Count:1,Slot:2,id:35,Damage:15}
can spawn a hopper with items inside just fine, however
/testforblock ~0 ~1 ~0 154 0 {Items:[:]}
will return: The block at x,y,z did not have the required NBT keys.
/setblock ~0 ~1 ~0 154 0 replace {Items:[:
{Count:1,Slot:2,id:35,Damage:15}]}
{Count:1,Slot:2,id:35,Damage:15}
can spawn a hopper with items inside just fine, however
/testforblock ~0 ~1 ~0 154 0 {Items:[:]}
will return: The block at x,y,z did not have the required NBT keys./setblock ~0 ~1 ~0 154 0 replace {Items:[:{Count:1,Slot:2,id:35,Damage:15}]}can spawn a hopper with items inside just fine, however
/testforblock ~0 ~1 ~0 154 0 {Items:[:{Count:1,Slot:2,id:35,Damage:15}]}will return:
The block at x,y,z did not have the required NBT keys.
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
is duplicated by
What is the syntax?
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
is duplicated by
relates to
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
Duplicate of MC-30976 - If you have not, please use the search function in the future, to see if your bug has already been submitted. If you could not find the original report, please comment with the keywords you searched for.
Duplicate of MC-30976. See the comments section for a workaround.
This is probably related to MC-30976.
Probably you have to specify the complete content of the Inventory tag and you'll have to provide the datatypes ("Slot:1b")
The datatypes are missing.
see http://minecraft.gamepedia.com/Chunk_format#Tile_Entity_Format and http://minecraft.gamepedia.com/Player.dat_Format#Item_structure
Slot is a byte, thus "Slot:0b"
Also explained in MC-30976
I don't think its an issue, I think we (I have this issue too) just aren't including all the tags.
It does say "required" in the error message, so one would think that the tags you supply must be there and not that the block should only have those tags. Besides, what about checking for certain items in a chest with 27 individual slots to test for? That seems like an awful lot of text to see if a chest has a named diamond sword in a specific slot.
I am led to believe there are tags being filled in that we aren't seeing. After all, there is no way to see them.
Still an issue as of 13w08c . If there are tags being added "invisibly", I'd call it a bug, because it's being made pretty much impossible to use this feature.
Confirmed as well, with hoppers and chests. Assuming this happens with all other container blocks. Trying out other blocks with other NBT tags, such as a command block with a CustomName tag, works just fine.
I haven't heard anything about invisible NBT tags. There's a nifty third-party program called NBT Explorer which lets you view all of the tags a block has. I've matched the /testforblock tag for tag with a chest and it made no difference.
Confirmed. I have tried everything. If we are doing something wrong TELL US WHAT IT IS PLEASE!
I can confirm this for Heads/Skulls as well. "/setblock ~ ~ ~ 144 1 destroy
{SkullType:0}" will place a Skeleton Skull (and I can change the number to other heads no problem), but "/testforblock ~ ~ ~ 144 1
{SkullType:0}" gives "The block at x,y,z did not have the required NBT keys" like what was mentioned in the bug description.
Confirmed Jacomere's skull issue. The "ExtraType" will produce a signal correctly if it matches the skull owner of the placed head (didn't even need to input a SkullType, but doing so gives the error of course). I went further and checked the rotation (Rot) tag. I matched the rotation of the tile entity with the /testforblock with no success; gives the "did not have the required NBT keys" error.
It appears that noteblocks have issues as well. Not sure if I should open a new bug report since it's related. I'll edit this comment if I find more blocks that have these issues.
-Noteblocks with the 'note' tag (determines the pitch of the note). Created a block with a note of 5, and tested for a note of 5 with a failure. The 'id' of 'Music' alone works, adding the 'note' fails.
I added a screenshot (screenshot mcedit.png) which shows the nbt tags of the chest (in this case I just placed a paper in the top left corner)
then I used
testforblock -64 26 -250 54 3 {Items:[{id:339,Damage:0,Count:1,Slot:0}]}but I got the same message. All the tags are exactly like in mcedit so that can't be the problem.
Confirmed to still be present in 13w39a.
It would be handy to see the datatag that the block does contain in the chat. So you know what you did wrong.
Yes. It does this for the damage values but not the NBT tags.
MOD PLEASE UPDATE --> Still an issue in 13w39b
Confirmed.
confirmed
Yep still cant do it
Still present in 13w41a.
confirmed
I can confirm as well...if my luck with finding bugs continues, this will be fixed by next snapshot (I discovered two of them that were then fixed in the next snapshot released after finding...others had found before).
in that case: confirm all bugs now!
still present in 13w43a
The issue is not caused by the user missing tags, it is not adding a 's' if the tag is a short, a 'b' if the tag is a byte, a 'L' if the tag is a long, a 'f' if the tag is a float and a 'd' if the tag is a double, so test for a chest with stone in the first slot you could do:
/testforblock ~ ~+1 ~ chest 0 {Items:[0:{Slot:0b,id:1s,Damage:0s,Count:1b}]}Confirming Paul's comment. Very ambiguous way of doing it, but it actually works. One would hope that it'd be easier than doing it that way, so I say the report should still be open unless there's a specific reason it has to be done that way. You can /setblock the same exact command while removing the 'b' and 's' successfully.
EDIT:
Checked noteblocks as well using Paul's method, and it worked.
Go Paul!
I actually remember seeing something like this earlier, and totally forgot about it after realizing it worked when you spawned in items not using this.
how come I didn't know about that thanks paul!
Still in 1.7 pre release, I think. This is what I have to test for a furnace with coal in the fuel slot:
/testforblock ~1 ~4 ~-1 minecraft:furnace 4 {Items:{Slot:1,id:263}} Either a problem with my tags, a problem with this issue, or (most likely) both.
P.S. I would be great if the error could tell you specifically what NBT tag didn't match, to make debugging SOOOOOO much easier.
Im sorry WHAT. This does not work as intended. We have proved above that it is a bug. Leave it open and let Mojang dismiss it as intended.
From Paul Fulham:
^Therefore the bug is the need to add those characters. That is not something you need to do in other commands. This is obviously a bug.
If anyone is doubting, I second this WAI. It's how item formatting works.
Where is this character addition in other commands for vanilla? I understand this is how the game works in its raw code. However, this isn't parallel with other command's syntax.
Confirmed WAI, this is playing with the guts of the game, they do not have to make sense. You have your work-around, work with it
Lol ok Grum. Sounds good!
Is there any way to check for an empty chest?
Sure. Empty item array.
@Dustin
The damage value may vary depending on its facing.
Yeah I figured it out. That's why I deleted the comment. Thank you so much for your reply though! (I had another comment asking about syntax)
I can see how this new method works for items in a chest. But how does it work for testing for a named block such as a lever. Such as, when a lever is placed on a block with a specific name it'll trigger. We'll pretend this name is "Key" Sorry if this is the wrong place to post this, I needed both the chest and this for my map. The chest is now solved now i just need this.
Placed blocks, with a few exceptions such as Chests and whatnot, do not support having names.
Oh :/ that's unfortunate. Thanks though. It's odd that you can name a lever but cant test for it.
It's not actually named once it's in the world as a block.
Indeed. See MC-209.
I understand tht this is classified as WAI, but I still think it is worthy of being called a bug, because you don't have to do this with setblock, but with testforblock.
{Slot:1b,id:263s,Count:1b}EDIT: Also, even using Paul's workaround, I still can't get the command to detect a furnace with coal in the fuel slot: /testforblock ~ ~+3 ~-1 furnace 4 {Items:[0:
]}
What is wrong?
You're missing the Damage tag:
/testforblock ~ ~1 ~ furnace 4 {Items:[0:{Slot:1b,id:263s,Count:1b,Damage:0s}]}Anybody looking for help on this should watch this video: http://www.youtube.com/watch?v=So9xQ0Lu9Mg
Is this topic resolved? There are no hints to the fact that it is, but I can't vote for it.
It's working as intended.
Tag tag isn't working...?
testforblock ~ ~ ~-3 chest 2 {Items:[0:{Slot:0b,id:397s,Damage:3s,Count:1b,tag:{display:
{Name:"Dr. Whats's Head"}}}]}
does not work, even
testforblock ~ ~ ~-3 chest 2 {Items:[0:{Slot:0b,id:397s,Damage:3s,Count:1b,tag:{}}]}
does not work, however
testforblock ~ ~ ~-3 chest 2 {Items:[0:
{Slot:0b,id:397s,Damage:3s,Count:1b}]}
does work.
Also, testing for enchantments does not work either.
@Carl Nathans Since you're using player heads, just need to be sure: have you specifically renamed the item manually? Or is it owned by a specific player? If it's owned by a specific player, you need to use the "SkullOwner" tag, the "Name" is for custom displays.
Yes, the head is renamed using an anvil. Even if I add a blank Lore tag, it doesn't work. (Even a blank tag tag doesn't work)
The workaround by Paul Fulham does not work anymore in 14w04a.
/testforblock ~ ~+1 ~ chest 0 {Items:[0:{Slot:0b,id:1s,Damage:0s,Count:1b}]}14w03 has switched over to the new item format. You have to label the correct item ID, complete with "minecraft:":
/testforblock ~ ~+1 ~ chest 0 {Items:[0:{Slot:0b,id:minecraft:stone,Damage:0s,Count:1b}]}Working for me sometimes but not others... works with just the one stone block but not a whole array of items...
Even after trying the format above, I still get the reported error.