This is no copy of MC-88533. That one concerns marker armorstands.
___

Motivation

Over the past 2 years that I have been working with commandblocks, I've noticed all kinds of weird (seemingly) bugs when using the target arguments r, rm, c, dx, dy, & dz: one observation I made was that entities that should not be detected at certain radii, happen to be detected. Whereas at other times entities that should be detected were not. Since for me this felt completely random I decided to do some research into it and graph my results to see if I could recognize a pattern. I also consulted SkylinerW, who was kind enough to dig through some source-code for me.

Set-up experiment

The core-plan of this experiment was to execute a testfor command at a specific position (at y=0) and test for an entity right above or below it or any other direction for a given value of the target argument being investigated.

I decided to do experiments on all ways possible to test for an entity from a certain location. Fortunately the results showed there was no difference in how either of these commands performed. They all gave the same results.

1. A repeating commandblock positioned at y=0 that fires:

   /testfor @p[dx=X]

2. A repeating commandblock with target argument at y=0.

   /testfor @p[y=0,dx=X]

3. A repeating commandblock that executes from an entity positioned at y = 0.

   /execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[dx=X]

4. A repeating commandblock that executes relative to the players own location at y=0.

   /execute @p ~ 0 ~ testfor @p[dx=X]

Results: target argument "c"

In the following table you find the results for the behavior of 'rm' for various versions of MC.
To interpret this table correctly, consider the command:

/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=!EntityA,c=1]

EntityA is here located at [0.3, 0.3, 0.3] and from there targets the neirest EntityB.

Visualizing problem
Still considering the same command;

/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=!EntityA,c=1]

We hope to target EntityC since it is clearly closer to EntityA, however since EntityB is closer to the North West bottom corner of the block, EntityB is targeted.

Proposed behavior
From all target arguments, 'c' deserves the most to target EntityB from the exact location EntityA is located. It should target a number of nearest or farthest entities depending on the sign used. It is very inconvenient that it instead targets from a corner of a block. If EntityA would be on the South East upper corner of a block, then there is a max error of 1.73 when selecting an entity, which is huge.

Results: target argument "dx, dy, dz"

In the following table you find the results for the behavior of 'dx', 'dy', 'dz' for various versions of MC.
To interpret this table correctly, consider the command:

/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,dx=X,dy=Y,dz=Z]

EntityA is here located at [0.3, 0.3, 0.3] and from there targets the neirest EntityB.

Visualizing problem
It might be hard to interpret how this box looks like in 3d space. Therefore I made the following picture that shows the volume in which EntityB can be for dx=0, dy=0, dz=0. For higher values of dx, dy and dz this box incrementally expands into the desired direction by 1.

Proposed behavior
Since dx, dy and dz are often used in conjunction with x, y and z. It seems logical for dx, dy and dz to snap to the grid. This way players can accurately target entities in a specific volume of blocks. The current 'base' box of 1.6x2.8x1.6, as seen in the picture above, is hard to work with. Actually I've heard feedback from many commandblockers that they mostly evade dx, dy and dz altogether since they do not know what to expect.

Why is this a bug?

After the inconsistency of the 'r' argument was fixed in 07a, it could be debated whether this bug-report has become more of a feature request. I've spoken with a great deal of the commandblock community. Most of them agreed that the current way the target arguments behave is counter-intutive and hard to work with and needs a solid fix. There were a few that disagreed however, with the argument that it broke their old contraptions. My personal opinion is that I feel that it is an outdated way to target entities with respect to some point in the grid with 'c', 'r', and 'rm' instead of the exact location of the targeting entity. I think this behavior comes from the time when commandblocks where first introduced, and it only made sense for commandblocks to target entities with respect to the center of the block. However, since the introduction of the 'execute @e' command together with armorstands & effect clouds, this method has become outdated.

Furthermore, eventhough the devs might argue that the target arguments are 'working as intended', there are many (even infinite) scenerio's possible where unintended entities are targeted by the commands. Because it works differently then intuitively expected, it is perceived as a bug by the community.

Additional potential useful info

A few months ago I consulted SkylinerW for his opinion on what I thought was a bug. He dug through the source code and modified it to give some feedback of what was happening. Some highlights of this conversation were these, concering the "r" target argument:

After having dug through the source for an explanation, I'm left with: I really can't say for sure.

There's a few things required for proper radius selection, but I'll go through the two that are relevant. The first requirement is whether or not the target's hitbox intersects the radius' bounding box.

I believe the first requirement with the boundingbox is just a cheap operation and it quickly cuts down the pool of all entities that could lie within a radius r away from the point of execution. At the end we are left with all entities that find themselves in some sort of cube with sides of length 2*r around the point of execution. (Correct me if I am wrong).

The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius * radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.

The second requirement does a test whether the squared distance between the point of execution & the entities is smaller then the squared specified radius. This way only those entities that find themselves within a sphere with radius r around the point of execution will be succesfully tested for. The point of execution is always the centerpoint of a block, so when the command is executed at a y = [0,1), this centerpoint will be at y = 0.5

But there's an extra issue: if the mobs are resting at an exact Y coordinate (5.0 vs 5.5), then I can replicate the issue with one command working while the other doesn't work. If the Y coordinates are not exact (I used +-0.5), then neither command works even though the positions are essentially no different. It always results in a "distanceSqToCenter" of 2. There are certainly some obscure mathematical issues going on, and there's really no way around it (I can hardly explain it either, which I apologize for).

The full conversation with SkylinerW can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/

Discussion & Solutions

Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, rm, c, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.

Many people have tried to get the absolute or relative coordinates of an entity in a scoreboard score. This will always remain diffecult & tedious, even if these target arguments were working correctly. I think a scoreboard stat such as stat.Xcoord, stat.Ycoord, stat.ZCoord, stat.RY (rotation around y axis) & stat.RX (rotation around x axis) would make so many new contraptions possible. Basically it automatically updates your score based on the coordinate you are. But I understand this is not the right place for a feature request.

Thanks for reading.