redo of steam workshop

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

View file

@ -40,6 +40,10 @@ The agent stores the cron entry and executes it locally.
| `server_content_update_all` | same | same | `cron`, `addonsmanager` | aggregate update flow |
| `server_content_validate_files` | same | same | `cron`, `addonsmanager` | validation flow |
| `server_content_backup_before_update` | same | same | `cron`, `addonsmanager`, backup-related helpers | backup hook before content update |
| `workshop_update` | same | same | `cron`, `addonsmanager` | Server Content Manager Workshop update flow |
| `workshop_update_and_restart` | same | same | `cron`, `addonsmanager`, `gamemanager` | Workshop update plus safe restart request |
| `workshop_download_only` | same | same | `cron`, `addonsmanager` | SteamCMD download/cache without copying into live mod folders |
| `workshop_install_pending_on_restart` | same | same | `cron`, `addonsmanager` | Install Workshop items marked `pending_action=install_on_restart` |
## Agent Scheduler RPCs

View file

@ -33,3 +33,35 @@ Important references:
- clear logs and results
- no customer raw shell commands by default
## Server Content / Workshop Actions
The Scheduler must use Server Content Manager actions for Workshop automation. Do not build a separate Workshop scheduler.
Current Server Content actions:
| Action Key | Purpose |
|---|---|
| `server_content_check_updates` | Check content update state. |
| `server_content_check_workshop_updates` | Check Workshop update state. |
| `server_content_install_updates_if_stopped` | Install only when the server is stopped. |
| `server_content_install_updates_next_restart` | Queue updates for the next restart. |
| `server_content_install_updates_now` | Install available updates immediately. |
| `server_content_install_updates_and_restart` | Install updates, wait, then restart. |
| `server_content_update_all` | Update all server content records. |
| `server_content_validate_files` | Validate server content files. |
| `server_content_backup_before_update` | Backup before applying updates. |
Workshop-specific aliases:
| Action Key | Purpose |
|---|---|
| `workshop_update` | Update installed Workshop items through Server Content Manager. |
| `workshop_update_and_restart` | Update Workshop items and request a safe restart. |
| `workshop_download_only` | Download/cache Workshop items without installing into live folders. |
| `workshop_install_pending_on_restart` | Install items marked as pending during the restart/maintenance window. |
Implementation references:
- `Panel/modules/cron/shared_cron_functions.php`
- `Panel/modules/addonsmanager/server_content_actions.php`
- `Panel/modules/addonsmanager/workshop_action.php`

View file

@ -26,7 +26,8 @@ Active workflow:
3. Open the `Steam Workshop Mods` category.
4. Paste one or more Steam Workshop URLs or numeric Workshop IDs.
5. Click `Install / Queue`.
6. The Panel validates input, stores numeric Workshop IDs, writes a manifest, syncs the install script, executes it through the agent, and shows the result.
6. The Panel validates input, stores numeric Workshop IDs, writes a manifest, syncs the install script, executes it through the agent's existing `exec` primitive, and shows the result.
7. Installed items can be enabled/disabled, updated, removed, downloaded without immediate install, assigned an update policy, and later used by Scheduler actions.
Accepted input examples:
@ -57,7 +58,7 @@ The admin template defines capability and policy. The customer supplies only Wor
- or `{SERVER_HOME}/gsp_server_content/scripts/workshop/generic_steam_workshop_windows_cygwin.sh`
6. The agent runs:
- `bash <script> <manifest>`
7. The script runs SteamCMD, copies downloaded content into the target mod folder, logs output, and copies `.bikey` files for DayZ/Arma-style strategies.
7. The script runs SteamCMD, copies downloaded content into the target mod folder when the action requires install, logs output, and copies `.bikey` files for DayZ/Arma-style strategies.
Current repair:
@ -65,6 +66,8 @@ Current repair:
- Missing custom scripts fall back to the bundled generic handler and log a warning.
- Generic installs default to `{SERVER_ROOT}/workshop/{MOD_FOLDER}`.
- DayZ/Arma installs keep `{SERVER_ROOT}/{MOD_FOLDER}` for `@<workshop_id>` compatibility.
- `download_only` and `validate_files` are accepted script actions and do not copy into live mod folders.
- `remove` does not require SteamCMD.
## Manifest Fields
@ -121,6 +124,8 @@ Key-copy behavior:
- `install_strategy`
- `enabled`
- `load_order`
- `update_policy`
- `pending_action`
- `install_state`
- `last_installed_at`
- `last_updated_at`
@ -131,9 +136,40 @@ Phase 1 states:
- `queued`
- `installing`
- `installed`
- `downloaded`
- `failed`
- `removed`
`server_content_workshop_catalog` tracks known/common items:
- `workshop_id`
- `app_id`
- `title`
- `install_count`
- `first_seen`
- `last_installed`
- `last_updated`
- `published_date`
- `tags`
- `game_key`
- `local_cache_path`
Supported update policies:
- `manual`
- `scheduled`
- `update_now`
- `update_and_restart`
- `download_only`
- `install_on_restart`
Scheduler action keys:
- `workshop_update`
- `workshop_update_and_restart`
- `workshop_download_only`
- `workshop_install_pending_on_restart`
## Security Notes
- Customer input is reduced to numeric Workshop IDs only.

View file

