Commands with coordinates are offset -2 x and/or z from where it should (at negative X and Z coordinates)

Not confirmed for positive X coordinates

Seems to affect Z coordinates sometimes as well.

I can confirm, although the block was off by 2 in both X and Z.

Strongly related to MC-30925 (same issue with testforblock)

I can confirm it only happens in the negative directions. Placing a block at 0,Y,0 and trying again at -1,Y,-1 will atempt to place the block at the exact same location.

I noticed the same using the command. In the negative directions, it tends to be offput by one or two blocks. In the positive directions however, it works as normal.

Had the same problem. Does not happen when using relative coordinates (e.g. ~-2 ~5 ~-4).

Negative direction has always looked off. To get the block you're in when in negative directions, you look at the number in the brackets as it is always right in positive or negative. Based on those, the targetting is 1 off in negative directions. Should be a simple enough fix I'd hope.

Confirmed, this is a pretty obvious bug. Really should be fixed ASAP so people can actually start using the snapshot's features.

For now if you want to use the snapshots features, please go to a positive set of coordinates. ~~ The community of until they fix it, go around it. 😛 But really, in my test world I TP all new players to a spawn @ 10000 , 80 , 10000... Now if only they could let me set spawn XY when generating the world.

Really annoying when trying to work with setblock.

It only actually places the block 1 off where it's supposed to go in both directions. Minecraft automatically adds 0.5 to your coordinates if you've given no decimal places so that it's not targeting the corner of a block. So it's 1.5 off where you specified, but only 1 off where it should actually be, as blocks have to fit onto the grid.

Same here

Still broken on 13w28a...

Isn't this an issue with any commands using coordinates? I've tried making TP command blocks, but it always was a block off somehow. I think this is a rounding error because it's rounding up, and not truncating or rounding to the nearest integer.

Updated the Bug Report to include all commands that use coordinates. It looks like it is a problem with the rounding engine.

it hard with testforblock. i have to more 2 over just get right spot.

Confirmed for 13w38c.

It's worth noting that the game considers "0 64 0", "-1 64 -1", "-1 64 0", and "0 64 -1" to be the same coordinate with /setblock.

It's worth noting that since co-ordinates in a command are given 0.5 added to them to center them on a block, the co-ordinates are only offset by -1x or z, not -2

Confirmed to still be a problem in 13w39b.

Yes. This bug is still unresolved as of 13w39b. It really is an annoyance; Makes it hard to start a project using these awesome new commands... 😞

I really hope that this command is fixed ASAP or never fixed at all! It works if you have the coords set off by one, but when it fixes everything will have to be redone 😞

but when it fixes everything will have to be redone

You are testing an alpha version at the moment. Things may and will change.

The direction in which negative coordinates round is a [much older issue|MC-4794], currently marked Works As Intended. However, the commands that used coordinates only affected entities before, which aren't bound to the grid like blocks are.

The simple workaround would be to specify the proper fractional values in the command, unless it only accepts whole values.

@Torabi
The issue you linked DOES work as intended, and is different to this one. Minecraft automatically adds 0.5 to a coordinate when you use it in a command, as this is the center of the block and normally what the user means. This could change a co-ord from -11 to -10.5 which could look like it has moved over a block but it has in fact not.

The issue here is that, for negative co-ordinates only, it is adding 1.5 rather than 0.5. This means that a co-ord could change from -11 to -9.5, which has in fact moved over a block.

A workaround to this problem is to append .0 to the X and Z coordinates, e.g. "/setblock -1.0 50 -1.0 stone". This ultimately makes no sense, since the block coordinate system should only take whole integers, but there is obviously something wrong with the algorithm they're using to convert negative integers.

Im building a capture the flag game and have the same problem, I worked around the bug so if it gets fixed I have to reset everything, however if it gets fixed it will help in the future.

Confirmed for 13w43a

wow, my entire map is broken after this fix. I hope someone will make a mcedit filter