Idea: better local problem reports, shared by the game and Longshot Launcher #44

New issue

Open

opened 2026-11-12 23:57:16 +00:00 by mooki · 1 comment

mooki commented

2026-11-12 23:57:16 +00:00

The idea

Help players report a problem without hunting for the right log, and give developers enough context to reproduce it. Keep collection local, separate from any decision to send something.

What is already on Longshot: Gameplay → Bug report writes report.txt, redacted copies of the current and previous logs when available, and a picture when the renderer can supply one. It lists what was written and explains missing logs/pictures. Nothing is uploaded and the game does not open a browser. PR 18 is merged: the saved link now names the Forgejo game form and uses field:<id> for version, location when known, GPU, system and settings. The player still chooses the update track/problem/frequency, explains what happened and attaches the files. Its four forms now separate game, install/build, save and idea reports; a replacement set of forms is not needed.

The launcher has moved, and its report scope is narrower than the old proposal. LongshotLauncher PR 1 replaces the closed in-tree launcher PR. Its build-failure screen already has Copy for a bug report: version/channel, system and build settings, the failure, and the last 200 build-log lines. The earlier crash-report model, crash-consent/Send screens and inbox integration are not in this port. I am not assuming a report inbox is available, or asking for another launcher. We need to agree the shared local-file contract with the launcher authors before adding an importer or consent UI there.

The proposed game-side follow-ups remain separate changes:

A richer report bundle: a machine-readable inventory of what was included, missing, truncated or deliberately excluded, plus the human-readable report. Extend what the existing report already records, not a second collector with different answers.
A separate crash record and unclean-end marker: do not call every unclean end a crash. An optional Windows minidump would remain local and outside the ordinary shareable bundle.
A stall record with thread stacks: complement the existing GPU-hang handling and Windows hang-dump tool, and distinguish a stall from loading, pause and shader preparation.

Reuse the diagnostics already merged: PR 8's Dev FPS level exposes renderer counts and memory information; there is no need to propose that overlay again. Settings must describe the incident, not just startup: PR 7 already makes the frame cap, descriptor reuse and sampler cache changeable in play. The open A/B tooling and Linux renderer-load diagnostic are related sources of evidence, not completed report-bundle features.

The game would still send nothing and open no browser. Saves, memory dumps, keys and game files stay out of the default bundle. The new save form and guide, and merged local save import/export, do not authorize uploading saves; the form explicitly forbids it.

Anything else

Why I proposed this: the earlier study of 200 recognizable GitHub game-form issues and their 415 comments found 83 GPU fields without a readable driver version and 36 bodies without a log-like link or excerpt; 30 whole threads were read by eye. Those figures are historical motivation, not a survey of the new Forgejo forms or a measurement of how often the existing Bug report row was used.

Not measured in this migration: running the enhanced collector, Windows behavior, overhead, the signed-in Forgejo prefill round trip, or whether an input recording reproduces a particular fault. The descriptions of the current game/launcher paths above come from their source, not a new UI or game run.

Possible next small changes, after the file contract:

An opt-in, local last-minute controller recording/replay, with an explicit matching-save requirement. An arbitrary later save cannot reliably replay earlier actions.
A control-bridge report command and CLI client, with a thin tool wrapper over the session-layer proposal, rather than a second game-control implementation.
A game-free collector for startup/build failures that the current builder or Longshot Launcher can call, reusing the launcher's existing copied build report.
An agreed policy for exceptional private evidence requests before adding any save/dump export.
An optional one-line description in the menu when the text-field proposal is available on Longshot.

Questions for the maintainers:

The current rules and save form say saves do not leave the player's PC. Historical support threads sometimes asked for one. Should there be an explicit exception, and where would such evidence go? Until decided, the reporter keeps saves local.
Is an off-by-default, local-only Windows minidump wanted? Even a filtered dump may contain private or game data, so it must stay outside ordinary report attachments or any future inbox.
Should shareable log copies retain guest-register and nearby-memory diagnostic rows when present, or omit them? Should the inventory and issue form explain that choice? The proposed extension would disclose retained rows rather than silently change the current log-copy policy.
Should the new stall recorder be opt-in initially? What threshold and handling of loading, pause and shader preparation would you want before enabling it by default?
Should the next game start show a local-report notice, and how should a future launcher acknowledgement prevent repeated notices?
Can we agree one pending-record and completed-report format across Longshot and LongshotLauncher, keeping collection separate from review, consent and any later sending UI?

PPSSPP's voluntary reporting and Dolphin's opt-in analytics policy are precedents for explicit data categories and consent, not a proposal to add telemetry here.

Moved from NotRexed/Hookshot#2923.

Assisted-by: GPT-6 Astra
Co-Authored-By: GPT-6 Astra [email protected]

