the symptom, in your words

"Grounded wish-speed servo silently destroys applied velocity"

✓ verified on engine 26.07lane: Writing gameplayposted

▸ SYMPTOM

An externally applied velocity -- mantle-exit carry, knockback impulse, launch boost -- looks correct in telemetry at the moment it's applied, but the player perceives no momentum at all. Boundary measurements (exit tick velocity, applied-velocity magnitude) read "100% carried" while the character visibly goes nowhere.

▸ CAUSE

The standard ground tick MoveTowards(horiz, wish*topSpeed, accel*dt) has no momentum concept. A full-run-speed exit (e.g. 7.3 m/s) that touches the ground is clamped to the wish target (walk speed with input, zero without) at the ground acceleration rate -- typically dead in 0.14-0.24 s, or ~7 ticks at 50 Hz. This is physically correct (ground friction) but perceptually nonexistent, and every boundary measurement reads green because the velocity WAS applied -- it just didn't survive contact.

The debugging trap: measuring at the exit tick and at the applied-velocity tick both show the effect is working. Only per-tick telemetry across the first second reveals the servo eating the velocity on contact.

▸ FIX

Two fix families:

A) Give the effect enough airtime to be the feature (preferred for traversal moves):

snippet
// At the mantle crest: ballistic hop instead of ground carry
velocity.z = 3.5f * M;  // ~0.71s airtime
velocity += carryDir * carrySpeed;
// Propulsion lives in the air where the servo can't reach;
// landing decay is normal jump behavior

B) Landing-momentum retention in the ground tick (for knockback/blast):

snippet
// Blend applied velocity into the wish target for N ticks after landing
if (_landingMomentumTicks > 0)
{
    wishSpeed = MathX.Lerp(appliedSpeed, wishSpeed,
        1f - (_landingMomentumTicks / landingBlendTicks));
    _landingMomentumTicks--;
}

Option B has blast radius -- it touches every landing. Option A is safer when you can design the effect to stay airborne.

Measurement law: when an applied velocity "disappears", measure per-tick across the first second (state, horizontal speed, vertical velocity per tick), never at a single boundary. Each state transition (exit tick, applied-velocity tick, first ground contact) is a separate suspect, and a boundary read can be true at one and blind at the next.

▸ WHY IT WORKS

The airtime approach moves the propulsion phase entirely above ground contact, where the wish-speed servo has no authority. The character experiences the velocity as a normal jump arc, and landing at walk speed is expected jump behavior. The per-tick measurement protocol catches the servo's clamping within the first few frames of contact, making the problem visible before you burn debugging cycles on false theories.

Verified on engine 26.07: seen in a real project.
s&box moves fast; an undated fix is a liability. Spot a stale detail?

Want to know when new guides or fixes drop? Join the community to help build this out. Report gotchas, flag outdated fixes, or just lurk.

Join the Discord