38 lines
2.4 KiB
Markdown
38 lines
2.4 KiB
Markdown
## Design
|
|
|
|
The lifecycle boundary becomes:
|
|
|
|
- Platform validates the selected plugin, resolves the plugin lifecycle action reference, packages plugin action assets into generated run workspaces, and dispatches a generic lifecycle job with typed inputs.
|
|
- The SCUM plugin owns Windows scripts/action specs that check whether `SCUMServer.exe` exists, install or update through SteamCMD, stop before update, write plugin-declared config values, and start with plugin-declared `port`/`MaxPlayers` plus the plugin default `-log`.
|
|
- Run executes the referenced action through generic primitives. It never branches on `game.scum`, `SCUMServer.exe`, or app `3792580`.
|
|
|
|
### SCUM Plugin Action Model
|
|
|
|
The SCUM install action is the authoritative setup action. It runs before first start and may also be reused as a pre-start update action. The action checks for SteamCMD, downloads it if missing, stops the SCUM process when an update is needed, runs:
|
|
|
|
```powershell
|
|
./steamcmd.exe +force_install_dir C:/scumserver +login anonymous +app_update 3792580 validate +quit
|
|
```
|
|
|
|
Then the start action runs:
|
|
|
|
```powershell
|
|
C:/scumserver\SCUM\Binaries\Win64\SCUMServer.exe -port=<gamePort> -MaxPlayers=<maxPlayers> -log
|
|
```
|
|
|
|
The concrete path may come from server deployment inputs, but the SCUM executable relative path, app id, SteamCMD arguments, and `-log` default are plugin assets, not platform/run code.
|
|
|
|
### Platform Changes
|
|
|
|
Platform no longer freezes a `ServerDeploymentPlan` for SCUM or requires `deployment.scum.v1`. It keeps generic deployment definitions and dispatches plugin action refs. Deployment projections can still show queued/running/failed lifecycle state from generic receipts, but detailed SCUM evidence is plugin-generated output/log/artifact data, not a platform-owned SCUM evidence schema.
|
|
|
|
### Run Changes
|
|
|
|
Run removes the SCUM deployment executor and SCUM capability advertisement. Assignments carrying `serverDeploymentPlan` are rejected as legacy unsupported input. Generic lifecycle template execution remains, including managed process start/stop/status, file operations, logs, and artifacts.
|
|
|
|
## Risks / Trade-Offs
|
|
|
|
- Existing tests expecting SCUM evidence need to shift to plugin-action dispatch assertions.
|
|
- The first plugin script implementation must be careful about Windows quoting and idempotency.
|
|
- If future games need richer setup flows, add generic action primitives or structured lifecycle DSL features without moving game policy into run.
|