codex steam workshop integrarion
This commit is contained in:
parent
3cefad183d
commit
c687165132
12 changed files with 629 additions and 84 deletions
|
|
@ -2,12 +2,14 @@
|
|||
|
||||
## Status
|
||||
|
||||
Accepted
|
||||
Accepted, Phase 1 implementation started
|
||||
|
||||
## Decision
|
||||
|
||||
`Panel/modules/addonsmanager` should remain the primary future home for Workshop items, mods, add-ons, and server content. `steam_workshop` should remain a deprecated compatibility layer only.
|
||||
|
||||
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.
|
||||
|
||||
## Reasoning
|
||||
|
||||
- `addonsmanager` already has the richer schema and more complete product direction.
|
||||
|
|
@ -24,3 +26,10 @@ Accepted
|
|||
- `steam_workshop` is explicitly deprecated in the codebase.
|
||||
- Separate modules would fragment user workflows and duplicate install logic.
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
- 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.
|
||||
- DayZ/Arma-style installs default to `@<workshop_id>` folders and copy `.bikey` files into `keys` when present.
|
||||
- Startup parameter generation remains a later phase.
|
||||
|
|
|
|||
167
docs/features/WORKSHOP_PHASE1_IMPLEMENTATION.md
Normal file
167
docs/features/WORKSHOP_PHASE1_IMPLEMENTATION.md
Normal file
|
|
@ -0,0 +1,167 @@
|
|||
# Workshop Phase 1 Implementation
|
||||
|
||||
## Summary
|
||||
|
||||
Phase 1 makes the active Server Content Manager Workshop path usable for DayZ/Arma-style Workshop installs without reviving the deprecated standalone `steam_workshop` user workflow.
|
||||
|
||||
Active workflow:
|
||||
|
||||
`Game Monitor` -> `Server Content` -> `Steam Workshop Mods`
|
||||
|
||||
## Files Changed
|
||||
|
||||
- `Panel/modules/addonsmanager/server_content_helpers.php`
|
||||
- `Panel/modules/addonsmanager/workshop_action.php`
|
||||
- `Panel/modules/addonsmanager/workshop_content.php`
|
||||
- `Panel/modules/addonsmanager/addons_manager.php`
|
||||
- `Panel/modules/addonsmanager/module.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/monitor_buttons.php`
|
||||
|
||||
## User Flow
|
||||
|
||||
1. Open a server from the Panel.
|
||||
2. Click `Server Content`.
|
||||
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.
|
||||
|
||||
Accepted input examples:
|
||||
|
||||
- `450814997`
|
||||
- `https://steamcommunity.com/sharedfiles/filedetails/?id=450814997`
|
||||
|
||||
Invalid text is rejected before reaching the manifest or shell script.
|
||||
|
||||
## Admin Flow
|
||||
|
||||
1. Create a Server Content template in `addonsmanager`.
|
||||
2. Set content type to `Steam Workshop Mods`.
|
||||
3. Configure `Workshop App ID` when the game XML/profile does not provide it.
|
||||
4. Leave `Default Workshop IDs` blank for normal user-supplied installs.
|
||||
5. Optionally configure a target path template.
|
||||
|
||||
The admin template defines capability and policy. The customer supplies only Workshop item IDs or URLs.
|
||||
|
||||
## Install Flow
|
||||
|
||||
1. `workshop_content.php` receives the form post.
|
||||
2. `workshop_action.php` parses URLs/IDs and records rows in `server_content_workshop`.
|
||||
3. The Panel builds a manifest with per-item install details.
|
||||
4. The manifest is written to:
|
||||
- `{SERVER_HOME}/gsp_server_content/workshop_manifest.json`
|
||||
5. The correct bundled script is copied to:
|
||||
- `{SERVER_HOME}/gsp_server_content/scripts/workshop/generic_steam_workshop_linux.sh`
|
||||
- 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.
|
||||
|
||||
## Manifest Fields
|
||||
|
||||
Phase 1 manifests include:
|
||||
|
||||
- `manifest_version`
|
||||
- `action`
|
||||
- `home_id`
|
||||
- `home_cfg_id`
|
||||
- `game_path`
|
||||
- `server_path`
|
||||
- `workshop_app_id`
|
||||
- `steam_app_id`
|
||||
- `items`
|
||||
- `item_details`
|
||||
- `install_strategy`
|
||||
- `target_path`
|
||||
- `extra`
|
||||
|
||||
Each `item_details` entry includes:
|
||||
|
||||
- `workshop_item_id`
|
||||
- `folder_name`
|
||||
- `target_path_template`
|
||||
- `target_path_resolved`
|
||||
- `install_strategy`
|
||||
- `copy_keys`
|
||||
- `keys_target_path`
|
||||
|
||||
## DayZ / Arma Behavior
|
||||
|
||||
The Panel detects `dayz_mod_folder` or `arma_mod_folder` from the game key/name/config file when no explicit strategy exists.
|
||||
|
||||
Default install folder:
|
||||
|
||||
- `@<workshop_id>`
|
||||
|
||||
Key-copy behavior:
|
||||
|
||||
- `.bikey` files found anywhere in the installed mod folder are copied to `{SERVER_HOME}/keys`.
|
||||
- Missing `.bikey` files are logged and do not fail the install.
|
||||
|
||||
## Database Tracking
|
||||
|
||||
`server_content_workshop` now tracks:
|
||||
|
||||
- `content_id`
|
||||
- `install_path`
|
||||
- `install_strategy`
|
||||
- `enabled`
|
||||
- `load_order`
|
||||
- `install_state`
|
||||
- `last_installed_at`
|
||||
- `last_updated_at`
|
||||
- `last_error`
|
||||
|
||||
Phase 1 states:
|
||||
|
||||
- `queued`
|
||||
- `installing`
|
||||
- `installed`
|
||||
- `failed`
|
||||
- `removed`
|
||||
|
||||
## Security Notes
|
||||
|
||||
- Customer input is reduced to numeric Workshop IDs only.
|
||||
- Invalid text is rejected.
|
||||
- Target paths are generated from trusted templates and checked to stay under the server home.
|
||||
- Scripts are copied from the Panel module source into a GSP-controlled folder under the server home.
|
||||
- Customers do not supply shell commands.
|
||||
- Admin-defined post-install scripts remain possible but should be treated as trusted admin configuration only.
|
||||
- Steam credentials are not introduced by Phase 1; scripts use anonymous login.
|
||||
|
||||
## Startup Parameters
|
||||
|
||||
Phase 1 does not rewrite startup parameter generation.
|
||||
|
||||
Current DayZ/Arma XML files already expose user-editable `-mod=` / `-serverMod=` parameters through `server_params`.
|
||||
|
||||
Phase 2 should generate structured mod lists from enabled `server_content_workshop` rows ordered by `load_order`, avoid duplicate `-mod=` entries, and preserve existing user parameters.
|
||||
|
||||
## Validation Performed
|
||||
|
||||
- PHP syntax checks passed for changed PHP files.
|
||||
- Bash syntax checks passed for both bundled Workshop scripts.
|
||||
- Parser test confirmed:
|
||||
- numeric ID accepted
|
||||
- full Steam URL accepted
|
||||
- invalid text rejected
|
||||
- Temporary manifest test with fake SteamCMD confirmed:
|
||||
- Linux script installs into `@<workshop_id>`
|
||||
- Windows/Cygwin script installs into `@<workshop_id>`
|
||||
- `.bikey` files are copied to `keys`
|
||||
- useful logs are written under `gsp_server_content`
|
||||
|
||||
## Phase 2 Work
|
||||
|
||||
- Add real asynchronous install jobs and progress polling.
|
||||
- Resolve Workshop item titles/metadata.
|
||||
- Add load-order UI.
|
||||
- Wire enable/disable and load order into safe startup parameter generation.
|
||||
- Support separate client mods and server-only mods.
|
||||
- Add update-all and repair semantics that can preserve old installs until success.
|
||||
- Add cache policy and cleanup controls.
|
||||
- Add admin XML/schema fields for explicit install strategy and key-copy behavior.
|
||||
- Add Steam account credential support without leaking secrets.
|
||||
|
|
@ -14,9 +14,72 @@ Important files:
|
|||
- `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:
|
||||
|
|
@ -32,10 +95,11 @@ The current direction already supports:
|
|||
## Main Limitations
|
||||
|
||||
- Workshop metadata is still incomplete.
|
||||
- load order is not yet a full first-class UX concept.
|
||||
- update/uninstall/enable/disable flows need a cleaner product model.
|
||||
- DayZ/Arma-specific folder and key-copy behavior needs a stronger canonical path.
|
||||
- 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
|
||||
|
||||
|
|
@ -50,4 +114,3 @@ Use `addonsmanager` as the main future home for:
|
|||
- install history
|
||||
|
||||
Treat `steam_workshop` as a legacy bridge for migration only.
|
||||
|
||||
|
|
|
|||
|
|
@ -35,15 +35,30 @@ The module can already represent several content types, including:
|
|||
- config packs
|
||||
- future profile-type content
|
||||
|
||||
For Workshop items, the current flow lets users enter IDs and routes the install through module pages and agent-side scripts.
|
||||
For Workshop items, the current flow lets users enter Workshop IDs or full Steam Workshop URLs and routes the install through module pages and agent-side scripts.
|
||||
|
||||
## Workshop Phase 1 Flow
|
||||
|
||||
1. Admin creates a Server Content template with install method `steam_workshop`.
|
||||
2. Admin configures the Workshop App ID on the template or relies on the game XML/profile fallback.
|
||||
3. User opens `Server Content` from the game monitor.
|
||||
4. User selects the Steam Workshop Mods category.
|
||||
5. User enters one or more Workshop URLs or numeric IDs.
|
||||
6. Panel parses IDs, rejects invalid entries, and records rows in `server_content_workshop`.
|
||||
7. Panel writes a manifest to `{SERVER_HOME}/gsp_server_content/workshop_manifest.json`.
|
||||
8. Panel syncs the bundled Linux or Cygwin script into `{SERVER_HOME}/gsp_server_content/scripts/workshop/`.
|
||||
9. Agent executes the script with the manifest path.
|
||||
10. Script runs SteamCMD, copies Workshop content into the configured target path, copies DayZ/Arma `.bikey` files when applicable, and writes a log under `gsp_server_content`.
|
||||
|
||||
The legacy `steam_workshop` monitor button is intentionally suppressed so users are not sent to the deprecated standalone module.
|
||||
|
||||
## Current Limitations
|
||||
|
||||
- Workshop and content metadata is still partial.
|
||||
- Load order and enable/disable behavior need a cleaner first-class model.
|
||||
- Load order and enable/disable are tracked but not wired into startup-parameter generation yet.
|
||||
- Async install job progress should be more visible.
|
||||
- Install strategies are still being broadened and need consistent game-specific rules.
|
||||
- DayZ/Arma style key-copy and startup-param behavior needs a stronger canonical implementation.
|
||||
- DayZ/Arma style key-copy is implemented for Phase 1; startup-param behavior still needs a stronger canonical implementation.
|
||||
- Cache and cleanup policy need a clearer product design.
|
||||
|
||||
## Where To Start Reading
|
||||
|
|
@ -67,4 +82,3 @@ This module is the right place for:
|
|||
- install history
|
||||
|
||||
The old `steam_workshop` module should be treated as a deprecated compatibility layer, not the main future path.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue