2.9 KiB
Windows Agent Update BAT
Workspace reference: GSP-WORKSPACE.md
Purpose
Update-Agent.bat updates the Git-managed GSP Windows Agent repository, stops the agent first, and starts it again after the update.
It is intentionally small and local:
- no Task Scheduler changes
- no installer execution
- no customer data cleanup
- no deletion of game server folders, configs, logs, or Workshop data
File location
Place Update-Agent.bat in the repository root:
- example checkout:
C:\GSP\windows-agent\Update-Agent.bat
The current repository layout expects the managed start and stop launchers here:
OGP64\agent_start.batOGP64\agent_stop.bat
If those are missing, the updater tries the obvious fallback launchers:
OGP64\OGP\Install\agent_start.batOGP64\OGP\Install\agent_stop.bat
How to run it
- Right-click
Update-Agent.bat. - Choose
Run as Administrator. - Review the console output.
- Press a key at the end so the window closes only after you read the result.
How it works
The script:
- verifies Administrator privileges
- verifies the agent repository path
- verifies
.gitexists - verifies
gitis available - stops the agent with the existing stop BAT if available
- runs
git fetch origin - runs
git reset --hard origin/unstable - starts the agent with the existing start BAT if available
- pauses so the operator can read any errors
Editable variables
At the top of Update-Agent.bat:
AGENT_DIRBRANCHSTART_BATSTOP_BAT
Default branch:
unstable
Changing branch
Edit:
set "BRANCH=unstable"
to another remote branch name if needed.
The script resets to:
origin/%BRANCH%
Relationship to start and stop BAT files
Update-Agent.bat does not replace the existing launchers.
It reuses:
OGP64\agent_stop.batOGP64\agent_start.bat
That keeps update behavior aligned with the normal manual agent lifecycle.
Task Scheduler note
This task does not modify Task Scheduler.
The agent can still be configured separately to start at boot through Task Scheduler. Update-Agent.bat is a manual administrative update helper, not a scheduled task installer.
What should stay outside the Git-managed directory
Do not place customer-owned runtime data inside the Git checkout if you want updates to remain low-risk.
Keep these outside the Git-managed repository when possible:
- hosted game server folders
- save files
- customer uploads
- customer scripts
- customer configs
- logs you want preserved independently of code updates
The repository should contain the Windows agent code and bundled runtime files, not mutable customer data.
Assumptions
- The Git checkout root is the correct update boundary.
- The active branch should be
unstableby default. - The existing root launchers under
OGP64\are the preferred lifecycle scripts.