#wrong-facing
11 items (11 fixes)
Angles uses .pitch/.yaw/.roll (lowercase) and Vector3 uses .x/.y/.z — capitalized sightings in a codebase belong to unrelated component properties.
Deriving a visual's facing from horizontal velocity causes 180-degree snaps on any momentum reversal — lock facing to an attach-time azimuth for pendulums and oscillators.
A front-flip rotation uses _baseRot.Forward (not .Right) when FacingYawOffset is ±90° — the offset swaps which local axis is perpendicular to travel.
CC0 kits import like any OBJ+vmdl; city kits share colormap.png, nature kits need per-color vmats, and facing is a per-model yaw guess.
Blender +X becomes world −Y after OBJ import; yaw +90° faces +X — and Blender +Y rotation tips the +X edge down.
Disabling a collider does nothing for a hand-integrated kinematic controller — noclip must be a movement state that skips traces, gravity, and ground-snap entirely.
Rotation.FromYaw alone leaves a decal flat on the floor — build a rotation that aligns the thin axis to the surface normal, then offset along it.
Transfer rest-delta rotations parent-relative (not world) — avoid the forward-hunch bug and never transform_apply scale on Mixamo armatures.
Rotation.FromYaw(+angle) is a LEFT (CCW) turn — get the sign right or steering, AI, and autopilot spiral the wrong way.
Default −Z/Y axes, bake_space_transform, no leaf bones, X/Z bone axes, mesh FBX + per-clip armature FBX; scale via ScaleAndMirror 0.3937.
Source engine convention: Forward = +X, Left = +Y, Right = -Y. Using Vector3.Right for '+X' silently slides geometry the wrong way.