### The idea Help players report a problem without hunting for the right log, and give developers enough context to reproduce it. Keep collection **local**, separate from any decision to send something. **What is already on Longshot:** Gameplay → Bug report writes `report.txt`, redacted copies of the current and previous logs when available, and a picture when the renderer can supply one. It lists what was written and explains missing logs/pictures. Nothing is uploaded and the game does not open a browser. [PR 18 is merged](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/18): the saved link now names the Forgejo game form and uses `field:<id>` for version, location when known, GPU, system and settings. The player still chooses the update track/problem/frequency, explains what happened and attaches the files. Its four forms now separate game, install/build, save and idea reports; a replacement set of forms is not needed. **The launcher has moved, and its report scope is narrower than the old proposal.** [LongshotLauncher PR 1](https://git.magicbean.dev/MagicBeanDev/LongshotLauncher/pulls/1) replaces the closed in-tree launcher PR. Its build-failure screen already has **Copy for a bug report**: version/channel, system and build settings, the failure, and the last 200 build-log lines. The earlier crash-report model, crash-consent/Send screens and inbox integration are not in this port. I am not assuming a report inbox is available, or asking for another launcher. We need to agree the shared local-file contract with the launcher authors before adding an importer or consent UI there. The proposed game-side follow-ups remain separate changes: - **A richer report bundle:** a machine-readable inventory of what was included, missing, truncated or deliberately excluded, plus the human-readable report. Extend what the existing report already records, not a second collector with different answers. - **A separate crash record and unclean-end marker:** do not call every unclean end a crash. An optional Windows minidump would remain local and outside the ordinary shareable bundle. - **A stall record with thread stacks:** complement the existing GPU-hang handling and Windows hang-dump tool, and distinguish a stall from loading, pause and shader preparation. Reuse the diagnostics already merged: [PR 8's Dev FPS level](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/8) exposes renderer counts and memory information; there is no need to propose that overlay again. Settings must describe the incident, not just startup: [PR 7](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/7) already makes the frame cap, descriptor reuse and sampler cache changeable in play. The open [A/B tooling](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/36) and [Linux renderer-load diagnostic](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/34) are related sources of evidence, not completed report-bundle features. The game would still send nothing and open no browser. Saves, memory dumps, keys and game files stay out of the default bundle. The new [save form and guide](https://git.magicbean.dev/MagicBeanDev/Longshot/src/commit/d4a69456c9de5131589af1fcf9a09adba4c403d1/.forgejo/ISSUE_TEMPLATE/3-save-problem.yml), and [merged local save import/export](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/20), do not authorize uploading saves; the form explicitly forbids it. ### Anything else **Why I proposed this:** the earlier study of 200 recognizable **GitHub** game-form issues and their 415 comments found 83 GPU fields without a readable driver version and 36 bodies without a log-like link or excerpt; 30 whole threads were read by eye. Those figures are historical motivation, not a survey of the new Forgejo forms or a measurement of how often the existing Bug report row was used. **Not measured in this migration:** running the enhanced collector, Windows behavior, overhead, the signed-in Forgejo prefill round trip, or whether an input recording reproduces a particular fault. The descriptions of the current game/launcher paths above come from their source, not a new UI or game run. Possible next small changes, after the file contract: - An opt-in, local last-minute controller recording/replay, with an explicit matching-save requirement. An arbitrary later save cannot reliably replay earlier actions. - A control-bridge `report` command and CLI client, with a thin tool wrapper over the [session-layer proposal](https://github.com/NotRexed/Hookshot/issues/2904), rather than a second game-control implementation. - A game-free collector for startup/build failures that the current builder or Longshot Launcher can call, reusing the launcher's existing copied build report. - An agreed policy for exceptional private evidence requests before adding any save/dump export. - An optional one-line description in the menu when the [text-field proposal](https://github.com/NotRexed/Hookshot/issues/2594) is available on Longshot. Questions for the maintainers: 1. The current rules and save form say saves do not leave the player's PC. Historical support threads sometimes asked for one. Should there be an explicit exception, and where would such evidence go? Until decided, the reporter keeps saves local. 2. Is an off-by-default, local-only Windows minidump wanted? Even a filtered dump may contain private or game data, so it must stay outside ordinary report attachments or any future inbox. 3. Should shareable log copies retain guest-register and nearby-memory diagnostic rows when present, or omit them? Should the inventory and issue form explain that choice? The proposed extension would disclose retained rows rather than silently change the current log-copy policy. 4. Should the new stall recorder be opt-in initially? What threshold and handling of loading, pause and shader preparation would you want before enabling it by default? 5. Should the next game start show a local-report notice, and how should a future launcher acknowledgement prevent repeated notices? 6. Can we agree one pending-record and completed-report format across Longshot and LongshotLauncher, keeping collection separate from review, consent and any later sending UI? [PPSSPP's voluntary reporting](https://www.ppsspp.org/privacy/) and [Dolphin's opt-in analytics policy](https://dolphin-emu.org/docs/privacy/) are precedents for explicit data categories and consent, not a proposal to add telemetry here. --- Moved from NotRexed/Hookshot#2923. Assisted-by: GPT-6 Astra Co-Authored-By: GPT-6 Astra <[email protected]>