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

20
docs/modules/SERVER_CONTENT_MANAGER.md
View file

@ -1,5 +1,7 @@
# Server Content Manager
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Current State
`Panel/modules/addonsmanager` is the current home of GSP's Server Content / Add-ons / Workshop work.
@ -47,17 +49,19 @@ For Workshop items, the current flow lets users enter Workshop IDs or full Steam
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 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`.
8. Panel writes a generated per-job shell script into `{SERVER_HOME}/gsp_server_content/jobs/workshop/`.
9. The generated job script creates a temporary SteamCMD runscript containing `workshop_download_item <appid> <workshop_id> validate`.
10. Agent executes the generated script with the manifest path through the existing authenticated `exec` RPC.
11. Script runs SteamCMD with `+runscript`, 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:
Current job-script behavior:
- Admin-defined custom scripts are supported when they exist on the agent.
- Missing custom scripts fall back to the bundled generic handler and are logged.
- Default script names such as `generic_steam_workshop_windows_cygwin.sh` are copied from the Panel module source and must not be checked as bare files on the agent.
- Server Content Manager generates a new job script for each Workshop action.
- Admin-defined static Workshop script paths are deprecated and ignored by the primary path.
- Default script names such as `generic_steam_workshop_windows_cygwin.sh` must not be checked as bare files on the agent.
- Agents need only the generic `writefile` and `exec` primitives.
Current default install paths:
@ -90,7 +94,7 @@ The Panel helper parser reads this block first and only tolerates old direct tag
SteamCMD requirements:
- Linux agents need SteamCMD available at the configured profile/template path, `STEAMCMD_PATH`, `/home/gameserver/steamcmd/steamcmd.sh`, or in `PATH`.
- Windows agents currently use the existing Cygwin agent model and run the bundled Cygwin-compatible shell handler. SteamCMD may be provided as `steamcmd.exe`, `steamcmd.sh`, an explicit configured path, or via `STEAMCMD_PATH`.
- Windows agents currently use the existing Cygwin agent model and run the Panel-generated shell job. SteamCMD may be provided as `steamcmd.exe`, `steamcmd.sh`, an explicit configured path, or via `STEAMCMD_PATH`.
- Missing SteamCMD should return a clear error, not a generic script failure.
The legacy `steam_workshop` monitor button is intentionally suppressed so users are not sent to the deprecated standalone module.