Hookshot/scripts · hooksho/Hookshot

Nnotquiteogfix(linux): the AppImage's parts list names the repository it is built in

Files	Last commit	Last update
linux	fix(linux): the AppImage's parts list names the repository it is built in scripts/linux/publish_parts.sh uploads the parts to the linux-parts release of $GITHUB_REPOSITORY, but appimage.sh made the list without --base, so it always named NotRexed/Hookshot's linux-parts. Here that is the same place and nothing changes. A fork's CI uploads its parts to the fork, and its list still named upstream's release, which holds none of them: a fork's Linux update could not find its own parts. The list now names the release of the repository the AppImage is built in, and NotRexed/Hookshot's when GITHUB_REPOSITORY is unset (a local build), as before. Tested: make_parts.py over a stand-in AppDir, through the same expansion appimage.sh now uses: with GITHUB_REPOSITORY=notquiteog/Hookshot every URL in hookshot-linux.txt is the fork's linux-parts release; unset, every URL is NotRexed/Hookshot's, identical to before. bash -n on the script. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	8 hours ago
changelog.py		1 day ago
crit.py	Release	3 days ago
framelog.py	Release	3 days ago
hotlist.py	PGO hot list: the game's Zstd decoder at the hot flags whatever the profile says The decode tree under f_80115c80 runs while areas load and stream, which a play profile seldom samples, so its 22 functions stayed in the cold -O1 chunks. At the hot flags a whole decode takes 16% less time and the code is no bigger. hotlist.py now lists them after the profile's own. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	1 day ago
make_setup_parts.py	ci: the Windows builder package and setup in CI, attached to a tag's release with the AppImage A new workflow, Windows builder, makes what a Windows player downloads, without game data: HookshotBuilder-Setup.exe (builder/setup/setup.c, with the llvm-mingw make_setup_parts.py names, SHA-256 checked and cached) and the Hookshot Builder package (dotnet publish -p:Version from the tag, as docs/versioning.md says), split by scripts/make_setup_parts.py. It also compiles the Windows Vulkan back end with the same llvm-mingw (RX_VK_ONLY, as the AppImage's): players build it on their PC, this checks that it still builds. A workflow artifact on every run. setup.c's build line gets -municode (its entry point is wWinMain). What CI cannot make comes from the latest stable release's hookshot-setup.txt (scripts/release_parts.py): the Python, emsdk, CPM and wgpu-native parts as they are (make_setup_parts.py --reuse), the play profile, and the third_party part's prebuilt files (a64emit.dll, lld-link.exe, SDL2.dll, SDL3.dll, zbic.dll) beside the tracked third_party. A fork with no release takes upstream's. On a tag, the parts builder-parts lacks are uploaded there, then the setup (HookshotBuilder.exe) and its list to the tag's release. The AppImage's release step moves to its own job with the same script (scripts/release_upload.sh): the first job to get there makes the release from the tag, the other adds its files, and a -rc tag is still a prerelease that is never latest. The AppImage's play profile comes through release_parts.py too, and never from the release being made.	1 day ago
ngx_sdk.py	ngx_sdk.py: a 60 s timeout on each download urlopen had none, so a connection that stalled held the build forever. The test opener checks that the timeout is passed.	21 hours ago
oot_saves.py	Saves: import from and export to every emulator that runs Ocarina of Time, not only Lichii	12 hours ago
probe.py		9 hours ago
prof.py		9 hours ago
release_parts.py	ci: the Windows builder package and setup in CI, attached to a tag's release with the AppImage A new workflow, Windows builder, makes what a Windows player downloads, without game data: HookshotBuilder-Setup.exe (builder/setup/setup.c, with the llvm-mingw make_setup_parts.py names, SHA-256 checked and cached) and the Hookshot Builder package (dotnet publish -p:Version from the tag, as docs/versioning.md says), split by scripts/make_setup_parts.py. It also compiles the Windows Vulkan back end with the same llvm-mingw (RX_VK_ONLY, as the AppImage's): players build it on their PC, this checks that it still builds. A workflow artifact on every run. setup.c's build line gets -municode (its entry point is wWinMain). What CI cannot make comes from the latest stable release's hookshot-setup.txt (scripts/release_parts.py): the Python, emsdk, CPM and wgpu-native parts as they are (make_setup_parts.py --reuse), the play profile, and the third_party part's prebuilt files (a64emit.dll, lld-link.exe, SDL2.dll, SDL3.dll, zbic.dll) beside the tracked third_party. A fork with no release takes upstream's. On a tag, the parts builder-parts lacks are uploaded there, then the setup (HookshotBuilder.exe) and its list to the tag's release. The AppImage's release step moves to its own job with the same script (scripts/release_upload.sh): the first job to get there makes the release from the tag, the other adds its files, and a -rc tag is still a prerelease that is never latest. The AppImage's play profile comes through release_parts.py too, and never from the release being made.	1 day ago
release_upload.sh	ci: the Windows builder package and setup in CI, attached to a tag's release with the AppImage A new workflow, Windows builder, makes what a Windows player downloads, without game data: HookshotBuilder-Setup.exe (builder/setup/setup.c, with the llvm-mingw make_setup_parts.py names, SHA-256 checked and cached) and the Hookshot Builder package (dotnet publish -p:Version from the tag, as docs/versioning.md says), split by scripts/make_setup_parts.py. It also compiles the Windows Vulkan back end with the same llvm-mingw (RX_VK_ONLY, as the AppImage's): players build it on their PC, this checks that it still builds. A workflow artifact on every run. setup.c's build line gets -municode (its entry point is wWinMain). What CI cannot make comes from the latest stable release's hookshot-setup.txt (scripts/release_parts.py): the Python, emsdk, CPM and wgpu-native parts as they are (make_setup_parts.py --reuse), the play profile, and the third_party part's prebuilt files (a64emit.dll, lld-link.exe, SDL2.dll, SDL3.dll, zbic.dll) beside the tracked third_party. A fork with no release takes upstream's. On a tag, the parts builder-parts lacks are uploaded there, then the setup (HookshotBuilder.exe) and its list to the tag's release. The AppImage's release step moves to its own job with the same script (scripts/release_upload.sh): the first job to get there makes the release from the tag, the other adds its files, and a -rc tag is still a prerelease that is never latest. The AppImage's play profile comes through release_parts.py too, and never from the release being made.	1 day ago
run-vk.ps1	Release	3 days ago
vkprof.py	Release	3 days ago