@ -19,7 +19,15 @@ Important files:
- `Panel/modules/steam_workshop/module.php`
- `Panel/modules/steam_workshop/agent_update_workshop.php`
## Phase 1 Implemented Behavior
## Current Implemented Behavior
Workshop is Panel-side orchestration. The active workflow lives in Server Content Manager and uses existing agent primitives only:
- Panel writes manifests with validated numeric Workshop IDs.
- Panel deploys an OS-appropriate bundled handler script into the server home.
- Panel invokes the handler through the existing authenticated agent `exec` RPC.
- Agents do not need new Workshop-specific business logic.
- Legacy agent RPCs from the old `steam_workshop` module remain compatibility-only and are not the primary path.
The active user workflow is now `addonsmanager` -> `workshop_content`.
@ -39,7 +47,7 @@ The Panel syncs the bundled install script to:
- `{SERVER_HOME}/gsp_server_content/scripts/workshop/generic_steam_workshop_linux.sh`
- `{SERVER_HOME}/gsp_server_content/scripts/workshop/generic_steam_workshop_windows_cygwin.sh`
The agent executes the synced script with the manifest path. Customers do not need to place scripts manually on the agent.
The agent executes the synced script with the manifest path by using the existing generic command execution path. Customers do not need to place scripts manually on the agent.
Script selection rules:
@ -108,6 +116,8 @@ The Panel helper parser reads `workshop_support` first. Older direct tags are to
- `install_strategy`
- `enabled`
- `load_order`
- `update_policy`
- `pending_action`
- `install_state`
- `last_installed_at`
- `last_updated_at`
@ -118,9 +128,26 @@ Current install states used by Phase 1:
- `queued`
- `installing`
- `installed`
- `downloaded`
- `failed`
- `removed`
`server_content_workshop_catalog` tracks known/common Workshop items seen through Server Content Manager:
- `workshop_id`
- `app_id`
- `title`
- `install_count`
- `first_seen`
- `last_installed`
- `last_updated`
- `published_date`
- `tags`
- `game_key`
- `local_cache_path`
The catalog is Panel-side and does not require Steam Web API metadata. Metadata can be added later.
## What Exists Today
The current direction already supports:
@ -136,12 +163,39 @@ The current direction already supports:
## Main Limitations
- Workshop metadata is still incomplete.
- load order is tracked but not yet a full drag-and-drop or startup-param UX concept.
- enable/disable is stored but does not yet regenerate startup parameters.
- Load order is tracked but not yet a full drag-and-drop or startup-param UX concept.
- Enable/disable is exposed and stored but does not yet regenerate startup parameters.
- update/remove are synchronous and should become background jobs.
- caching and cleanup policy need product-level design, not just ad hoc scripts.
- `-mod=` / `-serverMod=` generation still needs a safe structured implementation.
## Scheduler Integration
Workshop updates use the existing `cron` / Scheduler system. No second Workshop scheduler should be created.
Supported scheduler action keys:
- `workshop_update`
- `workshop_update_and_restart`
- `workshop_download_only`
- `workshop_install_pending_on_restart`
Compatibility Server Content keys remain available:
- `server_content_check_workshop_updates`
- `server_content_update_workshop`
- `server_content_install_updates_next_restart`
- `server_content_install_updates_and_restart`
Per-item update policy values stored on `server_content_workshop.update_policy`:
- `manual`
- `scheduled`
- `update_now`
- `update_and_restart`
- `download_only`
- `install_on_restart`
## Troubleshooting
| Symptom | Meaning | Fix |
@ -192,3 +246,12 @@ Important manifest fields:
- `extra.keys_target_path`
Both bundled handlers validate numeric item IDs, keep writes under the server home, use SteamCMD, copy files into the resolved target path, and copy `.bikey` files for DayZ/Arma strategies when enabled.
Bundled handler actions:
- `install` - download with SteamCMD, copy/install into target path.
- `update` - validate/download with SteamCMD, copy/install into target path.
- `check_updates` - validate/download only; does not alter live mod folders.
- `download_only` - download/cache only and leave install pending.
- `validate_files` - SteamCMD validate/download only.
- `remove` - move the installed target folder into `gsp_server_content/workshop/removed/`; this does not require SteamCMD.

View file

@ -94,6 +94,8 @@ XML definitions also feed:
Workshop-enabled games must use the canonical `workshop_support` block. Loose top-level tags such as `workshop_app_id` are compatibility parser fallbacks only and should not be used in new game XML because schema validation is intentionally strict.
The `workshop_support` block is a capability declaration only. It does not install mods by itself and it does not create an agent-side Workshop subsystem. Server Content Manager reads these values, writes a per-server manifest, stages the Panel-bundled handler, and calls the agent's existing generic execution primitives.
Example:
```xml
@ -128,6 +130,12 @@ Supported `install_strategy` values:
`workshop_app_id` is the Steam Workshop app ID used by `steamcmd +workshop_download_item`. It is not automatically the same as a dedicated server installer app ID. For Arma 3, Workshop content uses `107410` while the dedicated server installer remains defined on the normal mod installer entry.
Ordering rule:
- `workshop_support` belongs after `game_name` and before `server_exec_name` in the current schema sequence.
- New XML files should not add top-level Workshop tags.
- If `install_path` is omitted, Server Content Manager defaults to `{SERVER_ROOT}/workshop/{MOD_FOLDER}` or `{SERVER_ROOT}/{MOD_FOLDER}` for DayZ/Arma strategies.
The current XML schema is validated by:
```bash