Pagonia Land Manager¶
This folder hosts the Pagonia Land Manager.
The manager is a small C#/.NET command line tool that owns the stateful side of the modding workflow: install / enable / profile / plan / deploy / rollback against a real Pioneers of Pagonia game install. It wraps the Pagonia Land Patcher and Pagonia Land Paker core libraries — the engines that do the actual XML patching and .pak writing — and adds the layer they deliberately don't: mod store, profiles, deploy backup/rollback.
Intended Role¶
mod archives + collections --> install / enable / profile
profile + game install --> plan -> deploy -> rollback
A future GUI (Pagonia Land Manager.exe, WINDOWS subsystem) will sit on top of the same PagoniaLand.Manager.Core library. CLI and GUI ship as two binaries from one solution because Windows fixes a binary's subsystem at compile time — a single-exe-for-both setup forces awkward output races and broken piping. The split mirrors the established model (git / git-gui, code / Code.exe, docker CLI / Docker Desktop).
Interactive Mode (default)¶
Run pagonia-manager with no arguments in a terminal and it launches an interactive shell — coloured menus, prompts, progress spinners, no need to remember command names or flag spellings. Built on Spectre.Console, AOT-compiled so it ships in the same single-file binary.
First run: if the resolved store folder hasn't been initialised yet, the shell says so up front — naming the location and where it was resolved from (--store flag / PAGONIA_MANAGER_STORE env / platform default) — and offers to initialise it on the spot, so a first-time user isn't left bouncing off "store not initialised" messages. Decline and you can still initialise later via Advanced → Store → init.
The main menu is grouped into three task-oriented clusters plus two utility entries at the bottom. Discovery is by what you want to do, not by which CLI verb to type:
Mods¶
| Pick | What it does |
|---|---|
| Install a mod | Asks for a folder, .zip, GitHub repo, mod.io coordinate, or direct-download URL; validates through the patcher pipeline; advises on overlay conflict risks (for GameDatabase-overlay mods); installs; offers to enable it in the active profile in one step. Advanced → Mods → advise re-runs the advisor on any installed mod, with optional base-aware checks against a game root |
| Browse community catalogs | Federated aggregate view across every subscribed catalog (vouched by N catalogs trust signal). Select a repo to list the mods + collections it publishes, then install a mod (with the enable-in-profile prompt) or install-and-activate a collection — straight from the shell. Walks the user through adding a subscription if none exist yet |
| Update mods + collections | Runs a read-only check across your gh:-sourced mods and collections, lists what's behind, and for whatever you pick shows the delta (from→to, gameDatabaseVersion, whether your tweaks carry forward) before a confirm — then applies the transparent, reversible update (the old version is kept for rollback). The opt-in front door over the scriptable update / collection update verbs |
| Manage active profile | Sub-menu: enable / disable a mod, reorder load order, configure this mod (tweaks), copy this profile, export this profile as a collection, show profile details, create a new profile (multi-mod wizard), switch active profile |
| Configure this mod (tweaks) | Under Manage active profile (shown only when an enabled mod exposes tweaks): pick a mod, then edit each adjustable value with a type-matched prompt — yes/no for a boolean, a list for an enum, a validated number entry for a slider — or reset one / all to defaults |
| Copy / export this profile | Under Manage active profile: copy duplicates the profile under a new name (snapshot before a risky change, or branch to experiment, optionally activating the copy); export writes it out as a shareable *.collection.yaml (shown only when the profile has at least one enabled mod — a collection needs ≥1 mod). The same two verbs live under Advanced → Profiles for any profile, not just the active one |
Game¶
| Pick | What it does |
|---|---|
| Plan + deploy to game | Suggests the persisted default game path (or the Windows Steam default if no default is set yet), shows the detected game version, runs plan, renders the result as a tree, prompts for dry-run / deploy / abort, handles conflicts. Prompts to overwrite if a live file changed out-of-band since the last deploy. Live game-install path (folder with pak/*.pak) auto-extracts canonical paks into a cache and repacks the affected ones; extracted-layout path (core/gdb/*.gd.xml) writes loose XMLs |
| Roll back last deploy | Shows what would be reverted, default-No confirm, then restores byte-identically (whole pak files for live-install deploys, loose XMLs for extracted-layout). Verifies backup SHA-256 before overwriting, and prompts to force if a live file drifted since the deploy |
| View deploy history | Latest deploy summary + full per-game-install history table (timestamp, profile, mods, files) |
Status & Settings¶
| Pick | What it does |
|---|---|
| Status dashboard | Read-only overview: store + active profile + installed mods + last deploy. Surfaces warning panels when at least one orphaned deploy exists (game install moved or updated) or when <store>/deploys/ exceeds ~15 GB |
| Settings | Sub-menu: default game folder (inspect / set / clear the persisted state.yaml.defaultGameRoot) + catalog subscriptions (add / remove / refresh all) + Game expansions (DLC ownership) — a Present/Owned/Effective screen with a tri-state Owned toggle for decorations1/dlc1 (also mirrored under Advanced → Game Ops → expansions) |
| Plan + deploy ownership nudge | On the first deploy against an install with a DLC pak present but ownership undeclared, a one-time prompt asks whether you own it (owned / not-owned / ask-me-later). "Ask me later" leaves it unknown and is recorded so you aren't re-asked every deploy. The plan/deploy flow renders the ownership diagnostics inline, at parity with the scripted gate |
| Clean up old deploy backups | Lists orphaned deploys + trims per-fingerprint deploy directories to the N most recent. Dry-run first by default, with confirm-and-apply prompt after. The current state.yaml.lastDeploy entry is always protected from removal |
Utility¶
| Pick | What it does |
|---|---|
| Advanced | Full CLI surface organised by category — every command from the CLI contract, prompt-driven. Use this when you know what you want to do and the main-menu wizards don't cover it |
| Quit | Bye. |
The ordering is intentional: pick-by-task first (three clusters at the top), fall back to Advanced for the raw verb catalog. New modders should never need to leave the top three clusters for the common path.
The shell is the default when invoked with no args and stdin is a TTY. With stdin redirected (CI pipes, `