[MC-88533] Entities without hitboxes cannot properly be tested for with target argument "distance=0" or "dy=0"

These experiments involve marker armorstands – it also affects area effect clouds with zero radius. Most likely the bug occurs due to these armorstands lacking a hitbox.

Setup experiment
In this scenerio the armorstands involved in the testing were obtained as follows:

/summon armor_stand ~ ~ ~ {CustomName:"\"A\"",Marker:X}
/execute at @e[name=A] run summon armor_stand ~ ~ ~ {CustomName:"\"B\"",Marker:X}

Note that the X is either a 0 or 1 depending on the following cases.

Results experiment
We distinguish the following 3 cases

Case 1: ArmorStand A is not a marker, ArmorStand B is not a marker.
```
execute at @e[name=A] run kill @e[name=B,distance=0]
```
Kills B, works as expected
```
execute at @e[name=B] run kill @e[name=A,distance=0]
```
Kills A, works as expected
Case 2: ArmorStand A is a marker, ArmorStand B is not a marker.
```
execute at @e[name=A] run kill @e[name=B,distance=0]
```
Kills B, works as expected
```
execute at @e[name=B] run kill @e[name=A,distance=0]
```
Does not kill A, does not work as expected
Case 3: ArmorStand A is a marker, ArmorStand B is a marker.
```
execute at @e[name=A] run kill @e[name=B,distance=0]
```
Does not kill B, does not work as expected
```
execute at @e[name=B] run kill @e[name=A,distance=0]
```
Does not kill A, does not work as expected

Further research
I've had a talk about these seemingly bugs with SkylinerW who in the MC community is a well respected modder/'expert' on Minecraft. This talk can be found back in this reddit topic:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/

Here are some extracts from our conversation that might help you guys further, credit to SkylinerW:

"That one definitely seems to be a bug. It's not just armor stands, but any entity that is in the ground; I can't get the command to work even if there's a villager with its feet stuck in a block directly underneath the armor stand without increasing the radius to 2 (r=1 still presents the problem, so it's not restricted to r=0). It's specific to the Y coordinate, so it seems like their interpreted location is being skewed for being within a block. I imagine the eye height for marker stands being at the exact Y value causes it to be seen as being within a block.

Code analysis by @unknown can be found in this comment.

Also this can be more easily tested with this being run in chat while you don't move:

summon armor_stand ~ ~ ~ {NoGravity:1b,Marker:1b,CustomName:"\"c\""}
say @e[distance=0]

this'll only show your name and not the armor stand's, unless you change it to Marker:0b

Linked issues

is duplicated by 5

MC-79278 Armor Stands with Marker tag can't detect themselves with r=0 Resolved

MC-90967 Marker ArmorStands are not within r=0 when they stand on the ground. Resolved

MC-120514 Marker Armorstands cannot target themselves properly using dx or dz Resolved

MC-123410 Marker armor stand cannot find itself with 0 as distance selector argument Resolved

MC-197125 Distance matching for marker armor stands in entity selectors is inconsistent Resolved

relates to 3

MC-109020 Weird behavior with taged & markered armor stands. Resolved

MC-97178 Minecart with command block doesn't kill itself with r=0 with riders command block and ridden ones Resolved

MC-111144 /stats does not find marker armorstands in upper half of a block Resolved

Comments 48

[Bot] Arisa 2015-09-11T22:48:54Z

Please do not mark unreleased versions as affected.
You don't have access to them yet.

--- This action was performed automagically. If you believe this was done erroneously, please :light_bulb_on: raise an issue.

SlaxX 2015-12-30T18:19:22Z

Please fix this ;_; i can't do it otherwise...

user-f2760 2015-12-30T18:37:02Z

You can temperarely make it r=1, and when it's fixed you can change it to r=0

I hate this bug too, it makes some systems suck, but that's why there is a bug tracker, and this will get fixed at one point

SlaxX 2015-12-30T19:00:13Z

Thats the problem. I can't ^^
Cause there are other Armorstands around it that should not be affected.
And something like /execute (...) ~ ~1 ~ (...) @e[r=1] doesn't work either.
With an offset of 0.999 none of the Armorstands react, and with 0.998 all of them do...

user-f2760 2015-12-30T19:45:14Z

You could add c=1

38 more comments

SlaxX 2015-12-30T21:18:27Z

Oooooh guess i misunderstood the purpose of c...
good thing i looked it up before writing you an answer ^^
thats the exact thing i'm looking for, thanks!

GamerGuppy 2016-01-06T15:46:09Z

UPDATE: Previously this bug report contained a different scenerio in which the target argument "r" failed to test for the right entity. This scenerio has been moved to a new bug-report since it is completely unrelated as to why marker armorstands can't be tested for. See MC-95352.

marcono1234 2016-02-08T10:42:05Z

Confirmed for

16w05b

user-f2760 2016-02-15T18:29:06Z

In 16w07a seems to effect all entities, not only marker armor stands.
I suggest collecting them all here, as this issue is the same, and already assigned.

