Just making sure
Problem
Currently, when creating a Display, its rotation (yaw and pitch) is directly tied to the direction the player is looking at the moment of creation. This makes it difficult to properly control hologram orientation, especially when placing Displays in environments where the player cannot always look straight ahead during setup.
Although rotation is already conceptually treated as a separate property in the plugin (using yaw and pitch), in practice the initial orientation is still inherited from the player’s view direction during creation. This leads to inconsistent behavior and reduces predictability when creating Displays.
The documentation already shows that rotation is a configurable and independent system:
-
The /dh displays set-facing command allows explicitly setting yaw and pitch independently of position, within defined ranges:
- yaw: -180 to 180
- pitch: -90 to 90
-
Additionally, yaw and pitch are available as configurable attributes in attribute-defaults.yml, confirming that rotation is intended to be a separate concern from position
Despite this, the creation process still couples orientation to player direction, which introduces unnecessary friction when precise control is needed.
Feature
I would like to propose a strict separation between position and rotation for Display Entities:
1. Position (Location)
Responsible exclusively for defining where the Display exists in the world.
- World + coordinates (x, y, z)
- Must not include any rotation data
- Should not contain
yaw or pitch
This aligns with the current location definition used in configuration:
2. Facing (Rotation / Orientation)
Responsible exclusively for defining the direction the Display is facing.
-
Controls only yaw and pitch
-
Fully independent from position
-
Default values:
-
Must not inherit player view direction on creation
Alternatives
There are no viable alternatives within the current system behavior and documentation. Existing commands and configuration options still rely on player-based orientation during creation, and there is no consistent built-in mechanism to fully decouple initial rotation from placement without requiring manual correction afterward.
Just making sure
Problem
Currently, when creating a Display, its rotation (yaw and pitch) is directly tied to the direction the player is looking at the moment of creation. This makes it difficult to properly control hologram orientation, especially when placing Displays in environments where the player cannot always look straight ahead during setup.
Although rotation is already conceptually treated as a separate property in the plugin (using
yawandpitch), in practice the initial orientation is still inherited from the player’s view direction during creation. This leads to inconsistent behavior and reduces predictability when creating Displays.The documentation already shows that rotation is a configurable and independent system:
The
/dh displays set-facingcommand allows explicitly settingyawandpitchindependently of position, within defined ranges:Additionally,
yawandpitchare available as configurable attributes inattribute-defaults.yml, confirming that rotation is intended to be a separate concern from positionDespite this, the creation process still couples orientation to player direction, which introduces unnecessary friction when precise control is needed.
Feature
I would like to propose a strict separation between position and rotation for Display Entities:
1. Position (Location)
Responsible exclusively for defining where the Display exists in the world.
yaworpitchThis aligns with the current location definition used in configuration:
2. Facing (Rotation / Orientation)
Responsible exclusively for defining the direction the Display is facing.
Controls only
yawandpitchFully independent from position
Default values:
Must not inherit player view direction on creation
Alternatives
There are no viable alternatives within the current system behavior and documentation. Existing commands and configuration options still rely on player-based orientation during creation, and there is no consistent built-in mechanism to fully decouple initial rotation from placement without requiring manual correction afterward.