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

woekshop phase 1

Browse source
This commit is contained in:
Frank Harris 2026-06-09 06:13:44 -05:00
parent 17a31b7f5f
commit 5a03946bdf
15 changed files with 409 additions and 357 deletions
Download patch file Download diff file Expand all files Collapse all files

27
docs/features/WORKSHOP_SYSTEM.md
View file

@ -54,7 +54,7 @@ The agent executes the generated script with the manifest path by using the exis
Script/job rules:
1. Server Content Manager always generates the primary Workshop job script per action.
2. Old XML/static script settings are logged as deprecated and ignored by the primary path.
2. Game XML does not define static agent script paths.
3. The default script filename must never be treated as a pre-existing agent path.
4. The agent does not require `generic_steam_workshop_linux.sh` or `generic_steam_workshop_windows_cygwin.sh` to exist on disk.
@ -88,9 +88,9 @@ Default install paths:
App ID rules:
- `workshop_app_id` must come from a Server Content template, Steam Workshop profile, or game XML.
- Game XML should declare Workshop support in the canonical `workshop_support` block.
- Do not silently use the dedicated server Steam app ID as the Workshop app ID unless a legacy profile explicitly does so.
- `workshop_app_id` must come from the selected game's canonical `workshop_support` XML block.
- Server Content admin forms must not ask for Workshop app IDs, target paths, launch params, or Workshop script paths.
- Do not silently use the dedicated server Steam app ID as the Workshop app ID.
- Arma 3 XML declares Workshop app ID `107410`; its dedicated server Steam app ID remains `233780`.
Canonical XML:
@ -111,10 +111,11 @@ Canonical XML:
<source_pattern>{MOD_PATH}/keys/*.bikey</source_pattern>
<target_path>{SERVER_ROOT}/keys</target_path>
</copy_keys>
<post_install_action></post_install_action>
</workshop_support>
```
The Panel helper parser reads `workshop_support` first. Older direct tags are tolerated only as a compatibility fallback in helper code; they are not the canonical XML format.
The Panel helper parser reads `workshop_support` as the source of truth. New game XML must not use loose top-level Workshop tags, and the schema no longer accepts per-game static agent script tags such as `script_linux` or `script_windows`.
## Database State
@ -150,6 +151,8 @@ Current install states used by Phase 1:
- `workshop_id`
- `app_id`
- `title`
- `author`
- `thumbnail_url`
- `install_count`
- `first_seen`
- `last_installed`
@ -159,7 +162,7 @@ Current install states used by Phase 1:
- `game_key`
- `local_cache_path`
The catalog is Panel-side and does not require Steam Web API metadata. Metadata can be added later.
The catalog is Panel-side and does not require Steam Web API metadata. It grows from real installs and can be searched by Workshop ID, Steam URL, keyword/title, author, tag, or game key. Metadata can be enriched later through Steam Web API or SteamCMD output parsing.
## What Exists Today
@ -169,9 +172,9 @@ The current direction already supports:
- Workshop item IDs
- installation metadata
- install history tables
- game compatibility fields
- launch parameter additions
- post-install behavior fields
- XML-owned game compatibility fields
- XML-owned launch parameter format
- XML-owned post-install action placeholder
## Main Limitations
@ -181,6 +184,7 @@ The current direction already supports:
- 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.
- Steam keyword/tag search currently searches the local Panel catalog and links to Steam's app-scoped Workshop search; direct Steam Web API search is Phase 2.
## Scheduler Integration
@ -214,8 +218,9 @@ Per-item update policy values stored on `server_content_workshop.update_policy`:
| Symptom | Meaning | Fix |
|---|---|---|
| `Configured workshop script not found on agent host: generic_steam_workshop_windows_cygwin.sh` | Old Panel logic treated the default script filename as an agent path. | Update the Panel. Current logic generates a per-job script under `gsp_server_content/jobs/workshop/`. |
| `SteamCMD is missing on the agent host.` | The handler could not find SteamCMD at the configured path, `STEAMCMD_PATH`, or common locations. | Install SteamCMD on the agent and/or set the SteamCMD path in the Workshop profile/template. |
| `Workshop App ID is missing` | No template/profile/XML provided an app ID. | Add `workshop_app_id` to the Server Content template or game XML. |
| `SteamCMD is missing on the agent host.` | The generated job could not find SteamCMD at `STEAMCMD_PATH` or common locations. | Install SteamCMD on the agent or set `STEAMCMD_PATH` for the agent environment. |
| `Workshop App ID is missing` | The selected game XML does not provide `workshop_support/workshop_app_id`. | Add a canonical `workshop_support` block to the game XML and validate it. |
| `This game XML does not enable Steam Workshop support` | The user opened Workshop for a game whose XML lacks enabled Workshop capability. | Add `workshop_support` with `enabled` and `workshop_app_id`, or do not expose Workshop for that game. |
| Download succeeds but mod does not load | Startup parameters are not yet regenerated from installed Workshop rows. | Manually add the installed `@...` folders to the game startup params until Phase 2 startup integration is complete. |
## Recommended Mental Model

6
docs/features/XML_SYSTEM.md
View file

@ -94,7 +94,7 @@ XML definitions also feed:
## Workshop / Server Content Capability
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.
Workshop-enabled games must use the canonical `workshop_support` block. The game XML is the source of truth for Steam Workshop capability and runtime behavior. Loose top-level tags such as `workshop_app_id` must 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, writes a generated per-job script, and calls the agent's existing generic execution primitives.
@ -116,6 +116,7 @@ Example:
<source_pattern>{MOD_PATH}/keys/*.bikey</source_pattern>
<target_path>{SERVER_ROOT}/keys</target_path>
</copy_keys>
<post_install_action></post_install_action>
</workshop_support>
```
@ -132,10 +133,13 @@ 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.
`post_install_action` is reserved for a safe admin-owned post-install action identifier or template name. It is not customer input and must not be treated as an arbitrary shell command.
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.
- New XML files should not define static agent script paths. Server Content Manager stages generated per-job scripts under the server home and invokes them through generic agent execution.
- 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: