GamerGuppy

After testing I can confirm target argument 'c' now behaves as it should in 1.9.1pre1 Though one can argue whether they are truly useful in their current state, dx, dy & dz are strictly spoken, working as intended. Therefore I propose to close this bug report. Thanks to all that helped and contributed to this report!

Your way of writing makes it seem as if you disagree with virtually everything, whereas our viewpoints almost exactly overlap.
Also you make the discussion quite complex to still understand.

Just to show this:
-I dont think adding hdx, hdy, hdz is a good idea either. I meant adding a target variable @h[dx=1] for targeting hitboxes. Which would work exactly as @e[dx=1] works right now, it namely targets the hitbox of an entity relative to the grid. @h[r=5] will too, target hitboxes, but relative to the exact point of execution within a radius of 5.
-All the other properties behave consistently. r, rm & c still target from an exact position, dx, dy & dz still target relative to the grid.

Its actually not confusing at all. If you want to target a hitbox? -> @h. Want to target entities feet? -> @e.

I feel the dx, dy & dz discussion is gradually transforming more into a "feature" request. But the fact that this happens does show how counter-intuitive some target arguments behaved and it might be a good time to settle this matter once and for all, now that finally most of the community understands the current behavior of dx, dy & dz, and can form a solid opinion on how they wish to see it behave.

I tend to be overly descriptive, but once again I feel the need to make a neat list;
In these examples we consider again /execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,dx=X,dy=Y,dz=Z]

Current situation

• dx, dy and dz target entities relative to the grid; namely the block EntityA's feet are in.

• With dx, dy and dz a cubic volume is specified that snaps exactly to the grid

• a dx = 0, dy = 0 or dz = 0, or a super-position of these, results in a volume of 1 block. Which is the block EntityA's feet are in.

• Higher values of dx, dy & dz incrementally enlarges this cube in the desired direction.

• A succesful testfor takes place, once the hitbox of EntityB intersects the cubic volume specified by the dx, dy & dz selectors.

Analysis delta properties
We conclude the delta arguments (dx, dy & dz) have 2 unique properties. I came up with several PRO & CON arguments as to why these properties are good or bad:

Property 1. They target entities relative to the grid

• PRO: If we were to make the delta arguments look for EntityB relative to EntityA's location (just like r & rm now does), the player is virtually 'blind' to the environment the entities are in. For a block-based game, there is a strong need to interact with entities on specific places on the grid. It is therefore important to know the entities absolute location for this purpose.

• PRO: It sort of makes sense for the delta arguments to target relative to the grid, since these are often used in conjunction with the x, y & z arguments which only allow integers.

• PRO: dx, dy & dz targetting relative to EntityA would not even give many benefits over using dx, dy & dz in conjunction with the r argument. You can namely just use r to specify an exact distance with regard to EntityA, and use dx, dy and dz relative to the grid to decide in which direction should be looked for.

Property 2. They target an entity based on it's Hitbox, instead of it's feet's position.

• PRO: Being able to target EntityB based on it's hitbox is important. E.g. tall mobs like endermen are often missed by 'r' arguments, despite their head or torso being within reach of the Radius. The dx, dy & dz argument make it however possible to target entities based on their hitbox.

• CON: The pro argument above, directly crushes the first pro argument of the first unique property; namely we now again can't precisely interact with entities on specific places on the grid, since instead we also select many other entities due to their hitboxes crossing the border.

• CON: Being able to target EntityB's hitbox seems something that seems especially useful in many situations when done relative to EntityA. Which again conflicts with property 1.

Conclusion
Both properties are highly functional and much wished for in the community, but they conflict greatly, rendering dx, dy & dz useless altogether for the purpose of many contraptions. As has been the case for quite some time now, and as a result many people did not use them altogether.

My personally proposed solution would therefore be to seperate these two properties; Delta target arguments keep property 1, which means targetting entities relative to the grid. And in order to target entities by their hitboxes a new Target Variable @h could be used. This would be the ideal solution in my opinion, but this might very well be a bit wishful thinking, considering how much of a "feature" request this is.

Curious to your opinions.

Hey Adrian Uffmann,

You were right, my gut-feeling was wrong. I've no idea how it slipped under the radar since I actually discussed with 2 other CMB people whether the players' hitbox was responsible for the seemingly weird off-set when using dx, dy & dz. But either we (read: I) messed up these ridiculous simple calculations or assumed the wrong dimensions of hitboxes of several entities. Anyway, let me explain:

/execute @e[name=EntityA] ~ ~ ~ testfor @p[dx=0 or dy=0 or dz=0]
So this command again searches for entities relative to the center of a block EntityA is in:
With dx=0, or dy=0 or dz=0 corresponding with a search volume of one block exactly.
It finds an entity, in this case the player, once that entities hitbox intersects this volume of one block.
(I previously assumed this would not be feastible since it would involve too heavy mathematical computations, but since it concerns AABB (axis alligned bounding boxes) intersections, I guess it's afterall a pretty cheap operation.)

So since a players hitbox has a base of 0.6 x 0.6 blocks wide and is 1.8 blocks tall, we indeed start targeting the player once it is in the volume as I had drawn out in the image of my bug-report. My apologies to all for this misinformation & thanks to Adrian for rechecking the facts.

So I guess, dx, dy & dz is "working as intended" after all. I am still interested in peoples opinion whether it's function is useful & intutive. Namely, as far as I've heard, many, many people evade dx, dy & dz entirely since they never knew what to expect.

After extensive testing I can conclude that 'r' and 'rm' are working as it should. It works as expected whenever it is executed from a commandblock, an entity or with tilde notations relative to an entity. The problem with 'c' is still persistent, I'm currently re-evaluating dx, dy & dz behavior based on new insights by Adrian Uffmann.

Wow, I only just read it. Can't wait till I get home to do some testing 😉
Thank you Devs!

Hey Adrian,

I did not do any tests on your claim yet, since I still have work to do. However, my 'gut-feeling' says that a hitbox will not have any effect on commands or 'dx, dy & dz' target selectors at all.
With this I mean that they never did so in the past either. As I said, I think you are confused by the other bug concerning marker armorstands.

That said, I do understand and even share your frustration on this, but I feel at the same time there is some logic behind it:
Namely, when you execute from EntityA a command containing the arguments 'r', 'rm', 'dx', 'dy', or 'dz', you could mathematically think of it as 3d volume where EntityB should be in, in order to be succesfully targeted. So for 'r' and 'rm' this volume is a sphere with a specified radius, and for dx, dy & dz a cube of specified dimensions.

If the location of EntityB is only defined by it's feet, in mathematical terms, a 'point in 3d space', then it's a very easy and cheap operation to check if this point lies within the specified volume. However if the location of EntityB is defined by it's hitbox, then it becomes suddenly a much more complicated mathematical problem. Even if the hitbox is just a cube, then you'll need to do a test for each edge (12 on a cube) whether it intersects the specified volume. I mean... it's doable, but I think it will cost quite some performance. Also I must admit there are some tricks to enhance performance... in case you're really interested; http://www.realtimerendering.com/intersections.html.

-Gups

Whoops, I misinterpreted one aspect of your test. I'll run some tests to see whether I can confirm it.
Thanks for notifying me.

Hey Adrian!
Thanks for checking and verifying my information, that's an important and right thing to do.

However I must inform you that a hitbox (should) not have any effect on
-from which location (EntityA) a target argument starts targeting from
-nor where it starts detecting an entity (EntityB).

The only thing that should matter as of now is:
-The block the feet of EntityA is in
-Where the feet of EntityB are

I think you are mislead to believe that hitbox matters due to another bug regarding Marker ArmorStands.
https://bugs.mojang.com/browse/MC-88533
If you repeat the same test for EntityEffectClouds without a hitbox, everything is just fine.

I've finally managed to find time to update it. Thanks for the help and patience, redstonehelper.

I've almost completely rewritten this bug report to reflect the current situation & include new input from the community. If you spot any errors or flaws please inform me.

I had very limited time the last 2 days to update this report, but I think I'll manage to by this evening.

Dang, you are fast! Could you maybe reupload an image with many arrows scattered on the floor then doing /execute @e[type=Arrow] - - - kill @e[type=Arrow,r=0]. Then toggle hitboxes with f3+b. I expect only arrows to be deleted in a radius of 0.25 around the center of the bottom face of a block. I can only test it myself in the evening today, and I typed this on phone.

I'm going to leave this here; since I've noticed there is a lot of misunderstanding & misinterpretation of this bug.
http://imgur.com/bR6eRjL
I feel the discussion has become very scattered over many seperate bug reports, that often have a far too specific title whereas the problem is more general.

Since I've noticed there is a lot of misunderstanding & misinterpretation of this bug, I've made this:
http://imgur.com/bR6eRjL
I feel the discussion has become very scattered over many seperate bug reports, that often have a far too specific title whereas the problem is more general.
This bug report is not even fixed; namely, the dx, dy and dz problem still persists and has remain untouched by the update. Also, with 07b 'r' and 'rm' behave once again unexpectedly.
I feel this bug report should therefore be reopened.

Hey Meri,
Don't worry about the shape. The image SkylinerW posted had me confused for a little bit too, but the shape is actually a perfect sphere (so with a fixed actual radius).
http://imgur.com/7HB5egK
That is the case in all snapshots & MC versions so far.
I contacted SkylinerW about his image, but he was experimenting with the glow effect, which can not render spheres in MC (without texturepack). I'm unable to tell you whether it would really hit performance.

I agree, the radius "r" and "rm" target selectors correspond to euclidean distances and it would make sense if these are executed based on the position of the entity instead of the center of the block. Dx, dy and dz on the other hand are more like "Manhattan" distances, and it would make sense if these snap to the grid. Meaning dx=0 test everything in the block the entity is in, and with dx=1, also everything that is in the block besides it. Combinations of the 2 would give a commandblock user powerful tools to precisely select specific entities.

So in 06a everything worked exactly as it should. But I guess many people complained since their contraptions were no longer working. But with the 06b snapshot things changed once again, and in my humble opinion, for the worse. Let me clarify for those interested:

Let's consider the command /execute @e[name=A] ~ ~ ~ testfor @e[name=B,r=0]

Snapshot 06a and below (also MC 1.8):
In case entity A was standing at e.g. (0.8, 0.3, 0.4) the testfor command would be executed at (0.5, 0.5, 0.5). Also known as the center of the block entity A is in, and from there would test for the position of entity B.

Snapshot 06b:
In case entity A was standing at e.g. (0.8, 0.3, 0.4) the testfor command would be executed at (0.5, 0.0, 0.5). Also known as the center of the bottom face of the block entity A is in, and from there would test for the position of entity B.

This offset in point of execution might even lead to more contraptions being broken and other diffeculties with contraptions in the future since it is very counter intutive. Because let's face it; the most intuitive thing, would be if a command would be executed right at the position of entity A. The center of the block worked reasonably well too. But it will be very hard to explain new players that a command will be executed at the center of the bottom face of the block entity A is in.

But thats not the only change, let's now focus on the position of B that is required for a succesful testfor, considering the same command again.

In MC 1.8
In MC 1.8 the required position of B was inconsistent and behaved weirdly with the radius used. Hence this bug-report. Since the command was executed at the center of the block, a radius of r=0 would imply that entity B must be at the very center to be succesfully detected. However as you know, this was not the case. Entity B could be anywhere within the block and still be detected. This is why many people (falsely) assumed r=0 would only target the entities within that specific block. In reality you could think of a sphere with radius 1 around the point (0.5, 0.5, 0.5) in which all entities would be tested for. Which is weird because our radius was r=0 right?

In 06a
In 06a r=0 indeed meant the entity B had to be at the exact center of the block in order to be tested for. Hence a radius of 0. A radius of r=1 now gives exactly the same functionality as r=0 did in MC 1.8. Which is now logical.

In 06b
In 0.6b a radius r=0 no longer corresponds with a sphere with radius 0, but instead a radius of 0.25. Also r=1 corresponds to a sphere of radius 1.25. This is probably a fix such that r=0 is not completely useless.

Conclusion & advice
The current state, as of 06b, the radius selector is again very counter-intutive. The y-offset is hard to work with, and the 0.25 added to the radius feels random. I would seriously consider either reverting back to 06a or choose to have commands once again be executed at the center of a block with 0.5 added to the radius instead of 0.25. My reasoning for this is that this way, with r=0, you get a sphere, with radius 0.5, that is enclosed by the block entity A is in, in which B can be succesfully tested for. This is convenient and intutive to work with. I hope you understand all of the above, because it's terribly diffecult to explain these things in words and English is not my native language.

It seems you are mostly right, I have only little time to test. But it behaves for x & z directions the same in 1.8 and 1.9. For y direction it behaves in 1.9 as it should.

For x and z directions:

in 1.8
Test: /execute @e[type=ArmorStand] ~ ~ ~ testfor @p[r=0]
Armorstand at pos 0 0 0
player at pos 1 0.5 0 or 0 0.5 1
(this is where I first get succesfully detected, if I tp a little bit down or up or to the sides I dont get detected any more).

in 1.9
Test: /execute @e[type=ArmorStand] ~ ~ ~ testfor @p[r=1]
Armorstand at pos 0 0 0
player at pos 1 0.5 0 or 0 0.5 1
(this is where I first get succesfully detected, if I tp a little bit down or up or to the sides I dont get detected any more).

For y direction:

in 1.8
Test: /execute @e[type=ArmorStand] ~ ~ ~ testfor @p[r=0]
Armorstand at pos 0 0 0
player at pos 0 1 0
(this is where I first get succesfully detected, if I tp a little bit up or to the sides I dont get detected any more).

in 1.9
Test: /execute @e[type=ArmorStand] ~ ~ ~ testfor @p[r=1]
Armorstand at pos 0 0 0
player at pos 1 1.5 0
(this is where I first get succesfully detected, if I tp a little bit up or to the sides I dont get detected any more).

There seems to be a weird offset for the dx and dz arguments still though.

In the strict sense, the "r" argument is now working as it should. Let me explain. Whenever you execute a command, it is not really executed at the entities location, but rather the exact center of the block the entity is in. This has always been the case. That means that with the new behavior of "r", that with r=0, you will only target an entity if that entity is at the exact center of the block.

However... I do understand that many people, including me, used r=0 as a way to target all entities within a certain block. Many of my contraptions are broken too. I therefore hope that r=0 will maybe get an exception to the new and improved behavior of the "r" argument, and get it's old behavior back. Or that dy=0 replaces that functionality. However now we don't seem to have any way to interact with entities in a particular block anymore.