I would argue that Coordinates should include (or be renamed to and merged with) the below Vec3 in its union type, as defined below, and Rotation should include the below Rotation in its union type:
type AbsoluteFloat = number | `${number}`;
type RelativeFloat = `~${'' | number}`;
type LocalFloat = `^${'' | number}`;
type AbsoluteOrRelativeFloat = AbsoluteFloat | RelativeFloat;
type AbsoluteOrRelativeVec3 = `${AbsoluteOrRelativeFloat} ${AbsoluteOrRelativeFloat} ${AbsoluteOrRelativeFloat}`;
type LocalVec3 = `${LocalFloat} ${LocalFloat} ${LocalFloat}`;
type Vec3 = AbsoluteOrRelativeVec3 | LocalVec3;
type Rotation = `${AbsoluteOrRelativeVec3} ${AbsoluteOrRelativeVec3}`;
(These types partially are named based on the official brigadier IDs of argument types which can be found here.)
This is much more natural and readable, especially to those who are more familiar with vanilla syntax (like people outside the project who just want to learn how a data pack works despite it being written in Sandstone). It's also more concise and short in many cases.
I would argue that
Coordinates
should include (or be renamed to and merged with) the belowVec3
in its union type, as defined below, andRotation
should include the belowRotation
in its union type:(These types partially are named based on the official brigadier IDs of argument types which can be found here.)
This is much more natural and readable, especially to those who are more familiar with vanilla syntax (like people outside the project who just want to learn how a data pack works despite it being written in Sandstone). It's also more concise and short in many cases.
For example: