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 Marcono1234 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 by5
MC-79278Armor Stands with Marker tag can't detect themselves with r=0DuplicateMC-90967Marker ArmorStands are not within r=0 when they stand on the ground.DuplicateMC-120514Marker Armorstands cannot target themselves properly using dx or dzDuplicateMC-123410Marker armor stand cannot find itself with 0 as distance selector argumentDuplicateMC-197125Distance matching for marker armor stands in entity selectors is inconsistentDuplicaterelates to5
MC-109020Weird behavior with taged & markered armor stands.FixedMC-97178Minecart with command block doesn't kill itself with r=0 with riders command block and ridden onesFixedMC-103726Marker Armor Stands Are Not Saved With StructuresFixedMC-107172Hitbox of Marker "true" Armor Stands lets their names now appear above themFixedMC-111144/stats does not find marker armorstands in upper half of a blockInvalid- Unresolved
Alex³
GamerGuppy- 86
- 41
- Confirmed
Low- Platform
- Commands
- Marker argument armor_stand radius selector
1.8.8 - 1.21.3
1.8.8 15w36d 15w37a 15w42a 15w51b 16w05b 1.9-pre4 1.9 1.9.1-pre3 1.9.4 16w21b 1.10.2 1.11-pre1 1.11 1.12-pre5 1.12-pre7 1.12.1 1.12.2 17w50a 18w05a 18w10d 18w16a 1.13-pre3 1.13-pre4 1.13-pre5 1.13-pre6 1.13-pre7 1.13-pre8 1.13-pre9 1.13 18w30a 18w30b 18w31a 18w32a 18w33a 1.13.1-pre1 1.13.1-pre2 1.13.1 1.13.2-pre1 1.13.2-pre2 1.13.2 18w43a 18w43b 18w43c 18w44a 18w45a 18w46a 18w47a 18w47b 18w48a 18w48b 18w49a 18w50a 19w02a 19w03a 19w03b 19w03c 19w04b 19w05a 19w06a 19w07a 19w08a 19w08b 19w09a 19w11a 19w11b 19w12a 19w12b 19w13a 19w13b 19w14a 19w14b 1.14-pre1 1.14-pre2 1.14-pre3 1.14-pre4 1.14-pre5 1.14 1.14.1-pre1 1.14.1-pre2 1.14.1 1.14.2-pre1 1.14.2-pre2 1.14.2-pre3 1.14.2-pre4 1.14.2 1.14.3-pre2 1.14.3-pre3 1.14.3-pre4 1.14.3 1.14.4-pre1 1.14.4-pre2 1.14.4-pre3 1.14.4-pre4 1.14.4-pre5 1.14.4-pre6 1.14.4-pre7 1.14.4 19w34a 19w35a 19w36a 19w37a 19w38b 19w39a 19w40a 19w41a 1.15.2 20w17a 20w18a 20w19a 20w20a 20w20b 20w21a 20w22a 1.16-pre1 1.16-pre2 1.16-pre3 1.16-pre4 1.16-pre5 1.16-pre6 1.16-pre7 1.16-pre8 1.16-rc1 1.16 1.16.1 20w27a 20w28a 20w29a 20w30a 1.16.2-pre1 1.16.2-pre2 1.16.2-pre3 1.16.2-rc1 1.16.2 1.16.3 1.17.1 1.18.1 1.19 1.21.3- 16w38a
Created Issue:
Several cases where the target argument "r" behaves unexpectedly
The target specifier (argument) "r" behaves unexpectedly in several scenerios.
Scenerio 1
These experiments involve marker armorstands. 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 ArmorStand ~ ~ ~ {CustomName:A,Marker:X} /execute @e[name=A] ~ ~ ~ summon ArmorStand ~ ~ ~ {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 @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Kills A, works as expected
- Case 2: ArmorStand A is a marker, ArmorStand B is not a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Does not kill A, does not work as expected
- Case 3: ArmorStand A is a marker, ArmorStand B is a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Does not kill B, does not work as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Does not kill A, does not work as expected
Scenerio 2
These experiments involve all regular armorstands.Setup experiment
In this scenerio the armorstands involved in the testing were obtained as follows:/summon ArmorStand ~ ~ ~ {CustomName:A} /execute @e[name=A] ~ ~ ~ summon ArmorStand ~ ~1 ~1 {CustomName:B,NoGravity:1}Note that the NoGravity tag did not influence the results in anyway, you can leave it out when there is a block to support it. Also the results are the same in any direction, here was chosen for positive Z as relative coordinates.
Results experiment
We distinguish the following 2 actions
- Action 1:
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=1]Kills B, works as expected
- Action 2:
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=1]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:
"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.
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. This results in true for both commands.
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 first command results in a "distanceSqToCenter" of 1, which is <= to the radius of 1 * 1, but the second command has the target's "distanceSqToCenter" become 3, which is not <= 1, failing the selection.
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).
A radius of 0 does result in a required distance of 0; my reply was concerning a radius of 1 as well as the positioning of the entities from his comment.
On top of perusing the source with MCP, I also modded it a tiny bit it to give me feedback (didn't change any values, only added logger output and that's it). It would provide me with the necessary data I needed, which includes the radius bounding box, successful intersects of entity hitboxes in the radius bounding box, and then the resulting "distanceSqToCenter".
Of course, MCP does use 1.8 and not the current version, so there will be differences. They both have this same particular bug, though."
Environment
Windows 8.1 64 bit, Java 8 update 60
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
The target specifier (argument) "r" behaves unexpectedly in several scenerios.
Scenerio 1
These experiments involve marker armorstands. 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 ArmorStand ~ ~ ~ {CustomName:A,Marker:X} /execute @e[name=A] ~ ~ ~ summon ArmorStand ~ ~ ~ {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 @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Kills A, works as expected
- Case 2: ArmorStand A is a marker, ArmorStand B is not a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Does not kill A, does not work as expected
- Case 3: ArmorStand A is a marker, ArmorStand B is a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Does not kill B, does not work as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Does not kill A, does not work as expected
Scenerio 2
These experiments involve all regular armorstands.Setup experiment
In this scenerio the armorstands involved in the testing were obtained as follows:/summon ArmorStand ~ ~ ~ {CustomName:A} /execute @e[name=A] ~ ~ ~ summon ArmorStand ~ ~1 ~1 {CustomName:B,NoGravity:1}Note that the NoGravity tag did not influence the results in anyway, you can leave it out when there is a block to support it. Also the results are the same in any direction, here was chosen for positive Z as relative coordinates.
Results experiment
We distinguish the following 2 actions
- Action 1:
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=1]Kills B, works as expected
- Action 2:
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=1]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.
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. This results in true for both commands.
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 first command results in a "distanceSqToCenter" of 1, which is <= to the radius of 1 * 1, but the second command has the target's "distanceSqToCenter" become 3, which is not <= 1, failing the selection.
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).
A radius of 0 does result in a required distance of 0; my reply was concerning a radius of 1 as well as the positioning of the entities from his comment.
On top of perusing the source with MCP, I also modded it a tiny bit it to give me feedback (didn't change any values, only added logger output and that's it). It would provide me with the necessary data I needed, which includes the radius bounding box, successful intersects of entity hitboxes in the radius bounding box, and then the resulting "distanceSqToCenter".
Of course, MCP does use 1.8 and not the current version, so there will be differences. They both have this same particular bug, though."
Several cases where the target argument "r" behaves unexpectedlyTarget argument "r" behaves unexpectedly and inconsistently
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
is duplicated by
is duplicated by
The target specifier (argument) "r" behaves unexpectedly in several scenerios.
Scenerio 1
These experiments involve marker armorstands. 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 ArmorStand ~ ~ ~ {CustomName:A,Marker:X} /execute @e[name=A] ~ ~ ~ summon ArmorStand ~ ~ ~ {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 @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Kills A, works as expected
- Case 2: ArmorStand A is a marker, ArmorStand B is not a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Does not kill A, does not work as expected
- Case 3: ArmorStand A is a marker, ArmorStand B is a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Does not kill B, does not work as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Does not kill A, does not work as expected
Scenerio 2
These experiments involve all regular armorstands.Setup experiment
In this scenerio the armorstands involved in the testing were obtained as follows:/summon ArmorStand ~ ~ ~ {CustomName:A} /execute @e[name=A] ~ ~ ~ summon ArmorStand ~ ~1 ~1 {CustomName:B,NoGravity:1}Note that the NoGravity tag did not influence the results in anyway, you can leave it out when there is a block to support it. Also the results are the same in any direction, here was chosen for positive Z as relative coordinates.
Results experiment
We distinguish the following 2 actions
- Action 1:
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=1]Kills B, works as expected
- Action 2:
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=1]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.
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. This results in true for both commands.
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 first command results in a "distanceSqToCenter" of 1, which is <= to the radius of 1 * 1, but the second command has the target's "distanceSqToCenter" become 3, which is not <= 1, failing the selection.
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).
A radius of 0 does result in a required distance of 0; my reply was concerning a radius of 1 as well as the positioning of the entities from his comment.
On top of perusing the source with MCP, I also modded it a tiny bit it to give me feedback (didn't change any values, only added logger output and that's it). It would provide me with the necessary data I needed, which includes the radius bounding box, successful intersects of entity hitboxes in the radius bounding box, and then the resulting "distanceSqToCenter".
Of course, MCP does use 1.8 and not the current version, so there will be differences. They both have this same particular bug, though."
Setup experiment
In this scenerio the armorstands involved in the testing were obtained as follows:/summon ArmorStand ~ ~ ~ {CustomName:A,Marker:X} /execute @e[name=A] ~ ~ ~ summon ArmorStand ~ ~ ~ {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 @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Kills A, works as expected
- Case 2: ArmorStand A is a marker, ArmorStand B is not a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Does not kill A, does not work as expected
- Case 3: ArmorStand A is a marker, ArmorStand B is a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Does not kill B, does not work as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=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.
Target argument "r" behaves unexpectedly and inconsistentlyMarker armorstands cannot properly be tested for with target argument "r"
Marker armorstands cannot properly be tested for with target argument "r=0"
These experiments involve marker armorstands. 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 ArmorStand ~ ~ ~ {CustomName:A,Marker:X} /execute @e[name=A] ~ ~ ~ summon ArmorStand ~ ~ ~ {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 @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Kills A, works as expected
- Case 2: ArmorStand A is a marker, ArmorStand B is not a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Does not kill A, does not work as expected
- Case 3: ArmorStand A is a marker, ArmorStand B is a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Does not kill B, does not work as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=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.
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
[Mojang] Searge (Michael Stoyke)relates to
relates to
These experiments involve marker armorstands. 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 ArmorStand ~ ~ ~ {CustomName:A,Marker:X} /execute @e[name=A] ~ ~ ~ summon ArmorStand ~ ~ ~ {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 @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Kills A, works as expected
- Case 2: ArmorStand A is a marker, ArmorStand B is not a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Does not kill A, does not work as expected
- Case 3: ArmorStand A is a marker, ArmorStand B is a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Does not kill B, does not work as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=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 Marcono1234 can be found in this comment.
relates to
relates to
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
relates to
Issue is back!
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
These experiments involve marker armorstands. 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:/summonArmorStand ~ ~ ~ {CustomName:A,Marker:X} /execute @e[name=A] ~ ~ ~ summonArmorStand ~ ~ ~ {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 @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Kills A, works as expected
- Case 2: ArmorStand A is a marker, ArmorStand B is not a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Does not kill A, does not work as expected
- Case 3: ArmorStand A is a marker, ArmorStand B is a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Does not kill B, does not work as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=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 Marcono1234 can be found in this comment.
These experiments involve marker armorstands. 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 @e[name=A] ~ ~ ~ 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 @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Kills A, works as expected
- Case 2: ArmorStand A is a marker, ArmorStand B is not a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=0]Does not kill A, does not work as expected
- Case 3: ArmorStand A is a marker, ArmorStand B is a marker.
execute @e[name=A] ~ ~ ~ kill @e[name=B,r=0]Does not kill B, does not work as expected
execute @e[name=B] ~ ~ ~ kill @e[name=A,r=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 Marcono1234 can be found in this comment.
![[Mod] Skylinerw](../../../data/assets/gravatar/skylinerw.png){kind=small}
is duplicated by
Marker armorstands cannot properly be tested for with target argument "r=0" or "dy=0"
relates to
is duplicated by
relates to
relates to
relates to
is duplicated by
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
is duplicated by
[Mojang] Searge (Michael Stoyke)Marker armorstands cannot properly be tested for with target argument "r=0" or "dy=0"Entities without hitboxes cannot properly be tested for with target argument "distance=0" or "dy=0"
These experiments involve marker armorstands. 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 @e[name=A]~ ~ ~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 @e[name=A]~ ~ ~kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B]~ ~ ~kill @e[name=A,r=0]Kills A, works as expected
- Case 2: ArmorStand A is a marker, ArmorStand B is not a marker.
execute @e[name=A]~ ~ ~kill @e[name=B,r=0]Kills B, works as expected
execute @e[name=B]~ ~ ~kill @e[name=A,r=0]Does not kill A, does not work as expected
- Case 3: ArmorStand A is a marker, ArmorStand B is a marker.
execute @e[name=A]~ ~ ~kill @e[name=B,r=0]Does not kill B, does not work as expected
execute @e[name=B]~ ~ ~kill @e[name=A,r=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 Marcono1234 can be found in this comment.
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 Marcono1234 can be found in this comment.
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 Marcono1234 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
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
relates to
![[Mod] SPGoding](../../../data/avatars/users/44622.png){kind=small}
is duplicated by
relates to
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
![[Mod] Les3awe](../../../data/avatars/users/79847.png){kind=small}
(for the code analysis comment)This could be solved by expanding the bounding box by an additional 1 in the negative direction as well.
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] <- resultFor 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).
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
![[Mod] ManosSef](../../../data/avatars/users/61702.png){kind=small}
Forward resolving to MC-88533 in favor of the extensive information about the issue located there.
if you check for a Marker which is on the same y-level like you, while using a positiv dy you won't find the marker.
Steps for Reproduction:
0) position yourself at a steady position
1)
/summon ArmorStand ~1 ~ ~1 {Marker:1,NoGravity:1}
2)
/say @e[dx=2,dz=2,dy=10]
=> the ArmorStand won't be listed
Useful to know: If you summon the armorstand one block higher, it will be listed.
Note: May be related to MC-88533.
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.
- A repeating commandblock positioned at y=0 that fires:
/testfor @p[dx=X]
- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,dx=X]
- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[dx=X]
- 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.
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.
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.
This seems to be the same as MC-88533 which now effects all entities, not only marker armor stands.
I'd say collect them there
Actually duplicate of MC-88533
The information regarding dx, dy and dz are incorrect and missleading (I only tested it in 1.9-pre).
I asked before whether or not GamerGuppy tested this using Marker-ArmorStands. It turns out, that he only used regular ArmorStands, because Marker ArmorStands are affected by MC-88533.
Actually dx, dy and dz all work as expected (I only tested this without using x, y and z and only with values of 0).
The basebox for normal ArmorStands is just like he describes, but that is as I expected due to a hitbox check.
If you do the same tests using a chicken you get different results, because the hitbox of a chicken is smaller.
For instance is you summon a Chicken "B" with NoAI:1 exactly one block below an ArmorStand "A" with NoGravity:1 and run this command:
/execute @e[name=A] ~ ~ ~ /testfor @e[name=B,dx=0,dy=0,dz=0]
The Chicken will not be found, wich is exactly as expected.
If you use a non-Marker ArmorStand instead of the Chicken it is found, because the Hitbox now intersects with the block of "A".
This behaviour is exactly as I expected it and I wish to keep it this way.
I still fully support this bugreport regarding r, rm and c wich are affected by an extremely annoying bug
It's likely your issue is actually MC-88533. The player is not found because the origin of execution is not where you're expecting it to be, so the score isn't going to change.
Let's do a experiment :
Place 3 command blocks that you'll activate in this order :
/summon armor_stand ~ ~1 ~ {Tags:["A"],Marker:1}
/entitydata @e[tag=A] {Tags:["B"]}
/execute @e[tag=B] ~ ~ ~ say test
Everything will work as expected, and the armor_stand will say "test".
Now kill the armor_stand, and change the 3rd command with this :
/execute @e[tag=B] ~ ~ ~ kill @e[r=0]
Reactivate all the command blocks.
Strangely, the armor_stand won't be killed, and "Failed to execute 'kill @e[r=0]' as Armor Stand" will appear in the command output.
Kill the armor_stand again, and just set the marker's value in the 1st command block to 0.
Reactivate all the command blocks.
Now, the armor_stand was killed...
Initially, I thought that this bug is related to MC-88533, but the basic
/summon armor_stand ~ ~1 ~ {Tags:["A"],Marker:1}
&
/execute @e[tag=A] ~ ~ ~ kill @e[r=0]
works perfectly.
Are you sure it isn't MC-88533 you're seeing?
Hum, you're certainly right. It seems like more MC-88533 related
(
/summon armor_stand ~ ~1 ~
/execute @e[tag=A] ~ ~ ~ kill @e[r=0]
won't work now.
)
This would be MC-88533.
As a work-around, removing the Marker tag should help, but of course you may need it for what you're doing. You could otherwise use a different entity for marking position, such as an area_effect_cloud with a high Duration.
@skylinerw this affects dy too, are you sure it is related? and wasn't MC-88533 caused by a y coordinate without decimal places?
The second selector of the /stats entity command does not find area_effect_clouds that are in the center of a block when using r=0 or dy=?. This is related to MC-111144 and might even be a duplicate, but it does not behave exactly the same way and is probably not related to MC-88533.
Steps to reproduce:
/scoreboard objectives add STATS_TEST dummy
/scoreboard objectives setdisplay sidebar STATS_TEST
/kill @e[type=area_effect_cloud,name=statsTest]
/summon area_effect_cloud ~ ~0 ~ {CustomName:"statsTest",Duration:2147483647}/scoreboard players add @e[type=area_effect_cloud,name=statsTest] STATS_TEST 0
/stats entity @e[type=area_effect_cloud,name=statsTest] set SuccessCount @e[type=area_effect_cloud,name=statsTest,r=0,c=1] STATS_TEST
/execute @e[type=area_effect_cloud,name=statsTest] ~ ~ ~ testfor @p
After the execute-testfor command the area_effect_cloud should have a score of 1, but it has a score of 0. If I repeat the same experiment, but summon the area_effect_cloud at other y values and use other selectors instead of
r=0
these are the results:
| r=0 | r=1 | dy=0 | dy=1 | |
|---|---|---|---|---|
| ~-.00000000000001 |  |
|
|
|
| ~.0 |  |
|
|
|
| ~.00000000000001 | |
|
|
|
| ~.1 | |
|
|
|
| ~.4 | |
|
|
|
| ~.5 | |
|
|
|
| ~.6 | |
|
|
|
| ~.9 | |
|
|
|
| ~1 | |
|
|
|
Note that the relative coordinates are executed from a command block, so ~.0 relates to a y coordinate like 57.5. I could not observe any difference when modifying the x or z axis, this bug seems to only affect the y axis.
/tp @e[type=area_effect_cloud,name=statsTest] ~ ~ ~
summon falling_block ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:falling_block,Block:activator_rail,Time:1},{id:commandblock_minecart,Command:fill ~1 ~-2 ~1 ~9 ~-2 ~6 air},{id:commandblock_minecart,Command:setblock ~2 ~-2 ~6 command_block 5 {Command:scoreboard objectives add STATS_TEST dummy}},{id:commandblock_minecart,Command:setblock ~3 ~-2 ~6 chain_command_block 5 {auto:1,Command:scoreboard objectives setdisplay sidebar STATS_TEST}},{id:commandblock_minecart,Command:setblock ~4 ~-2 ~6 chain_command_block 5 {auto:1,Command:kill @e[type=area_effect_cloud,name=statsTest]}},{id:commandblock_minecart,Command:setblock ~5 ~-2 ~6 chain_command_block 5 {auto:1,Command:summon area_effect_cloud ~ ~ ~ {CustomName:"statsTest",Duration:2147483647}}},{id:commandblock_minecart,Command:setblock ~6 ~-2 ~6 chain_command_block 5 {auto:1,Command:scoreboard players add @e[type=area_effect_cloud,name=statsTest] STATS_TEST 0}},{id:commandblock_minecart,Command:setblock ~7 ~-2 ~6 chain_command_block 5 {auto:1,Command:stats entity @e[type=area_effect_cloud,name=statsTest] set SuccessCount @e[type=area_effect_cloud,name=statsTest,r=0,c=1] STATS_TEST}},{id:commandblock_minecart,Command:setblock ~8 ~-2 ~6 chain_command_block 5 {auto:1,Command:execute @e[type=area_effect_cloud,name=statsTest] ~ ~ ~ testfor @p}},{id:commandblock_minecart,Command:setblock ~ ~-2 ~ command_block},{id:commandblock_minecart,Command:setblock ~ ~2 ~ command_block 0 {Command:fill ~ ~-3 ~ ~ ~ ~ air}},{id:commandblock_minecart,Command:setblock ~ ~1 ~ redstone_block},{id:commandblock_minecart,Command:kill @e[type=commandblock_minecart,r=0]}]}
probably relates to MC-88533
when summoning a marker armorstand at the edge of a block and trying to make it detect itself using dx/dz it will fail.
Steps to reporduce:
1. summon one armorstand at a fixed position:
/summon armor_stand 5 5 5 {Marker:1,NoGravity:1}
2. try to make it detect itself using execute:
/execute @e[type=armor_stand] ~ ~ ~ /say @s[x=0,dx=10]
the command will fail. So will
@s[z=0,dz=10]
.
@s[y=0,dy=10]
on the other hand will succeed.
3. try the same thing with a fixed position not at the bottom of a block, like
5 5.5 5
-> it works now.
4. try the original coordinates with a non-marker armorstand
-> it works as well.
This is not a duplicate of MC-88533 because this also affects area_effect_clouds!
- Summon an aec
/summon area_effect_cloud ~ ~ ~ {CustomName:"\"statsTest\"",Duration:2147483647} - Print all entities that are not within radius 0 of themselfs:
/execute as @e at @s unless entity @e[distance=0] run say @s
Related to or maybe even a duplicate of MC-88533
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
raise an issue.
Please fix this ;_; i can't do it otherwise...
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
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...
You could add c=1
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!
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.Confirmed for
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.
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.Confirmed for 1.9-pre4
Confirmed for 1.9.1-pre3
How long has Searge been working on this?
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
In that case, how long has be been assigned to this?
Since 11/Feb/16 3:56 PM, like you can see in the activity feed.
confirmed up to 1.9.4
Confirmed for 16w21b
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.
Fixed for 16w38a
Confirmed fixed.
Back (or still, idk) in 16w42a for me.
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:
Confirmed for 1.11-pre1. Please reopen
Confirmed for 1.11. Hopefully this gets fixed soon.
Confirmed for 1.12-pre5.
Confirmed for 1.12-pre7
Can confirm for 1.12.2
Can confirm for 18w10d
Confirmed for 18w16a
confirmed for 1.13pre-3
Affects 1.13-pre4
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
Affects 1.13-pre6
Affects 1.13-pre7
And 1.13-pre8
And 1.13-pre9
And 1.13
And 18w30a
And 18w30b
Please do not mark unreleased versions as affected.
You don't have access to them yet.
And it's still here in 1.16.3
I found any markers can't be selected via volume.
(Workaround)
This does not occur in predicate's distance detection. Use that instead.
Still affects 1.17.1
still a problem in 1.18.1
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:
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).
Can confirm in 1.21.1 with marker entities