GamerGuppy 2016-02-15T19:05:04Z

And I suggest not to, since these are 2 entirely different problems.

I do understand where you are coming from FVbico, since many of my contraptions are broken too. After the fix of MC-95352, "r" now works as it should; /execute @e[name=A] ~ ~ ~ testfor @e[name=B,r=0] now only succesfully finds B if B is located exactly at the center of the block where A is too. Why is it working as it should? Well a command is always executed with respect to the center of a block, even if you do /execute @e[name=A]. But as I said, maybe r=0 should be an exception to this rule, since so many people use it to target an entity somewhere in the same block as the entity the command is executed from.

Adrodoc55 2016-02-26T17:01:30Z

Confirmed for 1.9-pre4

Plagiatus 2016-03-14T22:34:16Z

Confirmed for 1.9.1-pre3

koder 2016-03-22T08:11:13Z

How long has Searge been working on this?

user-f2760 2016-03-22T09:10:43Z

He only assigned himself, that doesn't mean he works on it at the moment, only that he is the one willing to fix it

koder 2016-03-22T09:22:35Z

In that case, how long has be been assigned to this?

FaRo1 2016-03-22T10:49:46Z

Since 11/Feb/16 3:56 PM, like you can see in the activity feed.

Ely G 2016-05-23T17:05:41Z

confirmed up to 1.9.4

Adrodoc55 2016-05-29T11:35:16Z

Confirmed for 16w21b

marcono1234 2016-08-31T22:22:09Z

Please link to this comment in the description

The following is based on a decompiled version of Minecraft 1.10 using MCP 9.30.

The reason for this is very likely that the method net.minecraft.command.EntitySelector.filterResults(Map<String, String>, Class<? extends T>, List<Predicate<Entity>>, String, World, BlockPos) creates a bounding box which is expanded in the negative and positive directions by the radius but only in the positive direction by an additional 1. It looks like this bounding box is only used to reduce the amount of entities that will be tested. It then searches for entities whose bounding box intersects with it. A bounding box counts as intersecting if bb1.minX < bb2.maxX AND bb1.minY < bb2.maxY AND bb1.minZ < bb2.maxZ AND bb1.maxX > bb2.minX AND bb1.maxY > bb2.minY AND bb1.maxZ > bb2.minZ. The problem is that both armor stands are at the same Y block coordinate. As the bounding box is only expanded in the positive direction by an additional 1 the bounding boxes which will be compared have both the same minY value which means they don't intersect.

This could be solved by expanding the bounding box by an additional 1 in the negative direction as well.
Edit: This solution might be flawed and could cause issues similar to MC-123441.

private static <T extends Entity> List<T> filterResults(Map<String, String> params, Class <? extends T > entityClass, List<Predicate<Entity>> inputList, String type, World worldIn, BlockPos position)
{
    List<T> list = Lists.<T>newArrayList();
    String s = getArgument(params, "type");
    s = s != null && s.startsWith("!") ? s.substring(1) : s;
    boolean flag = !type.equals("e");
    boolean flag1 = type.equals("r") && s != null;
    int i = parseIntWithDefault(params, "dx", 0);
    int j = parseIntWithDefault(params, "dy", 0);
    int k = parseIntWithDefault(params, "dz", 0);
    int l = parseIntWithDefault(params, "r", -1);
    Predicate<Entity> predicate = Predicates.and(inputList);
    Predicate<Entity> predicate1 = Predicates.<Entity> and (EntitySelectors.IS_ALIVE, predicate);
    int i1 = worldIn.playerEntities.size();
    int j1 = worldIn.loadedEntityList.size();
    boolean flag2 = i1 < j1 / 16;

    if (!params.containsKey("dx") && !params.containsKey("dy") && !params.containsKey("dz"))
    {
        if (l >= 0)
        {
            // Changed this
            //AxisAlignedBB axisalignedbb1 = new AxisAlignedBB((double)(position.getX() - l), (double)(position.getY() - l), (double)(position.getZ() - l), (double)(position.getX() + l + 1), (double)(position.getY() + l + 1), (double)(position.getZ() + l + 1));
            AxisAlignedBB axisalignedbb1 = new AxisAlignedBB((double)(position.getX() - l - 1), (double)(position.getY() - l - 1), (double)(position.getZ() - l - 1), (double)(position.getX() + l + 1), (double)(position.getY() + l + 1), (double)(position.getZ() + l + 1));

            if (flag && flag2 && !flag1)
            {
                list.addAll(worldIn.<T>getPlayers(entityClass, predicate1));
            }
            else
            {
                list.addAll(worldIn.<T>getEntitiesWithinAABB(entityClass, axisalignedbb1, predicate1));
            }
        }
        else if (type.equals("a"))
        {
            list.addAll(worldIn.<T>getPlayers(entityClass, predicate));
        }
        else if (!type.equals("p") && (!type.equals("r") || flag1))
        {
            list.addAll(worldIn.<T>getEntities(entityClass, predicate1));
        }
        else
        {
            list.addAll(worldIn.<T>getPlayers(entityClass, predicate1));
        }
    }
    else
    {
        final AxisAlignedBB axisalignedbb = getAABB(position, i, j, k);

        if (flag && flag2 && !flag1)
        {
            Predicate<Entity> predicate2 = new Predicate<Entity>()
            {
                public boolean apply(@Nullable Entity p_apply_1_)
                {
                    return p_apply_1_ != null && axisalignedbb.intersectsWith(p_apply_1_.getEntityBoundingBox());
                }
            };
            list.addAll(worldIn.<T>getPlayers(entityClass, Predicates.<T> and (predicate1, predicate2)));
        }
        else
        {
            list.addAll(worldIn.<T>getEntitiesWithinAABB(entityClass, axisalignedbb, predicate1));
        }
    }

    return list;
}

