87 lines
3.4 KiB
Markdown
87 lines
3.4 KiB
Markdown
# 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>`. The workflow uses the Gitea action token by default. If the
|
|
server does not grant that token package-write access, configure repository
|
|
secrets named `REGISTRY_USERNAME` and `REGISTRY_TOKEN`.
|
|
|
|
### 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.
|