mojira.dev
MC-182677

dx dy dz target selector defines coordinates relative to a block

When defining a dx dy dz target selector in a command, the command defines a volume from the selector's starting coordinate to one meter in the positive direction along each axis (x, y, z) with dx, dy, and dz expanding the volume of this cube.

 

For example: "execute if entity @e[x=0.5,y=0,z=0,dx=0,dy=0,dz=0.5] run say hi"

This command creates a volume ranging from [0.5, 0.0, 0.0] to [1.5, 1.0, 1.5]. Instead of selecting a line from  [0.5, 0.0, 0.0] to [0.5, 0.0, 0.5], as would be intuitive, the command uses the dx, dy, and dz variables to expand the cube it initially defined (which is also not centered on the origin of the specifier).

 

Another example: "execute if entity @e[x=0,y=0,z=0,dx=0,dy=0,dz=-0.5] run say hi"

This command creates a volume ranging from [0.0, 0.0, -0.5] to [1.0, 1.0, 1.0]. The negative dz value causes the opposite side of the initial cube to be expanded. This is my main gripe with this selector; the command can select arbitrarily specific volumes but cannot define a volume smaller than one meter cubed.

 

Given that this selector succeeds when ANY part of an entity's hitbox is within the selected volume, the way it currently works prevents detecting whether an entity's hitbox intersects a point, line, or plane. I understand the way the selector currently works may be intentional, but it is unintuitive and limits precise hitbox detection.

A proposed solution would be to make x, y, and z define one corner of a volume and dx, dy, and dz define the opposite corner positioned relative to the first corner. This would allow for selecting volumes of any size along any dimension, including a single point, line, or plane. Personally, I think this makes the selector much more versatile (and would certainly help out with my command block creations!) and am unaware of how it might introduce problems into how the game runs/plays.

Thank you for your consideration!

Linked issues

Comments 4

Chris Reeves

As a note for the unintuitive nature of the way the selector currently works, on the Minecraft Wiki, it has been (incorrectly) described to work in the way I suggested it should:

https://minecraft.gamepedia.com/Commands#Target_selector_arguments , Selecting targets by volume, 2nd example from Java edition.

Chris Reeves

What I essentially would like to do with this selector is detect whether an entity is within the hitbox of another entity. I am teleporting area effect clouds along a given path and would like to detect when they intersect with players/mobs/etc.

The way the current selector works creates a large 'detection' region located asymmetrically relative to the position of the area effect cloud, which is imprecise and hard to work with. The alternative "distance" selector is also imprecise as distance is measured relative to the feet of entities, creating a large spherical 'detection' region centered at entities' feet.

The only solution I have come across involves calculating the bounds of the hitbox of each player/mob/etc and detecting whether the position data of the area effect cloud is within the calculated bounds. This, however, is relatively costly to run and just takes many more commands. Given that the dx dy dz selector already automatically calculates intersection with hitboxes, it seems like a waste to not be able to use it in this situation.

NeunEinser

Thank you for your report!
We're tracking this issue as MC-123441, 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 reported.

Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – ✍️ Feedback and Suggestions – 📖 Game Wiki

Chris Reeves

I did actually see that report. Now that I know about voting (thank you!), I have also just voted for it.

The reason I made this report despite it being a duplicate is that MC-123441 was reported two and a half years ago and has yet to be resolved or even assigned. I was attempting to call attention to it again.

Other than voting, is there any other way to respectfully increase attention to MC-123441?

Thanks!

Chris Reeves

(Unassigned)

Unconfirmed

(Unassigned)

1.15.2, 20w18a

Retrieved