Repository navigation
[WONTFIX?] Hold the jump pose until a drawn player lands - #2241
Draft
sunzenshen wants to merge 2 commits into
Draft
sunzenshen wants to merge 2 commits into
sunzenshen wants to merge 2 commits into
Conversation
The legs and feet decided "moving" on 3D speed, so a player rising or falling (a jump, a drop off a ledge, a lift) played the walk animation in the air. Classic NEOTOKYO and the 2006 SDK use horizontal speed. Ladders keep the 3D test, so climbing keeps the walk animation it has today.
The jump pose ended when the client saw the ground flag, 0.2 s or more after take-off. The flag is networked as received, but other players are drawn at an interpolated position that trails it by a few tenths of a second, so the pose ended near the top of the jump and the body came down in the walk pose. On the client, the jump now lasts until a short hull trace finds ground under the drawn body, or until the flag has been set for 0.5 s. The server and the flag test are unchanged.
Contributor
Author
sunzenshen
marked this pull request as ready for review
October 15, 2026 05:21
This was referenced Oct 15, 2026
sunzenshen
marked this pull request as draft
October 15, 2026 07:02
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Description
Case 1: jump pose ends at the top of the jump.
Review page: exported review page (Dropbox) · live review page (opening it lets you request access with your email or Claude account).
Other players drop out of the jump pose near the top of their jump in neo and come down in the walk pose, with a walk bob of the torso as they land. Classic NEOTOKYO holds the jump pose until the landing and goes straight to the idle legs. Two causes, one commit each:
HandleJumpingends the jump whenFL_ONGROUNDis set, 0.2 s or more after the jump event. The flag is networked and applied as soon as it arrives, but other players are drawn at an interpolated position that trails it: logged per frame, the flag arrived 0.19-0.27 s before the drawn body reached the ground, around the top of a standing jump. On the client the jump now lasts until a short hull trace (2 u, the player's own hull) finds ground under the drawn body. If the trace finds nothing while the flag has been set for 0.5 s, the jump ends anyway, so a surface the client cannot trace never leaves a player stuck in the pose. The server's anim state and the local player keep the flag test; for the local player the predicted origin and flag agree, and the trace ends the jump on the same frame.HandleMovingandComputePoseParam_AimYawtreated any velocity over 0.5 / 1 u/s as moving, so a rising or falling player played the walk legs (also when dropping off a ledge or riding a lift). Both now use horizontal speed, as classic NEOTOKYO and the 2006 SDK do. A player on a ladder keeps the 3D test, so ladder climbing looks as before (classic's ladder look was not compared).Independent of the other animation PRs from the review page: this touches only
hl2mp_playeranimstate.{cpp,h}; the upper-body blend PR (case 2) touchesmultiplayer_animstate.{cpp,h}. The "standing players stay twisted" case (3) will touchComputePoseParam_AimYawtoo; whichever merges second rebases.How to test
bot_mimic 1), watch the other player jump in place: the jump pose lasts until the feet touch the ground, then the idle pose, no walk legs or torso bob in the air.Results
Same scripted session as the review page:
nt_rise_ctg, mirror bot onbot_mimic 1(NSF Assault, MPN), viewed from a listen-server client atcl_updaterate 20/cl_interp_ratio 2(0.1 s lerp, as classic's defaults); classic NEOTOKYO logged withcl_showanimstate, neo with a temporary client-side per-frame logger of the anim layers, ground flag and drawn height (not part of this PR). neo: Release client builds of master (f426c22) and this PR. Standing jumps: 2 in the review pass plus 4 in a jump pass.Jumplength, standing jumpsJumpIdle_lower20walk_lower6-7, thenIdle_lowerIdle_lower20JumpJumplengthIn the review pass the running jump lands on a 12 u step in neo, so it is short in both neo builds (0.43 / 0.44 s); with this PR it ends where the drawn body meets the step. The local player's own jump (thirdperson) is 0.56-0.57 s in this PR; the bug did not affect it.
Unchanged, checked on the same pass: crouch / stand timing, fire and reload gestures, upper-body weights while walking and peeking, standing breathing. A Debug client with 10 bots on
ntre_rise_ctg(Recon crouch jumps of 57-63 u held until landing) logged no new assert (only the knownneo_root.cpp (378) localizedWszStrat startup).Not changed: the jump pose starts 0-0.16 s after the drawn lift-off (the jump event fires when it arrives, not interpolated), the same as master. Ladders were not filmed; the ladder path keeps master's test.
GIF (classic / master / this PR, standing jumps): case1-jump-land.gif
How this was compared
The code came first: NT;RE's player animation code was read against the 2006 Source base class that classic NEOTOKYO is built on (still in this tree as
shared/base_playeranimstate.cpp); classic'sclient.dllwas read only for class names, console settings and constants. Then both games logged every frame (classic's built-incl_showanimstate_log, an equivalent harness log in NT;RE) on the same map and spot, with the same class, weapon and scripted keys, and the same scripts read both logs. The clips only illustrate; the numbers above come from the logs.