Walk-up callsign/mech request: join menu -> relay -> the session egg

The 1995 front-desk conversation, over the internet.  join.bat/
join_lan.bat now open a JOIN-GAME menu (the FE in BT_FE_JOIN trim:
CALLSIGN edit + the 18-mech list + JOIN); the choice relaunches into the
normal join with BT_CALLSIGN/BT_MECH env, rides the relay SEAT_REQUEST
as {callsign NUL mech NUL} (empty payload = roster defaults, wire-
compatible), and the relay validates the mech tag, HOLDS egg delivery
until every pod's console pad is connected, rewrites the egg via
eggmodel (vehicle= + rasterized callsign bitmaps, graceful no-PySide6
fallback) and streams it to all pads -- so every player's egg copy
carries every player's callsign.

The hold is gated on CONSOLE-PAD count, not game-side registration: a
pod HELLOs only after parsing the egg's roster, so a registration gate
deadlocks (hit live in the first run; pods animate in WAITING FOR
MISSION ASSIGNMENT during the hold).

Verified 2-node e2e (env-injected requests): thor/vulture requested over
roster defaults bhk1/ava1 -> relay held 1/2, released at 2/2, rewrote
both seats (relay log), the delivered egg carries vehicle=thor/vulture +
name=VIPER/MONGOOSE, both pods launched and built [cyl] tables for both
requested mechs.  Join-menu layout screenshot-verified; the menu's
click-through relaunch awaits live human verification.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
arcattack
2026-07-22 13:58:51 -05:00
co-authored by Claude Opus 4.8
parent eb618fe9e6
commit fcedc046cf
9 changed files with 239 additions and 25 deletions
+16
View File
@@ -378,6 +378,22 @@ phase). Plan: `~/.claude/plans/partitioned-snuggling-piglet.md`.
SEAT_REQUEST branch (btconsole.py). Verified: 8/8 stub tests (distinct seats, FULL on
exhaustion, claim clears reserve, duplicate-HELLO refused) + 2-node localhost e2e with NO
BT_SELF on either pod → both seated, full ladder, launch, UDP flowing.
- **WALK-UP CALLSIGN/MECH REQUEST (2026-07-22) [T2]**: the 1995 front-desk conversation, over
the wire. join.bat/join_lan.bat set `BT_FE_JOIN=1` and launch ZERO-ARG -> the FE menu in JOIN
trim (btl4fe.cpp `FeJoinOnly()`: CALLSIGN edit + the 18-mech list + JOIN; screenshot-verified)
-> `BTFeLaunchJoinRelay` relaunches with the universal join args + `BT_CALLSIGN`/`BT_MECH` env
-> `RelayRequestSeat` sends them as the SEAT_REQUEST payload `{callsign NUL mech NUL}` (empty
= roster defaults, wire-compatible) -> the relay validates the mech tag (the 18 certified
codes), stores per-seat prefs, and **HOLDS egg delivery until every pod's console pad is
connected** -- NOT until game-side registration: a pod HELLOs only after parsing the egg
roster, so that gate DEADLOCKS (hit live, fixed; pods animate in WAITING FOR MISSION
ASSIGNMENT during the hold) -- then rewrites the egg via eggmodel (vehicle= + rasterized
callsign bitmaps; PySide6 absent -> vehicles still apply, bitmap fallback logged) and streams
it to all pads. VERIFIED 2-node e2e: requested thor/vulture over roster defaults bhk1/ava1 ->
relay held 1/2, released 2/2, rewrote both seats, LAST.EGG carries vehicle=thor/vulture +
name=VIPER/MONGOOSE, both pods launched with `[cyl] table 'thor'/'vulture'` live. The FE
menu->relaunch path itself: awaiting live human verification (env-injected path is what the
e2e run proves). BT_SELF pods skip the request (defaults).
- **PATIENT WALK-UP (2026-07-18) [T2]**: a pod dialed at a relay that isn't up yet no longer
aborts (release `Fail()` is a bare `abort()` = looked like a "crash", field report). Both the
seat request (`RelayRequestSeat`) and LAN discovery (`BT_RELAY=auto`) now RETRY (2s dials, 30