[Physics] Check a stall jump's landing on the heading air control will fly, not the launch velocity

Open
  • Is something wrong?
#797 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
22/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Domain
backend, game-dev

Research direction

The bug sits in the QuakeC bot code: the stall detector around src/argus.qc line 11505 sets ar_jump and turns angles_y, and the jump fires near line 2735, where the landing check in Argus_JumpLandHazard runs on the pre-turn heading. Reproduce with a fixture or targeted probe at the dm4 north-west pocket near 96 389 -296, using the runs/shane_dm4_2026-11-14_ed8926.log tape. Done means the check either refuses the bent flight or holds the approved line, with no jumpveto from a bot already in lava or slime, and stall parity holds on dm4 and dm2.

Written by the indexing model from the issue text.

Description

bug physics

Problem

Argus_JumpLandHazard (#773) refuses a reachability, stall or escort jump that would land in lava, slime or a void. It predicts the landing from the bot's horizontal velocity at the moment of launch. For the stall jump, that is not the flight the bot then flies.

The stall detector (src/argus.qc, around line 11505) sets ar_jump and, on the same tick, turns angles_y by 120 to 240 degrees; the stall also re-plans the route. The jump fires on the next physics frame (src/argus.qc, around line 2735), and the check approves it on the old heading. Once the bot is airborne, Argus_AirAccelerate follows the new wish heading. Only the predictive gap jump sets the flight latch (ar_sprintstate = 3) that keeps air control on the checked line.

Observed

dm4 human session on the installed build (runs/shane_dm4_2026-11-14_ed8926.log, skill 1), Joe Rogan at about t 100:

t Position Speed Event
100.2 96.6 389.3 -296 85 u/s, heading 246 stall, then jump; no jumpveto, so the check approved it
100.7 25.7 370.6 -252.8 201 u/s, heading 115 airborne, no damage taken, route re-planned on the jump tick
101.2 109.8 331.4 -360 239 u/s in the lava pocket, hp 80
about 102.8 -16 389.7 -360 jumpveto, then death to world

The bot gained 116 u/s in the air and turned about 130 degrees, with no damage, so this was air control.

The trailing jumpveto is a second, smaller defect. The stall jump keeps being attempted, and refused, while the bot is already in lava. A jump from a pocket whose lip is 64 units up cannot clear it (apex about 46 units), so neither the attempt nor the refusal helps.

How common

Across 30 recent dm4 tapes with 88 world deaths, four followed a stall and then a jump within about 3 s. All four landed in the same north-west pocket at z -360. Three are navmesh-ladder tapes (runs/nm_cand2_dm4_*) built before #773, when the stall jump had no landing check at all. On current code this tape is the only case found so far. It is a narrow path, not a dominant lava cause.

Proposal

Make the check describe the flight the bot will actually fly. Either:

  1. Check the landing along the heading air control will follow after the stall turn (the post-turn ar_moveyaw), with a speed bound that covers what Argus_AirAccelerate can add over the flight time; or
  2. Set the flight latch on the stall jump so air control holds the launch line the check approved.

Option 2 is simpler, but it may defeat the stall jump's purpose of hopping out in a new direction. Option 1 keeps that purpose. Separately, do not attempt or log a stall jump while the bot's feet are in lava or slime (ar_feettype).

Acceptance

  • A fixture or targeted probe reproduces a stall jump at the dm4 north-west pocket edge near 96 389 -296, and the fix refuses the bent flight or holds the safe one.
  • No jumpveto lines from a bot already in lava or slime.
  • Stall parity on dm4 and dm2, at least three tapes a side and five on dm2, because the stall jump is the main unstick move.
Dominant language
Rust
Stars
4
Forks
0
Avg merge
30m
Merged PRs (30d)
130

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from saworbit/argus

All issues in saworbit/argus

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.