Can't use the NBT tags with testforblock to detect items

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:

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}]}

^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

/testforblock X Y Z chest 0 {Items:[]}

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.
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:{Slot:1b,id:263s,Count:1b}]}
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.