# GSP Windows Agent Panel Integration

Workspace reference: [`GSP-WORKSPACE.md`](../../GSP-WORKSPACE.md)

The Panel is authoritative. The Windows agent executes the work the Panel requests.

## Integration points

- shared key and RPC configuration live in `OGP64/OGP/Cfg/Config.pm`
- startup preferences live in `OGP64/OGP/Cfg/bash_prefs.cfg`
- the Panel talks to the same command surface as the Linux agent wherever practical
- game server readiness is reported through the existing `server_status` RPC, extended with expected/listening/missing port details

## Compatibility rule

The Windows agent should mirror the Linux agent behaviorally as much as possible so the Panel can treat both platforms as one product family.

## Legacy Workshop RPC

The dedicated Panel `steam_workshop` module still uses the legacy `steam_workshop` XML-RPC call.

Current compatibility rule:

- if the Panel sends a blank `config_file_path`, the Windows agent runs post-install logic only
- the generated script must skip all `cat` / regex / config-write logic in that case
- `WorkshopModsInfo` is still written so the Panel can list/uninstall installed items even when no game config file is edited
- new installs write per-home records under `WorkshopModsInfo/home_<home_id>/`
- each record stores mod string, Workshop item ID, title, installed folder/path, Workshop App ID, install status, and timestamps
- the generated job writes `<game_home>/WorkshopInstallStatus.json` as `running`, `completed`, or `failed`
- the generated job prints `GSP_WORKSHOP_INSTALL_COMPLETE` or `GSP_WORKSHOP_INSTALL_FAILED` so the Panel can avoid stale `Update in progress` displays if the generic update screen lingers

## Status validation

The Panel remains the source of truth for assigned ports. The Windows agent validates only the ports supplied by the Panel for a specific server.

Detailed design:

- [`GSP_WINDOWS_AGENT_PORT_VALIDATION.md`](GSP_WINDOWS_AGENT_PORT_VALIDATION.md)