josh/electric-cherry
1
0
Fork 0
Code Issues 18 Pull Requests Actions Packages Projects Releases Wiki Activity

Support resumable game folder uploads and remove DLC declarations

Browse Source
This commit is contained in:
josh
2026-10-04 09:51:45 -04:00
parent 95cf7dd36f
commit 840f02b53e
22 changed files with 1121 additions and 102 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+12 -7
View File
@@ -29,11 +29,13 @@ The default Compose data mount preserves the previous
`EC_DATA_DIR` to your preferred persistent directory. Back up that directory,
including SQLite metadata and published game-file storage.
1. **Hosts → Add Host**: configure a Debian 12/13 amd64 machine and run its
1. **Library → Game Files**: select T5 or T6 and upload the complete local game
folder, including its DLC files. Name the library and version, then publish it.
Uploads work before any host is enrolled.
2. **Hosts → Add Host**: configure a Debian 12/13 amd64 machine and run its
generated enrollment command.
2. Prepare a Plutainer runtime from the host page.
3. **Library → Game Files**: import existing T5/T6 files once, then cache a
published version on the destination host.
3. Prepare a Plutainer runtime from the host page and download the published
game-file version to that host from **Game Files**.
4. Add the exact Plutonium server keys in **Keys**, or supply missing keys when
launching.
5. Launch a server or collection with an explicit host, game-file version and
@@ -69,9 +71,12 @@ server ID and retained after removal.
## Libraries and campaigns
Game-file versions include game, version, DLC metadata, manifests, checksums and
size. Actual game files use dedicated filesystem storage, never SQLite blobs.
Downloads resume, report progress and verify checksums before becoming usable.
Game-file versions contain the uploaded T5/T6 folder, with its directory layout
and included DLC preserved. There is no separate DLC declaration. Versions record
the game, label, file manifest, checksums and size. Uploads use bounded chunks,
support pause/resume and verify checksums before publication. Actual game files
use dedicated filesystem storage, never SQLite blobs. Host downloads resume,
report progress and verify checksums before becoming usable.
Multiple instances on one host share read-only base files.
Scripts, plugins, configuration baselines and overlays retain their versioning,