Command Blocks summon entities 1/2 a block too high when using relative coordinates

Jeb has tweeted that they will only be fixing Game Crashes & World Save Bugs and Nothing Else in Pre2

The real problem is "Is this intended ?" - I already changed all my /summon and I want to know if I should change them back (if I do, I'll do everything in absolute coordinates).

@Warren, still a good idea to keep the bug updated.

@Mlakuss, I doubt it's intended.

Perhaps they'll fix it in the third pre-release of 1.8.

Doesn't look like it.

We'll release 1.8-pre3 tomorrow morning. It will fix two duplication bugs (tripwire and heads on armorstands) and a worldborder issue.

https://twitter.com/seargedp/status/504648616665829376

Title should be changed to Command Blocks summon entities 1/2 a block too high when using relative coordinates to be more clear.
Edit: Thanks @unknown.

@Sonicwave we don't know if this is intended or not. For example, particle commands happen inside the command block. Technically setblock commands do as well. But if it is incorrect, which I believe it is, it's not 1.5 or a full block. Based on previous snapshots, the entities are being summoned 1/2 a block too high.

This relates to/is a duplicate of MC-56253.

This happens for probably all commands. (confirmed for setblock in 1.8.2-pre6) Title should be something like relative coordinate is interpreted half block higher to be exact.

Confirmed for

• 1.8.6

• 1.8.8

This behaviour seems intended to me. Minecraft adds 0.5 to all the coordinates causing commands to be centered on the center of a block. Having it different for them /summon command would cause an extreme inconsistency and mess as other commands like /entitydata needed to be changed as well while commands like /testfor would need this offset because else it would not get the closest player.

Confirmed for 1.9

Still in 1.9.1-pre3, seems intended

Still in 16w15b

Confirmed for 16w20a.
I suggest to change the command (or add a new one ever since/for 1.10 snapshots) in the bugpost into:

/summon Villager ~ ~1 ~ {NoGravity:1}

or, so the Villager stays in place, use additionally NoAI again:

/summon Villager ~ ~1 ~ {NoGravity:1,NoAI:1}

Because changes to the NoAI tag made entities being affected by gravity which means if you use the bugpost-command, the Villager will fall down, and the new tag NoGravity now takes care of that, so you can see the Y-Offset clearly/permanently }=)

Updated screenshots attached.

Confirmed for 16w21a and b.

Why is this still open? This should be a clear "works as intended"! The y coordinate is consistent with the x and z coordinate. The execution center is also consistent with r and c selectors. Why would you want this to change???

@unknown, it's not consistent, absolute coordinates don't spawn at y = #.5.

The only real inconsistency is, that absolute integer coordinates like `0 0 0` will be translated to `0.5 0.0 0.5` where relative integer coordinates `~0 ~0 ~0` are translated to `~0.0 ~0.0 ~0.0`. I think the inconsistency regarding absolute coordinates is ok, because absolute coordinates snap to the grid in a sence. I highly suggest against changing the relative coordinates! If you want full consistency you'd have to change absolute coordinates, but I don't think that should be done either, because for most usecases that use absolute coordinates y = .0 is what you want (for instance tp to absolute coordinates)

if executed from a command block 1 block above, you'd rather say that it ends at y=#.0 than #.5

I disagree, because that would imply that 1.1 blocks above the command block would be at #.1 instead of #.6 wich is inconsistent with the execution center.

Executiong at a entity also executes at the bottom of it, so why not in the block as well?

@FVbico why not the top of it then, since that is where entities will stand? /sarcasm

But seriously, it's executing the command based on the center of the block, as it is intended to do so. Otherwise it would be subject to people making Fence-Post errors https://en.wikipedia.org/wiki/Off-by-one_error#Fencepost_error

The execution center of command blocks is at the block center, because that is the point that makes The most sence when working with radii. Entities don't really have center so their execution center is at their feet. Technically you could define the center of an entity to be the center of it's hitbox, but that would make it extremly hard to work with because the size of hitboxes varies from entity to entity. 0.5 blocks above the entities feet would also be a way to define an entities center, but that doesn't make much sence for entities with a hitbox that is smaller than 0.5 blocks (like Marker ArmorStands).

After the recent change for the tp-command to make it consistent with the other commands I created a Reddit-thread for exact this reason, so that certain inconsistencies can be discussed with the community, to find a reasonable solution that works for mapmakers.

If there are any inconsistencies that work better by remaining an inconsistency, of course feel free to tell so, by making examples.

Here in this post of the same thread I asked specifically about the offset, or rather that the CommandBlock executes from its very middle, and referred to this bugpost here.
So far nobody contributed there to tell me or rather us or Mojang how they see it, so feel free to participate there.

I also asked dozens of other mapmakers to help out on a discussion about it, but the response or rather community contribution is sadly not as much as I'd like it to have.
Many seem to just complain mainly privately, but don't participate publicly, don't use their energy to help but rather complain.

I'll try again to get them to participate, but by any means, if you guys can contribute (and I see this topic is important for you), then please at least you give your input there.

Thank you in advance }=)
Regards, Meri

So what exactly is the problem here? Command blocks execute from their center, not their bottom. I don't think that's a bug, but if that's what's being reported here, the name and description need to be updated.