All minecraft projectiles behave unpredictably when attempting to copy one entity's motion to them through the /execute store command.
How to recreate:
[media]
-Place down three command blocks with one of these commands in them:
/execute store result entity @e[type=potion,limit=1] Motion[0] double 1 run data get entity @e[type=player,limit=1] Motion[0] 1
/execute store result entity @e[type=potion,limit=1] Motion[1] double 1 run data get entity @e[type=player,limit=1] Motion[1] 1
/execute store result entity @e[type=potion,limit=1] Motion[2] double 1 run data get entity @e[type=player,limit=1] Motion[2] 1
-Throw a potion. Instead of following the player's movement, the potion simply acts as though it collided with an entity or a block. This does not change when firing it out of a dispenser.
Similarly copying a snowball's motion on to a potion makes the potion fly off in a completely different direction until the snowball starts descending, where it breaks on the ground.
This can also be recreated with arrows, snowballs, eggs and xp bottles, so I'm under the impression this bug affects any projectile affected by gravity.
Attachments
Comments 6
Thanks for helping @tryashtar , but it doesn't seem to have worked. I jumped the scale up to 100 in the second set of numbers, and 10 in the first set. The behavior's no longer erratic, but the projectile's still not following the snowball's motion.
/execute store result entity @e[type=egg,limit=1] Motion[0] double 10 run data get entity @e[type=snowball,limit=1] Motion[0] 100
/execute store result entity @e[type=egg,limit=1] Motion[1] double 10 run data get entity @e[type=snowball,limit=1] Motion[1] 100
/execute store result entity @e[type=egg,limit=1] Motion[2] double 10 run data get entity @e[type=snowball,limit=1] Motion[2] 100
Shall I update the information, or let the issue close?
If you want to copy the motion of the snowball, use something like 0.001
for the first scale
and 1000
for the second.
The numbers have to multiply together to get 1
for the copy to work, and the larger the second number, the more precise the copy.
I'm afraid it's still not working. Even when it declares the value as 1, the egg still doesn't follow the snowball's path, no matter which order. I'm still not sure if I'm doing something wrong, or there's a legitimate bug. I'm going to post up some pictures of the command block in question.
It works just fine for me when I use:
/execute store result entity @e[type=egg,limit=1] Motion[0] double 0.001 run data get entity @e[type=snowball,limit=1] Motion[0] 1000
(plus two more for Motion[1]
and Motion[2]
)
Hm...
You're fetching the motion with no scale, so it is forced to round to the nearest integer – likely zero.