Codex documentstion created

This commit is contained in:
Frank Harris 2026-06-05 11:07:47 -05:00
parent 3dc017421e
commit b5dcf01a8c
27 changed files with 6648 additions and 1069 deletions

View file

@ -0,0 +1,82 @@
# GameManager
## Role
`Panel/modules/gamemanager` is the core customer server control module. It owns:
- start
- stop
- restart
- logs
- server monitor
- update flow hooks
- RCON integration
- status display
## Important Files
- `Panel/modules/gamemanager/module.php`
- `Panel/modules/gamemanager/home_handling_functions.php`
- `Panel/modules/gamemanager/server_monitor.php`
- `Panel/modules/gamemanager/start_server.php`
- `Panel/modules/gamemanager/stop_server.php`
- `Panel/modules/gamemanager/restart_server.php`
- `Panel/modules/gamemanager/log.php`
- `Panel/modules/gamemanager/view_server_log.php`
- `Panel/modules/gamemanager/get_server_log.php`
- `Panel/modules/gamemanager/update_server.php`
## Start / Stop / Restart
The module calls the agent through `Panel/includes/lib_remote.php`.
Current shape:
- start -> `universal_start`
- stop -> `remote_stop_server`
- restart -> `remote_restart_server`
The right behavior is:
- start shows `STARTING` as soon as the managed session exists
- online status requires the process/session plus the game port
- restart should be stop, wait, start
- stop should not be treated as complete until the session/process is actually gone
## Status Reporting
The current flow now points toward agent-truth status reporting via:
- `remote_server_status`
- `get_agent_server_status` in `home_handling_functions.php`
- `server_status_without_decrypt` in both agents
Useful state labels:
- `OFFLINE`
- `STARTING`
- `ONLINE`
- `STOPPING`
- `UNRESPONSIVE`
- `UNKNOWN`
Query checks should remain optional metadata only.
## Log Viewer
Relevant files:
- `Panel/modules/gamemanager/log.php`
- `Panel/modules/gamemanager/view_server_log.php`
- `Panel/modules/gamemanager/get_server_log.php`
The log view should be treated as live, AJAX-updated output rather than a full page reload workflow.
## What This Module Depends On
- `config_games` for startup parameters and protocol definitions
- `lib_remote.php` for agent calls
- `user_games` for server home records
- `rcon` for command support where available
- `addonsmanager` for content/mod interactions

View file

@ -0,0 +1,68 @@
# Module Index
This is the current Panel module inventory. It is intentionally concise so future Codex sessions can decide which module to inspect in code.
| Module | Purpose | Current State | Dependencies | Notes |
|---|---|---|---|---|
| `TS3Admin` | Teamspeak 3 admin interface | Required, legacy niche | TS3 admin files | Keep if TS3 hosting is sold. |
| `addonsmanager` | Server Content Manager | Required, actively evolving | DB tables, game XML, agent install scripts | Best current home for mods, add-ons, Workshop, and content installs. |
| `administration` | Admin utilities | Required | Core admin pages | Includes logger/watch tools. |
| `backup-restore` | Backup/restore UI | Optional, broken/testing | Hard-coded backup host/path logic | Hide until replaced. |
| `billing` | Billing, provisioning, commerce | Optional, large custom module | Payment gateways, invoices, shop/provisioning docs | Important for commercial hosting. |
| `circular` | Notification/circular messages | Optional | Panel UI | Good candidate for maintenance and announcement notices. |
| `config_games` | Game XML definitions and CLI builder | Required | XML schema/parser | Critical for startup templates, queries, custom fields, and game capabilities. |
| `cron` | Scheduler / CRON | Required | Agent scheduler methods, Panel action selection | Needs safe action registry and task history. |
| `dashboard` | Main landing dashboard | Required | Panel auth and server summaries | Should surface status, support, billing, and alerts. |
| `dsi` | Dynamic Server Image | Optional | Game imagery and cached assets | Useful for server cards and branding. |
| `editconfigfiles` | Config file shortcuts | Optional | Game config metadata | Good for surfacing common editable files. |
| `faq` | FAQ/help | Required | Site docs/content | Should link to game docs and common workflows. |
| `fast_download` | FastDL support | Required | Source/GoldSrc-style web distribution | Still useful for older Source engine communities. |
| `ftp` | FTP admin | Required | File transfer service, access rights | Needs security review but remains important. |
| `gamemanager` | Server monitor, lifecycle, logs, RCON | Required | Agent RPC, game XML, query libraries | Core customer workflow module. |
| `lgsl_with_img_mod` | LGSL server status images | Optional legacy | Query/image cache data | Secondary to agent truth. |
| `litefm` | In-panel file manager | Required | File system access rights | Should be the preferred in-panel file tool. |
| `lostpwd` | Password recovery | Required | Auth/account flow | Basic account support. |
| `modulemanager` | Module installation/configuration | Required | Module metadata | Admin maintenance tool. |
| `mysql` | MySQL hosting/admin | Required | MySQL service setup | Good future product tie-in for databases. |
| `news` | Legacy news/announcements | Optional legacy | Old CMS-like data | Consider hiding unless modernized. |
| `rcon` | RCON admin tool | Required | Server protocol support | Useful for commands, warnings, and scheduler integration. |
| `register` | Account registration | Required | Auth flow | Basic customer onboarding. |
| `server` | Server manager | Required | Agent/node management | Admin-facing node controls. |
| `settings` | Global settings | Required | Auth, site config | Admin configuration area. |
| `status` | Status page | Optional alpha | Status data | Not ready for customer-facing critical use. |
| `steam_workshop` | Legacy Workshop module | Optional deprecated | Workshop DB helpers | Hidden/deprecated in favor of `addonsmanager`. |
| `subusers` | Subuser permissions | Required | Authorization model | Important for commercial teams and communities. |
| `support` | Support landing page | Required | Ticketing/docs | Better as an entry point than the full ticket workflow. |
| `teamspeak3` | Teamspeak 3 web interface | Required if sold | TS3 service | Hide if not part of the product offering. |
| `tickets` | Support ticket system | Optional but useful | DB tables, attachments, notifications | Stronger support workflow than `support` alone. |
| `tshock` | Terraria/TShock utilities | Optional niche | Terraria/TShock game support | Expose only for supported games. |
| `update` | Panel updates | Required admin tool | Patch/update system | Admin-only maintenance. |
| `user_admin` | User management | Required | Auth/admin roles | Important for staff administration. |
| `user_games` | Server provisioning and assignment | Required | Game homes, ports, billing integration | Core provisioning path. |
| `util` | Utility tools | Required | Misc tools | Keep useful tools, hide legacy helpers that are not maintained. |
## Dependency Notes
Common dependencies across many modules:
- `includes/lib_remote.php`
- auth/session and role checks
- `config_games` XML parsing
- DB access helpers
- server home and IP/port records
## High-Value Modules
The modules most likely to matter in future investigations are:
1. `gamemanager`
2. `config_games`
3. `user_games`
4. `addonsmanager`
5. `cron`
6. `litefm`
7. `ftp`
8. `billing`
9. `tickets`
10. `subusers`

