GSP/Panel
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

redo of steam workshop

Browse source
This commit is contained in:
Frank Harris 2026-06-06 18:18:40 -05:00
parent e662415f36
commit e6541370b9
19 changed files with 610 additions and 38 deletions
Download patch file Download diff file Expand all files Collapse all files

23
docs/decisions/0004-workshop-system.md
View file

@ -2,7 +2,7 @@
## Status
Accepted, Phase 1 implementation active
Accepted, Panel-side orchestration active
## Decision
@ -10,6 +10,8 @@ Accepted, Phase 1 implementation active
Phase 1 implements this decision by routing the user-facing Workshop install flow through `addonsmanager/workshop_content.php` and suppressing the standalone `steam_workshop` monitor button.
The current implementation keeps Workshop business logic in the Panel. Agents are generic executors: the Panel writes manifests, stages scripts, invokes `exec`, reads logs/results, and updates database state. New first-class Workshop subsystems should not be added to `Agent-Windows` or `Agent_Linux` unless a future decision explicitly changes this.
## Reasoning
- `addonsmanager` already has the richer schema and more complete product direction.
@ -31,8 +33,12 @@ Phase 1 implements this decision by routing the user-facing Workshop install flo
- Workshop input accepts numeric IDs or Steam URLs, then stores numeric IDs only.
- Manifests are written under the server home in `gsp_server_content`.
- Bundled Linux/Cygwin scripts are copied from the Panel module to an agent-managed folder under the server home before execution.
- These scripts are Panel-owned deployment artifacts, not persistent agent features.
- Default script names are treated as bundled handlers, not as existing agent paths.
- Missing custom scripts fall back to bundled handlers and log the fallback.
- Known Workshop items are cataloged in `server_content_workshop_catalog`.
- Per-server item state, enablement, load order, update policy, and pending action are stored in `server_content_workshop`.
- Scheduler integrates via `workshop_update`, `workshop_update_and_restart`, `workshop_download_only`, and `workshop_install_pending_on_restart`.
- Generic content installs under `{SERVER_ROOT}/workshop/{MOD_FOLDER}` by default.
- DayZ/Arma-style installs default to `@<workshop_id>` folders and copy `.bikey` files into `keys` when present.
- Startup parameter generation remains a later phase.
@ -40,6 +46,21 @@ Phase 1 implements this decision by routing the user-facing Workshop install flo
- The Panel helpers read `workshop_support` first, then tolerate older direct tags only as compatibility fallbacks.
- Arma 3 Linux and Windows configs declare Workshop app ID `107410` through `workshop_support`.
## Reference Module Findings
The old `reference/Module-Steam_Workshop` module stored per-game profile XML under its own module folder, required admin-managed Workshop mod lists for some workflows, called dedicated agent RPCs such as `steam_workshop`, and used regex/profile rules to mutate game config values. Useful lessons retained:
- Customers should be able to paste one or more Workshop IDs or URLs.
- The Panel should store per-server installed Workshop rows.
- SteamCMD command generation should be controlled by admin/game configuration, not customer shell text.
Rejected legacy behavior:
- making `steam_workshop` the primary user module
- requiring admins to pre-enter every Workshop item ID
- mutating base game XML per customer install
- adding new Workshop-specific agent business logic
## Validation
Current validation commands: