[Movement] Diagnose the e1m5 stationary route window without a pause marker

Open
  • Is something wrong?
#628 1 comment 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
Tech stack
python
Domain
ai, game-dev

Research direction

Start by running python tools/argus_gait.py runs/broad_mhb_e1m5_2.log and reading docs/mover-intelligence.md and runs/mover-intelligence.results.json to rebuild the steering, goal, door and lift context around the six-second window at about t=33.1 near -555.1 1569.9 16.9. Done means classifying that window as a controller wait or a physical wedge with explicit attribution, and, if it is a wedge, adding a physical regression test before any recovery change. The study tools and tapes exist only in the local working tree, so confirm they are available before starting.

Written by the indexing model from the issue text.

Description

bug navigation physics

This follow-up comes from the 2026-10-31 broader-map study and documentation audit. Session baseline: 777ae0bbc8c439aa9888c6a0c978f428464752cf. New study tools, fixtures and tapes are currently in the local development working tree; the paths below describe that tree, not files already published at the baseline commit. No gameplay binary was installed.

Observed window

The rejected mover prototype's second 60-second e1m5 holdout has a six-second Romero stationary window beginning about t=33.1 at -555.1 1569.9 16.9, mode 2, with zero health lost. The native brief reports one freeze. The gait reader finds no chosen-hesitation marker for that window:

python tools/argus_gait.py runs/broad_mhb_e1m5_2.log

Its output labels this the pre-existing wedge class, meaning no attributable hesitation marker; that label does not prove the defect predates the candidate. The tape is not an under-fire freeze, and a single window does not establish that the mover prototype caused it. No board event occurs on that tape, though two lift selections do.

Evidence: docs/mover-intelligence.md, runs/mover-intelligence.results.json and the unchanged raw holdout tape. Closed #274 concerned an obsolete 38-node graph; this tape uses the current 155-node graph, so regenerating the old issue's graph is not an established fix.

Acceptance

  • Reconstruct steering/goal/door/platform context around the exact window using native brief/timeline and the shared tape reader; distinguish a controller wait from a physical wedge.
  • Reproduce with an unchanged control and candidate, preserving source/binary/tape identities and actual cadence.
  • If this is a necessary mover/door hold, attribute it explicitly rather than changing safety thresholds to hide it. If it is a wedge, add a meaningful physical regression before changing recovery.
  • Validate any movement change on other maps and retain aim/fire, task/mover ownership and destination safety.
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.