This appears to occur currently on ArmorItems/HandItems (all entities) and Rotation (armor stand) under certain circumstances.
When a NoGravity armor stand is summoned, and then a tp or entitydata cmd is run to alter its rotation in the same tick after the summon, the rotation of the entity does not visually update, however the rotation tag in the entity does update.
When an armor stand any entity is summoned with hand or armor items, and then updated in the same tick to have air in the slot, the item will remain visually from the summon, but the tag in the entity has no item set.
Does not occur with Pose tag.
*To test (Rotation issue):*
1. impulse:
/summon ArmorStand ~ ~1 ~ {NoGravity:1b}
– Then run this into the following two cmds to test both entitydata and teleport
2a. chain (running from the impulse cmd):
/entitydata @e[type=ArmorStand,r=4] {Rotation:[90.0f,0.0f]}
2b. chain (running from the chain cmd):
/tp @e[type=ArmorStand,r=4] ~ ~ ~90 ~
3. Power the chains and run the impulse cmd. Notice visually, the armor stand is not facing the right direction, however if one looks inside its nbt by /entitydata, its rotation value will have been updated.
4. Try updating the armor stand again using the same cmds used in 2a as well as trying
/tp @e[type=ArmorStand,r=4] ~ ~ ~ ~to see that rotation still does not visually update. It only updates once you apply a different value and then switch it back after.
5. Try this again using NoGravity:0b to see that the rotation DOES visually update, likely because the armor stand is moving and so rotation is being updated.
*To test (Armor/Hand items issue):*
1. impulse:
/summon ArmorStand ~ ~1 ~ {ArmorItems:[{},{},{},{id:stone}],HandItems:[{id:stone}]}
– Then run this into the following two cmds to test both entitydata and replaceitem to replace the item with air (this only occurs with removing the item)
2a. chain (running from the impulse cmd):
/entitydata @e[type=ArmorStand,r=4] {ArmorItems:[],HandItems:[]}
2b. chain (running from the chain cmd):
/replaceitem entity @e[type=ArmorStand,r=4] slot.armor.head air
3. Power the chains and run the impulse cmd. Notice visually, the armor stand still retains the items, however if one looks inside its nbt by /entitydata, its armor/hand items will have been updated to have no item.
4. Try updating the armor stand again using the same cmds used in 2a and 2b to see that equipment still does not visually update. It only updates once you apply different items and then switch it back after.
5. Try this again using an item instead of air in 2a/2b to see that the item updates this time, possibly due to different treatment of removing items vs replacing with another item.
Linked issues
relates to 2
Comments 6
I know it's because of it being in the same tick, but if the nbt states it is a rotation, I believe the visual should show that rotation as well, even if run in the same tick.
It's simply impossible to
make it visually update
within the same tick because
it will happen too fast for your
eyes to see it. just have the
armorstand update it's rotation
one tick later. As even mojang can't
make the armorstand update it's rotation
within the same tick.
Yes, it's impossible because it may be a bug. If you set NoGravity to 0 again, and run this all in the same tick, the rotation does indeed update, thus NoGravity 1 should be no different. It is DEFINITELY not impossible to make it update in one tick. This isn't an issue of trying to make it update somehow by activating it a tick later in this snapshot, i'm talking about the effect it is having right now which appears as if it is acting like a bug. The issue has nothing to do with it changing too fast and not seeing it turn around visually. The issue instead is that if you spawn it at rotation [0.0f,0.0f] and instantly update it to [90.0f,0.0f], it will display [0.0f,0.0f] instead of [90.0f,0.0f] while the nbt states it is at [90.0f,0.0f]. I'm not trying to address seeing it move between the rotations, just that it should acquire a visual rotation identical to its final determined rotation.
Ah I see, just didn't fully understand
the issue as it seemed
like you wanted it to visually
update properly. But I see
exactly what you mean. I'll do more
further tests and see if I can find a workaround
to the bug. But for now I guess we can
confirm that this is a bug in 15w39b.
Confirmed for Minecraft 1.9 pre3
This caused by it's rotation
being updated too fast.
which is why it seems like
it's rotation isn't visually
updated. Try to figure out a way to
do timed execution of the rotation
being updated. A Youtuber who I gotten most
of my command block knowledge
from explains how this is done:
Video 1: https://www.youtube.com/watch?v=ak5DYcoIC74
Follow video
to video 1: https://www.youtube.com/watch?v=hJAnCdS6cAg