NBT list comparison tests if item in list, but ignores position
The NBT list comparison (like it is used for the /testfor or /scoreboard command only tests if an item is in the list, but ignores the position.
Example:
/summon item ~2 ~ ~ {Item:{id:stone,Count:1,tag:{display:{Lore:[A,B,C]}}}}
/execute if entity @e[type=item,limit=1,nbt={Item:{tag:{display:{Lore:[A]}}}}] run say test (works as "A" is in "Lore") /execute if entity @e[type=item,limit=1,nbt={Item:{tag:{display:{Lore:[A,C,B]}}}}] run say test (works as "A", "C" and "B" are in "Lore") /execute if entity @e[type=item,limit=1,nbt={Item:{tag:{display:{Lore:[A,C,B,D]}}}}] run say test (doesn't work as "D" is not in "Lore")
This is mostly problematic when testing for numbers like for example:
/execute if entity @s[nbt={Motion:[0d,0d,0d]}] run say test
as this would return true if 0d is in "Motion", that means however that the other two numbers in "Motion" can be anything.
Note: Maybe this is the intended feature, if so it would be appreciated if the developers find a way to make direct comparison possible (maybe by saying if a list contains the same amount of items as the to-compare list, then try comparing it directly).
Original description:
There is a bug where using the /testfor ArmorStand command with a specified NBT Rotation value of
{0.0f, 0.0f} returns all Armor Stands, regardless of rotation. Using a Rotation value other than {0.0f, 0.0f}works as expected. This happens when your command is run in a command block or from the chat. I haven't tested this with anything other than armor stands.
This command returns only armor stands with the specified rotation:
/testfor @e[type=ArmorStand] {Rotation:[45.0f,0.0f]}
This command returns all armor stands, regardless of rotation.
/testfor @e[type=ArmorStand] {Rotation:[0.0f,0.0f]}
To reproduce, place stand with 45 degree rotation, and place a stand with 0 degree rotation. Run the two commands above. The first will give one result, the second will return two results.
Linked Issues
is duplicated by7
MC-80649Can't detect the Motion tag of non-mob-entitiesDuplicateMC-93929Detecting Players not movingDuplicateMC-96099Motion NBT Tag is broken for playersDuplicateMC-133369Motion NBT tag in execute selectors doesn't seem to be checking actual valuesDuplicateMC-193015HandItems issueDuplicateMC-234626Armor Stand Rotation:0 Detect All Armor StandsDuplicateMC-272657The Motion NBT data turns into 0, 0, 0 when a entity walks direction south or east.Duplicate- Unresolved
Ben Reddersen- 28
- 21
- Confirmed
Low- Platform
- Commands
1.8 - 1.21-pre1
1.8 15w49b 16w04a 1.10.2 16w32b 16w36a 16w38a 16w39a 16w39b 16w39c 16w40a 16w41a 16w42a 16w43a 16w44a 1.11-pre1 1.11 16w50a 1.11.1 1.11.2 17w06a 17w13b 17w15a 17w16b 17w17a 17w18b 1.12-pre2 1.12.2 17w50a 18w06a 1.13-pre7 1.15.2 20w06a 20w13b 1.16.1 1.16.2-pre2 1.16.2-rc1 1.16.2 1.17.1 1.20.4 1.21-pre1
Created Issue:
Armor Stand testfor Command Rotation Issue
This command returns only armor stands with the specified rotation:
{Rotation:[45.0f,0.0f]}
/testfor @e[type=ArmorStand]This command returns all armor stands, regardless of rotation.
{Rotation:[0.0f,0.0f]}
/testfor @e[type=ArmorStand]This happens when your command is run in a command block or from the chat.
Environment
Java 1.7.0_71 32bit
Windows 7
No mods installed
This command returns only armor stands with the specified rotation:
{Rotation:[45.0f,0.0f]}
/testfor @e[type=ArmorStand]This command returns all armor stands, regardless of rotation.
{Rotation:[0.0f,0.0f]}
/testfor @e[type=ArmorStand]This happens when your command is run in a command block or from the chat.
The problem is that the second command should only return stands with rotation:
{0.0f,0.0f}. If you want to ignore rotation, simply use /testfor @e [type=ArmorStand] .
Armor Stand testforCommandRotationIssueArmor Stand and /testfor with NBT Rotation, too many results when using 0.0f, 0.0f
This command returns only armor stands with the specified rotation:
{Rotation:[45.0f,0.0f]}
/testfor @e[type=ArmorStand]This command returns all armor stands, regardless of rotation.
{Rotation:[0.0f,0.0f]}
/testfor @e[type=ArmorStand]T
his happens when your command is run in a command block or from the chat.The problem is that the second command should only return stands with rotation:
{0.0f,0.0f}. If you want to ignore rotation, simply use /testfor @e [type=ArmorStand] .
There is a bug where using the /testfor armor_stand command with a specified NBT Rotation value of
{0.0f, 0.0f} returns all armor_stands, regardless of rotation. Using a Rotation value other than {0.0f, 0.0f}works as expected. This happens when your command is run in a command block or from the chat.
This command returns only armor stands with the specified rotation:
{Rotation:[45.0f,0.0f]}
/testfor @e[type=ArmorStand]This command returns all armor stands, regardless of rotation.
{Rotation:[0.0f,0.0f]}
/testfor @e[type=ArmorStand]To reproduce, place stand with 45 degree rotation, and place a stand with 0 degree rotation. Run the two commands above. The first will give one result, the second will return two results.
There is a bug where using the /testfor
{0.0f, 0.0f} returns allarmor_stand command with a specified NBT Rotation value ofarmor_stands, regardless of rotation. Using a Rotation value other than {0.0f, 0.0f}works as expected. This happens when your command is run in a command block or from the chat.
This command returns only armor stands with the specified rotation:
{Rotation:[45.0f,0.0f]}
/testfor @e[type=ArmorStand]This command returns all armor stands, regardless of rotation.
{Rotation:[0.0f,0.0f]}
/testfor @e[type=ArmorStand]To reproduce, place stand with 45 degree rotation, and place a stand with 0 degree rotation. Run the two commands above. The first will give one result, the second will return two results.
There is a bug where using the /testfor ArmorStand command with a specified NBT Rotation value of
{0.0f, 0.0f} returns all Armor Stands, regardless of rotation. Using a Rotation value other than {0.0f, 0.0f}works as expected. This happens when your command is run in a command block or from the chat. I haven't tested this with anything other than armor stands.
This command returns only armor stands with the specified rotation:
{Rotation:[45.0f,0.0f]}
/testfor @e[type=ArmorStand]This command returns all armor stands, regardless of rotation.
{Rotation:[0.0f,0.0f]}
/testfor @e[type=ArmorStand]To reproduce, place stand with 45 degree rotation, and place a stand with 0 degree rotation. Run the two commands above. The first will give one result, the second will return two results.
Armor Stand and /testfor with NBT Rotation,too many results when using 0.0f, 0.0fArmor Stand and /testfor with NBT Rotation gives too many results when using 0.0f, 0.0f
Armor Stand and /testfor with NBT Rotation gives too many results when using 0.0f, 0.0fNBT list comparison tests if item in list, but ignores position
There is a bug where using the /testfor ArmorStand command with a specified NBT Rotation value of
{0.0f, 0.0f} returns all Armor Stands, regardless of rotation. Using a Rotation value other than {0.0f, 0.0f}works as expected. This happens when your command is run in a command block or from the chat. I haven't tested this with anything other than armor stands.
This command returns only armor stands with the specified rotation:
{Rotation:[45.0f,0.0f]}
/testfor @e[type=ArmorStand]This command returns all armor stands, regardless of rotation.
/testfor @e[type=ArmorStand]{Rotation:[0.0f,0.0f]}To reproduce, place stand with 45 degree rotation, and place a stand with 0 degree rotation. Run the two commands above. The first will give one result, the second will return two results.
The NBT list comparison (like it is used for the /testfor or /scoreboard command only tests if an item is in the list, but ignores the position.
Example:
Test command/summon Item ~2 ~ ~ {Item:{id:stone,Count:1,tag:{display:{Lore:[A,B,C]}}}}Comparison commands/testfor @e[type=Item,c=1] {Item:{tag:{display:{Lore:[A]}}}} (works as "A" is in "Lore") /testfor @e[type=Item,c=1] {Item:{tag:{display:{Lore:[A,C,B]}}}} (works as "A", "C" and "B" are in "Lore") /testfor @e[type=Item,c=1] {Item:{tag:{display:{Lore:[A,B,C,D]}}}} (doesn't work as "D" is not in "Lore")This is mostly problematic when testing for numbers like for example:
/testfor @e {Motion:[0d,0d,0d]}as this would return true if 0d is in "Motion", that means however that the other two numbers in "Motion" can be anything.
Note: Maybe this is the intended feature, if so it would be appreciated if the developers find a way to make direct comparison possible (maybe by saying if a list contains the same amount of items as the to-compare list, then try comparing it directly).
Original description:
There is a bug where using the /testfor ArmorStand command with a specified NBT Rotation value of
{0.0f, 0.0f} returns all Armor Stands, regardless of rotation. Using a Rotation value other than {0.0f, 0.0f}works as expected. This happens when your command is run in a command block or from the chat. I haven't tested this with anything other than armor stands.
This command returns only armor stands with the specified rotation:
/testfor @e[type=ArmorStand] {Rotation:[45.0f,0.0f]}This command returns all armor stands, regardless of rotation.
/testfor @e[type=ArmorStand] {Rotation:[0.0f,0.0f]}To reproduce, place stand with 45 degree rotation, and place a stand with 0 degree rotation. Run the two commands above. The first will give one result, the second will return two results.
is duplicated by
Confirmed for
- 1.8.6
Update reportTitle
Please change the title to:
NBT list comparison tests if item in list, but ignores position
(Or something similar)
Description
Please change the description to:
The NBT list comparison (like it is used for the /testfor or /scoreboard command only tests if an item is in the list, but ignores the position.
Example:
Test command/summon Item ~2 ~ ~ {Item:{id:stone,Count:1,tag:{display:{Lore:[A,B,C]}}}}Comparison commands/testfor @e[type=Item,c=1] {Item:{tag:{display:{Lore:[A]}}}} (works as "A" is in "Lore") /testfor @e[type=Item,c=1] {Item:{tag:{display:{Lore:[A,C,B]}}}} (works as "A", "C" and "B" are in "Lore") /testfor @e[type=Item,c=1] {Item:{tag:{display:{Lore:[A,B,C,D]}}}} (doesn't work as "D" is not in "Lore")This is mostly problematic when testing for numbers like for example:
/testfor @e {Motion:[0d,0d,0d]}as this would return true if 0d is in "Motion", that means however that the other two numbers in "Motion" can be anything.
Note: Maybe this is the intended feature, if so it would be appreciated if the developers find a way to make direct comparison possible (maybe by saying if a list contains the same amount of items as the to-compare list, then try comparing it directly).
Note: I tried these colors of the panel because they are the bug tracker colors. If you (the mods and developers) disapprove that, I will stop it.
is duplicated by
is duplicated by
Java 1.7.0_71 32bit
Windows 7
No mods installed
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
relates to
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
![[Helper] Jack McKalling](../../../data/avatars/users/92859.png){kind=small}
Java 1.7.0_71 32bit
Windows 7
is duplicated by
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
is duplicated by
The NBT list comparison (like it is used for the /testfor or /scoreboard command only tests if an item is in the list, but ignores the position.
Example:
Test command/summon Item ~2 ~ ~ {Item:{id:stone,Count:1,tag:{display:{Lore:[A,B,C]}}}}Comparison commands/testfor@e[type=Item,c=1]{Item:{tag:{display:{Lore:[A]}}}} (works as "A" is in "Lore") /testfor@e[type=Item,c=1]{Item:{tag:{display:{Lore:[A,C,B]}}}} (works as "A", "C" and "B" are in "Lore") /testfor@e[type=Item,c=1]{Item:{tag:{display:{Lore:[A,B,C,D]}}}} (doesn't work as "D" is not in "Lore")This is mostly problematic when testing for numbers like for example:
/testfor @e {Motion:[0d,0d,0d]}as this would return true if 0d is in "Motion", that means however that the other two numbers in "Motion" can be anything.
Note: Maybe this is the intended feature, if so it would be appreciated if the developers find a way to make direct comparison possible (maybe by saying if a list contains the same amount of items as the to-compare list, then try comparing it directly).
Original description:
There is a bug where using the /testfor ArmorStand command with a specified NBT Rotation value of
{0.0f, 0.0f} returns all Armor Stands, regardless of rotation. Using a Rotation value other than {0.0f, 0.0f}works as expected. This happens when your command is run in a command block or from the chat. I haven't tested this with anything other than armor stands.
This command returns only armor stands with the specified rotation:
/testfor @e[type=ArmorStand] {Rotation:[45.0f,0.0f]}This command returns all armor stands, regardless of rotation.
/testfor @e[type=ArmorStand] {Rotation:[0.0f,0.0f]}To reproduce, place stand with 45 degree rotation, and place a stand with 0 degree rotation. Run the two commands above. The first will give one result, the second will return two results.
The NBT list comparison (like it is used for the /testfor or /scoreboard command only tests if an item is in the list, but ignores the position.
Example:
Test command/summon Item ~2 ~ ~ {Item:{id:stone,Count:1,tag:{display:{Lore:[A,B,C]}}}}Comparison commands/execute if entity @e[type=Item,limit=1,nbt={Item:{tag:{display:{Lore:[A]}}}}] run say test (works as "A" is in "Lore") /execute if entity @e[type=Item,limit=1,nbt={Item:{tag:{display:{Lore:[A,C,B]}}}}] run say test (works as "A", "C" and "B" are in "Lore") /execute if entity @e[type=Item,limit=1,nbt={Item:{tag:{display:{Lore:[A,C,B,D]}}}}] run say test (doesn't work as "D" is not in "Lore")This is mostly problematic when testing for numbers like for example:
/execute if entity @s[nbt={Motion:[0d,0d,0d]}] run say testas this would return true if 0d is in "Motion", that means however that the other two numbers in "Motion" can be anything.
Note: Maybe this is the intended feature, if so it would be appreciated if the developers find a way to make direct comparison possible (maybe by saying if a list contains the same amount of items as the to-compare list, then try comparing it directly).
Original description:
There is a bug where using the /testfor ArmorStand command with a specified NBT Rotation value of
{0.0f, 0.0f} returns all Armor Stands, regardless of rotation. Using a Rotation value other than {0.0f, 0.0f}works as expected. This happens when your command is run in a command block or from the chat. I haven't tested this with anything other than armor stands.
This command returns only armor stands with the specified rotation:
/testfor @e[type=ArmorStand] {Rotation:[45.0f,0.0f]}This command returns all armor stands, regardless of rotation.
/testfor @e[type=ArmorStand] {Rotation:[0.0f,0.0f]}To reproduce, place stand with 45 degree rotation, and place a stand with 0 degree rotation. Run the two commands above. The first will give one result, the second will return two results.
The NBT list comparison (like it is used for the /testfor or /scoreboard command only tests if an item is in the list, but ignores the position.
Example:
Test command/summonItem ~2 ~ ~ {Item:{id:stone,Count:1,tag:{display:{Lore:[A,B,C]}}}}Comparison commands/execute if entity @e[type=Item,limit=1,nbt={Item:{tag:{display:{Lore:[A]}}}}] run say test (works as "A" is in "Lore") /execute if entity @e[type=Item,limit=1,nbt={Item:{tag:{display:{Lore:[A,C,B]}}}}] run say test (works as "A", "C" and "B" are in "Lore") /execute if entity @e[type=Item,limit=1,nbt={Item:{tag:{display:{Lore:[A,C,B,D]}}}}] run say test (doesn't work as "D" is not in "Lore")This is mostly problematic when testing for numbers like for example:
/execute if entity @s[nbt={Motion:[0d,0d,0d]}] run say testas this would return true if 0d is in "Motion", that means however that the other two numbers in "Motion" can be anything.
Note: Maybe this is the intended feature, if so it would be appreciated if the developers find a way to make direct comparison possible (maybe by saying if a list contains the same amount of items as the to-compare list, then try comparing it directly).
Original description:
There is a bug where using the /testfor ArmorStand command with a specified NBT Rotation value of
{0.0f, 0.0f} returns all Armor Stands, regardless of rotation. Using a Rotation value other than {0.0f, 0.0f}works as expected. This happens when your command is run in a command block or from the chat. I haven't tested this with anything other than armor stands.
This command returns only armor stands with the specified rotation:
/testfor @e[type=ArmorStand] {Rotation:[45.0f,0.0f]}This command returns all armor stands, regardless of rotation.
/testfor @e[type=ArmorStand] {Rotation:[0.0f,0.0f]}To reproduce, place stand with 45 degree rotation, and place a stand with 0 degree rotation. Run the two commands above. The first will give one result, the second will return two results.
The NBT list comparison (like it is used for the /testfor or /scoreboard command only tests if an item is in the list, but ignores the position.
Example:
Test command/summon item ~2 ~ ~ {Item:{id:stone,Count:1,tag:{display:{Lore:[A,B,C]}}}}Comparison commands/execute if entity @e[type=item,limit=1,nbt={Item:{tag:{display:{Lore:[A]}}}}] run say test (works as "A" is in "Lore") /execute if entity @e[type=item,limit=1,nbt={Item:{tag:{display:{Lore:[A,C,B]}}}}] run say test (works as "A", "C" and "B" are in "Lore") /execute if entity @e[type=item,limit=1,nbt={Item:{tag:{display:{Lore:[A,C,B,D]}}}}] run say test (doesn't work as "D" is not in "Lore")This is mostly problematic when testing for numbers like for example:
/execute if entity @s[nbt={Motion:[0d,0d,0d]}] run say testas this would return true if 0d is in "Motion", that means however that the other two numbers in "Motion" can be anything.
Note: Maybe this is the intended feature, if so it would be appreciated if the developers find a way to make direct comparison possible (maybe by saying if a list contains the same amount of items as the to-compare list, then try comparing it directly).
Original description:
There is a bug where using the /testfor ArmorStand command with a specified NBT Rotation value of
{0.0f, 0.0f} returns all Armor Stands, regardless of rotation. Using a Rotation value other than {0.0f, 0.0f}works as expected. This happens when your command is run in a command block or from the chat. I haven't tested this with anything other than armor stands.
This command returns only armor stands with the specified rotation:
/testfor @e[type=ArmorStand] {Rotation:[45.0f,0.0f]}This command returns all armor stands, regardless of rotation.
/testfor @e[type=ArmorStand] {Rotation:[0.0f,0.0f]}To reproduce, place stand with 45 degree rotation, and place a stand with 0 degree rotation. Run the two commands above. The first will give one result, the second will return two results.
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
is duplicated by
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
Can confirm in 1.20.4 with this command (replace Funzen with the desired entity selector)
execute store result score Funzen speed run data get entity Funzen Motion[0] 100
is duplicated by
Duplicate of MC-73887
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
The Rotation tag represents an angle, in degrees, not angular velocity. What you're experiencing may be MC-73887, but it's hard to tell, since you haven't provided a description of a bug, or proper reproduction steps. We need three things:
- What are the exact steps we should take to observe the bug?
- When you perform those steps, what is the result?
- What did you expect to happen when you performed those steps?
Unless you can check off those three requirements, then you haven't actually provided us with a useful bug report. If we can't watch it happen, and don't know what to look for, then there's no way to identify the cause or the solution. Everything we've tried works as we expect it to, so either your expectations are wrong, or we're not trying the right things. There's no way for us to tell given the information you've provided.
Order of arguments and pair names being ignored is MC-73887.
Duplicates MC-73887
Duplicates MC-73887
Thank you for your report!
We're tracking this issue in MC-73887, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automagically! Please report any issues in Discord or Reddit
Thank you for your report!
We're tracking this issue in MC-73887, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automagically! Please report any issues in Discord or Reddit
This is a duplicate of MC-73887; the list checking ignores position, providing the same value multiple times has no effect, it sees all armor stands face the horizon (not up/down) that's why they're all found.
As a fix for your system, use y_rotation and x_rotation in the selector instead.
Thank you for your report!
We're tracking this issue in MC-73887, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
This is a misunderstanding. NBT list checks only check that each value exists in the list, so you are checking for 0 on any axis redundantly 3 times. See MC-73887
confirmed in 1.8-pre4.
It seems like testing for a rotation of [0.0f,0.0f] on armor stands defaults to testing for the base plate rotation, which I'm assuming is always [0.0f,0.0f].
That might explain why it outputs a signal for any armor stand, regardless of rotation.
I made a suggestion which might solve this problem: http://www.reddit.com/r/minecraftsuggestions/comments/38tipq/better_nbt_comparison/
If you use the entitydata command, it shows that the Motion and Rotation tag lists have numerical position indicators, for example
However, using them in a testfor command doesn't make any difference in whether or not it detects the entity. Zero values also seem to match any entity.
Confirmed for 17w50a with
/execute if entity @s[nbt={Motion:[0d,0d,0d]}] run say testConfirmed in 18w06a, using updated commands.
Relates to/ duplicated by
MC-124532.