142 lines
5.3 KiB
Markdown
142 lines
5.3 KiB
Markdown
# Workshop System
|
|
|
|
## Current State
|
|
|
|
The current Workshop/content work is split across two module lines:
|
|
|
|
- `Panel/modules/steam_workshop` - deprecated compatibility layer
|
|
- `Panel/modules/addonsmanager` - the active Server Content Manager path
|
|
|
|
Important files:
|
|
|
|
- `Panel/modules/addonsmanager/module.php`
|
|
- `Panel/modules/addonsmanager/user_addons.php`
|
|
- `Panel/modules/addonsmanager/addons_manager.php`
|
|
- `Panel/modules/addonsmanager/workshop_content.php`
|
|
- `Panel/modules/addonsmanager/workshop_action.php`
|
|
- `Panel/modules/addonsmanager/scripts/workshop/generic_steam_workshop_linux.sh`
|
|
- `Panel/modules/addonsmanager/scripts/workshop/generic_steam_workshop_windows_cygwin.sh`
|
|
- `Panel/modules/steam_workshop/module.php`
|
|
- `Panel/modules/steam_workshop/agent_update_workshop.php`
|
|
|
|
## Phase 1 Implemented Behavior
|
|
|
|
The active user workflow is now `addonsmanager` -> `workshop_content`.
|
|
|
|
Users can enter either:
|
|
|
|
- a numeric Workshop item ID
|
|
- a full Steam Workshop URL containing `id=<number>`
|
|
|
|
The Panel extracts and stores only numeric Workshop IDs. Invalid text is rejected before any manifest or shell command is built.
|
|
|
|
The Panel writes a manifest under the server home:
|
|
|
|
- `{SERVER_HOME}/gsp_server_content/workshop_manifest.json`
|
|
|
|
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.
|
|
|
|
Script selection rules:
|
|
|
|
1. If game XML defines a custom `workshop_script_linux` or `workshop_script_windows` and that script exists on the agent, use it.
|
|
2. If the custom script is missing, log a fallback warning and stage the bundled generic handler.
|
|
3. If no custom script is defined, stage the bundled generic handler for the server OS.
|
|
4. The default script filename must never be treated as a pre-existing agent path. The Panel must copy the bundled script first.
|
|
|
|
The manifest includes:
|
|
|
|
- `home_id`
|
|
- server/game path
|
|
- `workshop_app_id`
|
|
- Workshop item IDs
|
|
- per-item target paths
|
|
- install strategy
|
|
- key-copy settings
|
|
- content template metadata
|
|
|
|
Default install paths:
|
|
|
|
- Generic Workshop installs default to `{SERVER_ROOT}/workshop/{MOD_FOLDER}`.
|
|
- DayZ/Arma-style installs default to `dayz_mod_folder` or `arma_mod_folder` based on the game key/name/config file. Those strategies install to `{SERVER_ROOT}/{MOD_FOLDER}` so `@<workshop_id>` folders remain compatible with existing `-mod=` workflows.
|
|
- DayZ/Arma key-copy behavior copies `.bikey` files into the server `keys` folder when found. Missing key files are logged but do not fail the install.
|
|
|
|
App ID rules:
|
|
|
|
- `workshop_app_id` must come from a Server Content template, Steam Workshop profile, or game XML.
|
|
- Do not silently use the dedicated server Steam app ID as the Workshop app ID unless a legacy profile explicitly does so.
|
|
- Arma 3 XML declares Workshop app ID `107410`; its dedicated server Steam app ID remains `233780`.
|
|
|
|
## Database State
|
|
|
|
`server_content_workshop` tracks:
|
|
|
|
- `content_id`
|
|
- `home_id`
|
|
- `workshop_app_id`
|
|
- `workshop_item_id`
|
|
- `title`
|
|
- `install_path`
|
|
- `install_strategy`
|
|
- `enabled`
|
|
- `load_order`
|
|
- `install_state`
|
|
- `last_installed_at`
|
|
- `last_updated_at`
|
|
- `last_error`
|
|
|
|
Current install states used by Phase 1:
|
|
|
|
- `queued`
|
|
- `installing`
|
|
- `installed`
|
|
- `failed`
|
|
- `removed`
|
|
|
|
## What Exists Today
|
|
|
|
The current direction already supports:
|
|
|
|
- content records in the Panel database
|
|
- Workshop item IDs
|
|
- installation metadata
|
|
- install history tables
|
|
- game compatibility fields
|
|
- launch parameter additions
|
|
- post-install behavior fields
|
|
|
|
## 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.
|
|
- 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.
|
|
|
|
## Troubleshooting
|
|
|
|
| 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 stages the bundled handler under `gsp_server_content/scripts/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. |
|
|
| 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
|
|
|
|
Use `addonsmanager` as the main future home for:
|
|
|
|
- mods
|
|
- add-ons
|
|
- Workshop items
|
|
- scripts
|
|
- config packs
|
|
- server content manifests
|
|
- install history
|
|
|
|
Treat `steam_workshop` as a legacy bridge for migration only.
|