96
docs/modules/SCHEDULER.md Normal file
View file

@ -0,0 +1,96 @@
# Scheduler
## Current Implementation
The scheduler lives in the `cron` module on the Panel and in scheduler methods inside the agents.
Important files:
- `Panel/modules/cron/module.php`
- `Panel/modules/cron/cron.php`
- `Panel/modules/cron/shared_cron_functions.php`
- `Agent_Linux/ogp_agent.pl`
- `Agent-Windows/ogp_agent.pl`
## How It Works Today
The Panel builds cron-like jobs and sends them to the agent using RPC methods such as:
- `scheduler_add_task`
- `scheduler_edit_task`
- `scheduler_del_task`
- `scheduler_list_tasks`
- `scheduler_read_tasks`
The agent stores and executes the tasks locally.
## Current Task Model
Current jobs are built as cron expressions plus a command string.
The command can be:
- a safe predefined server action
- an update-related action
- a server content action
- a raw admin command
## Scheduled Actions Observed
From the current codebase and related Server Content work, the action set includes:
- restart server
- stop server
- start server
- Steam auto update
- server content update checks
- server content install/update actions
- validate files
- backup before update
- notify-only update flow
## Problems With the Current Design
- The task model is not strongly typed.
- Customer-safe and admin-only actions are too easy to blur together.
- Task output and run history are not user-friendly enough.
- The agent is the executor, but the Panel needs a better task record and result view.
- Overlap/conflict rules are not explicit.
- Missed-task behavior after reboot should be documented and normalized.
## Recommended Next-Step Shape
Use typed actions instead of raw command strings for customer-facing scheduler tasks.
Suggested fields:
- action key
- display name
- role
- arguments
- timeout
- retry behavior
- conflict rules
- log policy
## Agent Interaction Pattern
```text
Panel schedules task
-> Panel stores intent and UI data
-> Panel sends job to agent
-> agent writes/loads scheduler state
-> agent executes action at the right time
-> agent logs result
-> Panel reads back task state
```
## What To Inspect in Code
If scheduler behavior needs deeper investigation, start with:
- `Panel/modules/cron/cron.php`
- `Panel/modules/cron/shared_cron_functions.php`
- `Agent_Linux/ogp_agent.pl` scheduler subroutines
- `Agent-Windows/ogp_agent.pl` scheduler subroutines

View file

@ -0,0 +1,70 @@
# Server Content Manager
## Current State
`Panel/modules/addonsmanager` is the current home of GSP's Server Content / Add-ons / Workshop work.
The module title has already been moved toward `Server Content Manager`, but the schema and some folder names remain backward-compatible.
Important files:
- `Panel/modules/addonsmanager/module.php`
- `Panel/modules/addonsmanager/addons_manager.php`
- `Panel/modules/addonsmanager/user_addons.php`
- `Panel/modules/addonsmanager/workshop_content.php`
- `Panel/modules/addonsmanager/workshop_action.php`
- `Panel/modules/addonsmanager/server_content_helpers.php`
- `Panel/modules/addonsmanager/server_content_categories.php`
## Database Tables
Known tables used by the module:
- `addons`
- `server_content_workshop`
- `server_content_manifest`
- `server_content_install_history`
## What It Already Does
The module can already represent several content types, including:
- downloads/extracted packages
- post-script driven installs
- workshop-oriented items
- config packs
- future profile-type content
For Workshop items, the current flow lets users enter IDs and routes the install through module pages and agent-side scripts.
## Current Limitations
- Workshop and content metadata is still partial.
- Load order and enable/disable behavior need a cleaner first-class model.
- Async install job progress should be more visible.
- Install strategies are still being broadened and need consistent game-specific rules.
- DayZ/Arma style key-copy and startup-param behavior needs a stronger canonical implementation.
- Cache and cleanup policy need a clearer product design.
## Where To Start Reading
1. `Panel/modules/addonsmanager/module.php`
2. `Panel/modules/addonsmanager/addons_manager.php`
3. `Panel/modules/addonsmanager/user_addons.php`
4. `Panel/modules/addonsmanager/workshop_content.php`
5. `Panel/modules/addonsmanager/workshop_action.php`
## Important Concept
This module is the right place for:
- mods
- add-ons
- Workshop content
- config packs
- script-driven installs
- server content manifests
- install history
The old `steam_workshop` module should be treated as a deprecated compatibility layer, not the main future path.