MC-78006Closest entity selector doesn't always find itself.
If you use a selector that searches for the nearest entity (@p, @e[c=1], etc), it will always find the entity executing the command (if possible), even if there is another equally close entity. Essentially, entities are always closer to themselves than to any other entity, regardless of actual location. This is extremely useful, and is not a bug. However, this behavior only occurs when specifically searching for the one closest entity. If you search for the 2 closest entities, or the farthest entity, this property will not be taken into account.
To reproduce, execute these commands:
/summon minecraft:armor_stand ~ ~ ~ {Tags:["test1"]}
/execute as @e[tag=test1] at @s run summon minecraft:armor_stand ~ ~ ~ {Tags:["test2"]}
/execute as @e[tag=test1] at @s run summon minecraft:armor_stand ~ ~ ~ {Tags:["test3"]}
/execute as @e[tag=test3] at @s run tag @e[limit=2,sort=nearest] list
Or these
/summon armor_stand ~ ~ ~ {CustomName:"test1",NoGravity:1b}
/execute @e[name=test1] ~ ~ ~ /summon armor_stand ~ ~ ~ {CustomName:"test2",NoGravity:1b}
/execute @e[name=test1] ~ ~ ~ /summon armor_stand ~ ~ ~ {CustomName:"test3",NoGravity:1b}
/execute @e[name=test3] ~ ~ ~ /say @e[c=2]
The last command will find "test1" and "test2", while you executed it from "test3"
Code analysis by Marcono1234 can be found in this comment
Linked Issues
Attachments1
![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
Created Issue:
Closest entity selector doesn't always find itself.
If you use a selector that searches for the nearest entity (@p, @e[c=1], etc), it will always find the entity executing the command, even if there is another equally close entity. Essentially, entities are always closer to themselves than to any other entity, regardless of actual location. This is extremely useful, and is not a bug. However, this behavior only occurs when specifically searching for the one closest entity. If you search for the 2 closest entities, or the farthest entity, this property will not be taken into account.
Environment
Operating system: OSX 10.9.5
Java Version: 1.6.0_65
If you use a selector that searches for the nearest entity (@p, @e [c=1] , etc), it will always find the entity executing the command (if possible), even if there is another equally close entity. Essentially, entities are always closer to themselves than to any other entity, regardless of actual location. This is extremely useful, and is not a bug. However, this behavior only occurs when specifically searching for the one closest entity. If you search for the 2 closest entities, or the farthest entity, this property will not be taken into account.
relates to
relates to
relates to
two entities.png
Confirmed for 16w07b
Steps to reproduce
- Summon every armorstand in the middle of the blocks as shown in the pictures "two entities.png" and "four entities.png" in +X+Z direction
- Stand on each wool block in the corners between iron blocks and type in chat
/say @e[c=2].
- If you stand on yellow or red wool you will see
[YourNick] YourNick and Armorstandwhich is intended
- On orange wool
[YourNick] Armorstand and YourNick- On blue wool:
- If you stand in the corner next to the yellow wool
[YourNick] YourNick and Armorstand(intended)
- Next to the orange or red wool
[YourNick] Armorstand and Armorstand
If you use a selector that searches for the nearest entity (@p, @e [c=1] , etc), it will always find the entity executing the command (if possible), even if there is another equally close entity. Essentially, entities are always closer to themselves than to any other entity, regardless of actual location. This is extremely useful, and is not a bug. However, this behavior only occurs when specifically searching for the one closest entity. If you search for the 2 closest entities, or the farthest entity, this property will not be taken into account.
Steps to reproduce:
- {}
- {}
- {}
- {}
If you use a selector that searches for the nearest entity (@p, @e[c=1], etc), it will always find the entity executing the command (if possible), even if there is another equally close entity. Essentially, entities are always closer to themselves than to any other entity, regardless of actual location. This is extremely useful, and is not a bug. However, this behavior only occurs when specifically searching for the one closest entity. If you search for the 2 closest entities, or the farthest entity, this property will not be taken into account.
Steps to reproduce:
- {}
- {}
- {}
- {}
If you use a selector that searches for the nearest entity (@p, @e[c=1], etc), it will always find the entity executing the command (if possible), even if there is another equally close entity. Essentially, entities are always closer to themselves than to any other entity, regardless of actual location. This is extremely useful, and is not a bug. However, this behavior only occurs when specifically searching for the one closest entity. If you search for the 2 closest entities, or the farthest entity, this property will not be taken into account.
To reproduce, execute these commands:
/summon minecraft:armor_stand ~ ~ ~ {Tags:["test1"]} /summon minecraft:armor_stand ~ ~ ~ {Tags:["test2"]} /summon minecraft:armor_stand ~ ~ ~ {Tags:["test3"]} /execute @e[tag=test3] ~ ~ ~ /scoreboard players tag @e[c=2] listThe last command will find "test1" and "test2", while you executed it from "test3"
If you use a selector that searches for the nearest entity (@p, @e[c=1], etc), it will always find the entity executing the command (if possible), even if there is another equally close entity. Essentially, entities are always closer to themselves than to any other entity, regardless of actual location. This is extremely useful, and is not a bug. However, this behavior only occurs when specifically searching for the one closest entity. If you search for the 2 closest entities, or the farthest entity, this property will not be taken into account.
To reproduce, execute these commands:
/summon minecraft:armor_stand ~ ~ ~ {Tags:["test1"]} /execute @e[tag=test1] ~ ~ ~ /summon minecraft:armor_stand ~ ~ ~ {Tags:["test2"]} /execute @e[tag=test1] ~ ~ ~ /summon minecraft:armor_stand ~ ~ ~ {Tags:["test3"]} /execute @e[tag=test3] ~ ~ ~ /scoreboard players tag @e[c=2] listOr these
/summon armor_stand ~ ~ ~ {CustomName:"test1",NoGravity:1b} /execute @e[name=test1] ~ ~ ~ /summon armor_stand ~ ~ ~ {CustomName:"test2",NoGravity:1b} /execute @e[name=test1] ~ ~ ~ /summon armor_stand ~ ~ ~ {CustomName:"test3",NoGravity:1b} /execute @e[name=test3] ~ ~ ~ /say @e[c=2]The last command will find "test1" and "test2", while you executed it from "test3"
If you use a selector that searches for the nearest entity (@p, @e[c=1], etc), it will always find the entity executing the command (if possible), even if there is another equally close entity. Essentially, entities are always closer to themselves than to any other entity, regardless of actual location. This is extremely useful, and is not a bug. However, this behavior only occurs when specifically searching for the one closest entity. If you search for the 2 closest entities, or the farthest entity, this property will not be taken into account.
To reproduce, execute these commands:
/summon minecraft:armor_stand ~ ~ ~ {Tags:["test1"]} /execute @e[tag=test1] ~ ~ ~ /summon minecraft:armor_stand ~ ~ ~ {Tags:["test2"]} /execute @e[tag=test1] ~ ~ ~ /summon minecraft:armor_stand ~ ~ ~ {Tags:["test3"]} /execute @e[tag=test3] ~ ~ ~ /scoreboard players tag @e[c=2] listOr these
/summon armor_stand ~ ~ ~ {CustomName:"test1",NoGravity:1b} /execute @e[name=test1] ~ ~ ~ /summon armor_stand ~ ~ ~ {CustomName:"test2",NoGravity:1b} /execute @e[name=test1] ~ ~ ~ /summon armor_stand ~ ~ ~ {CustomName:"test3",NoGravity:1b} /execute @e[name=test3] ~ ~ ~ /say @e[c=2]The last command will find "test1" and "test2", while you executed it from "test3"
Code analysis by Marcono1234 can be found in this comment
![[Mod] Skylinerw](../../../data/assets/gravatar/skylinerw.png){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
If you use a selector that searches for the nearest entity (@p, @e[c=1], etc), it will always find the entity executing the command (if possible), even if there is another equally close entity. Essentially, entities are always closer to themselves than to any other entity, regardless of actual location. This is extremely useful, and is not a bug. However, this behavior only occurs when specifically searching for the one closest entity. If you search for the 2 closest entities, or the farthest entity, this property will not be taken into account.
To reproduce, execute these commands:
/summon minecraft:armor_stand ~ ~ ~ {Tags:["test1"]} /execute @e[tag=test1]~ ~ ~ /summon minecraft:armor_stand ~ ~ ~ {Tags:["test2"]} /execute @e[tag=test1]~ ~ ~ /summon minecraft:armor_stand ~ ~ ~ {Tags:["test3"]} /execute @e[tag=test3]~ ~ ~ /scoreboard playerstag @e[c=2] listOr these
/summon armor_stand ~ ~ ~ {CustomName:"test1",NoGravity:1b} /execute @e[name=test1] ~ ~ ~ /summon armor_stand ~ ~ ~ {CustomName:"test2",NoGravity:1b} /execute @e[name=test1] ~ ~ ~ /summon armor_stand ~ ~ ~ {CustomName:"test3",NoGravity:1b} /execute @e[name=test3] ~ ~ ~ /say @e[c=2]The last command will find "test1" and "test2", while you executed it from "test3"
Code analysis by Marcono1234 can be found in this comment
If you use a selector that searches for the nearest entity (@p, @e[c=1], etc), it will always find the entity executing the command (if possible), even if there is another equally close entity. Essentially, entities are always closer to themselves than to any other entity, regardless of actual location. This is extremely useful, and is not a bug. However, this behavior only occurs when specifically searching for the one closest entity. If you search for the 2 closest entities, or the farthest entity, this property will not be taken into account.
To reproduce, execute these commands:
/summon minecraft:armor_stand ~ ~ ~ {Tags:["test1"]} /execute as @e[tag=test1] at @s run summon minecraft:armor_stand ~ ~ ~ {Tags:["test2"]} /execute as @e[tag=test1] at @s run summon minecraft:armor_stand ~ ~ ~ {Tags:["test3"]} /execute as @e[tag=test3] at @s run tag @e[limit=2] listOr these
/summon armor_stand ~ ~ ~ {CustomName:"test1",NoGravity:1b} /execute @e[name=test1] ~ ~ ~ /summon armor_stand ~ ~ ~ {CustomName:"test2",NoGravity:1b} /execute @e[name=test1] ~ ~ ~ /summon armor_stand ~ ~ ~ {CustomName:"test3",NoGravity:1b} /execute @e[name=test3] ~ ~ ~ /say @e[c=2]The last command will find "test1" and "test2", while you executed it from "test3"
Code analysis by Marcono1234 can be found in this comment
If you use a selector that searches for the nearest entity (@p, @e[c=1], etc), it will always find the entity executing the command (if possible), even if there is another equally close entity. Essentially, entities are always closer to themselves than to any other entity, regardless of actual location. This is extremely useful, and is not a bug. However, this behavior only occurs when specifically searching for the one closest entity. If you search for the 2 closest entities, or the farthest entity, this property will not be taken into account.
To reproduce, execute these commands:
/summon minecraft:armor_stand ~ ~ ~ {Tags:["test1"]} /execute as @e[tag=test1] at @s run summon minecraft:armor_stand ~ ~ ~ {Tags:["test2"]} /execute as @e[tag=test1] at @s run summon minecraft:armor_stand ~ ~ ~ {Tags:["test3"]} /execute as @e[tag=test3] at @s run tag @e[limit=2,sort=nearest] listOr these
/summon armor_stand ~ ~ ~ {CustomName:"test1",NoGravity:1b} /execute @e[name=test1] ~ ~ ~ /summon armor_stand ~ ~ ~ {CustomName:"test2",NoGravity:1b} /execute @e[name=test1] ~ ~ ~ /summon armor_stand ~ ~ ~ {CustomName:"test3",NoGravity:1b} /execute @e[name=test3] ~ ~ ~ /say @e[c=2]The last command will find "test1" and "test2", while you executed it from "test3"
Code analysis by Marcono1234 can be found in this comment
![[Helper] Jack McKalling](../../../data/avatars/users/92859.png){kind=small}
Operating system: OSX 10.9.5
Java Version: 1.6.0_65
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
Confirmed in 1.9.1-pre3. I want to clarify that the c=1 behavior of entities always "being closest to themselves" is not a bug. That feature is simply causing some related bugs. See MC-78006 for more information.
To clear up what's going on, which is consistent across all commands:
There is a single object containing all information about what is executing the command (I'll refer to it as the "executor"), which is used no matter what the context is for command execution (player-executed, command-block-executed, sign-executed, /execute-executed). Included in that set of data is a "sender", an "origin", a "permission level", a "CommandStats target", and a "display name" (among other things).
- The sender will be set to that of the clicking player. Sender bias always targets the sender if, after a selector is processed, the sender is still in the list of possible targets and c is set to 1 (or the selector can only obtain 1 target by default), which is the case for @p and @a[c=1]. It does not take into consideration if the origin doesn't match up (
MC-80893). - The origin will be set to that of the sign that was clicked, which is why /setblock and /teleport behave in that manner (see
MC-62255). Anything that deals with XYZ origins will be dealing with the sign's origin. This allows modifying the clicked sign without knowing where the sign is, and /execute can otherwise be used to change the origin to that of the clicker (by using sender bias described above). Selectors use that origin, which is why the @a[c=2] and @e[c=2] selectors obtain targets starting at the sign (and technically @a[c=1] does too, but see MC-78006 as to why the sender isn't targeted for the other selectors). - The permission level is set to same value as command blocks, which is why a player clicking does not require OP status to execute the command.
- The receiver of CommandStats data is set to the sign. This is necessary in order for signs to make use of its CommandStats. The clicking player will not have their CommandStats triggered, so /execute is necessary to do so (which makes use of sender bias to always target the clicking player).
- The display name is set to that of the clicking player, which is where /say gets the display name from.
There are no exceptions for a command being run. The interaction with the executor does not explicitly change if it's a sign versus a command block, player, etc. All that changes is what the data is stored in the "executor" object.
Confirmed for
Relates to:
MC-79103Now it's a dupe ofMC-95352@SunCat That report details issues concerning directional bias, while this report covers the lack of sender bias if an entity has the potential to target itself.
For example, if you summoned 3 armor stands at the exact same location (thus disregarding directional bias) and cause the newest one of them to say the name of the closest two, it will not say its own name and will instead say the name of the two oldest armor stands.
The following commands might make it easier to reproduce since they don't require a scoreboard setup:
/summon armor_stand ~ ~ ~ {CustomName:"test1",NoGravity:1b} /execute @e[name=test1] ~ ~ ~ /summon armor_stand ~ ~ ~ {CustomName:"test2",NoGravity:1b} /execute @e[name=test1] ~ ~ ~ /summon armor_stand ~ ~ ~ {CustomName:"test3",NoGravity:1b} /execute @e[name=test3] ~ ~ ~ /say @e[c=2]Please link to this comment in the description
The following is based on a decompiled version of Minecraft 1.10 using MCP 9.30.
This could be solved by removing the sender entity from the list of the matching entities if it is contained and inserting it at the index 0. This way even if the distance comparison returns 0 it will be still the first entity in the list.
Confirmed and changed the first set of repro steps to current command syntax.
Can reproduce in 1.20.2/23w41a:
