mojira.dev

Adrodoc55

Assigned

No issues.

Reported

MC-132451 Command Parser - invalid value for block property and property name are reversed in error message Fixed MC-127200 '/data get' is not logged on server side Confirmed MC-122780 Admin commands executed by command blocks are no longer logged when the gamerule logAdminCommands is set to true unless the gamerule commandBlockOutput is also set to true Confirmed MC-112257 Some NBT tags require the correct suffix Fixed MC-112253 Primitive NBT Lists that are not of type int need a type suffix Confirmed MC-111789 /stats does not find area_effect_cloud in the center of a block Invalid MC-111144 /stats does not find marker armorstands in upper half of a block Invalid MC-110636 setblock uses incorrect data value for piston_extension Won't Fix MC-101073 Hitbox of Marker Armorstand is incorrect in the tick it is summoned Duplicate MC-97060 Repeating command runs one iteration to much Duplicate MC-92457 scoreboard players tag can result in commands.scoreboard.players.tag.tagError Duplicate MC-90967 Marker ArmorStands are not within r=0 when they stand on the ground. Duplicate MC-90892 /summon works incorrectly with ItemFrames Duplicate MC-89667 Position based selector arguments fail finding entity if it has been moved to a different chunk in the same tick Cannot Reproduce MC-89597 Selector with big radius will crash the game Duplicate MC-89505 Query with @e and multiple scoreboard tags depends on order Duplicate MC-81152 scoreboard command interacts wrong with execute Duplicate

Comments

I am fine with this being closed as works as intended, but closing this as invalid is definitely incorrect. This ticket does not refer to server administration commands, but to commands wich require admin/op privileges.

As /stats no longer exists this can be closed. However this may or may not be related to MC-123410 which is not a duplicate of MC-88533 (see my comment there).

This is not a duplicate of MC-88533 because this also affects area_effect_clouds!

  1. Summon an aec

    /summon area_effect_cloud ~ ~ ~ {CustomName:"\"statsTest\"",Duration:2147483647}

  2. Print all entities that are not within radius 0 of themselfs:

    /execute as @e at @s unless entity @e[distance=0] run say @s

Good hint, that way I can achieve what I wanted. I'll still leave this ticket, because I am not sure if this change was intended.

Still it would be more consistent in the code and therefor easier for mojang to maintain.

@FVbico I think it would be better to change all affected nbt, even those that can not be touched by commands. That has the advantage of beeing consistent and it is better for mods. I actually reported this bug because I am writing a mod.

In that case MC-101073 is not a duplicate and should be marked as fixed. I must admit that I didn't put that much effort into reproducing this bug, because my "duplicate" is what I was mostly interested in.

This was fixed in 16w44a and is still fixed in 1.11. It is difficult to pinpoint the exact fix version, because 16w43a behaves super weird and MC-88181 can not reliably be reproduced (but MC-101073 can).

@skylinerw this affects dy too, are you sure it is related? and wasn't MC-88533 caused by a y coordinate without decimal places?

This was fixed in 16w44a and is still fixed in 1.11. It is difficult to pinpoint the exact fix version, because 16w43a behaves super weird and MC-88181 can not reliably be reproduced.

Ah ok I found it, it is: /setblock ~ ~ ~ minecraft:stone variant=granite

Since I can't find information on it, how would I for instance place a granite using block states? This does not work: /setblock ~ ~ ~ minecraft:stone variant:granite

@@unknown Still not reviewed?

Same issue here!

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).

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.

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)

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???

Confirmed for 1.9.4 and 16w21b

Confirmed for 16w21b