Syplheed-Reborn/docs/re/pilot-never-fires.md

pilot.py never pulls the trigger — the proximal cause, measured

Status: ✅ ROOT CAUSE FOUND AND FIXED (2026-08-23, later the same day) — the flight tools' pad wrote to a FIFO nothing has read since the uinput pad was removed, so every stick, trigger and button they sent went nowhere. The gate measured below is real; it was open because the craft was never being flown at all. 🟡 The pilot still does not converge on a target in 150 s with the input working — see the last section.

The observation

Over a 900 s Stage 02 run, fire=1 appears in 0 of 13 521 logged samples. The loop flies, chases, evades and retires; the guns are never fired. Every "kill something and watch X" experiment in this corpus has therefore been leaning entirely on the wingmen.

Which gate closes

pilot.py's trigger needs all of: mode ENGAGE/DEFEND, a target, the aim error inside the firing cone, range < FIRE_RANGE (SHELL_MAX_RANGE = 4 000), and a small avoidance push. Over the 3 004 samples that had a target:

quantity	median	min	inside its gate
|aim yaw|	90.0°	90.0°	0 of 3 004 below 25°
|aim pitch|	179.2°	166.4°	0 of 3 004 below 25°
range	49 634	45 078	0 below 4 000, 0 below 10 000

|aim yaw| being exactly 90.0 in every sample is not a coincidence, it is a branch: sticks() contains

if ez < 0:                        # target behind: commit to a full turn
    yaw = math.copysign(math.pi / 2, ex if ex else 1.0)

So the committed target was behind the ship in 100 % of samples, with a pitch error near 180° — directly astern — and the range to it grew monotonically:

t=  0 s   22 265        t= 231 s   33 632
t=510 s   49 475        t= 884 s   48 200   (plateau)

The craft flies away from the thing it is chasing for fifteen minutes and the turn never completes. Nothing else needs to be wrong for the trigger to stay cold.

What is NOT established

Three explanations fit that shape and this pass did not separate them:

1. the attitude matrix the pilot reads is stale, so the ship turns and the controller cannot see it;
2. the matrix is live but fwd_row/fwd_sign name the wrong axis;
3. both are fine and the yaw stick sign is inverted, so the loop turns away from the error it is nulling.

🔴 An attempt to separate them was invalidated and is withdrawn. aim_probe.py watched the forward vector under neutral, full-left and full-right stick and reported it pinned at [-1, 0, 0] with |turn| = 0.00 °/s in every phase — which looks like explanation (1). It is not evidence: the guest had frozen partway through, confirmed immediately afterwards by frozen.py (max pixel delta 0) and by the player's position being byte-identical across 3 s. A dead world holds every matrix still. The probe is committed because it is the right experiment; its result is not.

One confusion resolved on the way

Today's repeated entities2.py self failures — # 0 moving triples, "player entity not found" — are the freeze, not a tool defect. moving() types entities by their position changing between two samples, so a frozen world yields nothing by construction. Runs where the bind failed were runs that had already stopped.

Next step

Re-run aim_probe.py on a run confirmed to be animating at the end of the probe as well as the start — the tool should check frozen.py itself and discard the phase otherwise. If the matrix does move under stick, the question becomes the sign; if it does not, the binding is what to chase.

---

✅ ROOT CAUSE — the flight tools' pad was writing into a dead file

flight_probe.Pad opened /tmp/sylph-vgamepad.fifo and wrote axis LX 0.850-style lines to it, described in its own docstring as "the vgamepad server's FIFO". That server does not exist any anymore: the uinput pad was removed because a uinput device is not namespaced and every scripted press leaked to the host's desktop, and it was replaced by Canary's --hid=file driver. The FIFO is now an ordinary 91-byte file that nothing reads.

Meanwhile /tmp/xenia_pad.txt — the file the emulator actually polls — was 0 bytes while the "autopilot" was supposedly flying.

So every axis, trigger and button from pilot.py, autopilot3.py, aim_probe.py and flight_probe.py itself went into a dead file, silently, and the craft flew on its own for the whole of every run. That is why the target sat astern at 90.0° forever and the range grew to 49 km: the ship was never being turned.

The corpus already carried this trap — for the other half of the toolkit. canary-scripted-input-traps.md records "pad.py, NOT vgamepad: that command no longer exists … and every call here failed silently, so the whole scripted route pressed nothing". The shell scripts were fixed then. This class was not, and every flight tool imports it.

Measured, before and after

Same probe, on runs confirmed animating at both ends of every phase (aim_probe.py brackets each phase with frozen.py now, after a freeze voided the first attempt):

	heading change under full stick	attitude matrix pos-0x70
before	0.00° in every phase, over 4 s, while travelling 350–735 units	d 0.0000 — unchanged
after	12.72° on LX=-1; LX=+1 swings the flight direction from [1,0,0] to [0.13,-0.14,-0.98]	d 0.4438 / d 0.3108 under stick, 0.0000 at neutral

🔴 So the "stale attitude matrix" reading is refuted, and with it the earlier suspicion that the binding was wrong: pos-0x70 is live and tracks the ship. It only looked dead because nothing was turning the ship.

🟡 Still open — the pilot does not converge

With the pad fixed, a 150 s pilot.py run still fired 0 times: over its 86 targeted samples |aim yaw| is still exactly 90.0° and the range is 36–43 km. Steering now works, so what remains is one of:

• the sign of the yaw stick against the pilot's own error convention — a controller that turns away from the error would hold ez < 0 forever, which is exactly the observed signature;
• target selection that keeps committing to something 40 km away, which at ~300 units/s cannot be closed inside the window.

Both are now testable, because the input path finally works. The measurement to make is the direct one: command the pilot's own sx for a known error and see whether |yaw| falls or rises.

Not fixed, and flagged in place

findrot_global.py, findself.py, findspeed.py and selfstate.py still write to the dead FIFO. Each now carries a comment saying so and pointing here. They are not repaired because none of them has been re-run since, and quietly changing the input plumbing under a tool whose results are unverified would only manufacture new unverified results.