One thing I've noticed now that I've been playing with the range argument is that arguments with xyz coordinates in them HAVE TO use absolute values. As in, you can't specify "~4 ~1 ~2" to mean "4 blocks away on the x, 1 up on the y, 2 away on the z". The only reason that bugs me is if I want to use an external map editor to copy and paste a structure a bunch of times I have to reprogram any command blocks in it that use arguments with xyz's. With relative coordinates you don't have to worry about that so long as facing is maintained (south is still south, east is still east, etc).
To reproduce? Start a single player game with creative mode and cheats on, use "/give @p 137" to get a command block, stick a button on it while crouched, program "/effect @p[x,y,z,r=1] 21 5 3" (replacing the x y and z with real numbers of course). Press the button while standing at the coordinates or beside it (should be JUST the coordinates since it's range 1 but that's a seperate bug report) and it should give you Health Boost 3 for 5 seconds.
NEXT, replace the coordinates with "~1,~0,~0" stand at the new spot and press the button. Nothing will happen (because the command block syntax-errored) and the "previous output" window on the command block should say that ~1 isn't a proper number.
For an example of a command block NOT choking on relative coordinates, try "/tp @p ~4 ~2 ~4"
Linked issues
is duplicated by 1
Comments 11
As relative coordinates are usable everywhere EXCEPT in arguments I would definately call this a bug and not a feature suggestion. Having something work in every situation except 1 is a bug.
The arguments within square brackets are used for areas of interest. For example, you could run /tp @a[x=10,y=10,z=10, r=1] would find all players within a radius of 1 of 10 10 10. If you were running it with relative arguments, the question is, relative to what? Should it be relative to the location of the player or command block that runs the command? If so, that functionality is not implemented, which is why it's a feature request. Note however that similar behaviour can be achieved through the new /execute command, which allows commands to be run relative to the location of players, entities etc.
First, yes, it should be relative to the player/commandblock issueing the comman. I see your, butpoint as Tokes said, you can use relative commands everywhere else, so not having them here seems like an oversight/bug.
Second, the /exec command is great, but it (currently) doesn't allow me to execute the command relative to the commandblock, only relative to entities, so it's not a proper solution to the problem. You could put an immovable entity on top of your commandblock and use that as the origin as a workaround, but it'd really be easier if we could use relative coordinates in selectors. 🙂
I put up a feature request in /r/minecraftsuggestions already though!
well it's been like 3 months now but here it is:
http://www.reddit.com/r/minecraftsuggestions/comments/1zpz9c/relative_coordinates_for_selectors/
MOJANG How should we create suggestions when they get then archived!?
We cannot vote anymore for http://www.reddit.com/r/minecraftsuggestions/comments/1zpz9c/relative_coordinates_for_selectors/
If you use /tp @p@unknown ~ ~10 ~, lets say your x=10,y=10,and z=10. now converting that to /tp @p[x=10,y=11,z=10,r=0] ~ ~10 ~ will fail every time because you will always be 1 block lower than where the command is checking.
Why does this fall under feature suggestions? There's no logical reason why relative coordinates work outside of selector arguments but not inside them. It certainly appears to be a bug (and very relevant one at that. Fixing this would open up worlds of new design space for mapmakers).
This site is for bug reports only. For feature suggestions or changes please do this on Minecraft Suggestions on Reddit.