Document native Windows setup and update compatibility tracker.
Add PowerShell examples, profile usage notes, and record completed Windows compatibility work in the tracker. Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
@@ -31,7 +31,8 @@ If `XDG_STATE_HOME` is not set, the state directory defaults to:
|
||||
|
||||
Override the instance root with `--instances-root`,
|
||||
`PLUGIN_HELPER_INSTANCES_ROOT`, or `plugin-helper.local.toml`. To search
|
||||
multiple explicit roots, separate them with `:`.
|
||||
multiple explicit roots, separate them with `:` on Linux/macOS or `;` on
|
||||
Windows.
|
||||
|
||||
Override the state directory with `--state-dir`, `PLUGIN_HELPER_STATE_DIR`, or
|
||||
`plugin-helper.local.toml`.
|
||||
@@ -73,6 +74,45 @@ state_dir = "~/Windows/Users/pleb/ops/plugin-helper/.state"
|
||||
CLI flags override environment variables, environment variables override local
|
||||
config, and local config overrides built-in defaults.
|
||||
|
||||
## Native Windows
|
||||
|
||||
For a separate checkout on a Windows partition, copy the Windows example config
|
||||
and adjust paths if needed:
|
||||
|
||||
```powershell
|
||||
Copy-Item plugin-helper.windows.toml.example plugin-helper.windows.toml
|
||||
```
|
||||
|
||||
`plugin-helper.windows.toml` is ignored by git. It uses profile entries:
|
||||
|
||||
```toml
|
||||
[[profiles]]
|
||||
id = "windows"
|
||||
label = "Native Windows BSManager"
|
||||
instances_root = "~/BSManager/BSInstances"
|
||||
state_dir = ".state"
|
||||
```
|
||||
|
||||
Run commands with `--config` and `--profile` so native Windows state stays in
|
||||
that checkout's `.state/` directory. If `plugin-helper.windows.toml` has only
|
||||
one `[[profiles]]` entry, that profile is selected automatically when
|
||||
`--profile` is omitted:
|
||||
|
||||
```powershell
|
||||
py -m venv .venv
|
||||
.\.venv\Scripts\Activate.ps1
|
||||
py -m pip install -e .
|
||||
py -m plugin_helper menu
|
||||
py -m plugin_helper --config plugin-helper.windows.toml --profile windows installed --instance 1.44.1
|
||||
```
|
||||
|
||||
On native Windows, `bootstrap` runs `IPA.exe -n` directly instead of through
|
||||
Proton. `bootstrap-check` accepts a recorded native bootstrap without requiring
|
||||
`Logs/_latest.log` when `IPA.exe -n` completed successfully.
|
||||
|
||||
When no config file is present on Windows, defaults are
|
||||
`~/BSManager/BSInstances` and `%LOCALAPPDATA%/plugin-helper`.
|
||||
|
||||
## Commands
|
||||
|
||||
For normal use, run the Textual menu from the repo root:
|
||||
@@ -170,9 +210,10 @@ custom content or non-obvious user choices rather than pure cache data.
|
||||
arguments such as `--no-yeet fpfc` can make the game fail command-line
|
||||
parsing after BSIPA and plugins have already loaded.
|
||||
- BSIPA is managed as a first-class bootstrap phase. The `bootstrap` command
|
||||
applies the locked `bsipa` root archive, runs `IPA.exe -n` through Proton, and
|
||||
records every bootstrap-relevant file under root `IPA.exe*`, `winhttp.dll`,
|
||||
`Libs/`, and `IPA/`, including backups created during patching.
|
||||
applies the locked `bsipa` root archive, runs `IPA.exe -n` (natively on
|
||||
Windows or through Proton on Linux), and records every bootstrap-relevant
|
||||
file under root `IPA.exe*`, `winhttp.dll`, `Libs/`, and `IPA/`, including
|
||||
backups created during patching.
|
||||
- If an instance lockfile includes `bsipa`, ordinary plugin plans require a
|
||||
recorded bootstrap state plus a `Logs/_latest.log` that shows BSIPA startup.
|
||||
Use `bootstrap-check` before planning a batch when you want a quick gate.
|
||||
|
||||
Reference in New Issue
Block a user