Class WalkGaitParameters.AsymmetryGroup
- Namespace
- CodeSmile.AnyMotion.AnimateYourself.Gait /
- Assembly
- ApiSource.dll
L19 (limp / asymmetric gait): per-limb divergence, one block for each of the four limbs,
applied in WalkGait.EvaluateLeg and WalkGait.EvaluateArm. Every multiplier is 1
by default, which is an even gait and the shipped behaviour. The pelvis and torso response
(favouring the good leg, rolling onto it, winding up against it) is not authored here — it
already falls out of WalkGait.Evaluate's existing leg-differential and weight-balance
terms once the two legs' strides diverge, since those derive from leg state rather than from
independent oscillators.
[Serializable]
public sealed class WalkGaitParameters.AsymmetryGroupExpand Details ...
- Inheritance
-
objectWalkGaitParameters.AsymmetryGroup
Remarks
Which channels may diverge per limb, and which may not. A multiplier here may scale a
limb's own reach, height or bend — how far it travels, how high it lifts, how much a
joint folds. It may not scale anything that feeds the shared two-leg phase model:
DutyFactor (how long a foot stays planted),
LegPhaseOffset (how far apart in the cycle the two legs are), and
the cadence derived from MoveSpeed. Both legs run on one phase
model whose stance sweep is what cancels body travel, so a per-leg stance duration
desynchronises that model rather than producing an uneven gait — which is why duty-factor
asymmetry needs the general contact-schedule field (locomotion-catalog.md §5) and not a
multiplier. PhaseOffset is shared for the same reason: an arm takes
the opposite leg's phase, so a per-arm offset would decouple an arm from the leg it belongs
with.
Why four blocks rather than one selected limb. This replaces an AffectedLeg
enum plus three multipliers, which could describe only one differing leg and no arm at
all. Two differently affected legs (a stride difference on one, a dragged foot on the
other) were unreachable by construction, and WalkGait.EvaluateArm takes a side but
had no per-side multiplier to read, so both arms were always the same swing mirrored. The
group shape is the expensive half of this to change once presets exist, so it is decided
once here rather than widened later — the narrow reservation named in
scout-p7-reserved-fields-budma/report.md §5.4 (C5, per-limb divergence).
A preset written before this reshape loses its asymmetry. The four keys it carries
— AffectedLeg, StrideMultiplier, StepHeightMultiplier,
KneeBendMultiplier — have no field to land in, so JsonUtility drops them and
every multiplier below loads at 1. That is an even gait, not a broken one.
Version is deliberately not bumped: it has no consumer,
the JSON preset schema is not frozen yet (P7), and the same decision was recorded for the
2026-08-15 WalkGaitParameters.LimbReachGroup split. See CLAUDE.md → Current state for
that reasoning; the repository's own serialized characters were rewritten to the new shape
in the same change rather than left to degrade.
Fields
LeftArm
[Tooltip("How the left arm differs from an even swing, for example an arm carrying something or an injured shoulder.")]
public WalkGaitParameters.AsymmetryGroup.ArmDivergence LeftArmField Value
LeftLeg
[Tooltip("How the left leg differs from an even gait.")]
public WalkGaitParameters.AsymmetryGroup.LegDivergence LeftLegField Value
RightArm
[Tooltip("How the right arm differs from an even swing.")]
public WalkGaitParameters.AsymmetryGroup.ArmDivergence RightArmField Value
RightLeg
[Tooltip("How the right leg differs from an even gait. This is the usual place to author a limp: leave the left leg alone and shorten this one.")]
public WalkGaitParameters.AsymmetryGroup.LegDivergence RightLeg