MC-95352Spatial 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.
- 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.
Environment
Not relevant; happens both on Windows/Mac
Linked Issues
Created Issue:
Spatial target arguments "r", "dx", "dy", "dz" behave unexpectedly and inconsistently
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
I decided to do experiments on all ways possible to test for an entity from a certain location:
- A repeating commandblock positioned at y=0 that fires:
/testfor @p[rm=X]- A repeating commandblock that checks at y=0 with target argument.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes from the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]
Fortunately the results showed there was no difference in how either of these commands performed. They all gave the same results.There was chosen for y=0 to eliminate any off-set. Do note however, that an entity positioned anywhere from y
se all gave consistently the same results. So there is no difference in the results b
Solutions & Discussion
The argument "rm" behaves fine as I'll explain in a bit.
Environment
Not relevant; happens both on Windows/Mac
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
I decided to do experiments on all ways possible to test for an entity from a certain location:
- A repeating commandblock positioned at y=0 that fires:
/testfor @p[rm=X]- A repeating commandblock that checks at y=0 with target argument.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes from the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]
Fortunately the results showed there was no difference in how either of these commands performed. They all gave the same results.There was chosen for y=0 to eliminate any off-set. Do note however, that an entity positioned anywhere from y
se all gave consistently the same results. So there is no difference in the results b
Solutions & Discussion
The argument "rm" behaves fine as I'll explain in a bit.
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
I decided to do experiments on all ways possible to test for an entity from a certain location:
- A repeating commandblock positioned at y=0 that fires:
/testfor @p[rm=X]- A repeating commandblock that checks at y=0 with target argument.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes from the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]Fortunately the results showed there was no difference in how either of these commands performed. They all gave the same results.
There was chosen for y=0 to eliminate any off-set. Do note however, that an entity positioned anywhere from y
se all gave consistently the same results. So there is no difference in the results b
Solutions & Discussion
The argument "rm" behaves fine as I'll explain in a bit.
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
I decided to do experiments on all ways possible to test for an entity from a certain location
:
- A repeating commandblock positioned at y=0 that fires:
/testfor @p[rm=X]- A repeating commandblock that checks at y=0 with target argument.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes from the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]Fortunately the results showed there was no difference in how either of these commands performed. They all gave the same results.
Therewas chosen for y=0 to eliminate any off-set. Do note however, thatan entity positioned anywhere from yse all gave consistently the same results. So there is no difference in the results b
Solutions & Discussion
The argument "rm" behaves fine as I'll explain in a bit.
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock that checks at y=0 with target argument.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes from the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Solutions & Discussion
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock
that checks at y=0with target argument./testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes
fromthe players own location at y=0./execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Solutions & Discussion
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Solutions & Discussion
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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. The full conversation can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/
Solutions & Discussion
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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. The full conversation can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/
Solutions & DiscussionThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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:
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 full conversation can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/
Solutions & Discussion
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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:
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 full conversation can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/
Solutions & DiscussionThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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 x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
The full conversation can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/
Solutions & Discussion
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.Thesecondrequirement&isif the "distanceSqToCenter" value (obtained fromthe target'scoordinates) is less than or equal to radius x radius.I can't say for sure the following is correct, but it appears that this is where the issue lies.The full conversation can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/
Solutions & DiscussionThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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 x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
The full conversation can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/
Solutions & Discussion
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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 x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
The full conversation can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/
Solutions & DiscussionThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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 x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
The full conversation can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/
Solutions & Discussion
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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 x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
The full conversation can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/
Solutions & DiscussionThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
The full conversation can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/
Solutions & Discussion
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
The full conversation can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/
Solutions & DiscussionThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
The full conversation can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/Results: target argument "r"
coming soonResults: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
The full conversation can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/Results: target argument "r"
coming soonResults: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y.
- execute @p ~ B ~ testfor @p[r=X]
I expect to detect for a players height -X+B+0.5 < Y < X+B+0.5- execute @p ~ B ~ testfor @p[rm=X]
I expect to detect for a players height -X+B+0.5 > Y > X+B+0.5- execute @p ~ B ~ testfor @p[dy=X]
I expect to detect for a players height B < Y < X+BThe 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/Results: target argument "r"
coming soonResults: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y.
- execute @p ~ B ~ testfor @p[r=X]
I expect to detect for a players height -X+B+0.5 < Y < X+B+0.5- execute @p ~ B ~ testfor @p[rm=X]
I expect to detect for a players height -X+B+0.5 > Y > X+B+0.5- execute @p ~ B ~ testfor @p[dy=X]
I expect to detect for a players height B < Y < X+BThe 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/Results: target argument "r"
coming soonResults: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y.
- execute @p ~ B ~ testfor @p[r=X]
I expect to detect for a players height -X+B+0.5 < Y < X+B+0.5- execute @p ~ B ~ testfor @p[rm=X]
I expect to detect for a players height -X+B+0.5 > Y > X+B+0.5- execute @p ~ B ~ testfor @p[dy=X]
I expect to detect for a players height B < Y < X+BThe 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/Results: target argument "r"
coming soonResults: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y.
execute @p ~ B ~testfor @p[r=X]
I expect to detect for a players height -X+B+0.5 < Y < X+B+0.5execute @p ~ B ~testfor @p[rm=X]
I expect to detect for a players height -X+B+0.5 > Y > X+B+0.5execute @p ~ B ~testfor @p[dy=X]
I expect to detect for a players heightB< Y < X+BThe 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/Results: target argument "r"
coming soonResults: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Results: target argument "r"
coming soonResults: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Results: target argument "r"
coming soonResults: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Results: target argument "r"
In the left table you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
In the right table you see the expected values as explained at the chapter "expectations".
coming soonResults: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Results: target argument "r"
In the left table you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
In the right table you see the expected values as explained at the chapter "expectations".
coming soonResults: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this error is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
Results: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Results: target argument "r"
Table 1 (left):here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.Table 2 (right):In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this error is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
Results: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this error is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
Results: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this error is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
Results: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more consistent the r argument behaves.Results: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more consistent the r argument behaves.Results: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more consistent the r argument behaves.Results: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more consistent the r argument behaves.Results: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more consistent the r argument behaves.Results: target argument "rm"
coming soonResults: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more consistent the r argument behaves.Results: target argument "rm"
As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently.Results: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more consistent the r argument behaves.Results: target argument "rm"
Asyou see there is no difference between the expected & actual values. The target argument rm behaves asexpected and consistently.Results: target argument "dy (& dx & dz)"
coming soonSolutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it fullfills the expectations and the more consistent the r argument behaves.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".
As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently.Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".
As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & is not expected me.Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it fullfills the expectations and the more consistent the r argument behaves.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".
As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently.Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".
As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & is not expected me.Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it fullfills the expectations and the more consistent the r argument behaves.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently.
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & is not expected me.
Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it fullfills the expectations and the more consistent the r argument behaves.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently.
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & is not expected me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it fullfills the expectations and the more consistent the r argument behaves.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm.
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & is not expected me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it fullfills the expectations and the more consistent the r argument behaves.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm.
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random &
isnot expected me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected in very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, but also those entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it fullfills the expectations and the more consistent the r argument behaves.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm.
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected
invery weird intervals. Even r=0 doesn't detect or interact with entities in that specific block,but alsothose entities 0.5 blocks below. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more itfullfills the expectations and the more consistent the r argument behaves.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player isfirst detected and the Y_max value (upperbound) of when the player islast detected.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm.
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 so kind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay.
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 wassokind 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay
.Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 ofthisexperiment was to execute a testfor command at a specific position(aty=0) and test for an entity right above or right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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.Expectation
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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.Expectation & Hypothesis
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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 0.5
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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.Expectation & Hypothesis
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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.Expectation & Hypothesis
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: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.
The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius x radius
. I can't say for sure the following is correct, but it appears that this is where the issue lies.
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 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 in a sphere of 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.5Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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.Expectation & Hypothesis
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: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 x 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 in a sphere of 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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.Expectation & Hypothesis
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: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 x 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 in a sphere
ofradius 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.5Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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.Expectation & Hypothesis
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: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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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.
Expectation & Hypothesis
A few monthsago 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: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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
How did I get my expectation values? (Why is it a bug)
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: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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
How did I get my expectation values? (Why is it a bug)
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: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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
How did I get my expectation values? (Why is it a bug)
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: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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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.
(empty line)
(empty line)
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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
(empty line)
(empty line)
Results
target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
How did I get my expectation values? (Why is it a bug)
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: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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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.
(empty line)
(empty line)
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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
(empty line)
(empty line)
Results
target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
How did I get my expectation values? (Why is it a bug)
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: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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results
target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
How did I get my expectation values? (Why is it a bug)
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: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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results
target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
How did I get my expectation values? (Why is it a bug)
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: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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
+ Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
How did I get my expectation values? (Why is it a bug)
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: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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
+Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
How did I get my expectation values? (Why is it a bug)
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: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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
How did I get my expectation values? (Why is it a bug)
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: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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
How did I get my expectation values? (Why is it a bug)
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: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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
How did I get my expectation values? (Why is it a bug)
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: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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
How did I get my expectation values? (Why is it a bug)
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: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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
How did I get my expectation values? (Why is it a bug)
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:
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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
How did I get my expectation values? (Why isit a bug)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:
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 x 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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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. 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)._
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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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. 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)._
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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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. 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)._
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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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. 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)._
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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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. 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).
_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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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.
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).
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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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.
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).
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
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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).
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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).
Computation of expectation values
Based on this information of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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).
Computation of expectation valuesBased on th
isinformation of I had the following expectations of detecting a player at height Y when executing a testfor command at y=0.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XThe 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/Solutions & Discussion
coming soonThis bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of expectation values
Based on the information of SkylinerW I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of expect
ationvaluesBased on the information of SkylinerW I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting + am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting
+ am afraid I'll loose my text).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XSolutions & Discussion
coming soon
This bug report is WIP. I'll be done within an hour (formatting).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < X
Solutions&Discussioncoming soon
This bug report is WIP. I'll be done within an hour (formatting).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accuractely 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 that
This bug report is WIP. I'll be done within an hour (formatting).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accuractely 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 thatThis bug report is WIP. I'll be done within an hour (formatting).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accuractely due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 bug report is WIP. I'll be done within an hour (formatting).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accura
ctely due to inconsistencies or unexpected behavior.I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 bug report is WIP. I'll be done within an hour (formatting).
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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.
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
[Mojang] Searge (Michael Stoyke)
is duplicated by
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, 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Table 1 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 2 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see players are detected at very weird intervals. Even r=0 doesn't detect or interact with entities in that specific block, as is commonly claimed and used in thousands of contraptions; it actually interacts with those entities 0.5 blocks below too. This is very counter-intutive and shows how unexpectedly the "r' target argument behaves. But this difference between the actual & expected values is inconsistent too and depends on the R value used. A quick visualization of this error shows something remarkable.
As you see the difference between the actual & expected values slowly converges to 0. This means that the greater the specified radius, the more it approaches the expected values and the more consistent the r argument behaves. This is very unfortunate, since many people very often use the argument for radii of between 0 and 5 at which the error is often greater then 0.1.Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Version: Actual Radius Point of 7b-Pre3 Pre3 Prior to 7a col A2 col A3 7a col B2 col B3 7b-Pre3 col B2 col B3 Pre3 col B2 col B3 Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Version: Actual Radius Point of 7b-Pre3 Pre3 Prior to 7a col A2col A37a col B2col B37b-Pre3 col B2col B3Pre3 col B2col B3Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Version: Actual Radius Point of search Prior to 7a Inconsistent Center of block 7a R Center of block entity is in 7b-Pre3 R+0.25 Center of bottom face of block entity is in Pre3 R+0.015625 Center of bottom face of block entity is in Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
Version: Actual Radius Point of search Prior to 7a Inconsistent Center of block 7a R Center of block entity is in 7b-Pre3 R+0.25 Center of bottom face of block entity is in Pre3 R+0.015625 Center of bottom face of block entity is in Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
In the following table you find the results for the behavior of 'r' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a Inconsistent Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
In the following table you find the results for the behavior of 'r' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a Inconsistent Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
In the following table you find the results for the behavior of 'r' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a Inconsistent Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "rm"
Table 3 (left): here you see the Y_min value (lowerbound) of when the player is last detected and the Y_max value (upperbound) of when the player is first detected again.
Table 4 (right):In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values. The target argument rm behaves as expected and consistently throughout all (positive) values of rm. Yay!
Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
In the following table you find the results for the behavior of 'r' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a Inconsistent Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "rm"
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=EntityB,rm=RM]EntityA is here located at [0.3, 0.3, 0.3] and 'RM' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 RM+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 RM+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "dy (& dx & dz)"
Table 5 (left): here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.
Table 6 (right): In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
In the following table you find the results for the behavior of 'r' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a Inconsistent Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "rm"
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=EntityB,rm=RM]EntityA is here located at [0.3, 0.3, 0.3] and 'RM' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 RM+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 RM+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "
dy (& dx & dz)"
Table 5 (left):here you see the Y_min value (lowerbound) of when the player is first detected and the Y_max value (upperbound) of when the player is last detected.Table 6 (right):In the right table you see the expected values as explained at the chapter "expectations".As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
In the following table you find the results for the behavior of 'r' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a Inconsistent Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "rm"
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=EntityB,rm=RM]EntityA is here located at [0.3, 0.3, 0.3] and 'RM' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 RM+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 RM+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,c=1]EntityA is here located at [0.3, 0.3, 0.3] and from there targets the neirest EntityB.
Version: Point of search Prior to 7a Bottom North West corner of block Entity A is in: [0.0, 0.0, 0.0] 7a Bottom North West corner of block Entity A is in: [0.0, 0.0, 0.0] 7b-Pre3 Bottom North West corner of block Entity A is in: [0.0, 0.0, 0.0] Pre3 Bottom North West corner of block Entity A is in: [0.0, 0.0, 0.0] As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
In the following table you find the results for the behavior of 'r' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a Inconsistent Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "rm"
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=EntityB,rm=RM]EntityA is here located at [0.3, 0.3, 0.3] and 'RM' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 RM+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 RM+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,c=1]EntityA is here located at [0.3, 0.3, 0.3] and from there targets the neirest EntityB.
Version: Point of search Prior to 7a Bottom North West corner of block Entity A is in: [0.0, 0.0, 0.0] 7a Bottom North West corner of block Entity A is in: [0.0, 0.0, 0.0] 7b-Pre3 Bottom North West corner of block Entity A is in: [0.0, 0.0, 0.0] Pre3 Bottom North West corner of block Entity A is in: [0.0, 0.0, 0.0] As you see there is no difference between the expected & actual values for the upperbound. However that lower bound of -1.8 seems completely random & was entirely not expected by me. For negative values of dy this -1.8 becomes more and more negative. (I thought dx, dy and dz were not specified for negative values?)
Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
In the following table you find the results for the behavior of 'r' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a Inconsistent Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "rm"
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=EntityB,rm=RM]EntityA is here located at [0.3, 0.3, 0.3] and 'RM' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 RM+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 RM+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,c=1]EntityA is here located at [0.3, 0.3, 0.3] and from there targets the neirest EntityB.
Version: Point of search Prior to 7a Bottom North West corner of block Entity A is in: [0.0, 0.0, 0.0] 7a Bottom North West corner of block Entity A is in: [0.0, 0.0, 0.0] 7b-Pre3 Bottom North West corner of block Entity A is in: [0.0, 0.0, 0.0] Pre3Bottom North West corner of block Entity A is in: [0. 0,0.0, 0.0]Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
In the following table you find the results for the behavior of 'r' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a Inconsistent Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "rm"
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=EntityB,rm=RM]EntityA is here located at [0.3, 0.3, 0.3] and 'RM' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 RM+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 RM+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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 (positive values, dx, dy, dz) Actual selection volume (negative values, dx, dy, dz) All Versions [-0.8, -1.8, -0.8] to [0.8+X, 1.0+Y, 0.8+Z] [-0.8-X, -1.8-Y, -0.8-Z] to [0.8, 1.0, 0.8] Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
In the following table you find the results for the behavior of 'r' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a Inconsistent Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "rm"
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=EntityB,rm=RM]EntityA is here located at [0.3, 0.3, 0.3] and 'RM' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 RM+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 RM+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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 itivevalues, dx, dy, dz)Actual selection volume (neg ativevalues, dx, dy, dz)All Versions [-0.8, -1.8, -0.8] to [0.8+X, 1.0+Y, 0.8+Z] [-0.8-X, -1.8-Y, -0.8-Z] to [0.8, 1.0, 0.8] Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
In the following table you find the results for the behavior of 'r' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a Inconsistent Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "rm"
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=EntityB,rm=RM]EntityA is here located at [0.3, 0.3, 0.3] and 'RM' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 RM+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 RM+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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.8, -1.8, -0.8] to [0.8+X, 1.0+Y, 0.8+Z] [-0.8-X, -1.8-Y, -0.8-Z] to [0.8, 1.0, 0.8] Why is this a bug?
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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
In the following table you find the results for the behavior of 'r' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a Inconsistent Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "rm"
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=EntityB,rm=RM]EntityA is here located at [0.3, 0.3, 0.3] and 'RM' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 RM+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 RM+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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.8, -1.8, -0.8] to [0.8+X, 1.0+Y, 0.8+Z] [-0.8-X, -1.8-Y, -0.8-Z] to [0.8, 1.0, 0.8] Why is this a bug?
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 ofthisconversation 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/Computation of "expected values"
Based on the information of SkylinerW, as well as some of my own experience with commandblocks, I had the following expectations of detecting a player at height Y when executing a testfor command at y=0. This is how I computed the expectation values in the experiments above too.
- testfor @p[r=X]
I expect to detect for a players height -X+0.5 < Y < X+0.5- testfor @p[rm=X]
I expect to detect for a players height -X+0.5 > Y > X+0.5- testfor @p[dy=X]
I expect to detect for a players height 0 < Y < XDiscussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r"
In the following table you find the results for the behavior of 'r' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a Inconsistent Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "rm"
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=EntityB,rm=RM]EntityA is here located at [0.3, 0.3, 0.3] and 'RM' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 RM+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 RM+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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.8, -1.8, -0.8] to [0.8+X, 1.0+Y, 0.8+Z] [-0.8-X, -1.8-Y, -0.8-Z] to [0.8, 1.0, 0.8] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "rm"
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=EntityB,rm=RM]EntityA is here located at [0.3, 0.3, 0.3] and 'RM' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 RM+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 RM+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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.8, -1.8, -0.8] to [0.8+X, 1.0+Y, 0.8+Z] [-0.8-X, -1.8-Y, -0.8-Z] to [0.8, 1.0, 0.8] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Results: target argument "
rm"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=EntityB,rm=RM]EntityA is here located at [0.3, 0.3, 0.3] and
'RM' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7a RM Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 RM+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 RM+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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.8, -1.8, -0.8] to [0.8+X, 1.0+Y, 0.8+Z] [-0.8-X, -1.8-Y, -0.8-Z] to [0.8, 1.0, 0.8] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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.8, -1.8, -0.8] to [0.8+X, 1.0+Y, 0.8+Z] [-0.8-X, -1.8-Y, -0.8-Z] to [0.8, 1.0, 0.8] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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.
Spatial target arguments "r", "rm", "c", "dx", "dy", "dz" behave unexpectedly and inconsistently
This is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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.8, -1.8, -0.8] to [0.8+X, 1.0+Y, 0.8+Z] [-0.8-X, -1.8-Y, -0.8-Z] to [0.8, 1.0, 0.8]
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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.8, -1.8, -0.8] to [0.8+X, 1.0+Y, 0.8+Z] [-0.8-X, -1.8-Y, -0.8-Z] to [0.8, 1.0, 0.8]
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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. 8, -1.8, -0.8] to [0.8+X, 1.0+Y,0.8+Z][-0. 8-X, -1.8-Y, -0.8-Z] to [0.8, 1.0,0.8]
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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] 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.
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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] 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.
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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] 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.
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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] 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.
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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.
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,c=1]EntityA is here located at [0.3, 0.3, 0.3] and from there targets the neirest EntityB.
Version: Point of searchAll versions Bottom North West corner of block Entity A is in: [0.0, 0.0, 0.0] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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.8, -1.8, -0.8] to [0.8+X, 1.0+Y, 0.8+Z] [-0.8-X, -1.8-Y, -0.8-Z] to [0.8, 1.0, 0.8]
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] 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. 8, -1.8, -0.8] to [0.8+X, 1.0+Y,0.8+Z][-0. 8-X, -1.8-Y, -0.8-Z] to [0.8, 1.0,0.8]
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] Visualizing problem
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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=EntityB,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 Entity A is in: [0.0, 0.0, 0.0] Visualizing problem
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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 Entity A 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.
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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 Entity A 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.
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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 Entity A 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.
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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 Entity A 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.
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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Visualizing problem
The image belows shows the behavior of the 'r' and 'rm' argument for several MC versions. When making this image the inconsistency in the 'r' argument prior to 7a was disregarded.Proposed behavior
In the ideal solution 'r' and 'rm' would target, when executed from an entity, at the exact place of that entity. If this is not possible, I think executing it from the center of the block is best with a small addition of 0.5 added to the specified value of the radius. This means that r=0, corresponds with a sphere with a radius of 0.5. The radius 'touches' the sides of the block, or in other words, is confined within a single block. This way also entities are detected that find themselves with their feet on the center of a block.
Version: Actual Radius Point of search Ideal Solution R Exact location of EntityA Sub-Ideal solution R+0.5 Center of block EntityA is in: [0.5, 0.5, 0.5] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Visualizing problem
The image belows shows the behavior of the 'r' and 'rm' argument for several MC versions. When making this image the inconsistency in the 'r' argument prior to 7a was disregarded.Proposed behavior
In the ideal solution 'r' and 'rm' would target, when executed from an entity, at the exact place of that entity. If this is not possible, I think executing it from the center of the block is best with a small addition of 0.5 added to the specified value of the radius. This means that r=0, corresponds with a sphere with a radius of 0.5. The radius 'touches' the sides of the block, or in other words, is confined within a single block. This way also entities are detected that find themselves with their feet on the center of a block.
Version: Actual Radius Point of search Ideal Solution R Exact location of EntityA Sub-Ideal solution R+0.5 Center of block EntityA is in: [0.5, 0.5, 0.5] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Visualizing problem
The image belows shows the behavior of the 'r' and 'rm' argument for several MC versions. When making this image the inconsistency in the 'r' argument prior to 7a was disregarded.
Proposed behavior
In the ideal solution 'r' and 'rm' would target, when executed from an entity, at the exact place of that entity. If this is not possible, I think executing it from the center of the block is best with a small addition of 0.5 added to the specified value of the radius. This means that r=0, corresponds with a sphere with a radius of 0.5. The radius 'touches' the sides of the block, or in other words, is confined within a single block. This way also entities are detected that find themselves with their feet on the center of a block.
Version: Actual Radius Point of search Ideal Solution R Exact location of EntityA Sub-Ideal solution R+0.5 Center of block EntityA is in: [0.5, 0.5, 0.5] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Visualizing problem
The image belows shows the behavior of the 'r' and 'rm' argument for several MC versions. When making this image the inconsistency in the 'r' argument prior to 7a was disregarded.
Proposed behavior
In the ideal solution 'r' and 'rm' would target, when executed from an entity, at the exact place of that entity. If this is not possible, I think executing it from the center of the block is best with a small addition of 0.5 added to the specified value of the radius. This means that r=0, corresponds with a sphere with a radius of 0.5. The radius 'touches' the sides of the block, or in other words, is confined within a single block. This way also entities are detected that find themselves with their feet on the center of a block.
Version: Actual Radius Point of search Ideal Solution R Exact location of EntityA Sub-Ideal solution R+0.5 Center of block EntityA is in: [0.5, 0.5, 0.5] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Visualizing problem
The image belows shows the behavior of the 'r' and 'rm' argument for several MC versions. When making this image the inconsistency in the 'r' argument prior to 7a was disregarded.
Proposed behavior
In the ideal solution 'r' and 'rm' would target, when executed from an entity, at the exact place of that entity. If this is not possible, I think executing it from the center of the block is best with a small addition of 0.5 added to the specified value of the radius. This means that r=0, corresponds with a sphere with a radius of 0.5. The radius 'touches' the sides of the block, or in other words, is confined within a single block. This way also entities are detected that find themselves with their feet on the center of a block.
Version: Actual Radius Point of search Ideal Solution R Exact location of EntityA Sub-Ideal solution R+0.5 Center of block EntityA is in: [0.5, 0.5, 0.5] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Visualizing problem
The image belows shows the behavior of the 'r' and 'rm' argument for several MC versions. When making this image the inconsistency in the 'r' argument prior to 7a was disregarded.
Proposed behavior
In the ideal solution 'r' and 'rm' would target, when executed from an entity, at the exact place of that entity. If this is not possible, I think executing it from the center of the block is best with a small addition of 0.5 added to the specified value of the radius. This means that r=0, corresponds with a sphere with a radius of 0.5. The radius 'touches' the sides of the block, or in other words, is confined within a single block. This way also entities are detected that find themselves with their feet on the center of a block.
Version: Actual Radius Point of search Ideal Solution R Exact location of EntityA Sub-Ideal solution R+0.5 Center of block EntityA is in: [0.5, 0.5, 0.5] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Visualizing problem
The image belows shows the behavior of the 'r' and 'rm' argument for several MC versions. When making this image the inconsistency in the 'r' argument prior to 7a was disregarded.
Proposed behavior
In the ideal solution 'r' and 'rm' would target, when executed from an entity, at the exact place of that entity. If this is not possible, I think executing it from the center of the block is best with a small addition of 0.5 added to the specified value of the radius. This means that r=0, corresponds with a sphere with a radius of 0.5. The radius 'touches' the sides of the block, or in other words, is confined within a single block. This way also entities are detected that find themselves with their feet on the center of a block.
Version: Actual Radius Point of search Ideal Solution R Exact location of EntityA Sub-Ideal solution R+0.5 Center of block EntityA is in: [0.5, 0.5, 0.5] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 is no copy of MC-88533. That one concerns marker armorstands.
CURRENTLY BEING MODIFIED, APOLOGIES FOR INCONVENIENCE.
___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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Visualizing problem
The image belows shows the behavior of the 'r' and 'rm' argument for several MC versions. When making this image the inconsistency in the 'r' argument prior to 7a was disregarded.
Proposed behavior
In the ideal solution 'r' and 'rm' would target, when executed from an entity, at the exact place of that entity. If this is not possible, I think executing it from the center of the block is best with a small addition of 0.5 added to the specified value of the radius. This means that r=0, corresponds with a sphere with a radius of 0.5. The radius 'touches' the sides of the block, or in other words, is confined within a single block. This way also entities are detected that find themselves with their feet on the center of a block.
Version: Actual Radius Point of search Ideal Solution R Exact location of EntityA Sub-Ideal solution R+0.5 Center of block EntityA is in: [0.5, 0.5, 0.5] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.
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 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Visualizing problem
The image belows shows the behavior of the 'r' and 'rm' argument for several MC versions. When making this image the inconsistency in the 'r' argument prior to 7a was disregarded.
Proposed behavior
In the ideal solution 'r' and 'rm' would target, when executed from an entity, at the exact place of that entity. If this is not possible, I think executing it from the center of the block is best with a small addition of 0.5 added to the specified value of the radius. This means that r=0, corresponds with a sphere with a radius of 0.5. The radius 'touches' the sides of the block, or in other words, is confined within a single block. This way also entities are detected that find themselves with their feet on the center of a block.
Version: Actual Radius Point of search Ideal Solution R Exact location of EntityA Sub-Ideal solution R+0.5 Center of block EntityA is in: [0.5, 0.5, 0.5] 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, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
I have trouble to figure out about what is going on with the r argument. The problem with the dx, dy and dz argument should be relatively easy to solve since there is just a weird lowerbound of -1.8 that should be set to 0.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 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Visualizing problem
The image belows shows the behavior of the 'r' and 'rm' argument for several MC versions. When making this image the inconsistency in the 'r' argument prior to 7a was disregarded.
Proposed behavior
In the ideal solution 'r' and 'rm' would target, when executed from an entity, at the exact place of that entity. If this is not possible, I think executing it from the center of the block is best with a small addition of 0.5 added to the specified value of the radius. This means that r=0, corresponds with a sphere with a radius of 0.5. The radius 'touches' the sides of the block, or in other words, is confined within a single block. This way also entities are detected that find themselves with their feet on the center of a block.
Version: Actual Radius Point of search Ideal Solution R Exact location of EntityA Sub-Ideal solution R+0.5 Center of block EntityA is in: [0.5, 0.5, 0.5] 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 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 thatshould 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Visualizing problem
The image belows shows the behavior of the 'r' and 'rm' argument for several MC versions. When making this image the inconsistency in the 'r' argument prior to 7a was disregarded.
Proposed behavior
In the ideal solution 'r' and 'rm' would target, when executed from an entity, at the exact place of that entity. If this is not possible, I think executing it from the center of the block is best with a small addition of 0.5 added to the specified value of the radius. This means that r=0, corresponds with a sphere with a radius of 0.5. The radius 'touches' the sides of the block, or in other words, is confined within a single block. This way also entities are detected that find themselves with their feet on the center of a block.
Version: Actual Radius Point of search Ideal Solution R Exact location of EntityA Sub-Ideal solution R+0.5 Center of block EntityA is in: [0.5, 0.5, 0.5] 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 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "r" & "rm"
In the following table you find the results for the behavior of 'r' & 'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and 'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Visualizing problem
The image belows shows the behavior of the 'r' and 'rm' argument for several MC versions. When making this image the inconsistency in the 'r' argument prior to 7a was disregarded.
Proposed behavior
In the ideal solution 'r' and 'rm' would target, when executed from an entity, at the exact place of that entity. If this is not possible, I think executing it from the center of the block is best with a small addition of 0.5 added to the specified value of the radius. This means that r=0, corresponds with a sphere with a radius of 0.5. The radius 'touches' the sides of the block, or in other words, is confined within a single block. This way also entities are detected that find themselves with their feet on the center of a block.
Version: Actual Radius Point of search Ideal Solution R Exact location of EntityA Sub-Ideal solution R+0.5 Center of block EntityA is in: [0.5, 0.5, 0.5] 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 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
Results: target argument "
r" & "rm"In the following table you find the results for the behavior of
'r' &'rm' for various versions of MC.
To interpret this table correctly, consider the command:/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,r(m)=R]EntityA is here located at [0.3, 0.3, 0.3] and
'R' is a numerical integer value for the radius.
Version: Actual Radius Point of search Prior to 7a R (Inconsistent for 'r') Center of block EntityA is in: [0.5, 0.5, 0.5] 7a R Center of block EntityA is in: [0.5, 0.5, 0.5] 7b-Pre3 R+0.25 Center of bottom face of of block EntityA is in: [0.5, 0.0, 0.5] Pre3 R+0.015625 Center of bottom face of block EntityA is in: [0.5, 0.0, 0.5] Visualizing problem
The image belows shows the behavior of the 'r' and 'rm' argument for several MC versions. When making this image the inconsistency in the 'r' argument prior to 7a was disregarded.
Proposed behavior
In the ideal solution 'r' and 'rm' would target, when executed from an entity, at the exact place of that entity. If this is not possible, I think executing it from the center of the block is best with a small addition of 0.5 added to the specified value of the radius. This means that r=0, corresponds with a sphere with a radius of 0.5. The radius 'touches' the sides of the block, or in other words, is confined within a single block. This way also entities are detected that find themselves with their feet on the center of a block.
Version: Actual Radius Point of search Ideal Solution R Exact location of EntityA Sub-Ideal solution R+0.5 Center of block EntityA is in: [0.5, 0.5, 0.5] 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 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 right below it for a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to the position of an entity along the verticial y-axis only, though a quick test showed the exact same values would be obtained in the x & z directions too.
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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
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.
Spatial target arguments"r", "rm","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
rightbelow itfor a given value of the target argument being investigated. Then I would write down the lowest value of the y coordinate (lowerbound) and the highest value of the y coordinate (upperbound) that resulted into a succesful testfor.
As you can see I've chosen to limit this experiment to theposition of an entity along the verticial y-axis only,though a quick test showed the exact same values would be obtained in the x & z directions too.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[rm=X]- A repeating commandblock with target argument at y=0.
/testfor @p[y=0,rm=X]- A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[rm=X]- A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[rm=X]As coordinate of execution was chosen for y=0 to eliminate any off-set. Do note however, that in the case of method 3 with an entity, the entity can be positioned anywhere between [0,1), and it will give the same results. This also goes for method 4, ~ ~Y ~ as long as Y lies between [0,1).
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 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.
anybody else still able to reproduce?
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.
Possibly related to the fix of MC-95352.
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.
I am probably the cause for the change in behavior of "r", since I submitted MC-95352. My apologies.
In the strict sense, the "r" argument is now working as it should. Let me explain. Whenever you execute a command, it is not really executed at the entities location, but rather the exact center of the block the entity is in. This has always been the case. That means that with the new behavior of "r", that with r=0, you will only target an entity if that entity is at the exact center of the block.
However... I do understand that many people, including me, used r=0 as a way to target all entities within a certain block. Many of my contraptions are broken too. I therefore hope that r=0 will maybe get an exception to the new and improved behavior of the "r" argument, and get it's old behavior back. Or that dy=0 replaces that functionality. However now we don't seem to have any way to interact with entities in a particular block anymore.
MC-95352 should (or will soon) cover that.
![[Mod] Skylinerw](../../../data/assets/gravatar/skylinerw.png){kind=small}
This is an intentional change due to inaccuracies in how radius had worked prior. You can use the delta parameters instead of radius to target blockspace:
/testfor @a[0,128,0,dx=0]
MC-95352 was where the fix was introduced and went through a couple phases before being finalized.
it's beautiful!
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).
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
Now this is working much worse.
This is related to:
MC-97178r=0 can't find all entities in the same position as the one it is executing command and the executer.
VarHar, you can just use /say @p
Not if you want it to say all entities in your space
In the strict sense, the "r" argument is now working as it should. Let me explain. Whenever you execute a command, it is not really executed at the entities location, but rather the exact center of the block the entity is in. This has always been the case. That means that with the new behavior of "r", that with r=0, you will only target an entity if that entity is at the exact center of the block.
However... I do understand that many people, including me, used r=0 as a way to target all entities within a certain block. Many of my contraptions are broken too. I therefore hope that r=0 will maybe get an exception to the new and improved behavior of the "r" argument, and get it's old behavior back. Or that dy=0 replaces that functionality. However now we don't seem to have any way to interact with entities in a particular block anymore.
I hope that mojang makes some of these arguments more useful.
For example, [y=0] should select anything with y atleast 0.
[y=0,dy=10] should select anything between y=0 and y=10.
[y=!0] should detect anything in the void under y=0.
[y=!-64,score_deaths_min=1] could be used to detect a player who died in the void.
That way we could select entitys in specific areas of the world more easily.
Since the old mechanics are pretty broken, these changes wouldn't conflict with many old designs.
Because this bug is "fixed" pretty much none of my commandblock systems are working anymore. Some can not even be repaired I think.
For example: I used a testfor command with r=0 to detect when the hitbox of the player entered the same block as an Armorstand.
I don't think that is possible any more.
hey, thanks to GamerGuppy and Robert Schuh for explanation.
And to Adrian Uffmann:
I think you can use r=1, as old r=0, it's going to detect entities on this very block.
It's not really fixed in 16w07b.
15Redstones Can you elaborate?
How so?
So in 06a everything worked exactly as it should. But I guess many people complained since their contraptions were no longer working. But with the 06b snapshot things changed once again, and in my humble opinion, for the worse. Let me clarify for those interested:
Let's consider the command /execute @e[name=A] ~ ~ ~ testfor @e[name=B,r=0]
Snapshot 06a and below (also MC 1.8):
In case entity A was standing at e.g. (0.8, 0.3, 0.4) the testfor command would be executed at (0.5, 0.5, 0.5). Also known as the center of the block entity A is in, and from there would test for the position of entity B.
Snapshot 06b:
In case entity A was standing at e.g. (0.8, 0.3, 0.4) the testfor command would be executed at (0.5, 0.0, 0.5). Also known as the center of the bottom face of the block entity A is in, and from there would test for the position of entity B.
This offset in point of execution might even lead to more contraptions being broken and other diffeculties with contraptions in the future since it is very counter intutive. Because let's face it; the most intuitive thing, would be if a command would be executed right at the position of entity A. The center of the block worked reasonably well too. But it will be very hard to explain new players that a command will be executed at the center of the bottom face of the block entity A is in.
But thats not the only change, let's now focus on the position of B that is required for a succesful testfor, considering the same command again.
In MC 1.8
In MC 1.8 the required position of B was inconsistent and behaved weirdly with the radius used. Hence this bug-report. Since the command was executed at the center of the block, a radius of r=0 would imply that entity B must be at the very center to be succesfully detected. However as you know, this was not the case. Entity B could be anywhere within the block and still be detected. This is why many people (falsely) assumed r=0 would only target the entities within that specific block. In reality you could think of a sphere with radius 1 around the point (0.5, 0.5, 0.5) in which all entities would be tested for. Which is weird because our radius was r=0 right?
In 06a
In 06a r=0 indeed meant the entity B had to be at the exact center of the block in order to be tested for. Hence a radius of 0. A radius of r=1 now gives exactly the same functionality as r=0 did in MC 1.8. Which is now logical.
In 06b
In 0.6b a radius r=0 no longer corresponds with a sphere with radius 0, but instead a radius of 0.25. Also r=1 corresponds to a sphere of radius 1.25. This is probably a fix such that r=0 is not completely useless.
Conclusion & advice
The current state, as of 06b, the radius selector is again very counter-intutive. The y-offset is hard to work with, and the 0.25 added to the radius feels random. I would seriously consider either reverting back to 06a or choose to have commands once again be executed at the center of a block with 0.5 added to the radius instead of 0.25. My reasoning for this is that this way, with r=0, you get a sphere, with radius 0.5, that is enclosed by the block entity A is in, in which B can be succesfully tested for. This is convenient and intutive to work with. I hope you understand all of the above, because it's terribly diffecult to explain these things in words and English is not my native language.
What about considering making r= and c= run from the entity position itself rather than the block location?
I think the ideal solution to this would be making r= and c= run from the entity position, yes. That way, r=0 is a single point (which it would be, with radius 0), but can still be used, as it would work regardless of where in the block the entity is. In fact, it'd be even more useful than the old r=0 c=1 method, as that could be tricked if another entity is in the same block.
I agree, the radius "r" and "rm" target selectors correspond to euclidean distances and it would make sense if these are executed based on the position of the entity instead of the center of the block. Dx, dy and dz on the other hand are more like "Manhattan" distances, and it would make sense if these snap to the grid. Meaning dx=0 test everything in the block the entity is in, and with dx=1, also everything that is in the block besides it. Combinations of the 2 would give a commandblock user powerful tools to precisely select specific entities.
Ok, I made a new report to point the problem.
MC-97316- Executing a command from command block minecart and via /execute is running from middle of block instead of the position of entityIf I could I would upvote GamerGuppy's last comment. I think that is exactly how it should be done!
Since I've noticed there is a lot of misunderstanding & misinterpretation of this bug, I've made this:
http://imgur.com/bR6eRjL
I feel the discussion has become very scattered over many seperate bug reports, that often have a far too specific title whereas the problem is more general.
This bug report is not even fixed; namely, the dx, dy and dz problem still persists and has remain untouched by the update. Also, with 07b 'r' and 'rm' behave once again unexpectedly.
I feel this bug report should therefore be reopened.
Reopened, please make sure the description describes the current issue accurately.
GamerGuppy did you use Marker Armorstands for your tests or did they have a hitbox? While I do agree with most of your previous post I like the fact, that dx, dy and dz detect a player slightly before he enteres a block. I thought this was due to a hitbox check, but maybe it is just the 1.6 horizontal and 2.8 vertical width. For most Entities with a hitbox like Players, Armorstands, Zombies, … I prefer the current way this works. I do agree however that this does not make a lot of sence for stuff like marker Armorstands, chickens or slimes.
I had very limited time the last 2 days to update this report, but I think I'll manage to by this evening.
r=0 doesn't even select self anymore unless I'm in a coordinate that's a multiple of ~0.5 ~ ~0.5.
r/rm selectors (even dx/dy/dz selectors) snapping to a grid at all frustrates me greatly, and conflicts with the design differences between entities and blocks.
We're trying to select an ENTITY, whose coordinates are floating-point numbers, not blocks whose positions are quantized. This isn't a testforblock-like argument, it's one that specifically selects bounds (almost always) from the point of an entity (and if not, we already have coordinate parameters to execute from specific coords) in order to select other entities, whose coordinates are NOT fixed by integers and whose coordinates are almost never neatly multiples of 0.5. It makes absolutely no sense to snap them to grid.
This is particularly frustrating when trying to summon new objects that need specific parameters, since we can't just Summon entities with Scoreboard variables pre-set (another baffling decision). In my specific case, I have different ArmorStands with different types that suit different needs based on what entity they're Summoned by, and I make that difference with a Scoreboard variable, called StandType. I toss an Item or other entity out that summons an ArmorStand in the first Tick of its existence, and in that first Tick it assigns that ArmorStand a StandType, because again, I can't Summon with Scoreboard variables--this is already a workaround, and it's worked fine so far!
If it executes from the center of the nearest block, [r=1,c=1] will not select the appropriate ArmorStand if there's another ArmorStand nearer to the center of execution in a 3-block diameter sphere. There wouldn't a workaround for it either, it would just break many possibilities for Command Blocks. It's already broken a significant chunk of a project I've worked on for months, and there doesn't seem to be any immediate need for it or any increased flexibility. I don't want to have to refactor hundreds of lines of script and spend more countless hours debugging on this.
@Allen Taylor I absolutely agree with you in r and c arguments, but dx, dy and dz need to snap to the grid, because they are often used with integer coordinates (x, y and z)
For r and c this is indeed an extremly frustrating bug.
I've almost completely rewritten this bug report to reflect the current situation & include new input from the community. If you spot any errors or flaws please inform me.
Well described. Now this report covers mine:
MC-97316, so mine can be closed as duplication of this one.Hope it will be fixed for selectors for 1.9 or at least in minor patch (1.9.X)
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
Hey Adrian!
Thanks for checking and verifying my information, that's an important and right thing to do.
However I must inform you that a hitbox (should) not have any effect on
-from which location (EntityA) a target argument starts targeting from
-nor where it starts detecting an entity (EntityB).
The only thing that should matter as of now is:
-The block the feet of EntityA is in
-Where the feet of EntityB are
I think you are mislead to believe that hitbox matters due to another bug regarding Marker ArmorStands.
https://bugs.mojang.com/browse/MC-88533
If you repeat the same test for EntityEffectClouds without a hitbox, everything is just fine.
Whoops, I misinterpreted one aspect of your test. I'll run some tests to see whether I can confirm it.
Thanks for notifying me.
Hitbox of entity should not affect the tests. Chicken with the same Pos as Armor_stand, horse or enderman should result the same when checked with dx, dy, dz.
The only disadventage of dx,dy,dz being grid-like, and r,rm being Pos-like is that when using dx,dy,dz and r in one command whould be a bit confising. But I don't think so that it would be used often. Still I think dx,dy,dz should check for entities in specified blocks in grid, and r,rm should check distance from place where the command is executed grid-independent.
I do not agree with you Michael: I think hitboxes should continue to play a role when selecting entities with dx, dy and dz. I can think of many situations where this is better, but I currently can't think of a single situation where it would be better without the hitbox check.
I do agree, that it might be confusing when using both r and dx, ... in one selector, but I also agree, that that is an extremly rare use case.
Hey Adrian,
I did not do any tests on your claim yet, since I still have work to do. However, my 'gut-feeling' says that a hitbox will not have any effect on commands or 'dx, dy & dz' target selectors at all.
With this I mean that they never did so in the past either. As I said, I think you are confused by the other bug concerning marker armorstands.
That said, I do understand and even share your frustration on this, but I feel at the same time there is some logic behind it:
Namely, when you execute from EntityA a command containing the arguments 'r', 'rm', 'dx', 'dy', or 'dz', you could mathematically think of it as 3d volume where EntityB should be in, in order to be succesfully targeted. So for 'r' and 'rm' this volume is a sphere with a specified radius, and for dx, dy & dz a cube of specified dimensions.
If the location of EntityB is only defined by it's feet, in mathematical terms, a 'point in 3d space', then it's a very easy and cheap operation to check if this point lies within the specified volume. However if the location of EntityB is defined by it's hitbox, then it becomes suddenly a much more complicated mathematical problem. Even if the hitbox is just a cube, then you'll need to do a test for each edge (12 on a cube) whether it intersects the specified volume. I mean... it's doable, but I think it will cost quite some performance. Also I must admit there are some tricks to enhance performance... in case you're really interested; http://www.realtimerendering.com/intersections.html.
-Gups
Can someone confirm r runs from entities now in pre-4?
Guppy, could you test if related commands work smoothly/flawless/as desired now?
Wow, I only just read it. Can't wait till I get home to do some testing
Thank you Devs!
From my testing r and rm work correctly now, but c ist still executed from the bottom-west-north corner of the block. (In 1.9-pre4)
Can confirm. r and rm are working as intended in 1.9 pre 4.
{CustomName:"Arrows"}Made some tests.
Shot 1 arrow and renamed it:
/entitydata @e
than shot many arrows around it.
with command:
/execute @e[name=Arrows] ~ ~ ~ /kill @e[rm=0,type=!Player]
All arrows but one disappeared as intended.
with command
/execute @e[name=Arrows] ~ ~ ~ /kill @e[r=0]
only renamed disappeared as intended.
Also stacked (as passengers) command block minecarts are disappearing when one is with /kill @e[r=0]
AWESOME! ^^
Also, can you add affected version 1.9 pre 4? Still c, dx, dy, dz are not working as intended. (dx, dy, dz are checking if hitbox enters a grid instead of pos of entity, and c is not looking for nearest entity to execution)
So shall
MC-96927be closed after all?Just checking, Onnowhere said it can be closed (if this bugpost stays open that is, but I see only
MC-97316being closed as resolved so I'm guessing this here stays open? If so, ignore my comment onMC-96927😸)@GamerGuppy: Please let us know if we can mark this fixed in 1.9-pre4.
[Mod] redstonehelper, this bug is only partially fixed (r,rm). Most of this one (c,dx,dy,dz) is still affecting 1.9 pre 4.
Meri Diana please do not create links to the bug reports but instead just write their names, for example
This has these advantages:
Marcono1234 Didn't know it automatically creates the link (I thought it wouldn't), thought the way I did was the correct one, so it'd get struck through etc. - I'm not very well/knowledgeable with the bugtracker formatting };]
Noted, thanks! }=)
Directional bias of c still exists in pre-4, confirmed, 2 screenshots attached, also in
MC-96927.After extensive testing I can conclude that 'r' and 'rm' are working as it should. It works as expected whenever it is executed from a commandblock, an entity or with tilde notations relative to an entity. The problem with 'c' is still persistent, I'm currently re-evaluating dx, dy & dz behavior based on new insights by Adrian Uffmann.
Hey Adrian Uffmann,
You were right, my gut-feeling was wrong. I've no idea how it slipped under the radar since I actually discussed with 2 other CMB people whether the players' hitbox was responsible for the seemingly weird off-set when using dx, dy & dz. But either we (read: I) messed up these ridiculous simple calculations or assumed the wrong dimensions of hitboxes of several entities. Anyway, let me explain:
/execute @e[name=EntityA] ~ ~ ~ testfor @p[dx=0 or dy=0 or dz=0]
So this command again searches for entities relative to the center of a block EntityA is in:
With dx=0, or dy=0 or dz=0 corresponding with a search volume of one block exactly.
It finds an entity, in this case the player, once that entities hitbox intersects this volume of one block.
(I previously assumed this would not be feastible since it would involve too heavy mathematical computations, but since it concerns AABB (axis alligned bounding boxes) intersections, I guess it's afterall a pretty cheap operation.)
So since a players hitbox has a base of 0.6 x 0.6 blocks wide and is 1.8 blocks tall, we indeed start targeting the player once it is in the volume as I had drawn out in the image of my bug-report. My apologies to all for this misinformation & thanks to Adrian for rechecking the facts.
So I guess, dx, dy & dz is "working as intended" after all. I am still interested in peoples opinion whether it's function is useful & intutive. Namely, as far as I've heard, many, many people evade dx, dy & dz entirely since they never knew what to expect.
Maybe dx,dy,dz is working as programmers intended, but not as redstoneblockers would except. Looking for hitbox can cause many problems. For example when making shapeshifting zombie/bat "vampire" as zombie it will be in "change to bat" area, but after summoning bat at pos of zombie and getting rid of zombie, bat will be out of this area (because of smaller hitbox) and will change back to zombie making constant "morphing".
You say many people never knew what to expect from dx, dy and dz and that is completely understandable because dx, dy and dz where completely broken in Minecraft 1.8 and below, but that is fixed already.
I think dx, dy and dz should stay the way they are, because of multiple reasons:
While I think that hitboxes should continue to play a role for dx, dy and dz, I noticed a different weird, but (probably) easy to fix behaviour:
When not using any of dx, dy or dz their values are basically infinite, meaning any player will be found.
If all of them are specified the target area becomes a box.
So far this is all good.
If you however run a command that only uses one or two of the d selectors any unspecified d selector has the value of 0.
So if you run /testfor @e[dx=0]
It is exactly the same as running /testfor @e[dx=0,dy=0,dz=0]
but instead it should kind of be like /testfor @e[dx=0,dy=INFINITE,dz=INFINITE]
because dy and dz have not been specified (INFINITE stands for both positive and negative directions).
This makes it impossible to target all entites with (roughly) the same x coordinate.
Changing this would only increase the usefullness, nothing that can be done without this change can not be done with this change.
You can use /execute to do this:
Only players on X10 (disregarding Y and Z) will be selected.
@Skylinerw that is only possible for absolute coordinates, but you can't target all entites on the same x coordinate as another entity.
@Adrodoc55 Still not technically impossible (just looking to diffuse impossibilities here), but performance-wise it is definitely not good:
Which may be why unspecified delta parameters default to 0.
@[Mod] Skylinerw yeah ok using the fact that a minecraft world is only 60000000 * 255 * 60000000 blocks big it can be done.
You got me there, I didn't think about that.
If my suggestion creates performance problems it might be better to leave it as it is, but if there is an implementation that does not create performance issues it could be a better alternative to Skylinerw's command.
@Adrodoc55 I'm afraid it does. Even a 10,000*10,000 selection area causes absolutely unplayably-slow tickrate, I know from personal experience.
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
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
Property 2. They target an entity based on it's Hitbox, instead of it's feet's position.
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.
@GamerGuppy 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.
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.
@GamerGuppy sorry I misunderstood your request. I should also note that I am not a native english speaker.
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!