For dedicated-server operators
GSP keeps remote hosts as first-class operating units. The panel can list agent snapshots, update status, assigned game servers, and per-agent operations instead of treating every server as local.
Why GSP
A practical path for operators who know the OGP model and need current maintenance.
GSP keeps the architecture hosting teams understand while documenting where the fork is evolving: agents, XML validation, Workshop workflows, installer baselines, and commercial-site integration points.
For hosting businesses
The codebase includes website, register, billing, support, and tickets modules. The first public website should present those as integration foundations until provider details are fully audited.
For Workshop-heavy games
The local docs confirm a dedicated Workshop module, admin profile management, item lookup, and schema-level `workshop_support` blocks in game templates.
For OGP migrations
GSP is explicit about being a fork. Existing OGP concepts remain familiar, while new installs and current docs should follow GSP-specific behavior where it diverges.
What changes from inherited assumptions?
The fork notes identify confirmed differences and areas still under review, so migrations can separate stable architecture from current GSP behavior.
Confirmed
Dedicated Steam Workshop module, Workshop XML support, XML validation tooling, current install guidance, and `gsp_` database prefix guidance.
Under review
Exact compatibility behavior for older XML tags and module-by-module differences from upstream OGP remain documented TODOs.
Migration posture
Use the GSP wiki and source as the current authority, with upstream OGP material only where it still matches active behavior.