How do I make Hookshot portable? #2258

Closed

opened 2026-11-11 12:16:57 +00:00 by alexandrbril · 2 comments

alexandrbril commented

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

(Migrated from github.com)

The idea

I'm really grateful for your work on Hookshot. Could you help me with this? I have two PCs, one running Windows 10 and one running Windows 11. They both have limited space. But I have a fast USB 4.0 SSD drive. I'd like the game to be completely installed on this drive, along with the launcher, so that no files are stored in the \AppData\Local\HookshotBuilder\ path. Is there a way to do this? And so that Hookshot can update from this path if there's an internet connection?

Anything else

No response

### The idea I'm really grateful for your work on Hookshot. Could you help me with this? I have two PCs, one running Windows 10 and one running Windows 11. They both have limited space. But I have a fast USB 4.0 SSD drive. I'd like the game to be completely installed on this drive, along with the launcher, so that no files are stored in the \AppData\Local\HookshotBuilder\ path. Is there a way to do this? And so that Hookshot can update from this path if there's an internet connection? ### Anything else _No response_

Arkex-ai commented

2026-11-11 13:53:59 +00:00

(Migrated from github.com)

I would like to take the Windows portable Builder support, claimed in dev-work. The shipped Windows workflow builds the C setup and WPF app; the setup has an alternate-root override, but actual compiled Storage and setup fast-launch probes still select AppData. No real install, game data or process launch was used.

Proposed contract:

Explicit opt-in portable setup into a dedicated folder beside it; default installs stay unchanged.
One persistent, relocatable home for tools/versions, settings, work, SDKs, self-update/repair and game launch/update association, including direct starts without the original environment.
Invalid or read-only portable roots fail clearly, without silently installing into AppData. Existing hash/manifest checks and current-version preservation stay intact.

S3 feature, Windows reach0.57 upper bound; confidence1.0 applies to the compiled root inconsistency. No production implementation yet. Is there existing work or a storage/update constraint this mode should follow?

I would like to take the Windows portable Builder support, claimed in [dev-work](https://discord.com/channels/1568810484818378804/1569019786766188665/1570073925902270599). The shipped Windows workflow builds the C setup and WPF app; the setup has an alternate-root override, but actual compiled Storage and setup fast-launch probes still select AppData. No real install, game data or process launch was used. Proposed contract: - Explicit opt-in portable setup into a dedicated folder beside it; default installs stay unchanged. - One persistent, relocatable home for tools/versions, settings, work, SDKs, self-update/repair and game launch/update association, including direct starts without the original environment. - Invalid or read-only portable roots fail clearly, without silently installing into AppData. Existing hash/manifest checks and current-version preservation stay intact. S3 feature, Windows reach0.57 upper bound; confidence1.0 applies to the compiled root inconsistency. No production implementation yet. Is there existing work or a storage/update constraint this mode should follow?

NotRexed commented

2026-11-11 21:27:56 +00:00

(Migrated from github.com)

Thanks for the report. Reports of the same problem are now collected in #1007, which lists this one with your details and links back here, so one fix closes them together and the open list stays readable. Follow #1007 for the fix, and add new details there (or here). If this turns out to be a separate problem it will be reopened. Pull request #2367 works on this.