feat(game): the shader caches and the button prompts in the game folder's cache, the logs in its logs #321

Merged
HumanBean merged 2 commits from lndf/Longshot:feat/cache-logs-folders into main 2026-11-14 01:58:51 +00:00
Contributor

Why

The game folder fills up with loose files the game makes as it runs: several GB of shader and pipeline caches, the button prompts made from your controls, and five logs, all beside longshot.exe. It's hard to tell what the build made from what can be deleted. This puts them in two folders: cache (safe to delete) and logs.

What changed

  • New folders (host/game_layout.c, new): at the very start of both mains (host/hos_main.c, before a --prepare-shaders run too), the game makes cache/, cache/prompts/ and logs/ in the game folder. It moves what a build from before left loose: renames in the same folder, never over a file already there (the log names one that stays). The old prompt outputs, the pipeline cache's cut-short writes (.tmp, .tmp-<n>) and the program cache's old lock files are deleted.

  • Renderer paths (gpu/vk/vk_paths.h: cache_path, log_path): these go in cache/:

    • the program cache (vk_progcache.cpp);
    • the pipeline notes and the files derived from them, the compute list, the local state lists, the prepare record, the driver faults and the "prepare skipped" marker (vk_draw.cpp, vk_main.cpp);
    • the Vulkan pipeline cache.

    The frame trace goes in logs/ (vk_replay.cpp). The shipped pipeline state list and the shader seed stay beside the game.

  • Pipeline cache name: mkw_vk_pipelines*.bin (mkw-recomp's) is now longshot_vk_pipelines*.bin, with its stamp and play files (vk_draw.cpp, pcache_stamp.h, pipeline_cache_file.h). The first start renames the old files.

  • Logs: longshot_log.txt and the runs before it are in logs/ (host/hos_main.c).

  • Button prompts: the files made from the player's face and controls go in cache/prompts/ (host/prompts.c made_dir). The build's own prompts/ inputs stay.

  • Tools:

    • nx2/make_game.py seeds the pipeline list into cache/;
    • the bug report reads logs/ (vk_bug_report.cpp);
    • the pipeline share finds the list in cache/ and the log in logs/ (nx2/pipeline_share.py, pipeline_share.h);
    • scripts/dev_packs.py seeds and warms cache/;
    • scripts/validate_spirv.py usage.
  • Docs: the README, CONTRIBUTING, docs/design.md, docs/development.md, docs/common-issues.md, docs/reporting-and-contributing.md, gpu/vk/VULKAN.md, and the game-problem issue template now say where the caches and logs are.

  • Unchanged: the settings (longshot_options.ini, longshot_env.txt), language.txt, the saves and the build's own files.

Flags and settings

None.

Measurements

Not a performance change, so there's no fps or frame-time table. What matters is that a game folder from an older build keeps its caches across the move, so the first start after the update doesn't translate the shaders again. Measured on one update, file by file:

main: 514591a3 (2026-11-13)
this PR: feat/cache-logs-folders @ 39694564
Hardware: AMD Radeon RX 7800 XT (RADV NAVI32, Mesa 26.2.6), Fedora Linux 45 (kernel 7.3.3), the mesh shaders' compute path
Scene: none (the game folder's files)
Method: a copy of a game folder the launcher built from main (nightly-80-7315957c, caches and logs loose beside the game), updated with this PR's Linux AppImage (--cli --update), the folder listed before and after.
How to reproduce: copy a launcher-built game folder, run Longshot-<version>-x86_64.AppImage --cli --update <copy>, then --play <copy>, and list the folder, cache/ and logs/.

main @ 514591a3 (before the update) this PR @ 39694564 (after the update)
longshot_programs.bin 7,790,116,026 bytes, beside the game 7,790,116,026 bytes, in cache/ (kept: no shader translated again)
Vulkan pipeline cache mkw_vk_pipelines.bin 374.3 MB + 4 play files, beside the game cache/longshot_vk_pipelines.bin 375.7 MB (the play files merged in, as at any start) + its stamp
Pipeline notes, lists, prepare record beside the game in cache/
longshot_log.txt beside the game in logs/
longshot_programs.bin.lock beside the game only in cache/ (the old one deleted)
Loose caches and logs left beside the game all of them none

Testing

Tested:

  • In the game, Linux (Fedora 45, RX 7800 XT, RADV), two runs on copies of a launcher-built game folder from main (nightly-80-7315957c), updated with this PR's AppImage:
    • e87e9685 (--cli --update, then --play):

      • the caches moved into cache/, renamed to longshot_vk_pipelines*, the old log into logs/;
      • the program cache was kept whole, so nothing was translated again;
      • the game started and played, writing its play files into cache/ and the button prompts into cache/prompts/;
      • settings and the build's files stayed in place.

      The only problem found: the old longshot_programs.bin.lock stayed loose. Fixed in 39694564.

    • 39694564 (--cli --update, a fresh copy): everything as above, and no lock file left beside the game.

  • python -I -B tests/run_all.py on Linux (CachyOS): 463 passed. The three failures (test_bake_portability, test_lift_cache, test_menu_i18n) fail on a clean main too.
  • New tests/test_game_layout.py, building host/game_layout.c with the POSIX shim on placeholder files, checks:
    • the moves into cache/ and logs/, including the pipeline cache rename and its stamp and play files;
    • the deletions;
    • that the build's files, settings and saves stay;
    • that nothing is written over;
    • a second start changing nothing;
    • the game in bin/.
  • Updated checks: test_bug_report (logs in logs/), test_pipeline_share (list in cache/, log in logs/), test_mods_size_table (prompts served from cache/prompts/), test_dev_packs, test_pcache_stamp, test_pipeline_cache_file, test_pipeline_play_cache, test_display_startup_failure.
  • host/game_layout.c compiles with no warnings for Windows (mingw-w64) and on Linux. The other host files pass a syntax check, and the Vulkan back end builds (Ubuntu 24.04 container).

Screenshots

Not relevant on this PR.

Risk and rollback

A cache file this PR doesn't list stays loose beside the game, unused, and the game makes it again in cache/. That's slower once, nothing worse. A file that can't be renamed stays where it is, and the log says so. Reverting the commit puts the paths back. The old loose files would then be gone (they were moved), so the game makes its caches again once.

Reviewer notes

  • host/game_layout.c is the new part to read first, then gpu/vk/vk_paths.h.
  • state_list_path (vk_draw.cpp) splits by name: the shipped list beside the game, the ones play adds in cache/.
  • Not in this PR on purpose: moving the settings or saves out of the game folder.

Issues

None.

Checklist

For everyone

  • One topic.
  • The title is a Conventional Commit (type(scope): description).
  • Rebased on current main.
  • python -I -B tests/run_all.py run and passing (any failure that also fails on main is named above).
  • Tested in the game, or what wasn't is named under Testing.
  • Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). (the Windows test request is still to open)
  • Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. (not a performance change: the files before and after the update are above, from two runs)
  • No game files, dumps, build output or generated files.
  • third_party/ untouched (a new folder with a PROVENANCE.md instead).
  • The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled.

If applicable

  • AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
  • A check under tests/ that reads changed source updated in this PR, not weakened.
  • Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths.
  • Docs updated.
<!-- Open as work in progress (a "WIP: " title; forge.py pr create does it) and mark it ready (forge.py pr ready) once every section and every For everyone box is done. Keep this description current, and post a comment for each new commit, measurement or test run: CONTRIBUTING.md, "Commits and pull requests". --> ## Why The game folder fills up with loose files the game makes as it runs: several GB of shader and pipeline caches, the button prompts made from your controls, and five logs, all beside `longshot.exe`. It's hard to tell what the build made from what can be deleted. This puts them in two folders: `cache` (safe to delete) and `logs`. ## What changed - **New folders** (`host/game_layout.c`, new): at the very start of both `main`s (`host/hos_main.c`, before a `--prepare-shaders` run too), the game makes `cache/`, `cache/prompts/` and `logs/` in the game folder. It moves what a build from before left loose: renames in the same folder, never over a file already there (the log names one that stays). The old prompt outputs, the pipeline cache's cut-short writes (`.tmp`, `.tmp-<n>`) and the program cache's old lock files are deleted. - **Renderer paths** (`gpu/vk/vk_paths.h`: `cache_path`, `log_path`): these go in `cache/`: - the program cache (`vk_progcache.cpp`); - the pipeline notes and the files derived from them, the compute list, the local state lists, the prepare record, the driver faults and the "prepare skipped" marker (`vk_draw.cpp`, `vk_main.cpp`); - the Vulkan pipeline cache. The frame trace goes in `logs/` (`vk_replay.cpp`). The shipped pipeline state list and the shader seed stay beside the game. - **Pipeline cache name**: `mkw_vk_pipelines*.bin` (mkw-recomp's) is now `longshot_vk_pipelines*.bin`, with its stamp and play files (`vk_draw.cpp`, `pcache_stamp.h`, `pipeline_cache_file.h`). The first start renames the old files. - **Logs**: `longshot_log.txt` and the runs before it are in `logs/` (`host/hos_main.c`). - **Button prompts**: the files made from the player's face and controls go in `cache/prompts/` (`host/prompts.c` `made_dir`). The build's own `prompts/` inputs stay. - **Tools**: - `nx2/make_game.py` seeds the pipeline list into `cache/`; - the bug report reads `logs/` (`vk_bug_report.cpp`); - the pipeline share finds the list in `cache/` and the log in `logs/` (`nx2/pipeline_share.py`, `pipeline_share.h`); - `scripts/dev_packs.py` seeds and warms `cache/`; - `scripts/validate_spirv.py` usage. - **Docs**: the README, CONTRIBUTING, `docs/design.md`, `docs/development.md`, `docs/common-issues.md`, `docs/reporting-and-contributing.md`, `gpu/vk/VULKAN.md`, and the game-problem issue template now say where the caches and logs are. - **Unchanged**: the settings (`longshot_options.ini`, `longshot_env.txt`), `language.txt`, the saves and the build's own files. ## Flags and settings None. ## Measurements Not a performance change, so there's no fps or frame-time table. What matters is that a game folder from an older build keeps its caches across the move, so the first start after the update doesn't translate the shaders again. Measured on one update, file by file: main: 514591a3 (2026-11-13) this PR: feat/cache-logs-folders @ 39694564 Hardware: AMD Radeon RX 7800 XT (RADV NAVI32, Mesa 26.2.6), Fedora Linux 45 (kernel 7.3.3), the mesh shaders' compute path Scene: none (the game folder's files) Method: a copy of a game folder the launcher built from `main` (`nightly-80-7315957c`, caches and logs loose beside the game), updated with this PR's Linux AppImage (`--cli --update`), the folder listed before and after. How to reproduce: copy a launcher-built game folder, run `Longshot-<version>-x86_64.AppImage --cli --update <copy>`, then `--play <copy>`, and list the folder, `cache/` and `logs/`. | | main @ 514591a3 (before the update) | this PR @ 39694564 (after the update) | |---|---|---| | `longshot_programs.bin` | 7,790,116,026 bytes, beside the game | 7,790,116,026 bytes, in `cache/` (kept: no shader translated again) | | Vulkan pipeline cache | `mkw_vk_pipelines.bin` 374.3 MB + 4 play files, beside the game | `cache/longshot_vk_pipelines.bin` 375.7 MB (the play files merged in, as at any start) + its stamp | | Pipeline notes, lists, prepare record | beside the game | in `cache/` | | `longshot_log.txt` | beside the game | in `logs/` | | `longshot_programs.bin.lock` | beside the game | only in `cache/` (the old one deleted) | | Loose caches and logs left beside the game | all of them | none | ## Testing **Tested:** - In the game, Linux (Fedora 45, RX 7800 XT, RADV), two runs on copies of a launcher-built game folder from `main` (`nightly-80-7315957c`), updated with this PR's AppImage: - **e87e9685** (`--cli --update`, then `--play`): - the caches moved into `cache/`, renamed to `longshot_vk_pipelines*`, the old log into `logs/`; - the program cache was kept whole, so nothing was translated again; - the game started and played, writing its play files into `cache/` and the button prompts into `cache/prompts/`; - settings and the build's files stayed in place. The only problem found: the old `longshot_programs.bin.lock` stayed loose. Fixed in 39694564. - **39694564** (`--cli --update`, a fresh copy): everything as above, and no lock file left beside the game. - `python -I -B tests/run_all.py` on Linux (CachyOS): 463 passed. The three failures (`test_bake_portability`, `test_lift_cache`, `test_menu_i18n`) fail on a clean `main` too. - New `tests/test_game_layout.py`, building `host/game_layout.c` with the POSIX shim on placeholder files, checks: - the moves into `cache/` and `logs/`, including the pipeline cache rename and its stamp and play files; - the deletions; - that the build's files, settings and saves stay; - that nothing is written over; - a second start changing nothing; - the game in `bin/`. - Updated checks: `test_bug_report` (logs in `logs/`), `test_pipeline_share` (list in `cache/`, log in `logs/`), `test_mods_size_table` (prompts served from `cache/prompts/`), `test_dev_packs`, `test_pcache_stamp`, `test_pipeline_cache_file`, `test_pipeline_play_cache`, `test_display_startup_failure`. - `host/game_layout.c` compiles with no warnings for Windows (mingw-w64) and on Linux. The other host files pass a syntax check, and the Vulkan back end builds (Ubuntu 24.04 container). ## Screenshots Not relevant on this PR. ## Risk and rollback A cache file this PR doesn't list stays loose beside the game, unused, and the game makes it again in `cache/`. That's slower once, nothing worse. A file that can't be renamed stays where it is, and the log says so. Reverting the commit puts the paths back. The old loose files would then be gone (they were moved), so the game makes its caches again once. ## Reviewer notes - `host/game_layout.c` is the new part to read first, then `gpu/vk/vk_paths.h`. - `state_list_path` (`vk_draw.cpp`) splits by name: the shipped list beside the game, the ones play adds in `cache/`. - Not in this PR on purpose: moving the settings or saves out of the game folder. ## Issues None. ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [x] Rebased on current `main`. - [x] `python -I -B tests/run_all.py` run and passing (any failure that also fails on `main` is named above). - [x] Tested in the game, or what wasn't is named under Testing. - [x] Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). (the Windows test request is still to open) - [ ] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. (not a performance change: the files before and after the update are above, from two runs) - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. ### If applicable - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. - [x] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. - [x] Docs updated.
feat(game): the shader caches and the button prompts in the game folder's cache, the logs in its logs
Some checks failed
PR description / Description follows the template (pull_request_target) Successful in 4s
CI / Conventional Commit title (pull_request) Has been cancelled
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been cancelled
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been cancelled
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been cancelled
CI / Workflow lint (actionlint) (pull_request) Has been cancelled
Third-party parts / As their notes say (pull_request) Has been cancelled
Third-party parts / The same as upstream (pull_request) Has been cancelled
e87e968568
What the game makes as it runs no longer lies loose beside it: the shader
and pipeline caches (several GB, made for this build and this GPU) and
the button prompts made from the player's controls go in the game
folder's cache/, which can be deleted, and the logs in its logs/. The
Vulkan pipeline cache takes Longshot's name, longshot_vk_pipelines*.bin
(mkw-recomp's mkw_vk_pipelines* before).

host/game_layout.c makes both folders at the very start of both mains,
before a --prepare-shaders run too, and moves once what a build from
before left loose: renames in the same folder, never over a file there
(the log names one that stays), the pipeline cache renamed with its
stamp and play files, its cut-short writes and the old prompts deleted.
The build's files, the settings and the saves stay where they are.

The renderer finds them by gpu/vk/vk_paths.h's cache_path and log_path;
the shipped pipeline state list and the shader seed stay beside the
game. make_game.py seeds the pipeline list into cache/, the bug report
and the pipeline share read logs/ and cache/, dev_packs follows, and the
docs say where the caches and logs are.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
fix(game): the program cache's old lock file beside the game is deleted
Some checks failed
PR description / Description follows the template (pull_request_target) Failing after 3s
Website / Website on Cloudflare (pull_request_target) Has been skipped
CI / Conventional Commit title (pull_request) Has been cancelled
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been cancelled
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been cancelled
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been cancelled
CI / Workflow lint (actionlint) (pull_request) Has been cancelled
Third-party parts / As their notes say (pull_request) Has been cancelled
Third-party parts / The same as upstream (pull_request) Has been cancelled
396945644e
The game locks cache/longshot_programs.bin.lock now; the one a build from
before made beside the game stayed loose, held by nothing. A run on a
game folder the launcher built (nightly-80) left it there.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Author
Contributor

New commit 39694564: the program cache's old lock file (longshot_programs.bin.lock) beside the game is now deleted, since the game locks the one in cache/. A test run left it loose. tests/test_game_layout.py covers it, and fails without the fix.

Tested in the game on Linux (Fedora 45, RX 7800 XT, RADV). I updated copies of a launcher-built game folder from main (nightly-80) with this PR's AppImage, once at e87e9685 and once at 39694564:

  • every cache moved into cache/, with mkw_vk_pipelines* renamed to longshot_vk_pipelines*;
  • the old log moved into logs/;
  • the program cache was kept whole (7,790,116,026 bytes before and after), so nothing was translated again;
  • the game ran with its play files and button prompts in cache/;
  • nothing was left loose beside the game.

The description has the before/after table. Still WIP: the Windows test request is next.

New commit 39694564: the program cache's old lock file (`longshot_programs.bin.lock`) beside the game is now deleted, since the game locks the one in `cache/`. A test run left it loose. `tests/test_game_layout.py` covers it, and fails without the fix. Tested in the game on Linux (Fedora 45, RX 7800 XT, RADV). I updated copies of a launcher-built game folder from `main` (nightly-80) with this PR's AppImage, once at e87e9685 and once at 39694564: - every cache moved into `cache/`, with `mkw_vk_pipelines*` renamed to `longshot_vk_pipelines*`; - the old log moved into `logs/`; - the program cache was kept whole (7,790,116,026 bytes before and after), so nothing was translated again; - the game ran with its play files and button prompts in `cache/`; - nothing was left loose beside the game. The description has the before/after table. Still WIP: the Windows test request is next.
lndf changed title from WIP: feat(game): the shader caches and the button prompts in the game folder's cache, the logs in its logs to feat(game): the shader caches and the button prompts in the game folder's cache, the logs in its logs 2026-11-13 23:54:33 +00:00
HumanBean added this to the v3.0.0 milestone 2026-11-14 01:20:14 +00:00
HumanBean left a comment

Code review of 39694564 (code only; I ran nothing). The move itself reads well: the migration is careful (a rename in the same folder, never over a file that's already there, and a second start does nothing). The mkw_vk_pipelines* to longshot_vk_pipelines* rename keeps the stamp and play files together. The launcher's --update goes through --prepare-shaders, so the move happens before the first play. A few things need fixing before it merges.

Must fix

  1. The PR is out of WIP, but the description check fails (run 2781). pr status 321 reports that Testing has no Not tested: or Needs other testers: part and that Measured is unticked. That makes the ticked box "Testing filled in: what was tested, what wasn't, and what needs other testers" false. Your last comment says it's still WIP until the Windows test request, but no test request for 321 is open (test_requests.py list --all). Either run pr wip 321 or fill in those parts. For Measured, the before/after file table is the right measurement for a change like this: tick the box, saying so.
  2. No Windows run yet. Most players are on Windows, and the paths that matter are Windows-only: MoveFileExA and FindFirstFileA on NTFS (the *.tmp-* pattern), the log rotation into logs\ in game_main, and narrow_paths_ok running before the layout. tests/test_game_layout.py is skipped on Windows. Please get a run that updates a launcher-built Windows folder with --update and then plays it, ideally through a test request. Related box: Host code builds on both Windows (llvm-mingw) and Linux. The description says only game_layout.c was compiled for Windows (mingw-w64), and the other host files got a syntax check. A full llvm-mingw build would settle it. The CI jobs for this head are still Blocked by required conditions (run 2771), so CI hasn't checked them either.
  3. Some docs still point at the old place, and their commands now fail. assets/pipeline_states/README.md lines 70 and 78 (<game folder>/longshot_pipeline_states.bin) and docs/development.md lines 532 and 537 ("writes longshot_pipeline_states.bin beside the executable", and the same add command). The file is now in cache/. These lines aren't in the diff, so I can't comment on them inline.

Outside this repo (please coordinate)

  • Open launcher PR MagicBeanDev/LongshotLauncher#42 (Send report) looks for crashes in Path.Combine(buildFolder, "longshot_log.txt") and .1.txt (CrashCheck.Find). With this PR the logs are in logs/, so it would never find a crash. Whichever lands second has to look in logs/ first, then the folder. The launcher's main doesn't read the game's logs or caches today, so nothing that's merged breaks.
  • longshot_startup.log is moved into logs/, and docs/common-issues.md now sends players there. According to README line 195, the launcher's Play writes that file, but I can't find a writer on the launcher's main or here. If something still writes it beside the game, the next start finds logs/longshot_startup.log already there and leaves the new one loose. Then the newest file is beside the game while the docs point at the older one in logs/. What writes it now?

Suggestions (non-blocking)

  • cache/ is described to players as "can be deleted at any time", but it also holds state that isn't a cache (inline).
  • A loose file that couldn't be moved stays loose for good (inline).
  • Stale comments still say "beside the game/executable": vk_progcache.cpp lines 1 and 76, vk_draw.cpp lines 1078, 1485 and 1523, driver_faults.h line 16, vk_main.cpp lines 995 and 1010.
  • A developer who switches one game folder between a branch from before this PR and one after it re-translates every time, and ends up with both copies (several GB). Worth one line in docs/development.md.

v3.0.0: I'd move this to v3.1.0. The PR is in the v3.0.0 milestone (due 2026-11-14), but rc.3 is already out, and docs/versioning.md says the stable is the same commit as a release candidate that proved good. So taking this in would need an rc.4 and a Windows run in under a day, for a change whose failure mode (shaders prepared again, minutes to hours) would hit every player on the first stable. Nothing in v3.0.0 depends on it, and the migration code works the same from any older layout later.

Code review of 39694564 (code only; I ran nothing). The move itself reads well: the migration is careful (a rename in the same folder, never over a file that's already there, and a second start does nothing). The `mkw_vk_pipelines*` to `longshot_vk_pipelines*` rename keeps the stamp and play files together. The launcher's `--update` goes through `--prepare-shaders`, so the move happens before the first play. A few things need fixing before it merges. **Must fix** 1. **The PR is out of WIP, but the description check fails** ([run 2781](https://git.magicbean.dev/MagicBeanDev/Longshot/actions/runs/2781/jobs/0)). `pr status 321` reports that *Testing* has no *Not tested:* or *Needs other testers:* part and that *Measured* is unticked. That makes the ticked box "Testing filled in: what was tested, what wasn't, and what needs other testers" false. Your last comment says it's still WIP until the Windows test request, but no test request for 321 is open (`test_requests.py list --all`). Either run `pr wip 321` or fill in those parts. For *Measured*, the before/after file table is the right measurement for a change like this: tick the box, saying so. 2. **No Windows run yet.** Most players are on Windows, and the paths that matter are Windows-only: `MoveFileExA` and `FindFirstFileA` on NTFS (the `*.tmp-*` pattern), the log rotation into `logs\` in `game_main`, and `narrow_paths_ok` running before the layout. `tests/test_game_layout.py` is skipped on Windows. Please get a run that updates a launcher-built Windows folder with `--update` and then plays it, ideally through a test request. Related box: *Host code builds on both Windows (llvm-mingw) and Linux*. The description says only `game_layout.c` was compiled for Windows (mingw-w64), and the other host files got a syntax check. A full llvm-mingw build would settle it. The CI jobs for this head are still *Blocked by required conditions* (run 2771), so CI hasn't checked them either. 3. **Some docs still point at the old place, and their commands now fail.** `assets/pipeline_states/README.md` lines 70 and 78 (`<game folder>/longshot_pipeline_states.bin`) and `docs/development.md` lines 532 and 537 ("writes `longshot_pipeline_states.bin` beside the executable", and the same `add` command). The file is now in `cache/`. These lines aren't in the diff, so I can't comment on them inline. **Outside this repo (please coordinate)** - Open launcher PR https://git.magicbean.dev/MagicBeanDev/LongshotLauncher/pulls/42 (Send report) looks for crashes in `Path.Combine(buildFolder, "longshot_log.txt")` and `.1.txt` (`CrashCheck.Find`). With this PR the logs are in `logs/`, so it would never find a crash. Whichever lands second has to look in `logs/` first, then the folder. The launcher's `main` doesn't read the game's logs or caches today, so nothing that's merged breaks. - `longshot_startup.log` is moved into `logs/`, and `docs/common-issues.md` now sends players there. According to README line 195, the launcher's Play writes that file, but I can't find a writer on the launcher's `main` or here. If something still writes it beside the game, the next start finds `logs/longshot_startup.log` already there and leaves the new one loose. Then the newest file is beside the game while the docs point at the older one in `logs/`. What writes it now? **Suggestions (non-blocking)** - `cache/` is described to players as "can be deleted at any time", but it also holds state that isn't a cache (inline). - A loose file that couldn't be moved stays loose for good (inline). - Stale comments still say "beside the game/executable": `vk_progcache.cpp` lines 1 and 76, `vk_draw.cpp` lines 1078, 1485 and 1523, `driver_faults.h` line 16, `vk_main.cpp` lines 995 and 1010. - A developer who switches one game folder between a branch from before this PR and one after it re-translates every time, and ends up with both copies (several GB). Worth one line in `docs/development.md`. **v3.0.0:** I'd move this to v3.1.0. The PR is in the v3.0.0 milestone (due 2026-11-14), but rc.3 is already out, and `docs/versioning.md` says the stable is the same commit as a release candidate that proved good. So taking this in would need an rc.4 and a Windows run in under a day, for a change whose failure mode (shaders prepared again, minutes to hours) would hit every player on the first stable. Nothing in v3.0.0 depends on it, and the migration code works the same from any older layout later.
@ -0,0 +35,4 @@
"longshot_pipelines.bin.predicted_keys", "longshot_pipelines.bin.built", "longshot_pipelines.bin.running",
"longshot_pipelines.bin.predicting", "longshot_pipelines.bin.built.warming", "longshot_computes.bin",
"longshot_compute_variants.bin", "longshot_pipeline_states.bin", "longshot_pipeline_states_v1.bin", "longshot_prepared.bin",
"longshot_prepared.bin.warming", "longshot_prepare_skipped", "longshot_driver_faults.txt", "longshot_load_start.txt",
Owner

longshot_driver_faults.txt, longshot_prepare_skipped and longshot_load_start.txt aren't caches. They're decisions the game made on this PC: the quarantine of programs the driver faulted on (driver_faults.h: on AMD's Windows driver a re-asked faulted program froze the game, issue 996), the player's skipped preparation, and the load-mode fallback. README line 252 now tells players cache can be deleted at any time. A player who clears it to fix something re-meets the driver fault on the next run. I'd keep these three beside the settings (or in a folder that isn't called cache), or make the README say which files in cache/ are worth keeping. longshot_pipeline_states.bin is also the list players send in; deleting it is fine, but it's not really a cache either.

`longshot_driver_faults.txt`, `longshot_prepare_skipped` and `longshot_load_start.txt` aren't caches. They're decisions the game made on this PC: the quarantine of programs the driver faulted on (driver_faults.h: on AMD's Windows driver a re-asked faulted program froze the game, issue 996), the player's skipped preparation, and the load-mode fallback. README line 252 now tells players `cache` can be deleted at any time. A player who clears it to fix something re-meets the driver fault on the next run. I'd keep these three beside the settings (or in a folder that isn't called cache), or make the README say which files in `cache/` are worth keeping. `longshot_pipeline_states.bin` is also the list players send in; deleting it is fine, but it's not really a cache either.
@ -0,0 +67,4 @@
moved++;
return;
}
if (!kept++) snprintf(kept_first, sizeof kept_first, "%s", from);
Owner

When the move fails (on Windows a file held open without FILE_SHARE_DELETE: an antivirus scan of a 7.8 GB file, an Explorer preview, a game still closing), this start writes a new cache in cache/. From then on the loose one can never move, because the target exists. The player is left with a dead 7.8 GB longshot_programs.bin beside the game, and the only sign is one log line at each start. Could a later start delete a loose cache file whose cache/ copy exists (caches only, never logs), or at least name the bytes left in the log line? Non-blocking.

When the move fails (on Windows a file held open without FILE_SHARE_DELETE: an antivirus scan of a 7.8 GB file, an Explorer preview, a game still closing), this start writes a new cache in `cache/`. From then on the loose one can never move, because the target exists. The player is left with a dead 7.8 GB `longshot_programs.bin` beside the game, and the only sign is one log line at each start. Could a later start delete a loose cache file whose `cache/` copy exists (caches only, never logs), or at least name the bytes left in the log line? Non-blocking.
Owner

Rebased onto current main (0815d9843c). Main had moved 30 commits, among them #248. The two commits are now 20b7bd5b and b797f590, still yours.

Only docs/development.md conflicted. main added the RX_VK_PCACHE_FETCH_LOCK row right after RX_VK_PCACHE_STAMP, the row where this PR renames mkw_vk_pipelines to longshot_vk_pipelines. I kept main's new row and applied the rename in place. Each commit's added and removed lines are the same as before. No tests or builds were run on this PC.

Our review's points still stand: #321 (comment)

Rebased onto current `main` (0815d9843c93). Main had moved 30 commits, among them https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/248. The two commits are now 20b7bd5b and b797f590, still yours. Only `docs/development.md` conflicted. `main` added the `RX_VK_PCACHE_FETCH_LOCK` row right after `RX_VK_PCACHE_STAMP`, the row where this PR renames `mkw_vk_pipelines` to `longshot_vk_pipelines`. I kept main's new row and applied the rename in place. Each commit's added and removed lines are the same as before. No tests or builds were run on this PC. Our review's points still stand: https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/321#issuecomment-15787
HumanBean force-pushed feat/cache-logs-folders from 396945644e
Some checks failed
PR description / Description follows the template (pull_request_target) Failing after 3s
Website / Website on Cloudflare (pull_request_target) Has been skipped
CI / Conventional Commit title (pull_request) Has been cancelled
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been cancelled
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been cancelled
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been cancelled
CI / Workflow lint (actionlint) (pull_request) Has been cancelled
Third-party parts / As their notes say (pull_request) Has been cancelled
Third-party parts / The same as upstream (pull_request) Has been cancelled
to b797f590f3
Some checks failed
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been skipped
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been skipped
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been skipped
Third-party parts / The same as upstream (pull_request) Has been skipped
Website / Website on Cloudflare (pull_request) Has been skipped
PR description / Description follows the template (pull_request_target) Failing after 5s
CI / Conventional Commit title (pull_request) Successful in 6s
CI / Workflow lint (actionlint) (pull_request) Successful in 9s
Third-party parts / As their notes say (pull_request) Successful in 11s
Website / Website on Cloudflare (pull_request_target) Has been skipped
2026-11-14 01:58:06 +00:00
Compare
HumanBean deleted branch feat/cache-logs-folders 2026-11-14 01:58:51 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
MagicBeanDev/Longshot!321
No description provided.