The rotation of projectiles (arrows, snow balls, tridents, ...) is incorrect, its vector has negated x and y values. As you can see in the attached images, the rotation arrows/tridents have does not match the model/travel direction. The model represents the correct angle for the shot. The facing direction should match the direction that the projectile would travel in.
Steps to reproduce:
Enable hitboxes. (F3+B)
Spawn a projectile of any kind (eg by throw tridents or shoot arrows).
Inspect the facing line of the projectile.
Expected result:
The facing line follows the direction of the projectile, matching the model.
Actual result:
The facing line does not follow the direction the projectile moves/is visually facing.
This screenshot was taken while looking down from above. The x axis is vertical and goes upwards, the z axis is horizontal and goes to the right.
Linked issues
is duplicated by 14
MC-266405
Summoned wither skull facing backwards
Resolved
MC-264883
Arrow hitbox direction faces a different direction than the model
Resolved
MC-264703
projectiles don't face "the right way"
Resolved
MC-262425
Throwable Objects do not face the direction they are moving
Resolved
MC-231002
Arrow Rotation Error
Resolved
relates to 4
MC-135115
Ender dragons visually face the opposite direction from their rotation value
Open
MC-57899
New line of vision hitbox / direction tag is incorrect for some entities
Resolved
MC-134707
Phantoms' rotation pitch is reversed
Open
MCPE-168108
The rotation vector of projectiles has negated x and y values
Resolved
Attachments
Comments 26
The issue is duplicated by MC-182313.
This bug also effects relative coordinates(^ ^ ^), not (~ ~ ~).
Now it is impossible to do anything in position relative to arrow using only “^ ^ ^“, e.g. Summoning particles before arrow.
Potential solution for users having this problem is to flip sings of arrow/s rotations:
execute as @e[tag=targetArrow] store result entity @s Rotation[0] float -1 run data get entity @s Rotation[0]
execute as @e[tag=targetArrow] store result entity @s Rotation[1] float -1 run data get entity @s Rotation[1]But this works “great” only if arrow have already hit a block, because arrows in air return to their original rotations after moment, not mentions requirement to rotate them only once in most cases.
Unfortunately “execute rotated” doesn’t support “-~“ (at least in 1.20.4), which should help with this Bug.
Commands used for particles in screenshots:
execute as @e[type=minecraft:arrow] at @s run particle minecraft:happy_villager ^ ^ ^2
execute as @e[type=minecraft:arrow] at @s run particle minecraft:happy_villager ^ ^ ^1.5
execute as @e[type=minecraft:arrow] at @s run particle minecraft:happy_villager ^ ^ ^1
execute as @e[type=minecraft:arrow] at @s run particle minecraft:happy_villager ^ ^ ^0.5Confirmed in Java Edition 26.2.
This issue now also affects the new minecraft:apply_impulse entity effect. The effect interprets its direction vector using the affected entity's local coordinates, so when it is applied to an arrow with:
{
"type": "minecraft:apply_impulse",
"direction": [0.0, 0.0, 1.0],
"coordinate_scale": [1.0, 1.0, 1.0],
"magnitude": 2.0
}
the impulse is applied in the opposite direction on the world X and Y axes, while the Z axis is correct.
For example, a fully charged arrow with an initial velocity component of approximately 3 is reduced to approximately 1 along X or Y instead of increasing to approximately 5.
When fired diagonally at approximately 45 degrees in the XZ plane, the measured Motion components were approximately:
X = 0.70
Z = 3.47
This matches the expected result if the X component of the impulse is negated.
Using:
"coordinate_scale": [-1.0, -1.0, 1.0]
correctly compensates for the inverted projectile rotation and makes the impulse follow the arrow's actual movement direction.
This means the issue no longer only affects visual rotation and local coordinates (^ ^ ^); it can now directly alter projectile velocity and trajectory through minecraft:apply_impulse.
Can confirm for 1.15.2 and 20w18a.