today change

This commit is contained in:
Frank Harris 2025-11-30 09:21:45 -05:00
parent e1d91dcf47
commit 3de1526408
4 changed files with 873 additions and 20 deletions

View file

@ -1,22 +1,30 @@
# OGP-AdminLTE
AdminLTE Theme adapted for OpenGamePanel
# GSP Windows Agent
### Features
- [x] Installs a Theme Database for User specific Theme Settings
- [x] Responsive
- [x] Dark and Light Mode Switcher
- [x] Custom Dashboard with additional Rows (all Boxes are movable!)
- [x] Custom Server Overview (with Chart & Cronjob)
- [x] Custom FTP Style
- [x] Custom Shop Style
- [x] User specific Avatars (will also load other User Avatars if needed)
- [x] Maintenance Notification on Login Screen
- [x] Custom Logo Upload
Cygwin-based agent that lets the GameServer Panel manage Windows Server 2019/2022 hosts. It mirrors the Linux agent feature set: signed RPC transport, GNU Screen session management, and SteamCMD-aware installers.
### Images
![This is an image](../main/adminlte_dark.png)
![This is an image](../main/adminlte_light.png)
![This is an image](../main/adminlte_online-servers.png)
![This is an image](../main/adminlte_shop.png)
![This is an image](../main/adminlte_maintenance.png)
![This is an image](../main/adminlte_support_chat.png)
## Highlights
- One-click installer (`Install/onceinstall_agent.bat`) that bootstraps Cygwin, required packages, and the `gameserver` service account.
- Task Scheduler entry that keeps the agent running after reboots.
- Helper scripts (`agent_conf.sh`, `rebase_post_ins.bat`, etc.) for maintaining the environment.
- Markdown documentation under [`documentation/agent-guide.md`](documentation/agent-guide.md).
## Quick start
1. Clone or download the repository to `C:\\gsp-agent`.
2. Right-click `Install\\onceinstall_agent.bat` → “Run as administrator”.
3. Open the bundled Cygwin terminal and configure the agent:
```bash
cd /OGP
bash agent_conf.sh -p "gameserverPassword"
```
4. Edit `C:\\OGP\\Cfg\\Config.pm` (match the settings you entered in the GSP web panel) and start the “OGP agent start on boot” scheduled task.
## Related repositories
- [GSP](https://github.com/GameServerPanel/GSP) PHP panel that issues commands to the agents.
- [GSP_Agent_Linux](https://github.com/GameServerPanel/GSP_Agent_Linux) Linux counterpart with systemd service files.
## Contributing
Send pull requests through GitHub. Test installer changes on a clean Windows Server VM, keep batch files in ASCII, and update `documentation/agent-guide.md` whenever you modify the workflow.

View file

@ -0,0 +1,151 @@
# GameServer Panel Admin Guide
This document mirrors the internal WDS wiki entry so it can be viewed directly from the repository, packaged with releases, or imported into another wiki. It explains how we deploy, operate, and extend the GameServer Panel (GSP) fork of Open Game Panel.
## Overview
- **Project scope** PHP web panel + billing, Linux and Windows agents, 100+ XML driven game templates.
- **Audience** Administrators and integrators who maintain commercial hosting fleets.
- **Companion repos** [`GSP_Agent_Linux`](https://github.com/GameServerPanel/GSP_Agent_Linux) and [`GSP-Agent-Windows`](https://github.com/GameServerPanel/GSP-Agent-Windows).
- **Color coding** We keep the “rust + charcoal” palette across documentation so screenshots match the UX.
## Quick Install (deploy_gsp.sh)
The repository ships `deploy_gsp.sh`, a bash helper that stages the latest commit and syncs it to your web root. Always read the script before running it and override variables via the environment when necessary.
```bash
curl -fsSL https://raw.githubusercontent.com/GameServerPanel/GSP/main/deploy_gsp.sh \
-o /tmp/deploy_gsp.sh
bash /tmp/deploy_gsp.sh
```
Key behaviors:
1. Clones/updates the repo in `~/gsp_stage` (configurable via `STAGE_DIR`).
2. Uses `rsync` to copy files to `WEB_ROOT` while preserving `includes/config.inc.php` and billing configs.
3. Applies safe permissions (directories 755, files 644, writable directories such as `templates_c` set to 2775).
4. Leaves MySQL credentials untouched—only you should rotate them.
## Architecture
GSP is still built around the classic OGP topology:
1. **Web Panel** PHP application with billing, coupons, invoicing, and customer UI enhancements.
2. **Agents** Lightweight Perl daemons (`ogp_agent.pl`) installed on every game host. Default port 12679/TCP.
3. **Game Servers** Processes defined in `modules/config_games/server_configs/*.xml`. Agents launch them inside detached GNU screen sessions, capture PIDs, and stream console logs back to the panel.
All provisioning logic flows through XML definition files, so keep IDs, attributes, and order compliant with `modules/config_games/schema_server_config.xml`.
## Agent Management
### Linux Agent
1. Install dependencies: `sudo apt install git curl rsync perl libxml2-utils screen` (Ubuntu 24.04+).
2. Clone and install:
```bash
sudo git clone https://github.com/GameServerPanel/GSP_Agent_Linux.git /opt/gsp-agent
cd /opt/gsp-agent
sudo bash install.sh
sudo bash agent_conf.sh -s "yourRootPassword" -u ogp_agent
```
3. Edit `/home/ogp_agent/Cfg/Config.pm` to match the panel entry (listen ip/port, `key`, `web_api_url`).
4. Enable the service: `sudo systemctl enable --now ogp_agent` (installs from `systemd/ogp_agent.service`).
5. Confirm heartbeats from the panel → Administration → Game Servers.
### Windows Agent (Cygwin bundle)
1. `git clone https://github.com/GameServerPanel/GSP-Agent-Windows.git C:\\gsp-agent`.
2. Run `Install\onceinstall_agent.bat` as Administrator to install Cygwin, create the `gameserver` service user, and copy files.
3. Launch the bundled Cygwin terminal and execute:
```bash
cd /OGP
bash agent_conf.sh -p "gameserverPassword"
```
4. Update `C:\\OGP\\Cfg\\Config.pm` (same structure as Linux) with the panels key, API URL, and listen port.
5. Ensure the “OGP Agent” Windows service is set to Automatic (Delayed Start) and the firewall allows the agent port plus expected game ports.
## XML Deep Dive
Game definitions live under `modules/config_games/server_configs`. They must respect the schema order and content. Keep one tag per line so diffs remain clean.
```xml
<?xml version="1.0" encoding="UTF-8"?>
<game_config>
<game_key>valheim_linux64</game_key>
<protocol>lgsl</protocol>
<lgsl_query_name>valheim</lgsl_query_name>
<installer>steamcmd</installer>
<game_name>Valheim</game_name>
<server_exec_name>start_server.sh</server_exec_name>
<query_port type="add">1</query_port>
<cli_template>%HOME_PATH%/start_server.sh -name "%HOSTNAME%" -port %PORT% -world %MAP% %VAR_ALL%</cli_template>
<cli_params>
<cli_param id="HOSTNAME" cli_string="-name=" options="q" />
<cli_param id="PORT" cli_string="-port=" options="sq" />
<cli_param id="MAP" cli_string="-world=" options="q" />
</cli_params>
<reserve_ports>
<port type="add" id="QUERY_PORT">1</port>
<port type="add" id="RCON_PORT" cli_string="+rcon.port" options="sq">10</port>
</reserve_ports>
<cli_allow_chars>:-_\</cli_allow_chars>
<maps_location>saves/worlds</maps_location>
<max_user_amount>10</max_user_amount>
<control_protocol>rcon2</control_protocol>
<mods>
<mod key="default">
<name>Dedicated</name>
<installer_name>896660</installer_name>
</mod>
</mods>
<server_params>
<param key="+server.identity" type="text" id="IDENTITY">
<default>my_server_identity</default>
<desc>Sets the Rust identity folder.</desc>
</param>
</server_params>
<commands>
<command>
<name>Start</name>
<execute>./RustDedicated -port {PORT} -ip {IP} {VAR_ALL}</execute>
</command>
</commands>
<environment_variables>
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:{OGP_HOME_DIR}/RustDedicated_Data/Plugins/x86_64
</environment_variables>
</game_config>
```
### Schema Tag Reference (abridged)
The full human-readable version is provided in [`documentation/xml-notes.md`](./xml-notes.md). Highlights:
- `game_config` Root node, one per file.
- `game_key` Unique identifier plus OS suffix (`_linux64`, `_win32`, etc.).
- `protocol`, `lgsl_query_name`, `gameq_query_name` Control how the panel queries live status.
- `installer` `steamcmd`, `rsync`, `manual`, or custom.
- `cli_template` Command string appended after the executable; supports `%VARIABLE%` placeholders and `{VAR_ALL}` macros.
- `cli_param` Defines formatting rules for each variable (space/quote behaviors via the `options` attribute).
- `reserve_ports` Offsets additional ports relative to `%PORT%` (query, Steam, RCON, etc.).
- `server_params` / `param` Form inputs shown in the panel UI.
- `replace_texts` Declarative config edits (search/replace values inside cfg files).
- `commands` Start/stop/console actions executed by the agent.
- `environment_variables` Prepend exports before the command runs.
## Adding a New Game
1. **Research** Identify the executable, required CLI flags, optional parameters, config paths, and ports.
2. **Copy a template** Duplicate a similar XML file from `server_configs/` and modify it in-place.
3. **Wire up parameters** Use `server_params` for every knob you want exposed, and map those IDs inside `cli_params`.
4. **Validate** Run `xmllint --schema modules/config_games/schema_server_config.xml mygame.xml --noout`.
5. **Test** Upload through the panel, click “Update Games List,” provision a server, and watch `ogp_agent.log` for errors.
6. **Document** Update this guide or the wiki with any quirks, Steam app IDs, or non-standard install notes.
## Operational Notes
- **No panelStart wrapper** The agent handles PID tracking, console logs, and restart logic. Keep commands clean.
- **Logging** Agents write `ogp_agent.log`, `ogp_agent.pid`, `ogp_agent_run.pid`, and individual `console.log` files.
- **Stats database** Optional MySQL credentials in `Cfg/Config.pm` feed resource monitoring cron jobs.
- **Password rotation** Update credentials in `content/staff-passwords.txt` on the WDS website and regenerate secrets in the panel/agents at the same time.
For deeper schema commentary, consult [`documentation/xml-notes.md`](./xml-notes.md) or import the Markdown into your preferred wiki.

View file

@ -0,0 +1,72 @@
# Linux Agent Operations Guide
Packaged copy of the instructions we keep in the staff wiki so you can view them offline or import them into any other knowledge base.
## Purpose
The Linux agent (`ogp_agent.pl`) exposes the RPC endpoint that allows the GameServer Panel to install, start, stop, and monitor game servers on Linux hosts. Every host that runs customer games must run this service.
## Supported platforms
- Ubuntu 20.04/22.04/24.04 LTS
- Debian 11/12
- Rocky/AlmaLinux 8+
- Any modern distribution with Perl 5.30+, GNU Screen, and rsync
## Installation (Ubuntu example)
```bash
sudo apt update
sudo apt install -y git curl rsync screen perl libxml-parser-perl libpath-class-perl libarchive-zip-perl libhttp-daemon-perl
sudo git clone https://github.com/GameServerPanel/GSP_Agent_Linux.git /opt/gsp-agent
cd /opt/gsp-agent
sudo bash install.sh
sudo bash agent_conf.sh -s "root-password" -u ogp_agent
```
`agent_conf.sh` writes `/home/ogp_agent/Cfg/Config.pm`. Set:
| Key | Description |
| --- | ----------- |
| `listen_ip` | Interface to bind (use `0.0.0.0` unless you want to restrict access). |
| `listen_port` | TCP port exposed to the panel. Default is `12679`. |
| `key` | Shared secret copied from the panel → Administration → Game Servers. |
| `web_api_url` | HTTPS URL to `ogp_api.php` on the panel. |
| `stats_db_*` | Optional MySQL credentials for the resource stats cron. |
## Service management
```bash
sudo cp systemd/ogp_agent.service /etc/systemd/system/
sudo sed -i "s#{OGP_AGENT_PATH}#/opt/gsp-agent#g" /etc/systemd/system/ogp_agent.service
sudo systemctl daemon-reload
sudo systemctl enable --now ogp_agent
```
Logs live next to the binaries (`/opt/gsp-agent/ogp_agent.log`). Individual game servers stream to their own `console.log` files inside each home folder.
## Firewall checklist
1. Allow inbound TCP on the agent port.
2. Allow inbound/outbound UDP/TCP for the games you host.
3. Allow outbound HTTPS to the panel so the agent can talk to `ogp_api.php`.
## Upgrades
1. `cd /opt/gsp-agent && git pull`
2. Stop the service (`sudo systemctl stop ogp_agent`).
3. Re-run `bash install.sh` if new files were added.
4. Start the service (`sudo systemctl start ogp_agent`).
5. Verify the panel shows the agent as “online”.
## Troubleshooting
- `tail -f ogp_agent.log` handshake failures usually mean the encryption key or port mismatches the panel entry.
- `journalctl -u ogp_agent` capture Perl stack traces and missing dependency errors.
- `screen -ls` confirm customer servers are running in screen sessions.
- `nc -vz panel.example.com 12679` from the panel host ensures the agent port is reachable.
## Related docs
- [`GSP/documentation/admin-guide.md`](https://github.com/GameServerPanel/GSP/tree/main/documentation) Panel-side instructions plus XML authoring notes.
- [`GSP-Agent-Windows/documentation/agent-guide.md`](https://github.com/GameServerPanel/GSP-Agent-Windows/tree/main/documentation/agent-guide.md) Windows counterpart.

622
documentation/xml-notes.md Normal file
View file

@ -0,0 +1,622 @@
## GameServer Panel XML Notes / still W.I.P.
_The order of each XML element matters, and this guide presents them in their order of appearance for the GSP (OGP fork)!_
___
### Linux and Windows:
#### Game Config:
This is the first element. There can only be one `<game_config>` element.
```
<game_config>
the whole XML file content here
</game_config>
```
All the following elements should be contained within `<game_config>` element.
___
#### Game Key:
Comes after `<game_config>` element (actually within `<game_config>` element as said above). There can only be one `<game_key>` element. Example:
```
<game_key>space_engineers_win64</game_key>
```
This is a unique key used to identify this specific game server in OGP. You should not use spaces, nor any special character in it, only alpha-numeric value and underscores. It should contain a suffix related to the compatible OS. Available suffixes are `_win32`, `_win64`, `_linux32`, `_linux64`, using one of these suffixes in the game_key will let OGP know which OS it is available on, making it visible or not when you install a new game server, depending on your OS architecture. `_win` and `_linux` work too, but we highly recommend to now use the previously listed suffixes.
___
#### Query Protocol:
Comes after `<game_key>` element. There can only be one `<protocol>` element. Example:
```
<protocol>lgsl</protocol>
```
It defines the query protocol used by OGP. Available protocols are `lgsl`, `gameq`, `rcon` (`rcon2`? `lcon`?)
___
#### LGSL Query Name:
Comes after `<protocol>` element. There can only be one `<lgsl_query_name>` element. Example:
```
<lgsl_query_name>killingfloor2</lgsl_query_name>
```
This is the unique key referencing this specific game server in the LGSL protocol file, used to query the game server.
___
#### GameQ Query Name:
Comes after `<protocol>` element. There can only be one `<gameq_query_name>` element. Example:
```
<gameq_query_name>redorchestra2</gameq_query_name>
```
This is the unique key referencing this specific game server in the GameQ protocol files, used to query the game server.
___
#### Installer:
Comes after `<protocol>` element (or comes after `<lgsl_query_name>` or `<gameq_query_name>` element when used). There can only be one `<installer>` element. Example:
```
<installer>steamcmd</installer>
```
Defines the use of SteamCMD tool to install the game server.
___
#### Game Name:
Comes after `<installer>` element. There can only be one `<game_name>` element. Example:
```
<game_name>Killing Floor 2</game_name>
```
This is the real game server name appearing in the list when installing a new game server.
___
#### Server Executable Name:
Comes after `<game_name>` element. There can only be one `<server_exec_name>` element. Example:
```
<server_exec_name>SpaceEngineersDedicated.exe</server_exec_name>
```
This is the server executable name used in the start command line.
___
#### Query Port:
Comes after `<server_exec_name>` element. There can only be one `<query_port>` element. Example:
```
<query_port type='add'>13</query_port>
```
Difference between the server port (`%PORT%`) and the query port (`%QUERY_PORT%`). In this example the variable %QUERY_PORT% will be 13 added to the port value.
___
#### CLI Template:
Comes after `<server_exec_name>` element. There can only be one `<cli_template>` element. Example:
```
<cli_template>-console %BASE_PATH% -ignorelastsession</cli_template>
```
```
<cli_template>%MAP%%GAMEMODE%%DIFFICULTY%%GAMELENGTH%%PLAYERS%%MUTATOR% %PORT% %IP% %WEB_ADMIN_PORT% %QUERY_PORT%</cli_template>
```
This is the template that will generate the start command line placed after the server executable name.
You can use these variables which are known to OGP:
```
GAME_TYPE
HOSTNAME
IP
MAP
PID_FILE
PLAYERS
PORT
QUERY_PORT
BASE_PATH
HOME_PATH
SAVE_PATH
OUTPUT_PATH
CONTROL_PASSWORD
```
These variable should be between `%` characters, the Panel will then replace them with the proper value when generating the start command line.
You can also use custom variables that you will define later in the XML.
___
#### CLI Parameters:
Comes after `<cli_template>` element. There can only be one `<cli_params>` element. Example:
```
<cli_params>
<cli_param id="MAP" cli_string="" />
<cli_param id="IP" cli_string="-MultiHome=" options="q"/>
<cli_param id="PORT" cli_string="-Port=" options="sq"/>
<cli_param id="PID_FILE" cli_string="" />
<cli_param id="GAME_TYPE" cli_string="" />
<cli_param id="HOME_PATH" cli_string="" />
</cli_params>
```
It defines the known variables used in `<cli_template>`. In this example we can imagine that for **%MAP%** it will generate the map name without space or quotes around it, because there is no `options`, for **%IP%** it will generate `-MultiHome="123.123.123.123"` using the `cli_string` and adding only quotes around the game server IP value because of `options="q"`, and **%PORT%** will generate `-Port= "27015"` using the `cli_string` and adding space and quotes around the game server port because of `options="sq"`.
___
#### Reserve Ports:
Comes after `<cli_template>` or `<cli_params>` element. There can only be one `<reserve_ports>` element. Example:
```
<reserve_ports>
<port type="subtract" id="WEB_ADMIN_PORT" cli_string="-WebAdminPort=">5</port>
<port type="add" id="STEAM_PORT" cli_string="-SteamPort=">19238</port>
<port type="add" id="MY_CUSTOM_PORT">666</port>
</reserve_ports>
```
You can add reserved ports here to use in the generated start command line. These ports will also be managed by OGP if OGP is used to manage the Agent machine firewall. Type can be `add` or `subtract` which is self explanatory. In this example when using the %WEB_ADMIN_PORT% variable in the `<cli_template>` it will generate `-WebAdminPort=XXX`, XXX being 5 subtracted to the Port set for this game server, when using the %STEAM_PORT% variable in the `<cli_template>` it will generate `-SteamPort=XXX` where XXX will be 19238 added to the Port set for this game server. As you can see, the variable %MY_CUSTOM_PORT% have no `cli_string`, this can be used this way to simply open this port (which here would be 666 added to the game server port) in the Agent machine firewall, when OGP is set to control the machine firewall (note: the firewall management may actually not open anything else than the game server port, to be verified).
___
#### CLI Allowed Characters:
Comes after `<reserve_ports>` element. There can only be one `<cli_allow_chars>` element. Example:
```
<cli_allow_chars>;</cli_allow_chars>
```
Used to allow some special characters in the command line. Escaped by default: ```\ " ' | & ; > < ` $ ( ) [ ]```
___
#### Maps Location:
Comes after `<cli_template>` element. There can only be one `<maps_location>` element. Example:
```
<maps_location>folder/maps</maps_location>
```
It sets the path of the map folder for this game server, which will be used to generate a selectable map list available before starting the game server. If folder contains map files it will use their name without the extension, if it contains sub folders with each map inside each own sub folder, it will generate the map list based on the folders names contained in the defined path. The selected map in the list will be used to replace the %MAP% variable in the `<cli_template>`.
___
#### Map List:
Comes after `<cli_template>` element. There can only be one `<map_list>` element. Example:
```
<map_list>maplist.txt</map_list>
```
The map list file path used to generate the selectable map list available before starting the game server. In this example it will look for a file called maplist.txt inside the root of the game server. Map list should have one map per line. The selected map in the list will be used to replace the %MAP% variable in the `<cli_template>`.
___
#### Console Log:
Comes after `<cli_template>` element. There can only be one `<console_log>` element. Example:
```
<console_log>KFGame/Logs/Launch.log</console_log>
```
It defines the path of the log file that will be shown in the LOG page of the game server. Most game servers, especially on Linux, will not need that, when in general, Windows game server will need it to properly show the output log.
___
#### Executable Location:
Comes after `<console_log>` element. There can only be one `<exe_location>` element. Example:
```
<exe_location>Binaries/Win64</exe_location>
```
It defines the path of the game server executable when not in the root folder.
___
#### Max User Amount:
Comes after `<exe_location>` element. There can only be one `<max_user_amount>` element. Example:
```
<max_user_amount>64</max_user_amount>
```
It defines the maximum player number you will be able to set when creating the game server.
___
#### Control Protocol:
Comes after `<max_user_amount>` element. There can only be one `<control_protocol>` element. Example:
```
<control_protocol>rcon2</control_protocol>
```
Can be `rcon`, `rcon2`, or `lcon` (legacy). Note that `rcon` can also have type option to define, which can be `old` or `new`. Example:
```
<control_protocol>rcon</control_protocol>
<control_protocol_type>old</control_protocol_type>
```
___
#### Mods:
Comes after `<control_protocol>` element. There can only be one `<mods>` element. Example:
```
<mods>
<mod key="insurgency">
<name>none</name>
<installer_name>237410</installer_name>
</mod>
</mods>
```
Used to define different mods for the game server, in this example there is only one mod available which will be the default installed one (actually the game server itself here). The `<installer_name>` here is the Steam appID that will be used to install and update the game server. (note: case RSync to explain? Case multi mods to explain?)
___
#### Replace Texts
`<replace_texts>` Comes after `<mods>`.
Contains multiple `<text>` entries like so:
```
<replace_texts>
<text key="control_password">
<default>ServerAdminPassword=.*</default>
<var>ServerAdminPassword=</var>
<filepath>ShooterGame/Saved/Config/LinuxServer/GameUserSettings.ini</filepath>
<options>sq</options>
</text>
<text key="home_name">
<default>SessionName=.*</default>
<var>SessionName=</var>
<filepath>ShooterGame/Saved/Config/LinuxServer/GameUserSettings.ini</filepath>
<options>sq</options>
</text>
</replace_texts>
```
`<default>` within `<text>` is what the line to replace starts with.
`<var>` within `<text>` is the key for what should be kept when the line is replaced with the value entered by the user when replacing text occurs.
`<filepath>` within `<text>` specifies the text file to make the replacement in.
`<options>` within `<text>` specifies how to enter the user's value after the `<var>` key. Possible options are:
```
nothing / no value = placed as is
s = space / separated
q = quoted
sq = space and quotes
sc = space and ends with a comma
sqc = space, quoted, and ends with a comma
```
These replace text will be applied on server start and modify the specified config files with the values generated by the Panel.
___
#### Server Params:
`<server_params>` Comes after `<replace_texts>`.
Contains multiple `<param>` entries like so:
```
<server_params>
<param id="SP" key="?ServerPassword=" type="text">
<option>ns</option>
<caption>Server Password</caption>
<desc>Players must know this password to connect.</desc>
</param>
<param id="DIFFICULTY" key="?Difficulty=" type="select">
<option value=""></option>
<option value="0">Normal</option>
<option value="1">Hard</option>
<options>ns</options>
<caption>Difficulty</caption>
<desc>This sets the server difficulty. Leave empty to configure this parameter in the config files or webadmin</desc>
</param>
<param key="-EnableCheats" type="checkbox_key_value">
<caption>Cheats</caption>
<desc>Enable the cheats to be used from the ingame Admin menu</desc>
</param>
</server_params>
```
`id` attribute on the `<param>` specifies which variable to replace in the `<cli_template>`
`key` attribute specifies what will replace the variable defined by id attribute
type attribute will define what kind of parameter it is, possible values are `text` `select` `checkbox_key_value`:
- `text` will allow to write text value to be added during the replacement of the variables in startup command line. For example, `%SP%` in `<cli_template>` would be replaced with `?ServerPassword=XXX` where XXX would be the value entered by the user in the text box, if nothing is entered the variable is not replaced but removed from `<cli_template>`. The value entered can be modified to fit your needs by using the `<option>` element within the `<param>` element.
- `select` will create a selectable list to choose the parameter value. The `%DIFFICULTY%` variable in `<cli_template>` would be replaced with `?Difficulty=1` if `Hard` would have been selected before starting the server.
- `checkbox_key_value` will add a simple checkbox that, if ticked before starting server, would add the parameter `-EnableCheats` at the end of the startup command line.
Valid options are for the `<options>` element within the `<param>` element within the `<server_params>` element are:
```
ns = no space between key and value
q = quotes wrapped around value after key (no space added)
s = space added after key before value (no quotes added)
anything else = space after key and quotes around the value
```
___
#### Custom Fields:
Comes after `<server_params>` element. There can only be one `<custom_fields>` element. Example:
```
<custom_fields>
<field key="sv_maxrate" type="text">
<default>sv_maxrate.*</default>
<default_value>0</default_value>
<var>sv_maxrate</var>
<filepath>orangebox/cspromod/cfg/server.cfg</filepath>
<options>s</options>
<desc>Max bandwidth rate allowed on server ( bytes per second ), 0 == unlimited.</desc>
</field>
<field key="sv_minrate" type="text">
<default>sv_minrate.*</default>
<default_value>5000</default_value>
<var>sv_minrate</var>
<filepath>orangebox/cspromod/cfg/server.cfg</filepath>
<options>s</options>
<desc>Min bandwidth rate allowed on server ( bytes per second ), 0 == unlimited.</desc>
</field>
<field key="sv_maxcmdrate" type="text">
<default>sv_maxcmdrate.*</default>
<default_value>66</default_value>
<var>sv_maxcmdrate</var>
<filepath>orangebox/cspromod/cfg/server.cfg</filepath>
<options>s</options>
<desc>If sv_mincmdrate is > 0, this sets the maximum value for cl_cmdrate.</desc>
</field>
<field key="sv_mincmdrate" type="text">
<default>sv_mincmdrate.*</default>
<default_value>67</default_value>
<var>sv_mincmdrate</var>
<filepath>orangebox/cspromod/cfg/server.cfg</filepath>
<options>s</options>
<desc>This sets the minimum value for cl_cmdrate. 0 == unlimited.</desc>
</field>
<field key="sv_maxupdaterate" type="text">
<default>sv_maxupdaterate.*</default>
<default_value>66</default_value>
<var>sv_maxupdaterate</var>
<filepath>orangebox/cspromod/cfg/server.cfg</filepath>
<options>s</options>
<desc>Maximum updates per second that the server will allow.</desc>
</field>
<field key="sv_minupdaterate" type="text">
<default>sv_minupdaterate.*</default>
<default_value>67</default_value>
<var>sv_minupdaterate</var>
<filepath>orangebox/cspromod/cfg/server.cfg</filepath>
<options>s</options>
<desc>Minimum updates per second that the server will allow.</desc>
</field>
</custom_fields>
```
Custom Fields available when you go to Custom Fields button from the game server page. These custom fields will be applied on every server start and will replace the specific values in the specified config files.
___
#### List Players Command:
Comes after `<custom_fields>` element. There can only be one `<list_players_command>` element. Example:
```
<list_players_command>status</list_players_command>
```
This is the command to list the players on the server when using `control_protocol`.
___
#### Player Info Regex:
Comes after `<list_players_command>` element. There can only be one `<player_info_regex>` element. Example:
```
<player_info_regex>#\#\s*(\d*)\s*\"(.*)\".*#</player_info_regex>
```
Regex used for player info when using `control_protocol`.
___
#### Player Info:
Comes after `<player_info_regex>` element. There can only be one `<player_info>` element. Example:
```
<player_info>
<index key="1">userid</index>
<index key="2">Name</index>
</player_info>
```
Defines the different keys for player infos when using `control_protocol`.
___
#### Player Commands:
Comes after `<player_info>` element. There can only be one `<player_commands>` element. Example:
```
<player_commands>
<command key="Kick" type="hidden">
<string>kick "%Name%"</string>
</command>
<command key="Ban" type="select">
<option value="0">Permanent</option>
<option value="15">15m</option>
<option value="30">30m</option>
<option value="60">1h</option>
<option value="1440">1D</option>
<option value="10080">1W</option>
<option value="43200">30D</option>
<string>banid %input% %userid% kick</string>
</command>
<command key="Change Nick" type="text">
<default>new nick</default>
<string>sm_rename #%userid% "%input%"</string>
</command>
</player_commands>
```
Defines the commands available when using `control_protocol`.
___
#### Pre Install:
Comes after `<player_commands>` element. There can only be one `<pre_install>` element. It can contain multiple entries one per line. Example:
```
<pre_install>
</pre_install>
```
Script executed before installing the game server.
___
#### Post Install:
Comes after `<pre_install>` element. There can only be one `<post_install>` element. It can contain multiple entries one per line. Example:
```
<post_install>
cp linux64/steamclient.so ./steamclient.so
echo &apos;#!/bin/bash
./bin/AvorionServer $@&apos; &gt; avorion_ogpstarter.sh
chmod +x avorion_ogpstarter.sh
</post_install>
```
Script executed after installing or updating the game server, similar to `pre_install` (which `pre_install is executed before installation/update obviously)`. In this example, after installation or update of the game server, it will copy the file linux64/steamclient.so to ./steamclient.so and generate a bash script in the file avorion_ogpstarter.sh and then make this bash script executable. Note that the bash script must be written to be properly interpreted by the XML (see the `"` character replaced by `&apos;`, `>` replaced by `&gt;`, and so on.. if you write plain bash script it will break the XML in Panel, so keep that in mind and replace special characters with their XML readable counterpart.
___
### Windows:
#### Pre-Start Commands:
Comes after the `<server_params>` element. There can only be one `<pre_start>` element. It can run multiple lines of script that will be executed by the cmd batch environment.
This can be filled with lines of script that will be run in a batch script just before the game server is started. The script will always change directory into the home directory before your commands will run, so you can reference things locally.
```
<pre_start></pre_start>
```
___
#### Environment Variables:
Comes after `<pre_start>` element. There can only be one `<environment_variables>` element. It can contain multiple entries one per line.
```
<environment_variables>
</environment_variables>
```
Used for setting environment variables which may be needed by some servers. This is run in the batch environment, so please make sure you're using Windows commands for your environment SETS.
Special entries:
`{OGP_HOME_DIR}` will be replaced by the home directory for the game server.
___
### Linux:
#### Pre-Start Commands:
Comes after the `<server_params>` element. There can only be one `<pre_start>` element. It can run multiple lines of script that will be executed by the bash shell.
This can be filled with lines of script that will be run in a bash script just before the game server is started. You do NOT need to provide the shebang "#!/bin/bash" in your commands. The script will always change directory into the home directory before your commands will run, so you can reference things locally.
```
<pre_start></pre_start>
```
Example (writes hiya to a file named testingPreStart in the home directory of the server):
```
<pre_start>
echo "hiya" >> testingPreStart
</pre_start>
```
___
#### Environment Variables:
Comes after `<pre_start>` element. There can only be one `<environment_variables>` element. It can contain multiple entries one per line.
```
<environment_variables>
</environment_variables>
```
Used for setting environment variables which may be needed by some servers such as Rust.
Example:
```
<environment_variables>
export LD_LIBRARY_PATH="{OGP_HOME_DIR}/RustDedicated_Data/Plugins/x86_64"
</environment_variables>
```
Special entries:
`{OGP_HOME_DIR}` will be replaced by the home directory for the game server.
___
### Linux and Windows:
#### Locking / Protecting Additional Files:
Comes after `<environment_variables>` element. There can only be one `<lock_files>` element. It can contain multiple entries one per line.
```
<lock_files>
</lock_files>
```
Used for protecting additional game server files by using the system program `chattr`. This is a Linux only element. You can use relative (paths are relative to the home directory for the game server) or absolute paths.
Example:
```
<lock_files>
bin/AvorionServer
</lock_files>
```
The above example adds chattr +i to the bin/AvorionServer executable. This prevents the user from changing it. When SteamCMD or Rsync is run to update the files, everything is unlocked, but the files specified here will be locked post update / install. These files are also locked again (just to make sure) before the server is restarted and started. Entries here will not BREAK or AFFECT the steamcmd or Rsync update process.
Special entries:
`{OGP_HOME_DIR}` will be replaced by the home directory for the game server. However, if you're using this variable, you should just use a local path.
___
#### Configuration Files:
Comes after `<lock_files>` element. There can only be one `<configuration_files>` element.
There can be multiple `<file>` entries within `<configuration_files>` element, the description in the `<file>` element is not mandatory. Example:
```
<configuration_files>
<file description="The Main config file">Path/To/Config/File.ini</file>
<file description="Another Config file">FolderX/GameEngine.ini</file>
<file>FolderZ/GameConfig.ini</file>
</configuration_files>
```
It defines the files directly editable from Panel even without access to the server files directly. This requires the EditConfigFiles extra module.