The bug
The volume defined by target selector arguments dx, dy and dz is always larger than specified by 1 in all dimensions.
For example, @e[dx=0,dy=0,dz=0] would select entities in a 1x1x1 cube with the negative corner at the execution location, and @e[dx=1,dy=1,dz=1] would select entities in a 2x2x2 cube.
Negative values are allowed and work correctly in the negative directions; however the selection area is still extended 1 in all positive directions.
For example, If you have an armor stand besides you at each side, aligned to the x axis, @e[dx=-1] would select you and both armor stands, rather than just the one on the negative side.
Steps to reproduce
Setup some armor stands
Run the following commands:
/execute align xyz run summon armor_stand ~0.5 ~ ~0.5 {CustomName:'{"text":"Center"}'} /execute at @e[type=armor_stand,name=Center] run summon armor_stand ~1 ~ ~1 {CustomName:'{"text":"Positive"}'} /execute at @e[type=armor_stand,name=Center] run summon armor_stand ~-1 ~ ~-1 {CustomName:'{"text":"Negative"}'}Run the following command:
/execute at @e[type=armor_stand,name=Center] run say @e[dx=0,dy=0,dz=0,type=armor_stand]→ ❌ It finds "Positive" even though an area with the size of 0x0x0 is provided.
Use the following command:
/execute at @e[type=armor_stand,name=Center] run say @e[dx=-1,dy=-1,dz=-1,type=armor_stand]→ ❌ It finds all armor stand even though it should not find "Positive" as a negative area is provided.
Code analysis
A code analysis by @unknown can be found in this comment.
Linked issues
is duplicated by 4
relates to 1
Attachments
Comments 43
Basically the game defaults to checking a 1 meter cubed volume, starting form the north-west-bottom and ending in the south-east-top, with the executing position in one of the eight corners. With positive x and z coordinates, the executing point is the same as the start point of the volume. With negative x and z coordinates, the executing point will be in the south-east corner, and the start point of the volume will be in the north-west corner. On top of this behavior, x, y, z, dx, dy, and dz all check for entity hitboxes, not coordinates, which is very misleading and causes unexpected behavior.
Confirmed for 18w16a.
Confirmed for 1.13.2
Hope this gets fixed soon.
confirmed in 1.14. It's affecting a lot of my creations since it's impossible to select an area smaller than 1x1x1 with this bug. I really hope this gets fixed soon :/
It would be a huge help for me
It is actually possible to select a smaller region by combining a few parts of `execute` to get the intersection of two volumes:
execute as @a[dx=0] positioned ~-0.5 ~-0.5 ~-0.5 if entity @s[dx=0] run ...This will select entities that are in a 0.5x0.5x0.5 volume
But of course, it isn't always possible to do this trick depending on what you are doing, we shouldn't need this workaround, but we do
I've actually set up a little testing booth in my Testing World specifically for this bug, because of its pertinence to a project I'm doing.
I just tested it again today, and it is still a thing in 1.14.1
C'mon Mojang, I've seen you fix bugs with less attention than this. :/
Also, the commands needed to test for the bug should be updated to reflect the need for JSON text strings:
Set up armor stands:
/summon armor_stand ~ ~ ~ {NoGravity:1b,CustomName:"{\"text\":\"center\"}",CustomNameVisible:1b}/execute at @e[type=armor_stand,name=center] run summon armor_stand ~1 ~ ~1 {CustomName:"{\"text\":\"positive\"}",NoGravity:1b,CustomNameVisible:1b}/execute at @e[type=armor_stand,name=center] run summon armor_stand ~-1 ~ ~-1 {CustomName:"{\"text\":\"negative\"}",NoGravity:1b,CustomNameVisible:1b}Command for testing:
/execute at @e[type=armor_stand,name=center] run say @e[dx=0,dy=0,dz=0]
this bug is still a thing in the latest version.
dx ,dy, dz are fantastic features for custom maps and a simple fix would open up so many new possibilities.
Please take care of this one soon Mojang ;_;
Can confirm for 19w35a.
Confirmed for 19w41a.
Confirmed for 19w42a. Also please someone update the reproduce commands because CustomName requires a JSON text now.
Can this be closed as "works as intended" ?
The reason for this is that "align xyz" exists. It floors the executing position so it won't find the armor stand named "positive" if you do this:
/execute at @e[type=armor_stand,name=center] align xyz run say @e[dx=0,dy=0,dz=0]A potential fix to this bug would mean that the execution position is floored as a built in feature. I would advise against it, it would be detrimental actually. No functionality is lost if this would be resolved as WAI.
That's not the problem with the bug. The problem is that dx=0 results in a 1 block volume being checked, and dx=-1 results in a 2 block volume in the opposite direction being checked. This means there is no way to directly check for volumes smaller than 1 block volume
Confirmed for 19w44a. Could someone update the commands in the first step? I just added some single quotes to make CustomName become JSON text.
/summon armor_stand ~ ~ ~ {CustomName:'"center"',NoGravity:1b}
/execute at @e[type=armor_stand,name=center] run summon armor_stand ~1 ~ ~1 {CustomName:'"positive"',NoGravity:1b}
/execute at @e[type=armor_stand,name=center] run summon armor_stand ~-1 ~ ~-1 {CustomName:'"negative"',NoGravity:1b}Confirmed for 19w46a.
Confirmed for 1.15-pre2.
Confirmed for 20w18a
Demonstrating the unintuitive nature of the way the selector currently works, the Minecraft Wiki currently (incorrectly) describes it working as x, y, z define the corner of a volume and dx, dy, dz define the opposite corner, relative to the initial position:
https://minecraft.gamepedia.com/Commands#Target_selector_arguments , Selecting targets by volume, 2nd example from Java edition.
Because the selector currently checks if ANY part of an entity's hitbox overlaps with the volume, if it worked as described on the wiki, it would be possible to detect of an entity's hitbox overlaps with single points, lines, or planes. This would add lots of valuable functionality to the selector (particularly for raycasting entity hit detection) and, as far as I can tell, would not break anything.
Because precise hitbox detection is currently so difficult, I think modifying the dx dy dz selector would make certain mapmaking tools much easier to implement.
Confirmed for 1.16.1. This bug is extremely annoying! Why would defining a volume with size 0 define a volume with size 1?
Can confirm in 20w49a.
Can confirm in 21w03a.
Can confirm in 21w05b.
Can confirm in 1.17.1. Video attached.
Can confirm in 1.18.1
Can confirm in 1.18.2. I can't test this in 22w19a due to MC-251312.
Can confirm in 22w19a
Can confirm in 1.19.1pre5
Can confirm in 1.19.3
Can confirm in 23w12a
Can confirm in 23w18a.
Can confirm in 1.20 release canidate 1
I'd like to request ownership of this report since the reporter has done nothing to it since creating it. (I also made the bedrock edition equivalent report MCPE-174949, since this affects both editions.)
This is way too big an issue to have been overlooked since 1.12. Would be great if someone could get on it.
I thought this was due to the following methods (decompiled 1.20.4 with vanilla mappings:
net.minecraft.commands.arguments.selector.EntitySelectorParser.class
public EntitySelector getSelector() {
AABB $$0;
if (this.deltaX != null || this.deltaY != null || this.deltaZ != null) {
$$0 = createAabb((this.deltaX == null) ? 0.0d : this.deltaX.doubleValue(), (this.deltaY == null) ? 0.0d : this.deltaY.doubleValue(), (this.deltaZ == null) ? 0.0d : this.deltaZ.doubleValue());
} else if (this.distance.max().isPresent()) {
double $$1 = ((Double)this.distance.max().get()).doubleValue();
$$0 = new AABB(-$$1, -$$1, -$$1, $$1 + 1.0d, $$1 + 1.0d, $$1 + 1.0d);
} else {
$$0 = null;
}
...
}
private AABB createAabb(double $$0, double $$1, double $$2) {
boolean $$3 = ($$0 < 0.0d);
boolean $$4 = ($$1 < 0.0d);
boolean $$5 = ($$2 < 0.0d);
double $$6 = $$3 ? $$0 : 0.0d;
double $$7 = $$4 ? $$1 : 0.0d;
double $$8 = $$5 ? $$2 : 0.0d;
double $$9 = ($$3 ? 0.0d : $$0) + 1.0d;
double $$10 = ($$4 ? 0.0d : $$1) + 1.0d;
double $$11 = ($$5 ? 0.0d : $$2) + 1.0d;
return new AABB($$6, $$7, $$8, $$9, $$10, $$11);
}They seem doing additional offests in positive directions.
Confirmed in 21w14a
Confirmed in 1.20.5 release candidate 2
Confirmed in 1.21 Pre-release 3
Confirmed in 1.21 Pre-release 4
Confirmed in 1.21 Release Candidate 1
@unknown: Please stop confirming this for every new build, major releases are more than enough! Any further comments will be removed.
Got it. I will only comment for major releases. In this case, I can confirm this bug in Release 1.21
Confirmed in 1.21.4
Agreed, this should be fixed. Maybe for 1.21.5
[Mod] turbo
Disregard my last comment, had a wrong test setup.