mojira.dev
MC-105820

Relative decimal coordinates with block related commands are inconsistent

Basically, when you use

/setblock ~.4 ~ ~ stone

and stand at the most positive side of a block, right against another block, the stone gets placed in you, wheres

/setblock ~-.4 ~ ~ stone

and standing at the most negative side of a block is places it at the block next to you.

See screenshots.

This issue occures with the following commands:

  • /fill

  • /setblock

  • /blockdata

  • /testforblock

  • /testforblocks

  • /stats block

  • /replaceitem block

Happens in both single player and multiplayer, so it's not a desync.

Expected behaviour:

  • The block besides you gets targeted in both cases.

Reason this happens:

With these commands the coordinates ignore on what decimal you were in the first place, it get's rounded down to x.0 z.0.
So standing on the most positive part, and using ~.9999999 still places the block in you as x/y/z.0 +0.9999999 = x/z.9999999 =x/y/z.
A simple fix could be to round the numbers only after the final coordinates are calculated, rather then rounding down every coordinate provided.
So basically, the game said: .7 + .4 = .0+.0 = 0 instead of .7 + .4 = 1.1 = 1.


Code analysis by @unknown can be found in this comment.

Linked issues

Attachments

Comments

marcono1234

Why is this "WAI"?

marcono1234

Please link to this comment in the description

The following is based on a decompiled version of Minecraft 1.10 using MCP 9.30.

The reason for this is that the method net.minecraft.command.CommandBase.parseBlockPos(ICommandSender, String[], int, boolean) calls the method net.minecraft.command.ICommandSender.getPosition() which returns a block position (only integers). This could be fixed by having it call the method net.minecraft.command.ICommandSender.getPositionVector() instead.

user-f2760

Nathan Adams

Confirmed

Minecraft 1.10.2, Minecraft 16w32a

Minecraft 17w45a, Minecraft 17w47a

Retrieved