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

worshop work

Browse source
This commit is contained in:
Frank Harris 2026-06-08 16:09:54 -05:00
parent 0d44c65ea5
commit 3829a4a83d
92 changed files with 487 additions and 110 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/features/COMPANION_PROGRAMS.md
View file

@ -1,5 +1,7 @@
# Companion Programs
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Current State
Companion programs are not yet a first-class managed system. Current behavior is mostly script-driven and game-specific.

2
docs/features/COMPETITOR_COMPARISON.md
View file

@ -1,5 +1,7 @@
# Competitor Comparison
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Reviewed Hosts / Panels
- Open Game Panel

2
docs/features/FILE_EDITOR.md
View file

@ -1,5 +1,7 @@
# File Editor
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Current State
File editing is split across LiteFM, FTP, edit-config helpers, and agent remote read/write methods.

2
docs/features/FTP_SYSTEM.md
View file

@ -1,5 +1,7 @@
# FTP System
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Current State
GSP includes an FTP module and FTP-related provisioning fields.

2
docs/features/INSTALLERS.md
View file

@ -1,5 +1,7 @@
# Installers
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Current State
Installer behavior is split across game XML, gamemanager startup, addonsmanager, SteamCMD helpers, and agent scripts.

2
docs/features/LOGGING_SYSTEM.md
View file

@ -1,5 +1,7 @@
# Logging System
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Current State
Logging comes from multiple places:

2
docs/features/PROVISIONING.md
View file

@ -1,5 +1,7 @@
# Provisioning
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Current State
Server provisioning flows are centered in `user_games` and supported by billing and server manager modules.

2
docs/features/RCON_SYSTEM.md
View file

@ -1,5 +1,7 @@
# RCON System
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Current State
RCON support is part of the gamemanager and a dedicated admin RCON module.

2
docs/features/SCHEDULER_ACTIONS.md
View file

@ -1,5 +1,7 @@
# Scheduler Actions
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Scope
This file is the command reference for the current scheduler system.

2
docs/features/SCHEDULER_SYSTEM.md
View file

@ -1,5 +1,7 @@
# Scheduler System
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Current State
The scheduler is implemented through the `cron` Panel module and agent-side `Schedule::Cron` execution.

2
docs/features/STATUS_SYSTEM.md
View file

@ -1,5 +1,7 @@
# Status System
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Current Goal
The status system should tell the truth about a server's state without depending on stale marker files or query success alone.

2
docs/features/USER_API.md
View file

@ -1,5 +1,7 @@
# User API
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Scope
This file documents the externally reachable API and webhook surfaces discovered in the repository.

18
docs/features/WORKSHOP_PHASE1_IMPLEMENTATION.md
View file

