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

no idea

Browse source
This commit is contained in:
Frank Harris 2026-06-11 15:18:01 -05:00
parent 3d7aa64db6
commit f7d4c3e11b
8 changed files with 310 additions and 121 deletions
Download patch file Download diff file Expand all files Collapse all files

8
docs/agents/LINUX_AGENT.md
View file

@ -83,7 +83,7 @@ The agent reads screen logs and may also copy a local log file into the game hom
## Workshop / Server Content
The primary Workshop workflow is owned by the Panel `addonsmanager`, not the legacy `steam_workshop` RPC. For Linux servers the Panel:
The current customer-facing Workshop workflow is the dedicated Panel `steam_workshop` module. The older `steam_workshop` XML-RPC method is still used by that module for compatibility. For Linux servers the Panel:
1. writes `gsp_server_content/workshop_manifest.json` under the server home
2. writes a generated per-job shell script under `gsp_server_content/jobs/workshop/`
@ -92,7 +92,11 @@ The primary Workshop workflow is owned by the Panel `addonsmanager`, not the leg
The generated job uses Python and SteamCMD, validates numeric Workshop IDs, keeps writes under the server home, logs to `gsp_server_content/workshop_install.log`, and supports DayZ/Arma-style `@mod` folders plus `.bikey` copying. The Linux agent does not need a permanent `generic_steam_workshop_linux.sh` file on disk.
The older `steam_workshop` XML-RPC method remains for legacy compatibility only and should not be treated as the primary customer workflow.
For legacy `steam_workshop` RPC installs:
- blank `config_file_path` means no config-file editing
- the generated post-install script still runs
- `WorkshopModsInfo` is still written so uninstall can work without parsing a game config file
## Scheduler

8
docs/agents/WINDOWS_AGENT.md
View file

@ -163,7 +163,7 @@ Windows/Cygwin logs come from screen logs and/or local copies. Log retrieval sho
## Workshop / Server Content
The primary Workshop workflow is owned by the Panel `addonsmanager`, not the legacy `steam_workshop` RPC. For Windows/Cygwin servers the Panel:
The current customer-facing Workshop workflow is the dedicated Panel `steam_workshop` module. The older `steam_workshop` XML-RPC method is still used by that module for compatibility. For Windows/Cygwin servers the Panel:
1. writes `gsp_server_content/workshop_manifest.json` under the server home
2. writes a generated per-job shell script under `gsp_server_content/jobs/workshop/`
@ -172,7 +172,11 @@ The primary Workshop workflow is owned by the Panel `addonsmanager`, not the leg
The generated job uses Python and SteamCMD, validates numeric Workshop IDs, keeps writes under the server home, logs to `gsp_server_content/workshop_install_windows.log`, and supports DayZ/Arma-style `@mod` folders plus `.bikey` copying. The Windows agent does not need a permanent `generic_steam_workshop_windows_cygwin.sh` file on disk.
The older `steam_workshop` XML-RPC method remains for legacy compatibility only and should not be treated as the primary customer workflow.
For legacy `steam_workshop` RPC installs:
- blank `config_file_path` means no config-file editing
- the generated post-install script still runs
- `WorkshopModsInfo` is still written so uninstall can work without parsing a game config file
## Scheduler