116 lines
3.3 KiB
Markdown
116 lines
3.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.
|
|
|
|
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
|
|
|
|
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 `@<workshop_id>` by default and copy `.bikey` files into the server `keys` folder when found. Missing key files are logged but do not fail the install.
|
|
|
|
## 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.
|
|
|
|
## 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.
|