a23c321831
Takes the port branch up to77320d5e-- the state the human play-tested on 2026-09-02 -- for SOURCE paths only. Not a branch merge: `auto/port-p6-audio` is 366 commits and 938 files, and most of that must not land. WHAT COMES IN (76 files, all human-confirmed working): * the logo splash animation.08ed3dd1found it: `pose_at` ASSIGNED the settle instant instead of clamping to it, so the splash never animated at all -- and the same bug manufactured a passing harness result, because the harness photographed t past the settle. Confirmed by play-test: "cannot notice any obvious difference from the actual game." * gamepad input -- (A)/(B) bound additively (`ui_accept` ships with NO joypad binding), stick latched with hysteresis at the game's own 61% digitise threshold. This is what made (A), video-skip and Extras work at all. * menu navigation and flow, menu audio, the exporter, the authored declarations, and 23 verification tools under tools/port/. WHAT IS DELIBERATELY LEFT ON THE BRANCH: * everything afterc0ae460a-- the F5/F6 title-timing investigation, whose own tip commit calls itself a "hand-off for one-minute human checks". Unchecked by definition; it goes through the new review gate like anything else. * the OPTIONS menu work of 2026-09-03. Real, probably good, NOT play-tested. * the F1 repeat mechanism, which its own commit calls "deliberately inert". WHAT MUST NOT LAND, AND WHY THE .gitignore CHANGED: 545 MB of extracted game content was committed on that branch -- 850 sprite, audio and transcoded video files under `export-probe/` and `export-probe2/`, plus 246 MB of loose .wav and .tsv at the repo root. This repository's own rule, in this file, is "never game content". The rule was not missing. It was written, and it was tightened on that very branch, with a careful comment explaining why BOTH `export/` and `data/base/` had to be listed -- while the exporter was writing to a third name that nobody had thought to list. Enumerating names is the thing that failed. So the ignore rules now describe the SHAPE: any top-level `export*/`, game media by extension, and loose capture output at the root. Verified both ways -- it catches all four offenders and ignores nothing currently tracked. Verified: `cargo check --workspace` clean; all nine GDScript files parse in project context, with a positive control (an injected syntax error is detected, 3 lines) so the clean result means something. `tools/port/check-all` was NOT run -- it needs the container, the export tree and a display.
4.7 KiB
F1 — the menu repeats on a held direction: mechanism shipped, rate deliberately not
Status: ✅ mechanism implemented and wired. 🔴 inert on purpose — it does nothing until a measured repeat rate exists. Written 2026-09-02 by the Port.
What was reported
Two statements from the human, both about the real game, a play-test apart:
"Moving stick up/down and holding only moves one item. In game it actually continues to move when holding up/down, just at a medium pace so player does not need to move pad middle↔up/down, but also slow enough to see which item is selected and move to target."
"Confirmed D-Pad does repeat when holding too."
The file predicted its own refutation
gamepad.gd carried this, written when the latch was added:
"Whether the real game repeats while a direction is held, and how fast, is unknown… If the game does repeat, this is a difference a human will notice as 'I have to flick it again', and the fix is a measured repeat interval — not a guessed one."
That is exactly what happened, in the words it predicted. So one-step-per-deflection is no longer the conservative reading — it is a known defect, and keeping it is choosing a wrong behaviour over an approximate one.
What was built
Gamepad.held_direction() |
−1 / 0 / +1, polled from the devices |
Gamepad.repeat_due(delta) |
one step or 0, per frame |
Boot._menu_repeat(delta) |
calls it under the same guards a real press gets |
Why it polls devices and not Input.is_action_pressed
ui_up/ui_down are bound to the stick axis at Godot's 0.50 action
deadzone, while this port steps at the game's measured 0.61 (ENTER).
Polling the action would repeat throughout the 0.50–0.61 band — the exact band
ENTER exists to exclude — so the repeat would contradict the threshold on the
same stick, on the same frame.
That is the input-map lesson from 2026-09-01 arriving in a new place: assert
the device, not the layer above it. The stick reads from the latch
accepts() already maintains, so the first step and the repeat cannot disagree
about hysteresis; the d-pad reads JOY_BUTTON_DPAD_UP/DOWN directly, which the
human's second report makes load-bearing rather than defensive.
Why the guards are duplicated rather than shared
_menu_repeat re-applies the same four conditions _unhandled_input applies —
no movie playing, a menu exists, its stack is non-empty, no transition pending.
A repeat that could fire during a movie or mid-transition would be a second,
subtly different input path, and the first thing this port learned about input
is that a second path is where the defect hides.
🔴 And the rate is not shipped
An earlier draft of this change had REPEAT_DELAY = 0.40 and
REPEAT_INTERVAL = 0.20, with a paragraph explaining that they were authored.
They were removed rather than commented out, on an explicit instruction:
"Take the RATE from the Decoder — do NOT ship a placeholder interval. An invented rate here is indistinguishable from a measured one later, and this is the exact field where that already cost us."
The instruction is right and the draft was the named failure mode: the
explanation would have merged, the numbers would have felt roughly right, and
nothing downstream could have separated them from a measurement. REPEAT_DELAY
is -1.0; repeat_due() returns 0 while repeat_rate_known() is false.
One thing about the rate IS measured, and it narrows the question. The game digitises the left stick to four direction bits at 61 % deflection, so it cannot see deflection magnitude at all — the repeat it drives cannot be faster-the-harder-you-push. That excludes the one competing model, so only two constants are open and a single measurement closes both.
⚠️ Adopting the rate breaks a green check, for the right reason
tools/port/verify-input asserts "a held stick is ONE step, not six". That row
passes today because the feature is inert, i.e. it asserts the absence of the
repeat. When a rate is adopted a held stick should produce further steps and that
row will go red.
It is not wrong and it should not be deleted in a hurry: it was written for the 2026-09-01 jitter defect, so it will look like that bug returning. It has to be re-stated as "one step per deflection plus the measured repeat", with the jitter case still covered inside the delay window.
What this does not claim
- That the repeat feels right. It cannot — it does not run.
- Any rate, or any bound on one. "Medium pace" is a direction, not a number, and it is not recorded anywhere as data.
- That the d-pad and the stick repeat at the same rate. Both repeat; nobody has said they match, and the code currently assumes one rate for both.