redo of steam workshop
This commit is contained in:
parent
e662415f36
commit
e6541370b9
19 changed files with 610 additions and 38 deletions
|
|
@ -60,7 +60,7 @@ Primary categories:
|
|||
| updates | `steam_cmd`, `component_update`, `stop_update` |
|
||||
| system | `exec`, `sudo_exec`, `rebootnow`, `what_os`, `discover_ips`, `mon_stats` |
|
||||
| scheduler | `scheduler_add_task`, `scheduler_edit_task`, `scheduler_del_task`, `scheduler_list_tasks` |
|
||||
| content | `steam_workshop`, `get_workshop_mods_info` |
|
||||
| content | `writefile` + `exec` manifest/script orchestration; legacy `steam_workshop`, `get_workshop_mods_info` |
|
||||
|
||||
See the full command table in:
|
||||
|
||||
|
|
@ -82,7 +82,7 @@ Most Panel modules do not build XML-RPC directly. They call `OGPRemoteLibrary`.
|
|||
| `remote_query()` | `remote_query` | `gamemanager`, dashboards |
|
||||
| `component_update()` | `component_update` | update/admin pages |
|
||||
| `scheduler_*()` | `scheduler_*` | `cron` |
|
||||
| `steam_workshop()` | `steam_workshop` | legacy workshop path |
|
||||
| `steam_workshop()` | `steam_workshop` | legacy workshop path only |
|
||||
|
||||
## External Panel API
|
||||
|
||||
|
|
@ -207,7 +207,25 @@ Common manifest fields:
|
|||
- `items`
|
||||
- `options`
|
||||
|
||||
For Workshop-specific manifests, the broader fields documented in `WORKSHOP_SYSTEM.md` also apply, including app IDs, install strategy, and target paths.
|
||||
For Workshop-specific manifests, the broader fields documented in `WORKSHOP_SYSTEM.md` also apply, including app IDs, install strategy, update policy, pending action, and target paths.
|
||||
|
||||
Current Workshop actions:
|
||||
|
||||
- `install`
|
||||
- `update`
|
||||
- `check_updates`
|
||||
- `download_only`
|
||||
- `validate_files`
|
||||
- `remove`
|
||||
|
||||
Current Scheduler/API action aliases:
|
||||
|
||||
- `workshop_update`
|
||||
- `workshop_update_and_restart`
|
||||
- `workshop_download_only`
|
||||
- `workshop_install_pending_on_restart`
|
||||
|
||||
The legacy `steam_workshop/install` API route and agent `steam_workshop` RPC remain compatibility-only. New user-facing Workshop work should use `addonsmanager` / Server Content Manager.
|
||||
|
||||
## Status Contract
|
||||
|
||||
|
|
|
|||
|
|
@ -103,7 +103,9 @@ Current preferred implementation path:
|
|||
|
||||
- `addonsmanager` stages a manifest and helper script through `writefile`
|
||||
- it executes the helper through `exec`
|
||||
- it records per-server items and policies in Panel database tables
|
||||
- it uses `steam_workshop` only as legacy compatibility, not as the primary workflow
|
||||
- no new Workshop-specific business logic should be added to agents for the current design
|
||||
|
||||
## Shell And System Commands
|
||||
|
||||
|
|
@ -172,6 +174,10 @@ The built-in action names handled by the Panel-generated API URLs are:
|
|||
- `server_content_update_all`
|
||||
- `server_content_validate_files`
|
||||
- `server_content_backup_before_update`
|
||||
- `workshop_update`
|
||||
- `workshop_update_and_restart`
|
||||
- `workshop_download_only`
|
||||
- `workshop_install_pending_on_restart`
|
||||
|
||||
## Panel Wrapper Map
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
## Status
|
||||
|
||||
Accepted, Phase 1 implementation active
|
||||
Accepted, Panel-side orchestration active
|
||||
|
||||
## Decision
|
||||
|
||||
|
|
@ -10,6 +10,8 @@ Accepted, Phase 1 implementation active
|
|||
|
||||
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.
|
||||
|
||||
The current implementation keeps Workshop business logic in the Panel. Agents are generic executors: the Panel writes manifests, stages scripts, invokes `exec`, reads logs/results, and updates database state. New first-class Workshop subsystems should not be added to `Agent-Windows` or `Agent_Linux` unless a future decision explicitly changes this.
|
||||
|
||||
## Reasoning
|
||||
|
||||
- `addonsmanager` already has the richer schema and more complete product direction.
|
||||
|
|
@ -31,8 +33,12 @@ Phase 1 implements this decision by routing the user-facing Workshop install flo
|
|||
- 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.
|
||||
- These scripts are Panel-owned deployment artifacts, not persistent agent features.
|
||||
- Default script names are treated as bundled handlers, not as existing agent paths.
|
||||
- Missing custom scripts fall back to bundled handlers and log the fallback.
|
||||
- Known Workshop items are cataloged in `server_content_workshop_catalog`.
|
||||
- Per-server item state, enablement, load order, update policy, and pending action are stored in `server_content_workshop`.
|
||||
- Scheduler integrates via `workshop_update`, `workshop_update_and_restart`, `workshop_download_only`, and `workshop_install_pending_on_restart`.
|
||||
- Generic content installs under `{SERVER_ROOT}/workshop/{MOD_FOLDER}` by default.
|
||||
- DayZ/Arma-style installs default to `@<workshop_id>` folders and copy `.bikey` files into `keys` when present.
|
||||
- Startup parameter generation remains a later phase.
|
||||
|
|
@ -40,6 +46,21 @@ Phase 1 implements this decision by routing the user-facing Workshop install flo
|
|||
- The Panel helpers read `workshop_support` first, then tolerate older direct tags only as compatibility fallbacks.
|
||||
- Arma 3 Linux and Windows configs declare Workshop app ID `107410` through `workshop_support`.
|
||||
|
||||
## Reference Module Findings
|
||||
|
||||
The old `reference/Module-Steam_Workshop` module stored per-game profile XML under its own module folder, required admin-managed Workshop mod lists for some workflows, called dedicated agent RPCs such as `steam_workshop`, and used regex/profile rules to mutate game config values. Useful lessons retained:
|
||||
|
||||
- Customers should be able to paste one or more Workshop IDs or URLs.
|
||||
- The Panel should store per-server installed Workshop rows.
|
||||
- SteamCMD command generation should be controlled by admin/game configuration, not customer shell text.
|
||||
|
||||
Rejected legacy behavior:
|
||||
|
||||
- making `steam_workshop` the primary user module
|
||||
- requiring admins to pre-enter every Workshop item ID
|
||||
- mutating base game XML per customer install
|
||||
- adding new Workshop-specific agent business logic
|
||||
|
||||
## Validation
|
||||
|
||||
Current validation commands:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -22,6 +22,7 @@ Known tables used by the module:
|
|||
|
||||
- `addons`
|
||||
- `server_content_workshop`
|
||||
- `server_content_workshop_catalog`
|
||||
- `server_content_manifest`
|
||||
- `server_content_install_history`
|
||||
|
||||
|
|
@ -35,7 +36,7 @@ The module can already represent several content types, including:
|
|||
- config packs
|
||||
- future profile-type content
|
||||
|
||||
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.
|
||||
For Workshop items, the current flow lets users enter Workshop IDs or full Steam Workshop URLs and routes the install through module pages, staged manifests, and Panel-bundled scripts executed through existing agent primitives.
|
||||
|
||||
## Workshop Phase 1 Flow
|
||||
|
||||
|
|
@ -47,9 +48,11 @@ For Workshop items, the current flow lets users enter Workshop IDs or full Steam
|
|||
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.
|
||||
9. Agent executes the script with the manifest path through the existing authenticated `exec` RPC.
|
||||
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 agents are intentionally generic executors in this design. New Workshop business logic should not be added to `Agent-Windows` or `Agent_Linux`; use `remote_writefile`, `exec`, log reads, and normal start/stop/restart primitives instead.
|
||||
|
||||
Current script fallback behavior:
|
||||
|
||||
- Admin-defined custom scripts are supported when they exist on the agent.
|
||||
|
|
@ -92,10 +95,34 @@ SteamCMD requirements:
|
|||
|
||||
The legacy `steam_workshop` monitor button is intentionally suppressed so users are not sent to the deprecated standalone module.
|
||||
|
||||
## Current User Controls
|
||||
|
||||
The `workshop_content.php` page supports:
|
||||
|
||||
- direct install by numeric ID or Steam Workshop URL
|
||||
- installed item list
|
||||
- enable/disable selected items
|
||||
- update selected items
|
||||
- remove selected items
|
||||
- download selected items without installing immediately
|
||||
- update all saved Workshop items
|
||||
- per-item update policy storage
|
||||
- known/common item catalog sorted by name, install count, published date, last updated, or last installed
|
||||
|
||||
Update policies are stored as data for Scheduler/automation:
|
||||
|
||||
- `manual`
|
||||
- `scheduled`
|
||||
- `update_now`
|
||||
- `update_and_restart`
|
||||
- `download_only`
|
||||
- `install_on_restart`
|
||||
|
||||
## Current Limitations
|
||||
|
||||
- Workshop and content metadata is still partial.
|
||||
- Load order and enable/disable are tracked but not wired into startup-parameter generation yet.
|
||||
- Load order is tracked but not yet reorderable through a polished drag-and-drop UI.
|
||||
- Enable/disable is 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 is implemented for Phase 1; startup-param behavior still needs a stronger canonical implementation.
|
||||
|
|
|
|||
|
|
@ -80,6 +80,12 @@ Validate changes with:
|
|||
php Panel/modules/config_games/tests/validate_server_configs.php
|
||||
```
|
||||
|
||||
Important rules:
|
||||
|
||||
- Place `workshop_support` after `game_name` and before `server_exec_name`.
|
||||
- Do not add loose top-level tags such as `workshop_app_id`; helper code may tolerate them for old configs, but schema-valid XML should use the canonical block.
|
||||
- XML declares capability only. Server Content Manager owns the Panel-side install orchestration and uses agents only for generic file/command execution.
|
||||
|
||||
## Suggested Future Improvements
|
||||
|
||||
- extend XML capability model
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue