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

The command in the command block.

The result.

Confirmed for 14w33a. May be works as intended, block activates from center.

Mm, is possible. But when tried with a pressure plate is does the same, and if it were so with a button, it would be weird since it wasn't the case in previous snapshots...

This problem hasn't been solved in the prelease of 1.8, though I think it's a kinda major bug since /summon isn't used seldom...

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.

I added the current summary/feedback of the community regarding this to the Redditpost, will update it in case it changes over time (until Mojang makes a decision whether or not to consider this bugpost valid ir as "works as intended").

Confirmed for 1.10 pre-1 and pre-2.

WAI, see MC-67369.

@unknown I'm not sure if a Dev's statement from 2014, 2 years ago, can still be seen as valid, even more so considering all the changes we went through with commands and commandblocks. so personally I'd like to know if it is still reasonable, as it differs from other relative summon commands, e.g. if made by a player or executed at an entity.

Of course, for other things the very middle of the CB is taken as initial point and it should remain like that, but I feel as for summoning it should be consistent to others.

It'd be great if other CBers could voice their opinion on relative summon commands via a CB.
I suspect mapmakers will rather summon entities relative to other entities or at maximum at fix coordinates, so it might not be as big of an issue, but still, I feel it's inconsistent, and they said they aim for consistency.

If you chose to leave this bugpost closed, I'll add a post on Mojira to apply for reopening it.

Edit: Also, e.g. if you insert this command into a CB:

/teleport @e ~ ~2 ~

and trigger the CB, the entity will end up 1.5 blocks above the CB, because it executes from its very middle, so the entity does not end up exact 2, but 1.5 blocks above the CB, unlike if you teleport the entity via a player or relative to an entity.

That can be a bit confusing, and I'm not sure if that speaks for or against fixing this bugpost here, as the relative-tp to a CB would have to be changed then as well I guess, while other commands would still have to be executed starting from the very middle of the CB.

Thus I'd really like to know what Mojang intends to do about this inconsistency, if they want to make an exception in this case or not.

The tickets are from around the same time. This ticket has received no dev attention since creation. It might even be a duplicate.