937f05595c
F1: the human watched the real game and it repeats on a held direction, on the stick AND (confirmed separately) the d-pad. gamepad.gd had predicted this exact refutation in its own words, so one-step-per-deflection stops being the conservative reading and becomes a known defect. Mechanism: Gamepad.held_direction() polls the DEVICES -- not Input.is_action_pressed, because ui_up/ui_down sit on the stick at Godot's 0.50 deadzone while the port steps at the game's measured 0.61, so polling the action would repeat through the exact band ENTER exists to exclude. Boot._menu_repeat() re-applies the same guards a real press gets, rather than sharing them, because a second input path is where this port's defects hide. The RATE is NOT shipped, on instruction: an invented interval is indistinguishable from a measured one later. An earlier draft of this change had 0.40/0.20 with a why attached; that was the named failure mode and the numbers are removed, not commented out. repeat_due() returns 0 until both are set. Flagged at the adoption site: verify-input's 'a held stick is ONE step, not six' asserts the ABSENCE of this feature and will go red when a rate lands -- for the right reason, and looking exactly like the jitter bug returning.
100 lines
4.7 KiB
Markdown
100 lines
4.7 KiB
Markdown
# 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.
|