# Progression: Loader

This project pulls from the three steam workshop collections of Progression, then it searches through your installed mods, in the workshop folder and matches the steam id to a package id, and Formal name, then it takes those names, package ids and steam ids and creates the modloader modslist, thats a mouth full, and save it to your modslist folder so all you have to do is launch the game. The merge button will take your currently ENABLED mods and merge them with the latest progression pack to give you a new modslist called progresisonhomebrew which you can sort and load.


DLC detection is based on NotOwned_x.png if the user doesnt the same package NAME as the not owned png it doesnt proceed. 
.envs populate pre loaded data, only change if their is an update to collection url
Doesnt sort so the current guidence to autosort from base game mod manager will still apply.
Art by ferny

to bump the version

python version_manager.py 1.0.1 


build 

pyinstaller --clean --onefile --windowed --icon=art/Progression.ico --add-data "art;art" --name ProgressionLoader steam_workshop_gui.py

## Web dashboard and backend

The repository now includes a FastAPI backend and responsive dashboard in
`progression_backend`. It resolves the three Workshop collections through
Steam's `GetCollectionDetails` API, downloads missing or updated RimWorld mods
with anonymous SteamCMD, reads `About/About.xml`, and generates the same RimWorld
`.rml` format as the desktop loader.

The backend refreshes once per hour and records each run in SQLite, including:

- complete refresh time and status
- requested, successful, and failed downloads
- Workshop cache size on disk
- size added during the run and average throughput
- per-mod size, validation status, timestamps, and SteamCMD batch diagnostics

### Run locally

Install SteamCMD, copy `.env.example` to `.env`, and set `STEAMCMD_PATH` plus
`STEAMCMD_WORKSHOP_DIR` to the matching SteamCMD Workshop directory. Then run:

```powershell
python -m pip install -r requirements-web.txt
python -m progression_backend
```

Open `http://127.0.0.1:8000`. API documentation is available at
`http://127.0.0.1:8000/api/docs`.

Use one application process/worker because that process owns the hourly
scheduler. For an externally scheduled deployment, set `REFRESH_ON_STARTUP=false`
and call `POST /api/refresh` once per hour.

### Run with Docker

Docker provisions the SteamCMD binary and persists both analytics and downloaded
Workshop content:

```powershell
docker compose up --build
```

The SteamCMD Linux runtime requires an amd64 host or amd64 emulation. Set
`PROGRESSION_ADMIN_TOKEN` before exposing the manual refresh endpoint publicly.

### Published container

Gitea Actions builds and publishes the `linux/amd64` image on every push to
`main` and every `v*` version tag:

```text
git.hudsonriggs.systems/hriggs/progressionmods:latest
```

Published tags include `latest`, the branch or semantic version, and
`sha-<commit>`. Before running the workflow, configure `REGISTRY_TOKEN` as a
repository Actions secret containing a Gitea personal access token with
`write:package` permission.

The registry username defaults to `HRiggs`. An optional `REGISTRY_USERNAME`
secret can override it.

Gitea's built-in Actions token cannot currently publish OCI packages, so the
registry token is required even though the workflow requests `packages: write`.

### Mod-list endpoints

- `GET /api/modlists/vanilla?dlc=royalty&dlc=biotech`
- `POST /api/modlists/homebrew` with a `mods_config` XML upload
- `GET /api/status`, `/api/analytics`, and `/api/mods`

Generation fails closed when any current collection item is unavailable. An
operator can explicitly request `allow_partial=true` for diagnostics.