mojira.dev
MC-95352

Spatial target arguments "c", "dx", "dy", "dz" behave unexpectedly and inconsistently

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.

Version:

Point of search

All versions

Bottom North West corner of block EntityA is in: [0.0, 0.0, 0.0]

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.

[media]

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.

Version:

Point of search

Ideal solution

At the exact location of EntityA

Sub-ideal solution

At the center coordinate of a block

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.

Version:

Actual selection volume (pos. values, dx, dy, dz)

Actual selection volume (neg. values, dx, dy, dz)

All Versions

[-0.3, -1.8, -0.3] to [1.3+X, 1.0+Y, 1.3+Z]

[-0.3-X, -1.8-Y, -0.3-Z] to [1.3, 1.0, 1.3]

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.

[media]

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.

Version:

Actual selection volume (pos. values, dx, dy, dz)

Actual selection volume (neg. values, dx, dy, dz)

Solution

[0, 0, 0] to [1.0+X, 1.0+Y, 1.0+Z]

[0.0-X, 0.0-Y, 0.0-Z] to [1.0, 1.0, 1.0]

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.

Linked issues

Attachments

Comments 59

Mustek

it's beautiful!

Skylinerw

(I thought dx, dy and dz were not specified for negative values?)

Towards the end of the 1.8 snapshots, the delta parameters were changed to accept negative values (even though they were originally not intended to).

VarHar

Can i ask something?
Why /say @e[r=0] doesn't say my name now?
I know that's something i, and a lot of other users used and I'm very ANGRY that i need to rewrite my commands because of so settle change
@edit
i did a test, and i've putted two ArmorStand's in 0.5 radious (z axes) from each other,
i've moved myself ~ ~ ~1.0 exactly from armorstand or the +z (with was on -83 4 -150)
and putted in an command "/execute @e[type=ArmorStand,r=1] ~ ~ ~ /say hi" (without quotes)
Two armorstands have recalled with one was on radious more than 1! (but less than 2, this bug was there before fixes)
WITH MEANS this snapshot (16w07a) have broke more than it fixes

Irbis

Now this is working much worse.
This is related to: MC-97178
r=0 can't find all entities in the same position as the one it is executing command and the executer.

user-57e18

@unknown, you can just use /say @p

49 more comments
GamerGuppy

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.

Adrodoc55

@@unknown that really is a feature request now 😉
I don't quite agree with you on the third point of property 2: I think beeing able to target a hitbox is very useful both relative to an entity AND relative to the grid.
But I don't think using integer delta coordinates would make a lot of sence relative to an entity. So if a new target variable would be added it should still snap to the grid and get property 1.
Addind target variables hdx, hdy and hdz would of course give extreme precision, but to be realistic I think that the difference would be very confusing to anyone who does not exactly know how targets are selected.
The thing about property 2 is that at least one selector should exist that does not have property 2 and at least one that does.
Currently this is the case, because r and rm do not have property 2 while dx, dy and dz do have it.
If you would go full out to enable extreme precision you could also add hr and hrm as radii that take the hitbox into account, but I am not sure if that is neccessary.

I think it is sufficient to leave dx, dy and dz as they are with both property 1 and 2 and leave r and rm without property 1 and without property 2.

GamerGuppy

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.

Adrodoc55

@@unknown sorry I misunderstood your request. I should also note that I am not a native english speaker.

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!

GamerGuppy

michael

Unconfirmed

Minecraft 1.8.9, Minecraft 15w51b, Minecraft 1.9 Pre-Release 4, Minecraft 1.9

Minecraft 16w07a, Minecraft 1.9.1 Pre-Release 1

Retrieved