SunCat 2016-09-25T17:30:32Z

Fixed for 16w38a

user-f2760 2016-09-25T17:31:38Z

Confirmed fixed.

Bytenka 2016-10-21T20:02:24Z

Back (or still, idk) in 16w42a for me.

FaRo1 2016-10-21T20:54:40Z

Nope, not in 16w42a.

/summon armor_stand ~ ~ ~ {Marker:1,NoGravity:1}
/execute @e[type=armor_stand,r=1] ~ ~ ~ summon armor_stand ~ ~ ~ {Marker:1,NoGravity:1}
/execute @e[type=armor_stand,r=1] ~ ~ ~ tesfor @e[type=armor_stand,r=0]

gives out:

Found Armor Stand
Found Armor Stand
Found Armor Stand
Found Armor Stand

SunCat 2016-11-10T14:54:51Z

Confirmed for 1.11-pre1. Please reopen

Ersatz 2016-11-15T07:52:33Z

Confirmed for 1.11. Hopefully this gets fixed soon.

AjaxGb 2017-05-24T22:18:43Z

Confirmed for 1.12-pre5.

Maxaxik 2017-06-03T18:48:32Z

Confirmed for 1.12-pre7

JochCool 2017-10-21T21:52:33Z

Can confirm for 1.12.2 😞

vdvman1 2018-03-12T01:29:59Z

Can confirm for 18w10d

AlexMCool 2018-04-29T12:16:20Z

Confirmed for 18w16a

AlexMCool 2018-06-24T18:09:33Z

confirmed for 1.13pre-3

AlexMCool 2018-06-26T14:06:38Z

Affects 1.13-pre4

AlexMCool 2018-06-28T14:57:58Z

Affects 1.13-pre5. Also this can be more easily tested with this being run in chat while you don't move:

summon armor_stand ~ ~ ~ {NoGravity:1b,Marker:1b,CustomName:"\"c\""}
say @e[distance=0]

this'll only show your name and not the armor stand's, unless you change it to Marker:0b

AlexMCool 2018-07-04T13:28:44Z

Affects 1.13-pre6

AlexMCool 2018-07-10T17:56:10Z

Affects 1.13-pre7

AlexMCool 2018-07-13T15:08:58Z

And 1.13-pre8

AlexMCool 2018-07-16T15:25:41Z

And 1.13-pre9

AlexMCool 2018-07-19T09:57:04Z

And 1.13

AlexMCool 2018-07-25T16:43:48Z

And 18w30a

AlexMCool 2018-07-26T17:45:55Z

And 18w30b

[Bot] Arisa 2019-03-14T15:29:59Z

Please do not mark unreleased versions as affected.
You don't have access to them yet.

JochCool 2020-10-14T21:36:44Z

And it's still here in 1.16.3

SolidBlock 2020-10-29T10:14:53Z

I found any markers can't be selected via volume.

Triton365 2021-07-14T17:44:09Z

(Workaround)

This does not occur in predicate's distance detection. Use that instead.

JochCool 2021-07-21T22:39:24Z

Still affects 1.17.1

Simpy 2021-12-19T14:25:19Z

still a problem in 1.18.1

user-f2760 2022-07-17T21:52:09Z

This could be solved by expanding the bounding box by an additional 1 in the negative direction as well.

(for the code analysis comment)

This is actually a horrible way to fix it, as it makes making small selection cubes even harder, amplifying MC-123441 to be twice as severe.

The actual problem is that these entities are only a point in existence, as the point is not accepted in the selection box, because it's on the very edge. (The selector check is "in between min and max, excluding min and max values", rather than "in between min and max, including min and max values".)
You can literally offset the selection box by 0.00001 on x y and z, and then find it with dx/dy/dz just fine.
Example:

/summon marker
/execute as @e[type=marker] at @s run say @s[dy=0] <- no result
/execute as @e[type=marker] at @s positioned ~-0.00001 ~-0.00001 ~-0.00001 run say @s[dy=0] <- result

For distance= there doesn't seem to be a command-workaround, but you can use predicates are previously pointed out (because they properly check for including, not excluding).

RoarkCats 2024-09-29T19:11:51Z

Can confirm in 1.21.1 with marker entities