MC-182313Arrows face an incorrect direction
General description:
The direction arrows are facing does not, in general, align with their visual appearance and their "Motion" nbt tag. The x- and the y-direction components point from tip to tail, while the z-direction component points from the tail to the tip. This affects tp ^ ^ ^1 execution, resulting in an illogical arrow movement, as well as other dependent actions.
What I expected to happen was:
Either the arrow entity faces the direction it is/was moving (preferably) or the complete opposite direction.
What actually happened was:
Components x and y point in the direction the arrow came from, while the z component points in the direction of the movement.
Steps to reproduce:
- Take a bow and arrows
- Shoot in any direction
- Observe the direction the arrow is facing
Additional information:
Seems to be present in versions all the way from 1.8 even 14w29a (F3 + B introduced several snapshots prior, could not load them) up to the latest snapshot 20w18a.
Everything said applies to tipped arrows and spectral arrows.
Environment
MacOS Catalina version 10.15.4
java version "1.8.0_251"
Java(TM) SE Runtime Environment (build 1.8.0_251-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed mode)
Linked Issues
Normal
Created Issue:
Arrows face an incorrect direction
The direction arrows are facing does not, in general, align with their visual appearance and their "Motion" nbt tag. The x- and the y-direction components point from tip to tail, while the z-direction component points from the tail to the tip. This affects tp ^ ^ ^1 execution, resulting in an illogical arrow movement, as well as other dependent actions.
Attachments3
The direction arrows are facing does not, in general, align with their visual appearance and their "Motion" nbt tag. The x- and the y-direction components point from tip to tail, while the z-direction component points from the tail to the tip. This affects tp ^ ^ ^1 execution, resulting in an illogical arrow movement, as well as other dependent actions.
The same applies to tipped arrows and spectral arrows.
General description:
The direction arrows are facing does not, in general, align with their visual appearance and their "Motion" nbt tag. The x- and the y-direction components point from tip to tail, while the z-direction component points from the tail to the tip. This affects tp ^ ^ ^1 execution, resulting in an illogical arrow movement, as well as other dependent actions.
The same applies to tipped arrows and spectral arrows.
What I expected to happen was:
Either the arrow entity faces the direction it is/was moving (preferably) or the complete opposite direction.
What actually happened was:
Components x and y point in the direction the arrow came from, while the z component points in the direction of the movement.
Steps to reproduce:
- Take a bow and arrows
- Shoot in any direction
- Observe the direction the arrow is facing
MacOS Catalina version 10.15.4
java version "1.8.0_251"
Java(TM) SE Runtime Environment (build 1.8.0_251-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed mode)
General description:
The direction arrows are facing does not, in general, align with their visual appearance and their "Motion" nbt tag. The x- and the y-direction components point from tip to tail, while the z-direction component points from the tail to the tip. This affects tp ^ ^ ^1 execution, resulting in an illogical arrow movement, as well as other dependent actions.
The same applies to tipped arrows and spectral arrows.
What I expected to happen was:
Either the arrow entity faces the direction it is/was moving (preferably) or the complete opposite direction.
What actually happened was:
Components x and y point in the direction the arrow came from, while the z component points in the direction of the movement.
Steps to reproduce:
- Take a bow and arrows
- Shoot in any direction
- Observe the direction the arrow is facing
General description:
The direction arrows are facing does not, in general, align with their visual appearance and their "Motion" nbt tag. The x- and the y-direction components point from tip to tail, while the z-direction component points from the tail to the tip. This affects tp ^ ^ ^1 execution, resulting in an illogical arrow movement, as well as other dependent actions.
What I expected to happen was:
Either the arrow entity faces the direction it is/was moving (preferably) or the complete opposite direction.
What actually happened was:
Components x and y point in the direction the arrow came from, while the z component points in the direction of the movement.
Steps to reproduce:
- Take a bow and arrows
- Shoot in any direction
- Observe the direction the arrow is facing
Additional information:
Seems to be present in versions all the way from 1.8 (F3 + B introduced) up to the latest snapshot (20w18a).
Everything said applies to tipped arrows and spectral arrows.
General description:
The direction arrows are facing does not, in general, align with their visual appearance and their "Motion" nbt tag. The x- and the y-direction components point from tip to tail, while the z-direction component points from the tail to the tip. This affects tp ^ ^ ^1 execution, resulting in an illogical arrow movement, as well as other dependent actions.
What I expected to happen was:
Either the arrow entity faces the direction it is/was moving (preferably) or the complete opposite direction.
What actually happened was:
Components x and y point in the direction the arrow came from, while the z component points in the direction of the movement.
Steps to reproduce:
- Take a bow and arrows
- Shoot in any direction
- Observe the direction the arrow is facing
Additional information:Seems to be present in versions all the way from 1.8 (F3 + B introduced) up to the latest snapshot (20w18a).
Everything said applies to tipped arrows and spectral arrows.
General description:
The direction arrows are facing does not, in general, align with their visual appearance and their "Motion" nbt tag. The x- and the y-direction components point from tip to tail, while the z-direction component points from the tail to the tip. This affects tp ^ ^ ^1 execution, resulting in an illogical arrow movement, as well as other dependent actions.
What I expected to happen was:
Either the arrow entity faces the direction it is/was moving (preferably) or the complete opposite direction.
What actually happened was:
Components x and y point in the direction the arrow came from, while the z component points in the direction of the movement.
Steps to reproduce:
- Take a bow and arrows
- Shoot in any direction
- Observe the direction the arrow is facing
Additional information:
Seems to be present in versions all the way from 1.8 (F3 + B introduced) up to the latest snapshot
(20w18a).Everything said applies to tipped arrows and spectral arrows.
General description:
The direction arrows are facing does not, in general, align with their visual appearance and their "Motion" nbt tag. The x- and the y-direction components point from tip to tail, while the z-direction component points from the tail to the tip. This affects tp ^ ^ ^1 execution, resulting in an illogical arrow movement, as well as other dependent actions.
What I expected to happen was:
Either the arrow entity faces the direction it is/was moving (preferably) or the complete opposite direction.
What actually happened was:
Components x and y point in the direction the arrow came from, while the z component points in the direction of the movement.
Steps to reproduce:
- Take a bow and arrows
- Shoot in any direction
- Observe the direction the arrow is facing
Additional information:
Seems to be present in versions all the way from 1.8 even 14w29a (F3 + B introduced several snapshots prior, could not load them) up to the latest snapshot 20w18a.
Everything said applies to tipped arrows and spectral arrows.
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
duplicates
The issue is duplicated by MC-182313.
How do I add "1.12.2" to Affected versions?
You can't, at least as a non-Mojang employee. The "affected versions" tab is primarily for fixing issues in the latest release. If a bug isn't present in the latest release, it's not going to be fixed for older versions. Otherwise Mojang would have non-stop reports from players that play on 1.8 servers to "fix" bugs that have been solved for years.
Knowing that the bug occurs in a specific older version however, is in fact helpful to discover when it was introduced. For something like this that was recently discovered, but may have been always present in the game of course it's a different story, but it is helpful to know it's been around for a while
I finally found the head report: MC-112474. Therefore, this question is a duplicate.