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/decisions/0001-screen-vs-tmux.md
View file

@ -1,5 +1,7 @@
# Decision 0001: Keep `screen` As The Shared Backend
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Status
Accepted

2
docs/decisions/0002-status-detection.md
View file

@ -1,5 +1,7 @@
# Decision 0002: Agent-Truthed Status Detection
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Status
Accepted

2
docs/decisions/0003-companion-programs.md
View file

@ -1,5 +1,7 @@
# Decision 0003: First-Class Companion Programs
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Status
Accepted

12
docs/decisions/0004-workshop-system.md
View file

@ -1,5 +1,7 @@
# Decision 0004: Server Content Manager Is The Workshop Layer
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Status
Accepted, Panel-side orchestration active
@ -10,7 +12,7 @@ Accepted, Panel-side orchestration 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.
The current implementation keeps Workshop business logic in the Panel. Agents are generic executors: the Panel writes manifests, writes generated per-job 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
@ -32,10 +34,10 @@ The current implementation keeps Workshop business logic in the Panel. Agents ar
- 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.
- A generated Linux/Cygwin-compatible job script is written under `gsp_server_content/jobs/workshop/` before execution.
- The generated job script creates a temporary SteamCMD runscript and runs SteamCMD with `+runscript`.
- Default script names are not treated as existing agent paths.
- Static custom Workshop scripts are deprecated for the primary path and logged if encountered.
- 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`.

2
docs/decisions/0005-control-path-layout.md
View file

@ -1,5 +1,7 @@
# Decision 0005: Keep Managed Control Paths Outside Customer-Easy Edit Paths
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Status
Accepted

2
docs/decisions/0006-installers.md
View file

@ -1,5 +1,7 @@
# Decision 0006: Installers Must Be Game-Capability Driven
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Status
Accepted

2
docs/decisions/COMPANION_PROGRAMS_DESIGN.md
View file

@ -1,5 +1,7 @@
# Companion Programs Design Investigation
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
This is an investigation-only design report for adding first-class companion/sidecar application support to GSP game servers. No implementation is included here.
Repository layout reviewed:

2
docs/decisions/README.md
View file

@ -1,5 +1,7 @@
# Decisions
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
This folder holds permanent architecture decisions and a small set of preserved investigation reports that informed those decisions.
## Decision Records

2
docs/decisions/SCHEDULER_ACTIONS_DESIGN.md
View file

@ -1,5 +1,7 @@
# GSP Scheduler Actions Design
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Scope
This is an investigation and design report only. It does not implement code.

29
docs/decisions/STEAM_WORKSHOP_DESIGN.md
View file

@ -1,5 +1,7 @@
# GSP Steam Workshop and Server Content Design
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Scope
This document is an investigation and design report only. It does not implement code.
@ -43,8 +45,8 @@ What exists:
- Workshop IDs are validated as numeric strings.
- A `server_content_workshop` table is created/migrated by helper code.
- A remote manifest is written under the game server home.
- Bundled generic Linux and Cygwin/Windows scripts are copied to the agent and executed.
- The current scripts can call SteamCMD with `+workshop_download_item`.
- Panel-owned Linux and Cygwin/Windows templates are used to generate per-job scripts under the server home.
- The generated job script creates a temporary SteamCMD runscript and calls SteamCMD with `+runscript`.
- Basic install, update, update selected, update all, and remove selected actions exist.
- Actions are logged through the panel logger and the script writes a text log under `gsp_server_content`.
@ -74,18 +76,20 @@ The current user flow is:
3. Panel inserts or updates rows in `server_content_workshop`.
4. Panel writes a manifest to:
- `{GAME_HOME}/gsp_server_content/workshop_manifest.json`
5. Panel copies a bundled script to:
- `{GAME_HOME}/gsp_server_content/scripts/workshop/generic_steam_workshop_linux.sh`
- or `{GAME_HOME}/gsp_server_content/scripts/workshop/generic_steam_workshop_windows_cygwin.sh`
5. Panel writes a generated job script to:
- `{GAME_HOME}/gsp_server_content/jobs/workshop/workshop_job_<timestamp>_<random>.sh`
6. Panel executes:
- `bash <script_path> <manifest_path>`
7. The script uses SteamCMD:
- `+force_install_dir <server_root>`
- `+login anonymous`
- `+workshop_download_item <workshop_app_id> <workshop_id> validate`
8. The script copies downloaded files to a target folder, defaulting to:
7. The script writes a temporary SteamCMD runscript:
- `@ShutdownOnFailedCommand 0`
- `@NoPromptForPassword 1`
- `force_install_dir <server_root>`
- `login anonymous`
- `workshop_download_item <workshop_app_id> <workshop_id> validate`
8. The script runs SteamCMD with `+runscript <scriptfile>`.
9. The script copies downloaded files to a target folder, defaulting to:
- `{SERVER_ROOT}/@{WORKSHOP_ID}`
9. Panel updates DB row state to `installed`, `failed`, or `removed`.
10. Panel updates DB row state to `installed`, `failed`, or `removed`.
This is useful as a proof of concept, but it is not yet a commercial Workshop/mod system.
@ -121,7 +125,7 @@ The current helper also writes agent-side files under the server home:
- `gsp_server_content/workshop_install.log`
- `gsp_server_content/workshop_install_windows.log`
- `gsp_server_content/workshop/removed/*`
- `gsp_server_content/scripts/workshop/*`
- `gsp_server_content/jobs/workshop/workshop_job_*.sh`
Current DB weaknesses:
@ -1393,4 +1397,3 @@ The professional path is:
- Generate startup parameters from structured enabled/load-ordered rows.
- Treat LGSL/GameQ and game query systems as unrelated to content installation.
- Keep customers away from raw commands, helper scripts, and managed control files.