Sizelimited entity selectors (@e with c=1,@r with type=!entity) in commands prefer players
The problem:
The argument "c" in selectors (e.g. "@e[c=1]") is supposed to limit the amount of entities targeted by the selector to the x closest (for c=x) or x furthest (for c=-x) entities, sorted by their distance. However, when used inside a scoreboard command (e.g. "scoreboard players set @e[c=1,r=10] something 0") the selector will first "fill" the available slots with all players that match the remaining criteria, regardless of their distance (compared to other matching entities). When the limit was not reached with player entities alone, other entities will be processed like expected (based on their distance that is).
How to reproduce:
Start by creating an objective
/scoreboard objectives add demo dummy
and set up the sidebar so you can see it
/scoreboard objectives setdisplay sidebar demo
Now just place a command block down and put in a command like
/scoreboard players add @e[c=1,r=3] demo 1
Finally, place down an entity (i recommend an Armor stand) next to the command block.
When you activate the cmd block outside the range (in my example 3), the entity will get a new score. As soon as you are near enough (again, 3 blocks in my example), you will be targeted instead, even if the entity you use is standing between you and the cmd block (which makes it clearly the closer one).
Affects:
- Most /scoreboard commands (excluding /scoreboard teams <join|leave> and /scoreboard players tag <target> <add|remove>).
- The name shown in green from the results of /scoreboard players tag <target> <list> (though the list of tags shown in white is from the correct target).
- The stored selector for CommandStats.
Also note [Mod] Skylinerw's comment and code analysis.
Linked Issues
is duplicated by7
MC-79103The c=1 argument does not behave correctly in a scoreboard command within an executeDuplicateMC-81152scoreboard command interacts wrong with executeDuplicateMC-96356Scoreboard command entity selector prefers playersDuplicateMC-101544Scoreboard Command With @e[c=x] Selector Always Selects Players FirstDuplicateMC-102262/stats entity set ... problemDuplicateMC-103690dubious execute/scoreboard/@e interactionDuplicateMC-112339'@r' target selector in scoreboard commands ignores "not equal to" arguments about entity typeDuplicate
Created Issue:
Sizelimited entityselectors (@e with c=...) in scoreboardcommands prefer players
The problem:
The argument "c" in selectors (e.g. "@e[c=1]") is supposed to limit the amount of entities targeted by the selector to the x closest (for c=x) or x furthest (for c=-x) entities, sorted by their distance. However, when used inside a scoreboardcommand (e.g. "scoreboard players set @e[c=1,r=10] something 0") the selector will first "fill" the available slots with all players that match the remaining criteria, regardless of their distance (compared to other matching entites). When the limit was not reached with player entities alone, other entities will be processed like expected (based on their distance that is).How to reproduce:
Start by creating an objective
/scoreboard objectives add demo dummy
and set up the sidebar so you can see it
/scoreboard objectives setdisplay sidebar demo
Now just place a commandblock down and put in a command like
/scoreboard players add @e[c=1,r=3] demo 1
Finally, place down an entity (i recommend an Armorstand) next to the commandblock.
When you activate the cmd block outside the range (in my example 3), the entity will get a new score. As soon as you are near enough (again, 3 blocks in my example), you will be targeted instead, even if the entity you use is standing between you and the cmd block (which makes it clearly the closer one).
is duplicated by
relates to
relates to
Sizelimited entityselectors (@e with c=...) inscoreboardcommands prefer players
Sizelimited entityselectors (@e with c=...) in commands prefer playersSizelimited entityselectors (@e with c=1) in commands prefer players
The problem:
The argument "c" in selectors (e.g. "@e[c=1]") is supposed to limit the amount of entities targeted by the selector to the x closest (for c=x) or x furthest (for c=-x) entities, sorted by their distance. However, when used inside a scoreboardcommand (e.g. "scoreboard players set @e[c=1,r=10] something 0") the selector will first "fill" the available slots with all players that match the remaining criteria, regardless of their distance (compared to other matching entites). When the limit was not reached with player entities alone, other entities will be processed like expected (based on their distance that is).How to reproduce:
Start by creating an objective
/scoreboard objectives add demo dummy
and set up the sidebar so you can see it
/scoreboard objectives setdisplay sidebar demo
Now just place a commandblock down and put in a command like
/scoreboard players add @e[c=1,r=3] demo 1
Finally, place down an entity (i recommend an Armorstand) next to the commandblock.
When you activate the cmd block outside the range (in my example 3), the entity will get a new score. As soon as you are near enough (again, 3 blocks in my example), you will be targeted instead, even if the entity you use is standing between you and the cmd block (which makes it clearly the closer one).
From
MC-80893:
When you use a command like/say @e[x=0,y=0,z=0,c=1]It will ignore x, y and z if you use c=1 (probably because the developers thought that the closest entity is always the one that runs the command) so it will return the entity that ran the command (if it has the other attributes given, like type or name, if not, it will target correctly the closest entity to the position).
How to reproduce:
- /tp 1000 60 1000
- /summon Pig 1010 60 1000 {NoAI:1}
- /say @e[x=1010,y=60,z=1,c=1,r=20]
It will say your name.
Whereas when you try this, it says the the name or UUID of the pig:
/say @e[x=1010,y=60,z=1,c=1,r=1]
Sizelimited entityselectors (@e with c=1) in commands prefer players / the entity running the command
is duplicated by
The problem:
The argument "c" in selectors (e.g. "@e[c=1]") is supposed to limit the amount of entities targeted by the selector to the x closest (for c=x) or x furthest (for c=-x) entities, sorted by their distance. However, when used inside a scoreboardcommand (e.g. "scoreboard players set @e[c=1,r=10] something 0") the selector will first "fill" the available slots with all players that match the remaining criteria, regardless of their distance (compared to other matching entites). When the limit was not reached with player entities alone, other entities will be processed like expected (based on their distance that is).How to reproduce:
Start by creating an objective
/scoreboard objectives add demo dummy
and set up the sidebar so you can see it
/scoreboard objectives setdisplay sidebar demo
Now just place a commandblock down and put in a command like
/scoreboard players add @e[c=1,r=3] demo 1
Finally, place down an entity (i recommend an Armorstand) next to the commandblock.
When you activate the cmd block outside the range (in my example 3), the entity will get a new score. As soon as you are near enough (again, 3 blocks in my example), you will be targeted instead, even if the entity you use is standing between you and the cmd block (which makes it clearly the closer one).
From
MC-80893:
When you use a command like/say @e[x=0,y=0,z=0,c=1]It will ignore x, y and z if you use c=1 (probably because the developers thought that the closest entity is always the one that runs the command) so it will return the entity that ran the command (if it has the other attributes given, like type or name, if not, it will target correctly the closest entity to the position).
How to reproduce:
- /tp 1000 60 1000
- /summon Pig 1010 60 1000 {NoAI:1}
- /say @e[x=1010,y=60,z=1,c=1,r=20]
It will say your name.
Whereas when you try this, it says the the name or UUID of the pig:
/say @e[x=1010,y=60,z=1,c=1,r=1]
Also note [Mod] Skylinerw's comment.
is duplicated by
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
is duplicated by
is duplicated by
![[Mod] Skylinerw](../../../data/assets/gravatar/skylinerw.png){kind=small}
The problem:
The argument "c" in selectors (e.g. "@e[c=1]") is supposed to limit the amount of entities targeted by the selector to the x closest (for c=x) or x furthest (for c=-x) entities, sorted by their distance. However, when used inside a scoreboardcommand (e.g. "scoreboard players set @e[c=1,r=10] something 0") the selector will first "fill" the available slots with all players that match the remaining criteria, regardless of their distance (compared to other matching entites). When the limit was not reached with player entities alone, other entities will be processed like expected (based on their distance that is).How to reproduce:
Start by creating an objective
/scoreboard objectives add demo dummy
and set up the sidebar so you can see it
/scoreboard objectives setdisplay sidebar demo
Now just place a commandblock down and put in a command like
/scoreboard players add @e[c=1,r=3] demo 1
Finally, place down an entity (i recommend an Armorstand) next to the commandblock.
When you activate the cmd block outside the range (in my example 3), the entity will get a new score. As soon as you are near enough (again, 3 blocks in my example), you will be targeted instead, even if the entity you use is standing between you and the cmd block (which makes it clearly the closer one).
From
MC-80893:
When you use a command like/say @e[x=0,y=0,z=0,c=1]It will ignore x, y and z if you use c=1 (probably because the developers thought that the closest entity is always the one that runs the command) so it will return the entity that ran the command (if it has the other attributes given, like type or name, if not, it will target correctly the closest entity to the position).
How to reproduce:
- /tp 1000 60 1000
- /summon Pig 1010 60 1000 {NoAI:1}
- /say @e[x=1010,y=60,z=1,c=1,r=20]
It will say your name.
Whereas when you try this, it says the the name or UUID of the pig:
/say @e[x=1010,y=60,z=1,c=1,r=1]
Also note [Mod] Skylinerw's comment.
The problem:
The argument "c" in selectors (e.g. "@e[c=1]") is supposed to limit the amount of entities targeted by the selector to the x closest (for c=x) or x furthest (for c=-x) entities, sorted by their distance. However, when used inside a scoreboardcommand (e.g. "scoreboard players set @e[c=1,r=10] something 0") the selector will first "fill" the available slots with all players that match the remaining criteria, regardless of their distance (compared to other matching entites). When the limit was not reached with player entities alone, other entities will be processed like expected (based on their distance that is).How to reproduce:
Start by creating an objective/scoreboard objectives add demo dummyand set up the sidebar so you can see it
/scoreboard objectives setdisplay sidebar demoNow just place a commandblock down and put in a command like
/scoreboard players add @e[c=1,r=3] demo 1Finally, place down an entity (i recommend an Armorstand) next to the commandblock.
When you activate the cmd block outside the range (in my example 3), the entity will get a new score. As soon as you are near enough (again, 3 blocks in my example), you will be targeted instead, even if the entity you use is standing between you and the cmd block (which makes it clearly the closer one).Affects:
- Most /scoreboard commands (excluding /scoreboard teams <join|leave> and /scoreboard players tag <target> <add|remove>).
- The name shown in green from the results of /scoreboard players tag <target> <list> (though the list of tags shown in white is from the correct target).
Also note [Mod] Skylinerw's comment.
The problem:
The argument "c" in selectors (e.g. "@e[c=1]") is supposed to limit the amount of entities targeted by the selector to the x closest (for c=x) or x furthest (for c=-x) entities, sorted by their distance. However, when used inside a scoreboardcommand (e.g. "scoreboard players set @e[c=1,r=10] something 0") the selector will first "fill" the available slots with all players that match the remaining criteria, regardless of their distance (compared to other matching entites). When the limit was not reached with player entities alone, other entities will be processed like expected (based on their distance that is).How to reproduce:
Start by creating an objective/scoreboard objectives add demo dummyand set up the sidebar so you can see it
/scoreboard objectives setdisplay sidebar demoNow just place a commandblock down and put in a command like
/scoreboard players add @e[c=1,r=3] demo 1Finally, place down an entity (i recommend an Armorstand) next to the commandblock.
When you activate the cmd block outside the range (in my example 3), the entity will get a new score. As soon as you are near enough (again, 3 blocks in my example), you will be targeted instead, even if the entity you use is standing between you and the cmd block (which makes it clearly the closer one).Affects:
- Most /scoreboard commands (excluding /scoreboard teams <join|leave> and /scoreboard players tag <target> <add|remove>).
- The name shown in green from the results of /scoreboard players tag <target> <list> (though the list of tags shown in white is from the correct target).
- The stored selector for CommandStats.
Also note [Mod] Skylinerw's comment.
Sizelimited entityselectors (@e with c=1) in commands prefer players/ the entity running the command
relates to
is duplicated by
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
The problem:
The argument "c" in selectors (e.g. "@e[c=1]") is supposed to limit the amount of entities targeted by the selector to the x closest (for c=x) or x furthest (for c=-x) entities, sorted by their distance. However, when used inside a scoreboardcommand (e.g. "scoreboard players set @e[c=1,r=10] something 0") the selector will first "fill" the available slots with all players that match the remaining criteria, regardless of their distance (compared to other matching entites). When the limit was not reached with player entities alone, other entities will be processed like expected (based on their distance that is).How to reproduce:
Start by creating an objective/scoreboard objectives add demo dummyand set up the sidebar so you can see it
/scoreboard objectives setdisplay sidebar demoNow just place a commandblock down and put in a command like
/scoreboard players add @e[c=1,r=3] demo 1Finally, place down an entity (i recommend an Armorstand) next to the commandblock.
When you activate the cmd block outside the range (in my example 3), the entity will get a new score. As soon as you are near enough (again, 3 blocks in my example), you will be targeted instead, even if the entity you use is standing between you and the cmd block (which makes it clearly the closer one).Affects:
- Most /scoreboard commands (excluding /scoreboard teams <join|leave> and /scoreboard players tag <target> <add|remove>).
- The name shown in green from the results of /scoreboard players tag <target> <list> (though the list of tags shown in white is from the correct target).
- The stored selector for CommandStats.
Also note [Mod] Skylinerw's comment.
Code analysis by Marcono1234 in this comment.
The problem:
The argument "c" in selectors (e.g. "@e[c=1]") is supposed to limit the amount of entities targeted by the selector to the x closest (for c=x) or x furthest (for c=-x) entities, sorted by their distance. However, when used inside a scoreboardcommand (e.g. "scoreboard players set @e[c=1,r=10] something 0") the selector will first "fill" the available slots with all players that match the remaining criteria, regardless of their distance (compared to other matching entites). When the limit was not reached with player entities alone, other entities will be processed like expected (based on their distance that is).How to reproduce:
Start by creating an objective/scoreboard objectives add demo dummyand set up the sidebar so you can see it
/scoreboard objectives setdisplay sidebar demoNow just place a commandblock down and put in a command like
/scoreboard players add @e[c=1,r=3] demo 1Finally, place down an entity (i recommend an Armorstand) next to the commandblock.
When you activate the cmd block outside the range (in my example 3), the entity will get a new score. As soon as you are near enough (again, 3 blocks in my example), you will be targeted instead, even if the entity you use is standing between you and the cmd block (which makes it clearly the closer one).Affects:
- Most /scoreboard commands (excluding /scoreboard teams <join|leave> and /scoreboard players tag <target> <add|remove>).
- The name shown in green from the results of /scoreboard players tag <target> <list> (though the list of tags shown in white is from the correct target).
- The stored selector for CommandStats.
Also note [Mod] Skylinerw's comment.
Code analysis by Marcono1234 in this comment.
The problem:
The argument "c" in selectors (e.g. "@e[c=1]") is supposed to limit the amount of entities targeted by the selector to the x closest (for c=x) or x furthest (for c=-x) entities, sorted by their distance. However, when used inside a scoreboardcommand (e.g. "scoreboard players set @e[c=1,r=10] something 0") the selector will first "fill" the available slots with all players that match the remaining criteria, regardless of their distance (compared to other matching entites). When the limit was not reached with player entities alone, other entities will be processed like expected (based on their distance that is).How to reproduce:
Start by creating an objective/scoreboard objectives add demo dummyand set up the sidebar so you can see it
/scoreboard objectives setdisplay sidebar demoNow just place a commandblock down and put in a command like
/scoreboard players add @e[c=1,r=3] demo 1Finally, place down an entity (i recommend an Armorstand) next to the commandblock.
When you activate the cmd block outside the range (in my example 3), the entity will get a new score. As soon as you are near enough (again, 3 blocks in my example), you will be targeted instead, even if the entity you use is standing between you and the cmd block (which makes it clearly the closer one).Affects:
- Most /scoreboard commands (excluding /scoreboard teams <join|leave> and /scoreboard players tag <target> <add|remove>).
- The name shown in green from the results of /scoreboard players tag <target> <list> (though the list of tags shown in white is from the correct target).
- The stored selector for CommandStats.
Also note [Mod] Skylinerw's comment
.The problem:
The argument "c" in selectors (e.g. "@e[c=1]") is supposed to limit the amount of entities targeted by the selector to the x closest (for c=x) or x furthest (for c=-x) entities, sorted by their distance. However, when used inside a scoreboardcommand (e.g. "scoreboard players set @e[c=1,r=10] something 0") the selector will first "fill" the available slots with all players that match the remaining criteria, regardless of their distance (compared to other matching entites). When the limit was not reached with player entities alone, other entities will be processed like expected (based on their distance that is).How to reproduce:
Start by creating an objective/scoreboard objectives add demo dummyand set up the sidebar so you can see it
/scoreboard objectives setdisplay sidebar demoNow just place a commandblock down and put in a command like
/scoreboard players add @e[c=1,r=3] demo 1Finally, place down an entity (i recommend an Armorstand) next to the commandblock.
When you activate the cmd block outside the range (in my example 3), the entity will get a new score. As soon as you are near enough (again, 3 blocks in my example), you will be targeted instead, even if the entity you use is standing between you and the cmd block (which makes it clearly the closer one).Affects:
- Most /scoreboard commands (excluding /scoreboard teams <join|leave> and /scoreboard players tag <target> <add|remove>).
- The name shown in green from the results of /scoreboard players tag <target> <list> (though the list of tags shown in white is from the correct target).
- The stored selector for CommandStats.
Also note [Mod] Skylinerw's comment and code analysis.
is duplicated by
The problem:
The argument "c" in selectors (e.g. "@e[c=1]") is supposed to limit the amount of entities targeted by the selector to the x closest (for c=x) or x furthest (for c=-x) entities, sorted by their distance. However, when used inside a scoreboard command (e.g. "scoreboard players set @e[c=1,r=10] something 0") the selector will first "fill" the available slots with all players that match the remaining criteria, regardless of their distance (compared to other matching entities). When the limit was not reached with player entities alone, other entities will be processed like expected (based on their distance that is).How to reproduce:
Start by creating an objective/scoreboard objectives add demo dummyand set up the sidebar so you can see it
/scoreboard objectives setdisplay sidebar demoNow just place a command block down and put in a command like
/scoreboard players add @e[c=1,r=3] demo 1Finally, place down an entity (i recommend an Armorstand) next to the commandblock.
When you activate the cmd block outside the range (in my example 3), the entity will get a new score. As soon as you are near enough (again, 3 blocks in my example), you will be targeted instead, even if the entity you use is standing between you and the cmd block (which makes it clearly the closer one).Affects:
- Most /scoreboard commands (excluding /scoreboard teams <join|leave> and /scoreboard players tag <target> <add|remove>).
- The name shown in green from the results of /scoreboard players tag <target> <list> (though the list of tags shown in white is from the correct target).
- The stored selector for CommandStats.
Also note [Mod] Skylinerw's comment and code analysis.
Sizelimited entity selectors (@e with c=1) in commands prefer players
Sizelimited entity selectors (@e with c=1,@r with type=!entity) in commands prefer players
is duplicated by
The problem:
The argument "c" in selectors (e.g. "@e[c=1]") is supposed to limit the amount of entities targeted by the selector to the x closest (for c=x) or x furthest (for c=-x) entities, sorted by their distance. However, when used inside a scoreboard command (e.g. "scoreboard players set @e[c=1,r=10] something 0") the selector will first "fill" the available slots with all players that match the remaining criteria, regardless of their distance (compared to other matching entities). When the limit was not reached with player entities alone, other entities will be processed like expected (based on their distance that is).How to reproduce:
Start by creating an objective/scoreboard objectives add demo dummyand set up the sidebar so you can see it
/scoreboard objectives setdisplay sidebar demoNow just place a command block down and put in a command like
/scoreboard players add @e[c=1,r=3] demo 1Finally, place down an entity (i recommend an Armor stand) next to the command block.
When you activate the cmd block outside the range (in my example 3), the entity will get a new score. As soon as you are near enough (again, 3 blocks in my example), you will be targeted instead, even if the entity you use is standing between you and the cmd block (which makes it clearly the closer one).Affects:
- Most /scoreboard commands (excluding /scoreboard teams <join|leave> and /scoreboard players tag <target> <add|remove>).
- The name shown in green from the results of /scoreboard players tag <target> <list> (though the list of tags shown in white is from the correct target).
- The stored selector for CommandStats.
Also note [Mod] Skylinerw's comment and code analysis.
The bug
When you use a command in the chat like:
/say @e[x=0,y=0,z=0,c=1]
Your name will always be stated even if there was a different entity closer to those coordinates. In this case, sender bias (which assumes "the entity closest to itself is always itself") does not take into account if the origin has been changed.
How to reproduce
- /tp 20 60 0
- /summon armor_stand 0 60 0 {CustomName:"closestEntity",NoGravity:1b,NoAI:1b}
- /summon armor_stand 10 60 0 {CustomName:"commandExecuter",NoGravity:1b,NoAI:1b}
- /execute @e[type=armor_stand,name=commandExecuter] ~ ~ ~ /say @e[x=0,y=60,z=0,c=1,r=20]
→ It will print "commandExecuter" instead of "closestEntity"
To make sure that "closestEntity" is indeed the closest one, you can run the following command:
/say @e[type=armor_stand,x=0,y=60,z=0,c=1,r=20]
The reason
The following is based on a decompiled version of Minecraft 1.10 using MCP 9.30.
The reason for this is that the method net.minecraft.command.EntitySelector.getEntitiesFromPredicates(List<T>, Map<String, String>, ICommandSender, Class<? extends T>, String, Vec3d) explicitely uses the sender of the command if c=1.
private static <T extends Entity> List<T> getEntitiesFromPredicates(List<T> matchingEntities, Map<String, String> params, ICommandSender sender, Class <? extends T > targetClass, String type, final Vec3d pos) { int i = parseIntWithDefault(params, "c", !type.equals("a") && !type.equals("e") ? 1 : 0); if (!type.equals("p") && !type.equals("a") && !type.equals("e")) { if (type.equals("r")) { Collections.shuffle((List<?>)matchingEntities); } } else { Collections.sort((List<T>)matchingEntities, new Comparator<Entity>() { public int compare(Entity p_compare_1_, Entity p_compare_2_) { System.out.println(ComparisonChain.start().compare(p_compare_1_.getDistanceSq(pos.xCoord, pos.yCoord, pos.zCoord), p_compare_2_.getDistanceSq(pos.xCoord, pos.yCoord, pos.zCoord)).result()); return ComparisonChain.start().compare(p_compare_1_.getDistanceSq(pos.xCoord, pos.yCoord, pos.zCoord), p_compare_2_.getDistanceSq(pos.xCoord, pos.yCoord, pos.zCoord)).result(); } }); } // This prefers the sender of the command if c=1 //Entity entity = sender.getCommandSenderEntity(); // //if (entity != null && targetClass.isAssignableFrom(entity.getClass()) && i == 1 && ((List)matchingEntities).contains(entity) && !"r".equals(type)) //{ // matchingEntities = Lists.newArrayList((T)entity); //} if (i != 0) { if (i < 0) { Collections.reverse((List<?>)matchingEntities); } matchingEntities = ((List)matchingEntities).subList(0, Math.min(Math.abs(i), ((List)matchingEntities).size())); } return (List)matchingEntities; }
Note: This is not a duplicate of MC-80400, because there it only happens with scoreboard commands and affects command blocks. This bug described here is not caused by command blocks and also doesn't only prefer players but instead the entity which ran the command.
This is a duplicate of MC-80400
X/Y/Z are not ignored, but the player in the X/Y/Z/R area is preferred.
You are right, but isn't it then rather related?
If not could you please update the description and summary of MC-80400?
The description and summary of MC-80400 is perfect, if you have additional informaion, leave a comment there.
Dupe of MC-80400
c=1 doesn't have a player bias
That is simply incorrect. In the latest snapshot, do the following (preferably in a fresh world where you have no other commands running):
1. Create objective and set display.
/scoreboard objectives add NUM dummy /scoreboard objectives setdisplay sidebar NUM
2. Summon an armor stand with the necessary CommandStats already applied, using @e[c=1] as its target.
/summon ArmorStand ~ ~1 ~ {CommandStats:{SuccessCountName:"@e[c=1]",SuccessCountObjective:"NUM"}}
3. Set both the armor stand and your score to 0.
/scoreboard players set @e[r=10] NUM 0
4. Cause the armor stand to activate its stored trigger. Your score is changed, not its own, because there is a player bias with CommandStats.
/execute @e[type=ArmorStand] ~ ~ ~ testfor @p
I am experiencing no other issues in using /stats or CommandStats in general. There is something else interfering with your setup.
See MC-80400 for information concerning player bias in specific functions, as well as a spreadsheet detailing type biases.
Duplicate of MC-80400.
Duplicate of MC-80400, if you have not, please use the search function in the future to see if your issue has already been reported.
Looks the same as MC-80400.
Duplicate of MC-80400, please close
Relates to or duplicates
MC-79103Confirmed for
Is it possible to select either this one or
MC-79103(which is mine) as a duplicate? Mine was earlier, but this one appears to be better. If possible, please selectMC-79103as a duplicate of this one.@Nasm Nasmus: Done.
Confirmed for
It is a problem with 1.8.7 and /execute ignores arguments such as scores.
no it doesn't, you must use it wrong, works fine for me
Confirmed for 15w49b, up to 16w04a. Here's a spreadsheet that lists where player bias via c=1 occurs: https://docs.google.com/spreadsheets/d/1l4kmeuys3lidDOxZTGavilkUckhnE0LwGejhVrW8CRk/edit#gid=875984450
Being all /scoreboard commands (except /scoreboard teams join & /scoreboard players tag) and CommandStats.
Confirmed for 16w07b
Confirmed for 1.9-pre4
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.
Confirmed for 1.9.4 and 16w21b
Edit: Reason previously described in this comment is not the reason for this bug as [Mod] Skylinerw pointed it out. The reason is now contained in the description of
MC-80893and removed from this comment to prevent any confusion.@Marcono1234 That is not actually the reason (did you mean to post it for
MC-80893?). The root cause is from the command processor:net.minecraft.command.CommandHandler.executeCommand()
The selector is processed (method matchEntities()) if the getUsernameIndex() method doesn't return -1. However:
net.minecraft.command.CommandHandler.getUsernameIndex()
If the selector cannot potentially match multiple players (@p, @a[c=1], @e[c=1]), then -1 is returned, thus the selector is not processed yet.
At that point, the selector must be processed by the command classes themselves. Most command classes call the net.minecraft.command.CommandBase.getEntity() method, which returns an entity without any subclass bias. But any commands that call getPlayer() instead (those listed in the report) will have player bias, since the selector attempts to obtain targets from a list of players first.
Yes sorry that was my mistake. I will change the description of
MC-80893accordingly.Edit: I found net.minecraft.command.CommandBase.getEntityName(MinecraftServer, ICommandSender, String) which causes this bug (
MC-80400) but only for scoreboard and stats.is the bug still there, in the latest version?
or be fixed with the new command system?
It's fixed, however @r is not testable.