@ -1,5 +1,7 @@
# Workshop Phase 1 Implementation
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## 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.
@ -15,8 +17,8 @@ Active workflow:
- `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/addonsmanager/scripts/workshop/generic_steam_workshop_linux.sh` (Panel template for generated jobs)
- `Panel/modules/addonsmanager/scripts/workshop/generic_steam_workshop_windows_cygwin.sh` (Panel template for generated jobs)
- `Panel/modules/steam_workshop/monitor_buttons.php`
## User Flow
@ -26,7 +28,7 @@ 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's existing `exec` primitive, and shows the result.
6. The Panel validates input, stores numeric Workshop IDs, writes a manifest, writes a generated per-job 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:
@ -53,17 +55,17 @@ The admin template defines capability and policy. The customer supplies only Wor
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`
5. A generated job script is written to:
- `{SERVER_HOME}/gsp_server_content/jobs/workshop/workshop_job_<timestamp>_<random>.sh`
6. The agent runs:
- `bash <script> <manifest>`
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.
7. The script writes a temporary SteamCMD runscript containing `workshop_download_item <appid> <workshop_id> validate`.
8. The script runs SteamCMD with `+runscript`, 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:
- The default script filename is no longer treated as an agent-host path.
- Missing custom scripts fall back to the bundled generic handler and log a warning.
- Static custom Workshop scripts are deprecated for the primary path; the Panel generates a per-job script instead.
- 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.

53
docs/features/WORKSHOP_SYSTEM.md
View file

@ -1,5 +1,7 @@
# Workshop System
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Current State
The current Workshop/content work is split across two module lines:
@ -24,8 +26,9 @@ Important files:
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.
- Panel generates a per-job shell script under the server home.
- The generated job script writes a temporary SteamCMD runscript and runs `steamcmd +runscript <scriptfile>`.
- Panel invokes the job script 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.
@ -42,19 +45,29 @@ 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:
The Panel writes a generated per-job 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`
- `{SERVER_HOME}/gsp_server_content/jobs/workshop/workshop_job_<timestamp>_<random>.sh`
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.
The agent executes the generated 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:
Script/job 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.
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.
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.
The generated job script uses this SteamCMD runscript pattern:
```text
@ShutdownOnFailedCommand 0
@NoPromptForPassword 1
force_install_dir <server_root>
login anonymous
workshop_download_item <workshop_app_id> <workshop_id> validate
quit
```
The manifest includes:
@ -200,7 +213,7 @@ 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 stages the bundled handler under `gsp_server_content/scripts/workshop/`. |
| `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. |
| 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. |
@ -219,16 +232,22 @@ Use `addonsmanager` as the main future home for:
Treat `steam_workshop` as a legacy bridge for migration only.
## References Reviewed
- `reference/Module-Steam_Workshop` is the local legacy OGP module. It confirms that the Panel historically owned Workshop state/configuration and used the agent for execution.
- The uploaded `steam-workshop-downloader` reference was not present in this workspace, but its reviewed behavior is reflected in the active design: generate a SteamCMD runscript, call `workshop_download_item <appid> <workshop_id> validate`, copy or link the downloaded `steamapps/workshop/content/<appid>/<workshop_id>` folder into the server's mod location, optionally lowercase files for Linux, copy Arma/DayZ keys, and generate future `-mod=` data from installed items.
## Panel-Agent Contract
Phase 1 does not use the legacy `steam_workshop` XML-RPC method for the primary user workflow. Instead:
1. Panel parses customer input into numeric Workshop IDs.
2. Panel writes `{SERVER_HOME}/gsp_server_content/workshop_manifest.json`.
3. Panel stages the OS-appropriate bundled handler under `{SERVER_HOME}/gsp_server_content/scripts/workshop/`.
4. Panel invokes the handler through the existing authenticated agent `exec` RPC.
5. The handler writes `workshop_install.log` or `workshop_install_windows.log` under `gsp_server_content`.
6. Panel updates `server_content_workshop.install_state` from queued/installing to installed/failed/removed.
3. Panel writes a generated per-job script under `{SERVER_HOME}/gsp_server_content/jobs/workshop/`.
4. The job script writes a temporary SteamCMD runscript.
5. Panel invokes the job script through the existing authenticated agent `exec` RPC.
6. The job writes `workshop_install.log` or `workshop_install_windows.log` under `gsp_server_content`.
7. Panel updates `server_content_workshop.install_state` from queued/installing to installed/failed/removed.
Important manifest fields:
@ -245,7 +264,7 @@ Important manifest fields:
- `extra.copy_keys`
- `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.
Generated Workshop jobs validate numeric item IDs, keep writes under the server home, use SteamCMD through a temporary runscript, copy files into the resolved target path, and copy `.bikey` files for DayZ/Arma strategies when enabled.
Bundled handler actions:

4
docs/features/XML_SYSTEM.md
View file

@ -1,5 +1,7 @@
# XML Game Configuration System
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Purpose
The XML game configuration system describes how a game server should be started, queried, and customized.
@ -94,7 +96,7 @@ 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.
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.
Example: