I ran the following execute command (/execute as @e[type=armor_stand,nbt={Rotation:[0.0f,0.0f]}] run say hello) in a world where there was only one armorstand and its rotation was [180.0f,0.0f] and the command still executed successfully. However, when I changed the command a little bit (/execute as @e[type=armor_stand,nbt={Rotation:[10.0f,0.0f]}] run say hello), it didn't execute anymore. (If you didn't notice, I changed the rotation value.) So I guess minecraft interprets the rotation value of [0.0f,0.0f] as default and didn't take it into account when executing commands. Is there anything you can do about this or do I just have to change my commands a little bit?
Linked issues
Comments 5
Oh, there's still one little problem, I cant use the exclamation mark ⚠️ with x_rotation selector argument. Is this a bug or just the way the game works?
Even though x_rotation and y_rotation should be used, this still seems like bugged behavior, since the format of the Rotation nbt is: Rotation:[<y_rotation>f,<x_rotation>f]. The bug is that using nbt={Rotation:[]} sees Rotation as a list of various float values and not as two float values representing y_rotation and x_rotation repectively. Can you provide the documentation that states this behavior is intended? At the very least the Rotation nbt argument in selectors should be searching for no more than 2 values, since using 3 or more distinct values will always fail, and using repeat values serves no purpose. Here are examples that display how the list checking works:
/execute as @e[type=armor_stand,nbt={Rotation:[<value>f,<value>f, ... , <value>f]}] run say helloand
/execute as @e[type=armor_stand,nbt={Rotation:[<value>f]}] run say hello, where <value> is the same value in each case.
will execute at entities with a rotation of any combination in these forms: Rotation:[<-180.0 to 179.9>f,<value>f] and Rotation:[<value>f,<-90.0 to 90.0>f]
/execute as @e[type=armor_stand,nbt={Rotation:[<value 1>f,<value 2>f]}] run say hello, where value 1 != value 2 (applies to wrapping as well),
will execute at entities with a rotation of any combination in these forms: Rotation:[<value 1>f,<value 2>f] and Rotation:[<value 2>f,<value 1>f]
/execute as @e[type=armor_stand,nbt={Rotation:[<value 1>f,<value 2>f,<value 3>f]}] run say hello, where value 1, value 2, and value 3 are all unique (applies to wrapping as well), is guaranteed to fail every time, since the Rotation nbt can have at most 2 unique values, and the list checking only accepts those 2 values.
The issue should be reopened for the reason that the nbt format should take priority over the list checking, while it currently does not. What is expected is that the nbt={Rotation:[<y_rot>f,<x_rot>f]} argument will only search for an entity with that exact rotation, but instead the unexpected, undesirable behavior listed above occurs. Since the nbt argument was added recently, and (as far as I know) no documentation has been added to describe how it should behave (again, if there is any, please provide a link), this issue cannot be resolved as invalid until the developers explicitly provide proof that it is invalid.
NBT list checking works as follows: if every value in your list is also in the entity's list, it succeeds. So let's take a look at your two commands:
First the game looks at the first value –
0. The armor stand's rotation is[0, 180]. Does that list contain a zero? It does. The game looks at the second value – it's another0. Does the armor stand list contain a zero? It does. The command succeeds.First the game looks at the first value –
10. Does the armor stand list contain a ten? It does not, so the command fails.Ultimately you should be using
x_rotationandy_rotationselector arguments here.