When using a search selector such as "@p[ x,y,z,r]" (substitute x, y, z, and r for their values), the game does not search for players in the correct location. Although the game properly does floor(x ) and floor(z), for some reason, it does round(y ). The result is that the search area is a voxelized sphere, but it is offset from Minecraft's grid by 0.5 - this is very cumbersome to work around.
The expected results would be achieved if the game did floor(y ), consistent with its handling of the x and z coordinates. Because it does not, unexpected behavior can occur: walking up variable-height layers of snow can put you out of the radius, as can standing on slabs. Furthermore, it's counter-intuitive to have the search area physically offset by 0.5 blocks from Minecraft's grid - it's made of blocks, but the blocks do not correspond to blocks in the game.
Steps to reproduce:
Look at your coordinates in F3 - the integer coordinates in parentheses for x and z are floor(x ) and floor(z).
Use the command "/say @a[ floor(x ),floor(y ),floor(z),1]", substituting in the according numbers.
Observe that it says your name.
Jump up and place a whole block under yourself, standing on it. Use the command again.
Observe that it still says your name: you are 0.5 away from the offset search center.
Place a layer of snow, and repeat. Do this several times, and observe that once you are 1.5 blocks above your initial position, the command no longer works: you are 1.0 away from the offset search center.
Dig downwards, and observe that the command will work until you are 1.5 below your initial position.
Putting these facts together, observe that the search is centered at your feet from your initial position, rather than the center of the block. Also observe, as you play with your horizontal position, that it is centered around the middle of the block on the horizontal axes. Therefore, the search is centered around the middle of the block on x and z, but the bottom of the block on y: the detection area itself can be seen as a set of block-sized voxels which are offset by 0.5 on y from Minecraft's grid.
Linked issues
is duplicated by 2
Attachments
Comments 9
It's not working as intended - read the last paragraph. It is centered around the middle of the block for x and z, but is centered around the bottom of the block for y. When I said it does round(y ), I meant it's rounding the player's coordinates instead of flooring it. If it were consistent, it would handle y the same way it handles x and z.
If it were centered around the middle (adjusted by 0.5) on all axes, then standing on slabs would not put you outside a selection boundary.
I've attached an image representing how the selection boundaries work. It's clearly not consistent with regards to the y axis.
Mod Talven81, or any other mod - can this please be reopened? The actual behavior in-game is not the same as the behavior you said is "intended", so by definition, it's not working as intended.
Your description is really confusing, partially because it's not clear whether you're using the term "grid" to refer to blocks, or to the actual coordinate system, which is not centered on blocks, but on the corners of the blocks. (0,0,0) is actually the corner of a block, not the center, on any axis. I'm inclined to believe the game doesn't actually do any rounding or flooring in the search algorithm anyway.
However, because this is counter-intuitive to players, most commands deliberately offset x and z coordinates given to them by 0.5, but not the y coordinate, so that they appear to operate on the center of the top face of a block, rather than the corners. or the center of the block. The numbers displayed on the debug screen aren't meant for player use, but for the developers.
So yes, the y coordinate is treated differently from the x and z coordinates. However, this is done deliberately to match the expectations of the average player. Your expectations may be different, but that does not mean the current behavior is unintended.
Alright, I can see what you're saying, but I don't think this matches the average player's expectations. It results in players being inside a selection boundary until they stand on a slab, but not a cake, daylight detector, or similarly nearly-slab-sized object. It creates an imaginary ball of cubes which don't line up evenly with the world's own blocks.
Anyways, I was going by Mod Talven's own description of what behavior is intended. Either you're right and Talven's description is wrong (and Talven's closing was thus correct), or you're wrong about the intended behavior and Talven described the intentions correctly, in which case this should be reopened because the game does not exhibit that behavior (I suppose there's also the third option where everyone's wrong, but that would still mean the game's not exhibiting intended behavior). Both behaviors can't be intended, after all.
As of the 1.8 snapshots, the behavior has changed. It's hard to tell, but apparently it now selects a sphere (non-voxelized) around the block. Not the corner, but the block itself - it no longer treats y differently from x and z.
This behaviour was changed in 14w03a see comment in MC-44785
[Mojang] Searge (Michael Stoyke)
Using a radius of 65536 was an unintended side effect. We are not changing it back to the broken behavior. Instead I made a proper fix for the next version that will allow r=0 and/or rm=0 to be used to specify exact block positions. It will also center the radius around the blocks center position and not around on of its corners as it was before.
This is working as intended, commands testfor on the middle of the block (coordinates adjusted by 0.5) instead of the corner.