Win8, 32bit java
So I was playing with command blocks using the range argument. Specifically I was trying to replace pressure plates with command blocks using the "testfor" command. I had 2 ways to do it, A) specified range but no specified xyz which makes it use the command block's location as the center of the range, and B) specifying a range and an xyz to start from.
The problem is when it's from the command block the lowest range (1) counts as "you'd have to be standing in the command block" but when it's from a specified xyz it's "that spot plus 1 block out".
My immediate thought was "Mojang obviously tried to bugfix the first problem but applied the fix to the wrong spot". Am I right or is that clearly the only way to interprete this reversed situation? (no disrespect intended. Those Mojang folks have given me more hours of enjoyment than any other game company in the past DECADE!)
Oh steps to reproduce? Start a single player game on creative with cheats, use "/give @p 137" to get a command block. Set it down and program "/testfor @p[r=2]" into it. Hook up a hopper clock to it (2 hoppers that point to each other with a tool in it that they pass back and forth), use a comparitor to connect one of the hoppers to the command block, use another comparitor to hook the output to a piston pointed up (just for an easy to see end result). Step on blocks next to the command block to get a reaction out of the piston. It should be clear that in this situation (no xyz specified) range 2 counts as the command block itself + 1 block away. Now try it with a range of 1. It won't work because you'd have to be standing IN the command block.
NEXT try the same experiment with xyz coordinates. Even with the range set to 1 it will activate for the specified block PLUS ANY BLOCK BESIDE IT (not counting diagonal because that counts as "1 block forward + 1 to the right = 2 blocks away" like with the lighting)
Technically of course I can still achieve my original goal of using it to replace pressure plates by moving the xyz point down 1, although I have to make sure no walking areas go through the bottom 2 levels of the globe.
EDIT: So I just tested it again and got different results (range 1 with no xyz got the same result as with xyz), which doesn't change the second one being wrong but still how did I manage that?
MC-36602 Commands with coordinates are NOW offset -1 x and/or z from where it should be (at negative X and Z coordinates)