Repository navigation
feat(shell): replay link in the config pane (#126) - #150
Conversation
|
@nnunley this is marked draft because I haven't had enough time to think hard about this. I'm not sure if the approach in this PR is the best way. |
|
As a thought: you can include the current replay link in the browser window using our js bridge. |
Yeah, good idea. Probably should. I was thinking along the same lines some days ago, but feeling noncommittal about the UI shell as it existed. I thought at the very least, console.log it. I'll think a little more - if not in this PR, I'd land it in/after the one that introduces web UI. |
|
|
Consider using xterm web-links addon / OSC 8: |
0111520 to
dbfcac8
Compare
mparrett
changed the title
mparrett
added
deploy-preview
fe832c4 to
a7b65cd
Compare
Dev-build deaths (?mode=dev) now fire the existing xsofy/replay-dump capture unconditionally — no ?dump-replay= param needed — and the shell turns the emit into a chip in the ⚙ config pane: a ?replay= link that reproduces the run (long-press for the OS copy/share sheet). Emits already arrive as window CustomEvents, so no new host plumbing. Unavailable codes (parameterized-action runs) stay hidden rather than rendering a dead link; the chip is dev-only and invisible until a capture lands. Native XSOFY_DUMP_REPLAY stderr capture is unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…session context Death isn't special: encode-run-safe works on any live world, so a dev-gated bridge emit (every 10th turn, and turn 1 so the chip is live from a run's first action) keeps the config-pane chip current without dying first. Same :replay-dump channel as the death capture; native stays a js/emit no-op. The link also carries the session params now (mode/dpad/…, seed dropped — the code brings its own): the bare ?replay= URL landed in a chrome-less play tier that read as a dead click. Verified end-to-end in emulation: turn-1 emit, chip with a real code, link boots the replay with HUD + dev chrome. Note: an INVALID ?replay= code is a fatal decode error (nth out of bounds) — pre-existing, worth its own issue for a graceful fallback. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The live capture and the death capture now fire on every web run (native stays opt-in via XSOFY_DUMP_REPLAY / ?dump-replay=), and the config-pane chip loses its dev-only class: sharing/reproducing a run is a player feature. The chip also resets on every new run (xsofy/startup), fixing the stale-link window where it kept the previous run's code and a tap read as doing nothing. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The :replay-dump payload carries :turn (live and death emits); the chip labels itself 't42' instead of a truncated code prefix — the turn tells a human how fresh the capture is, the code prefix told them nothing. Falls back to the code snippet if an emit lacks :turn. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
7f36628 to
6f51265
Compare
|
So... Probably actually need a flash warning until you get your partial redraws code in. |
This is ready to go: #151 |
mparrett
added
deploy-preview
|
151 was merged, this is now unblocked. |
@nnunley I want to make sure I didn't miss your intent here. I assumed you were referring to the strobing replay, which was fixed by the (now merged) redraw improvements. Let me know if there was anything else. I'm taking the OSC-8 terminal link as a follow-on, since it'll require a little more thought about where (and when) we want that link to appear in the terminal. I also need to catch myself up on the state of any relevant issues. This PR, for the web replay link, is good to go. |
Closes #126. Reframed from the earlier help-screen shape — #137's config pane is the natural surface now, so this stacks on #137.
The gap (#126)
?dump-replay=fires(js/emit "xsofy/replay-dump" {:code …})on death, but nothing web-side listened: the code never surfaced on the primary (mobile) test surface. Native capture (XSOFY_DUMP_REPLAY→ stderr) already works and is unchanged.This change
encode-run-safeworks on any live world. Native stays opt-in (XSOFY_DUMP_REPLAY/?dump-replay=).?replay=link that reproduces the run in one tap (long-press for the OS copy/share sheet), carrying the session params (mode etc.; seed dropped — the code brings its own). Emits already arrive as window CustomEvents, so there's no new host plumbing. Unavailable codes (parameterized-action runs) keep the chip hidden rather than rendering a dead link, and the chip resets on every new run so it can never link a stale one. Not tier-gated: sharing/reproducing a run is a player feature.vs the earlier shape
The previous draft rendered a replay-code page inside the game's help screen. The config pane is the better surface: no game-render involvement, tap-to-reproduce instead of transcribing a code by hand, and the same coverage on the mobile test surface. The help-screen implementation is preserved on a local archive branch if the on-demand mid-run capture turns out to be wanted too.
Verification
?replay=code is a fatal decode error ("nth index out of bounds") — filed as Invalid ?replay= code crashes the boot (fatal decode error) #159._Config pane with the chip:
https://xsofy.quest/pr-preview/pr-150/?replay=AQAAAAAilCqbAwthdXRvZXhwbG9yZQVyaWdodARsZWZ0AAAAAwAUAQQCEA