731acffaa9f0019cf62680ce4863e6d249241576
3 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
07d83c4229 |
fix(port): held_direction() polls the stick instead of reconstructing it
Reported by a human on a real controller: hold the left stick down, the cursor moves one item and stops. The repeat never runs. `held_direction()`'s own comment says "Polled at the DEVICE, never through Input.is_action_pressed". It was not. The d-pad and keyboard branches polled; the STICK branch read `_latched`, which is a reconstruction of the stick's position from the event history. That reconstruction is only as good as the last event seen. A stick held still sends nothing, and one event reading below RELEASE -- a spring settling, a deadzone-shaped value, a driver emitting a zero on focus change -- clears it with no event afterwards to set it back. The port then believes the stick is centred while the player is holding it, which is precisely the symptom reported. Now polls `Input.get_joy_axis()` against the game's own 0.61, which is what the comment always meant. The latch stays as a fallback for INJECTED events, so the script harness and verify-input keep testing something. 🔴 Every instrument here missed this because every instrument SUPPLIES the input it measures: verify-input ticks repeat_due() directly, --script sends InputEventAction which bypasses the input map, and the new --script=hold: injects its own axis event. All three agreed with each other and none read a device. Same shape as the 2026-09-01 report that opened gamepad.gd, one level deeper, with the lesson already written at the top of that file. So this adds the two things that would have caught it: --script=hold:down:2.0 hold one real axis deflection and log every move --input-probe print what the devices report, on change ⚠️ The fix itself is NOT verified. It matches the symptom exactly and was found by reading, but only a human holding a stick can confirm it, and the probe exists so the answer is measured either way. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
c3758e3850 |
port: land the play-tested work, and only that
Takes the port branch up to |
||
|
|
65cefa74c3 |
monorepo: one repository for the decoders, the port and the corpus
Some checks failed
Merges the Godot port into the reverse-engineering repository, preserving both
histories -- 1019 commits of corpus plus the port's 31, brought in by subtree
merge and then moved into place so git can follow each file across the rename.
The reason is not tidiness. The two-repo split forced the exporter to depend on
the decoders by pinned revision, and that created a whole class of failure that
now disappears: a sha reachable only from a topic branch, orphaned by a
squash-merge, breaking a fresh checkout silently at build time. It also forced a
live read-only mount of one agent's working tree into another's container, which
is why a contract file could move mid-iteration. With a path dependency, a
decoder change and the exporter change it requires land in the same commit or
not at all.
Canary stays separate: it is a fork tracking upstream.
New structure for the long term:
docs/game/ how the game is NAVIGATED -- menus, modals, prompts, alerts,
and in-game flight. Written so nobody rediscovers it. Mostly
open questions on purpose; the in-game tutorials are the
resource for the flight half.
docs/port/MODDING.md
modding as a constraint on the exporter TODAY, not a later
feature: one logical asset in one file (the disc splits nearly
everything, and resolving that is the exporter's job), names a
person recognises, PNG/OGG/OGV/JSON only, base-and-overrides so
re-exporting is always safe, provenance in every file.
data/base + data/mods
generated tree and drop-in overrides, both gitignored
exchange/ transient inter-agent files, deliberately outside history
docs/agents/ the team protocol
Both the README and the navigation doc lead with the correction that cost the
most: the oracle is the real game under Xenia Canary. Reborn's renderer is a
hypothesis under test, it has been wrong, and treating it as ground truth
propagated into three documents and both agents before a human caught it.
Scripted modding stays possible without being built: no screen name is hardcoded
in GDScript and there is no native code in port/, which is what Godot Mod Loader
needs to be able to substitute behaviour later.
|