Summary of the bug:

The problem is that the F3 interface/GUI displays the wrong "X" cordinates by -1 too little (no matter what dimension you are in). I have tested it in several releases, and only seems to be occuring in minecraft > 1.11 (and above). Even in the current latest snapshot release (17w06a), and seems to persist.

What I expected to happen was...

When I performed the "/setblock" command to make a block appear underneath me (the player's position/coordinates according to the "F3" interface) using the: "/setblock <x> <y> <z> <block>" syntax/command, I expected the block to appear directly underneath me if I were to subtract the "<y>" coordinate by -1, and keep the "<x>" and "<z>" the same value (referring to the coordinates displayed at the "F3" display, so to say). That way, I would be able to change the block that a sign was standing on without having to destroy the sign; needless to say, without having to redo it completely. Or at least so I thought...

What actually happened was...

Instead, where the block supposedly was to be placed at (when comparing to the "F3" interface to find the desired coordinates for the block to be placed at), was set 1 block away from the coordinate that was typed in (regarding the <x> coordinate). Say for example that if I was standing on the coordinates x=0, y=72, and z=0 (for example). Then I did the command "/setblock x=0,y=71,z=0 <block>", to make the <block> appear underneath the player. The block would appear +1 block away from the desired spot/position (again, regarding the <x> coordinate), compared to what I had typed in. Simply because I was referring to where I wanted it by the "F3" display.

Now, I'm familiar with java script code myself. However this does not require the skills of coding to even understand "why" this is happening. I actually stumbled upon this while using a plugin called "World Edit" (A "bukkit server" based plugin that allows you to build more efficiently in large quantities/volumes/areas of blocks). This plugin allows you to use any item of your choice as a kind of "wand" (configured in the configuration files of the plugin itself) to set 2 different positions. Then, applying the commands/syntaxes to place blocks within that selected area in different ways (depending on what available commands that come with the plugin that you use).

So, using the "wand" (item to select these 2 positions with) so to speak, I get different positions/coordinates (displayed in the chat) when "selecting a positions/coordinates" by either right, or left clicking... Compared to if I were to stand on it, and look at the "F3" interface's displayed coordinates on the same place that I used the "wand" at.

It finally came down to show that the plugin was more accurate than the "F3" interface. Well, at least to what happens if you use a command such as the "/setblock" command/syntax. Because I then understood, that if I actually tried doing the /setblock command on the same position/coordinates (only comparing the coordinates displayed by the "wand", and the "F3" interface while standing on the exact same block/spot as using the "wand" at), the block would be placed correctly according to what I expected when using the position/coordinates of the "wand", but not when using the information displayed by the "F3" interface. In conclusion, the "wand" giving me the correct information, and the "F3" interface not so much when standing on the exact same block/position/spot/coordinates (whatever you prefer to call it).

I think my point has been sent across by now...

That's when I realized something was wrong. Very wrong.

So below I have listed 2 examples of how to reproduce this reoccurring bug. One of them that is a little more detailed, and the other a little less. Simply for the purpose of making it more simple to perform, in addition to being more precise at the same time.

Steps to Reproduce:

1. Open up the "F3" interface to view the current coordinates that you are standing on.

2. Now use the "/setblock <x> <y> <z> <block>" command to set a block directly beneath you (assuming that you already have permission to do so).

3. Hit Enter / Complete task.

4. The block should appear +1 block further away regarding the <x> axis, compared to where you actually typed/expected it to be in (regarding the information gathered by the "F3" interface to start off with). This can be proven by standing on top of the block that was just placed/set by the command, and comparing the (before) current "F3" interface's coordinates of that block, to the coordinates that you just typed in when doing the "/setblock" command/syntax before.

More distinct "straight forward" example:

1. A player is standing on the following coordinates according to the "F3" interface:

x = 100
y = 100
z = 100

2. The player then types in:
"/setblock 100 100 100 minecraft:bedrock"

3. According to the "/setblock <x> <y> <z> <block> [dataValue:state] [oldBlockHandling] [dataTag]" correct syntax, the block should be set directly where the player is standing.

4. (Result) The block is then placed, not at the same place as the player is standing on (x = 100, y = 100, and z = 100). Instead, it is placed on the block directly next to them (x = 101, y = 100, z = 100). +1 block to the right, if facing north during this whole procedure. Assuming that the player gathered the information to put the block where they were standing using the "F3" interface to start off with.

Ideas on how to solve it / What could be causing the bug:

From my understanding (of course I could be wrong, but I'm 99% sure), this is because the "F3" interface has been coded to only display the coordinates of the actual coordinates (that are normally hidden in game code). And since "secondary" displays are always just a plain "copy" of the actual product of some sort of code (since they're not actually what defines the coordinates unlike the game engine itself), sort of like a monitor screen of some sort designed to "replicate/screen" the product of another monitor with the same signal (not actually being the factor of determination of the final product, only a "replica" of the original, so to say). Like a translator, so we can see what is hiding behind all that code much easier. Maybe someone did so the "replica" (F3 interface) displayed 1 block/unit too much, compared to what was actually meant to be less regarding the <x> axis to start off with? I mean... I don't know who was responsible for that part, but that's not what matters is it?

Perhaps a button was miss clicked... "2" instead of "1"... Whoever stands responsible for this should stay away from the shelf's of whiskey next time they go for the "all night coding+drinking idea"... (I'm joking, just in case anyone took that too seriously) xD

Well, that's for Mojang to figure out I guess! Resulting in that the entire interface shows the incorrect coordinates? I actually found this extremely funny. But I still find it very serious regarding all the people in slavery to this specifically important feature in Minecraft. Or at least when it comes to using things such as command blocks (like me). Thus, felt like I had to share it with the people who actually can do something about it. It's very small, but causes major problems since this is the "one way to go" for nearly all people taking use/advantage of coordinates in their spectacular works of Minecraft.

With great regards,
BlueLixard (YouTuber)

"The smallest of things cause the biggest differences."