Struct FFITrajectoryPoint 

#[repr(C)]
pub struct FFITrajectoryPoint {
    pub time: c_double,
    pub position_x: c_double,
    pub position_y: c_double,
    pub position_z: c_double,
    pub velocity_magnitude: c_double,
    pub kinetic_energy: c_double,
}

One integrated trajectory point, in the launch frame.

Axis convention — read this before indexing the positions. All three are ABSOLUTE positions in METERS, measured from the muzzle (the bore exit is the origin):

field	axis	sign
position_x	DOWNRANGE, toward the target	increases with range; bracket on this to find a given distance
position_y	VERTICAL height	+ up, - down (below the muzzle)
position_z	LATERAL windage	+ right as seen by the shooter, - left

Two traps this ordering sets for consumers:

• It is not the “Z is downrange, X is lateral” convention. Engine 0.13.x used that opposite convention, and consumers and API layers written against those releases may still document it, so code ported from one must swap X and Z. Nothing fails loudly if you do not — all three fields stay valid doubles, so a mix-up silently plots range as windage instead of erroring. Take the convention from this struct, not from a downstream document.
• position_y is a height, not a drop. It is positive UP and relative to the muzzle, whereas FFITrajectorySample::drop_meters is positive DOWN and relative to the line of sight. The two disagree in both origin and sign; they are not interchangeable.

Enforced in this file’s tests: zero_then_fly_with_same_deck_is_consistent brackets the zero distance on position_x, and ffi_cant_angle_deflects_laterally asserts position_z grows rightward under cant.

Fields

time: c_double

position_x: c_double

Downrange distance from the muzzle, meters. See the struct docs.

position_y: c_double

Height above the muzzle, meters, positive up (NOT a drop). See the struct docs.

position_z: c_double

Lateral offset from the bore line, meters, positive right. See the struct docs.

velocity_magnitude: c_double

kinetic_energy: c_double