0ddeffa9a6
flight_probe.Pad opened /tmp/sylph-vgamepad.fifo, "the vgamepad server's FIFO". That server was removed when the uinput pad was replaced by Canary's --hid=file driver, because a uinput device is not namespaced and scripted presses leaked to the host's desktop. The FIFO is now an ordinary 91-byte file nothing reads, and /tmp/xenia_pad.txt - the file the emulator polls - was 0 bytes while the "autopilot" was flying. So every axis, trigger and button from pilot.py, autopilot3.py, aim_probe.py and flight_probe.py went nowhere, silently. The corpus already carried this trap for the SHELL scripts (canary-scripted-input-traps.md, "every call here failed silently"). This class was missed, and every flight tool imports it. Verified against the oracle rather than by inspection, on runs confirmed animating at both ends of every phase: before, full stick produced 0.00 degrees of heading change over 4 s while the ship travelled 350-735 units, and the attitude matrix at pos-0x70 was byte-identical; after, LX=-1 turns 12.72 degrees and LX=+1 swings the flight direction from [1,0,0] to [0.13,-0.14,-0.98], with the matrix moving 0.44/0.31 under stick and 0.0000 at neutral. That also REFUTES the "stale attitude matrix" suspicion from the earlier pass - pos-0x70 is live and tracks the ship; it only looked dead because nothing was turning the ship. Still open and said plainly: with the pad fixed a 150 s pilot run still fires 0 times, with |aim yaw| still exactly 90.0 and the target 36-43 km away. Steering works now, so what is left is the stick SIGN against the pilot's error convention or a target selection that commits to something too far to close. Both are finally testable. findrot_global/findself/findspeed/selfstate still write to the dead FIFO and now say so in place; they are not repaired because none has been re-run since. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
7.5 KiB
7.5 KiB