> For the complete documentation index, see [llms.txt](https://rust-console-edition.gitbook.io/community-servers/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rust-console-edition.gitbook.io/community-servers/provider-hosting/specifications.md). # Specifications ## Overview This document serves as a guideline for all the technical requirements, explanation of processes and expectations for being a provider of Rust Console Edition (RCE) community servers. RCE uses the Unity game engine and is a port of the PC version of the game. The game is published for Xbox and PlayStation consoles and allows cross-play between both, it does not allow cross-play to the PC version of the game. In order to have cross-play functionality, a custom framework and backend was created for the console product called ***`Rustworks`***, this manages our official servers directly, and contains data for community servers, this also provides functions for the game to run correctly such as server connections, the in-game skin store and automatic server wiping. It does not currently support external mods but certain features have been integrated which can be configured by many various Console Commands, these are continually updated and can be seen elsewhere in this wiki, these commands can be run with RCON (Remote-Console) or Server configuration file (server.cfg), please see the sections in this document for information. ## Server Details ### Hardware Each game server needs a minimum `16GB` of RAM to run correctly, memory consumption slowly rises over a period of a month on a standard official server (Automatically wiped at the end of the month). Due to the amount of game objects growing and the nature of the game, restarting the game server does not reset memory consumption as it quickly raises back to the previous peak. * A standard official server runs (One single server per machine) * Map Config * World Size - 4500 * Max Players - 100 * Total wipe time - 1 month * Specs * Minimum of 2 Physical Cores * High Single threaded performance is important (E.g 4.2 GHz) * More Cores (E.g 4) are also recommended for higher player population * 16 GB RAM * 10Gbps (Outbound) * 25 GB SSD * Virtual machine The provider is expected to issue a server per hardware type to the RCE team for gameplay checks which need to persist as long as they are a provider for RCE. Additionally, each region the provider supports will also need to be checked for network connectivity issues by the RCE team. This hardware may be subject to tests on the Staging environment (See the Environments section) by the RCE team. ### IPs and Ports Firstly the following command line options must be set to open connections to communicate to the server.\ \ One of the ports is sensitive and requires independent discussion to implement, therefore it is not visible on this page.Firstly the following command line options must be set to open connections to communicate to the server. > ***`+server.ip `*** > ***`+rcon.ip `*** 4 Ports per are required per server. These ports must be overridden on the command line. They must not overlap with this server or another server on the same IP. One of the ports is sensitive and requires independent discussion to implement, therefore it is not visible on this page. #### Game Server Traffic * All Client and Server communication go through this port * DTLS Network Protocol (UDP) * Command line: * ***`+server.port 1234`*** #### Ping Port * Client pings this port to calculate latency * TCP Socket * Command line: * ***`+server.pingport 1234`*** #### RCON User * Provider console UI and User tools go through this port * Websocket Server * Command line: * ***`+rcon.port 1234`*** #### Example: * Machine A - Server 1: * `28015`- Game Server Traffic * `28016`- RCON User * `28019`- Ping Port * Machine A - Server 2: * `28115`- Game Server Traffic * `28116`- RCON User * `28119`- Ping Port ### Managing the Server Process #### Starting and Stopping a server In the provided Build (See Builds section) the executable to start the server is called ***`RustDedicated`***. If not present already, ***`RustDedicated`*** will require the executable flags (***`chmod +x`***) so that it can be started. After loading all of the required assets and almost completing its boot-up the server will do two steps. Firstly, it will check that the hostname is provided, the server may log the following error if it is not, it must not be empty or the default hostname (See the Server configuration file (server.cfg) section). > ***`FAILED TO BOOT - Server hostname is missing! Please contact the server provider`*** Secondly, the server will make a https request (referred to as ***`Register`***) to Rustworks to authenticate itself, it will do this with the values provided from the Command line (See the Command Line Section). It is vital that the machine has the correct SSL certificates otherwise the Register request will fail blocking the entire startup, they must be located in: > **`/etc/ssl/certs/`** If the **`.crt`** files are not present they may be found in: > **`/etc/pki/tls/certs/`** Alternatively located by: > **`find / -type f -name "ca-certificates.crt”`** If present outside of the SSL folder, then symlinks must be made, for example this can be done by: > **`sudo ln -s /etc/pki/tls/certs/ca-bundle.crt /etc/ssl/certs/ca-certificates.crt`** It is recommended that all **`.crt`** files be symlinked. The data returned (Such as keys to open a connection) from the register request will allow the game server to finish its boot-up procedure. Detecting that a server has completed its bootup procedure is as simple as checking that the game server traffic port has been opened, alternatively a log will also be generated in ***`public.log`*** which will state ***`Server start-up complete`*** to indicate the boot-up is complete. Stopping the server is not graceful and is completed by terminating the server process / service. Please refer to the Saves and Backups section for any concerns about corrupted files. #### Commandline Please also refer to the following sections as these also contain categorised command line options. * IPs and Ports * RCON (Remote-Console) * Environments In order to correctly complete the bootup procedure and have the connection completely open the provider must pass the following command line options. These options are provided by RCE for the provider to enable access. This is the identifiable name of the provider, this allows the specific provider register to be called and internal errors to be categorised correctly for Community servers. > ***`-provider `*** The token is what allows the server from the provider to access Rustworks to authenticate itself. > ***`-providerToken `*** The provider server id is the unique permanent identifier for a provider server, the provider is expected to generate the id and passed to the command line, it allows the server to be correctly updated in Rustworks to be visible to all clients. A game server must always maintain the same id to be correctly mapped in Rustworks. > ***`-providerServerId `*** The provider is expected to add the server region to the command line, this is so that RCE can correctly show and filter the server in the game. The format is always the provider name, underscore, then the region that the provide supports, this must be done with without spaces otherwise quotes will be required. An example of this is ***`coolprovider_japan`\*\*\*\*.*** > ***`-providerRegion _`*** If the provider wishes to limit the maximum number of players for the example of purchasing a specific configuration they can pass the following option to the server in the command line. If the max player count is changed by the user, it will not surpass this command line option. The RCE team also add an absolute maximum which the game currently supports which the provider will not be able to pass. > ***`+server.maxplayers `*** ### RCON (Remote-Console) RCON is the primary way to communicate with the game server to send commands, retrieve requested information and retrieve logs. This is achieved over a Websocket that is configured on the boot of servers. A command executed by RCON is treated exactly as running a command through the server.cfg file. For configuring the RCON connections, please refer to the IPs and Ports section. The RCON password must be overridden on the command line with the following option: > ***`+rcon.password “”`*** When connecting to the server via the RCON system, the ***`password`*** should be applied as a path and not an authentication header, for example: > ***`ws://:/`*** RCON commands are sent as wrapped JSON strings with a ***`clear text`*** format to the WebSocket. The JSON payload contains the name of the application making the call, a unique message identity and the command to execute by the server. ``` { "identifier": 123, "name": "My Websocket App", "message": "serverinfo" } ``` Responses are streamed from the server in a broadcast fashion as is standard by RCON, the calling application holds responsibility for processing all streamed data from the server on this connection. The ***`identifier`*** should be used to correctly identify the response that is expected. The server will not await a confirmation of recite by any connected applications and once any data has been broadcast it is lost and not re-transmitted. Multiple applications could be requesting data at any one time, consideration should be given to handling more than one message response that is invalid and/or intended for another application that is connected. The server can be quite “chatty” and may broadcast data that was not requested, again, using the message ***`identifier`*** prevents working with unexpected data sets an application is not expecting. Server responses will vary depending on the command being executed, however, the payload will always be formatted in the following way: ``` { "identifier": 123, "message": "Some string, this could be anything..." } ``` It is expected the application connecting to the RCON will know what format the response ***`message`*** will be, this could be a single word, ***`string`***, ***`integer`*** or a complex object in ***`JSON`*** notation. #### Provider Server list API The provider’s is expected to supply an API call for the RCE team to retrieve the server list of purchased servers to correctly update Rustworks, this will need the following info: * Provider Server identifier * The server identifier should be the same as what was passed by the game server from the command line. * Environment * See the Environments Section. * Current status * Please also refer to Starting and Stopping a server section for identifying the server status. * This should indicate the server state from the providers perspective: * ***`shutdown`*** * ***`active`*** * ***`starting`***. The server list from the API is used to update the heartbeat time in Rustworks which determines whether the server is still active or not. If it is no longer active, then the server is ‘shutdown’ and will not be displayed in the game client. Example JSON ``` [ { "server": { "id": 123456 }, "environment": "internal", "state": "active" }, { "server": { "id": 987654 }, "environment": "production", "state": "starting" }, { "server": { "id": 29384756 }, "environment": "staging", "state": "shutdown" } ] ``` ### Builds #### Platform The primary distribution for RCE is Debian for Linux (Moving to Ubuntu). All dependencies are contained within the server. Although possible, we currently do not run official servers in docker containers, it is left to the discretion of the provider to implement, or to correctly manage the cores and threads of the servers using process containers such as CGroups or .service failing to do so will cause conflicts across servers. At the time of writing, server build excluding preset files sizes are: * \~2.48 GB (Compressed) * \~5.46 GB (Uncompressed) #### New Builds Currently choosing a build version is not optional, as a result we only provide one build per environment for servers. Builds are not public and are provided through SFTP to an endpoint of the providers choosing, other methods can be made available if required. As there is no visible versioning on files, to detect a build change, please refer to the modified date of the files, this must then trigger the Restart-To-Update procedure (See the Restart-To-Update section) and must update the webpage to the new cfg\_cms file (See the Webpage Overview section) as soon as possible. Once a server is running, if the version is required the ***`buildinfo`*** command will return the server version for example ***`d0297d.3652.33461`***. Please refer to RCON (Remote-Console) section for running commands. The RCE team will conduct “*Server upgrade tests*” before uploading of new builds to ensure that stability and save data is preserved. Additionally, some updates will require the client version to be the same or a higher version of the server, this is managed by the RCE service. Please also refer to the Environments section for file details. #### Environments RCE requires various environments for a clear pipeline of development and a separation from the public live game. This separation is left to the discretion of the provider however servers must have the ability to change between these environments for testing purposes, if a server is changed this resets the server to its default state in the new environment. The environments are described as follows: * Development * All in-progress changes for backend services or experimental features * Build File: ***`server_gen9.7z`*** * Internal * Core testing ground for Quality Assurance and feature stability testing. * Build File: ***`server_internal_gen9.7z`*** * Staging * Live testing ground for RCE to test new features (Including adding providers) * Build File: ***`server_staging_gen9.7z`*** * Production * Main stable live version of the game. * Build File: ***`server_production_gen9.7z`*** The environment must be passed in lowercase to the server on the command line to correctly register with Rustworks, option is as follows: > ***`-environment `*** #### Restart-To-Update RCE, due to being a live service game we want to avoid forcing players out of game as much as possible, as a result we follow the Restart-To-Update procedure, this is as follows: Once a new build has been detected (See the New builds section), the webpage will display a warning message that a new update is available. On the next start or restart of the server (Automated or manual) an automated backup (See the Saves and Backups section) is expected to be made and then the build will be applied to the server, only build related files should be touched. ### Saves and Backups Save, Map and configuration files are located in: > ***`/my_server_identity`*** Unless the ***`+server.identity `*** is specified, which would result in: > ***`/name`*** These files **Must not** be visible or downloadable to the public Save and Map files are generated on boot of the game server if the current configuration of ***`worldsize`**, **`seed`**, **`land monument filter`**, **`offshore monument filter`*** and ***`map version`*** files do not exist, this configuration is provided in the server.cfg file (See the Server configuration file (server.cfg) section). In the event of content updates, RCE may introduce a ***`force wipe`*** in which previous map and save files become invalid causing a new generation of files, this can be observed with the version at the end of the file names, resulting in “old” extra files remaining on the server. The format for these file names are: > ***`proceduralmap.....`*** > ***`proceduralmap.3500.1392.51539607423.15.176`*** A game server automatically saves every 10 minutes which uses a renaming process to prevent any partially written files, it works as follows: 1. Write the save to a file with the extension ***`.sav.new`*** (Overwriting if necessary) 2. Once written, rename the current save file (***`.sav`***) to the extension ***`.sav.bak`***. 3. Rename the ***`.sav.new`*** file to ***`.sav`***. It is expected that the provider supplies an automated backup system and restore process to prevent loss of progression. Files that require backing up and restoring are as follows: * ***`.sav.*`*** * ***`.map`*** * ***`.db`*** * ***`.cfg`*** ### Restarts and Wipes Please also refer to Starting and Stopping a server section. RCE requires a variety of restart types to complete actions against servers. These actions can be triggered by changing options on the Webpage, or alternatively from setting up restart schedules. The provider is expected to implement the following restart schedules. Although not required it is recommended to implement a date/time selection, alternatively region selection, or to follow the official wipe times of ***`6PM UTC+0`*** #### Daily The server will execute this restart procedure every 24 hours (1 day). #### Weekly The server will execute this restart procedure every 168 hours (7 days), alternatively to follow the official wipe cycle on each Thursday of the month at ***`6PM UTC+0`***. #### Biweekly The server will execute this restart procedure every every 336 hours (14 days). Official servers do not support this wipe cycle. #### Monthly The server will execute this restart procedure on the last day of the month that matches the selected date, alternatively to follow the official wipe cycle on the last Thursday of the month at ***`6PM UTC+0`***. The provider is expected to implement the following types of wipes for restart schedules #### Restart A normal restart procedure. Steps: 1. Stop server executable. 2. Start server executable. #### Save Wipe A save wipe is used when the server wants to keep its current map generation, but wants to reset all player interaction (E.g buildings, items etc.) If this wipe type is applied, it must be compared to all other Save wipes and Full Wipe schedules to determine the shortest duration, after this ***`save_wipe_schedule`*** must be added to the `server.cfg` file, (See Server configuration file (server.cfg) section) and the server restarted. For example: > ***`save_wipe_schedule "biweekly"`*** Steps: 1. Stop server executable. 2. Delete all ***`*.sav.*`*** files. 3. Delete all ***`*.db`*** files **excluding** ***`player.reports.db`*** *and **`player.blueprints.*.db`*** 4. Start server executable. #### Map Wipe Map wipes are used when a server wants to change its world generation configuration, it allows for the procedural gameplay elements to be re-generated. Steps: 1. Stop server executable. 2. Delete all ***`*.sav.*`*** files. 3. Delete all ***`*.map.*`*** files. 4. Delete all ***`*.textures.*`*** files. 5. Delete all ***`*.db`*** files **excluding** ***`player.reports.db`*** *and **`player.blueprints.*.db`*** 6. Start server executable. #### Blueprint Wipe Blueprints in RCE are the current research progression of a player on the server. This is tracked separately to the current save progression to allow the blueprints to persist over wipe cycles. This wipe type is used when the server wants to reset the progression of all players creating an even playing field. If this wipe type is applied, it must be compared to all other Blueprint wipes and Full Wipe schedules to determine the shortest duration, after this ***`blueprint_wipe_schedule`*** must be added to the ***`server.cfg`*** (See Server configuration file (server.cfg) section) and the server restarted. For example: > ***`blueprint_wipe_schedule "monthly"`*** Steps: 1. Stop server executable. 2. Delete the ***`player.blueprints.*.db`*** file. 3. Start server executable. #### Full Wipe A full wipe is a combination of all previous wipe types, this is a complete reset of a server, it is generally used by communities after content updates. Steps: 1. Stop server executable. 2. Delete all ***`*.sav.*`*** files. 3. Delete all ***`*.map.*`*** files. 4. Delete all ***`*.textures.*`*** files. 5. Delete all ***`*.db`*** files **excluding** ***`player.reports.db`*** 6. Delete all ***`*.log`*** files 7. Start server executable. ### Server configuration file (server.cfg) Console commands are added into the ***`server.cfg`*** file to run the commands on server start-up. The majority of commands will be cleared when the server restarts, commands which are excluded from this rule are commands which generate their own configuration files, so they can be shared (E.g kit system) or if commands directly add new entities which get included into the current save file (E.g special events). The ***`server.cfg`*** file is a text file in which each line of the file is one command, each space on the line will be treated as another parameter, unless quotes are present, therefore the provider should not escape quotes when writing to the file. All parameters are treated as text by the game server and then attempted to be parsed to the desired type. A command in the ***`server.cfg`*** file is treated exactly as running a command through RCON (Remote-Console). A console command has two versions, a partial version and a full version, the partial version is only the variable (or) function name, such as ***`hostname`*** however, the full name includes a prefix for the class or filename, such as ***`server.hostname`***, these are treated exactly the same in the game server. The provider **must** use the full name as priority otherwise conflicts may occur, for example the console commands for populations are the same name with ***`population`***, therefore to differentiate the prefix must be used such as, ***`chicken.population`*** and ***`boar.population`**** ****.*** The ***`cfg_cms.json`*** file will always provide the full name of a console command. The all files located in the following directory and sub-directories are configuration files, ***`server.cfg`*** specifically is in the root directory: > ***`/my_server_identify/cfg/`*** When a webpage button is modified is it expected that the provider follow the rule: > If the new value is the same as the default in cfg\_cms and does **not** have the ***`required`*** attribute as ***`true`***, this then is removed from the server.cfg file. Otherwise, it will be written to the server.cfg file. The provider should understand and expect that players will ask for assistance on using console commands, please refer them to the [Rust Console Edition Community Server Wiki](https://rust-console-edition.gitbook.io/rust-console-edition-community-servers). #### Example: ``` server.hostname " by " server.seed 1392 server.worldsize 3500 ai.think 0 env.progresstime 0 server.d11gatherscale 3 server.welcomemessage "Server provided by " ``` ## Webpage ### Overview This section of the document details what is required of the site in terms of functionality and display of the providers webpage. It is split into integration for Non-Generated content elements (Such as Buttons), and the generation of the webpage based on a JSON configuration file, we refer to this configuration as cfg\_cms due to the file name ***`cfg_cms.json`***. The ***`cfg_cms.json`*** file is used to prevent continuous development time from the Provider and allows the RCE team to add new options into the page without external support. The ***`cfg_cms.json`*** file is found in the root directory of the provided Build (See the Builds section). When an option is modified in the webpage, this must follow the rules described in the Server configuration file (server.cfg) section. It is expected that the provider ensures that if information is not visible due to being part of another environment (See the Environments section), or locked behind developer privileges, the data shouldn’t be sent to the users webpage. Instances have previously occurred in which users have used the browser Network tab to view this information and exploit it. During development of the webpage we recommend discussing FAQs and Wikis with our publishing team to prepare accurate information and available for the release of the provider. ### Non-Generated Content The provider is expected to provide the following static functionality for the server webpage. Currently no translations are provided for this content. Some of this functionality should be restricted to developer accounts, developer servers, or restricted to particular Environments (See the Environments section). #### Developer These options must not be visible to normal users in the Production environment and can be added anywhere on the server page. * A Environment selection box (See select) which supplies control to the development state of a server. Please refer to the Environments section for details on each environment and actions. * A Command line Inputbox (See inputfield) this option will pass additional command line options along with everything specified from the Command line section. * IP * Port #### User These options are available to both developers and users of the webpage. * Server Status * Server hostname * Active Number of Players * Max Number of Players #### A “Verify game files” / “Verify integrity” Button If no automatic verification of files, this then applies: The provider is expected to add a button called ***`Verify game files`*** located at the top of the server page, this will restore the original build files, and complete any provider procedures to attempt to reset the game server to a functional state, this must preserve the current Save and Configuration files. This button is not absolutely required if build files are regularly automatically checked. #### “Start Server” / “Stop Server” Button The provider is expected to add a button or alternatively a toggle called ***`Start`(or) `Stop`*** located at the top of the server page, this button will toggle the state of the server between on and off, please refer to the Starting and Stopping a server section. #### “Restart” Button The provider is expected to add a button called ***`Resart`*** at the top of the server page, this button will complete the ***`Restart`*** action from the Restarts and Wipes section. #### “Wipe Saves” Button The provider is expected to add a button called ***`Wipe saves`*** on a ***`status`*** page, this button will complete the ***`Save wipe`*** action from the Restarts and Wipes section. #### “Wipe Blueprints” Button The provider is expected to add a button called ***`Wipe player blueprints`*** on a ***`status`*** page, this button will complete the ***`Wipe Blueprints`*** action from the Restarts and Wipes section. #### “Full Wipe” Button The provider is expected to add a button called ***`Full wipe`*** on a ***`status`*** page, this button will complete the ***`Full Wipe`*** action from the Restarts and Wipes section. #### “Factory Reset” Button The provider is expected to add a button called ***`Factory Reset`*** on a ***`status`*** page, this button will restore the machine, game server and webpage to it’s default settings for users to have a clean slate to work on. #### Presets The provider is expected to provide a page or section for Presets. These presets should show an icon, a name and be selectable. Please also refer to the Presets section for selection and application of presets. The provider is expected to add a ***`No preset`*** or ***`Reset preset`*** option. Please also refer to the Presets section for resetting of presets. #### File Manager The provider is expected to include a file manager tab for the downloading and viewing of game server files. The only file available to users is the `public.log`, all other log files are for developers as they may contain sensitive data. The RCE team may request access to files from servers for troubleshooting issues, alternatively, if possible the provider should allow some access to the RCE team for accessing servers to prevent continuous time spent from the provider. #### Console window The provider is expected to add a ***`Console`*** page which will provide the ability for users to view and send Console commands through the RCON websocket (See RCON (Remote-Console) section) connection. While this page is open, all logs from the RCON connection must be displayed. Although not required the provider may read the public.log file to display previous log entries for any new users opening the console page. If the server is started or restarted in any way, the page must reconnect the RCON connection without refresh. Please also refer to the RCON (Remote-Console) section. ### Page(s) JSON format #### Overview The root of the JSON is “pages”, it can contain multiple pages in the object and each will have a unique name. All pages contain the following attributes: * ***`name_text_key`*** * This is to describe the name of the page on the sidebar / topbar. * See the Translations section for the format. * ***`name_page_title`*** * This is to describe the name of the page at the top of the page * See the Translations section for the format. * ***`name_page_hint`*** * This will describe what this page is for. * This will display under the title of the page. * See the Translations section for the format. * ***`order`*** * This is the index of the page. * This determines the order in which the pages are shown / listed. * ***`options`*** * This object holds all button JSON objects * Please refer to the Button(s) JSON format section. * This is list of options the page will display ``` { "pages": { "example_page": { "name_text_key": { "en-gb": "Page name here", "en-us": "A different name here", ... }, "name_page_title": { "en-gb": "Page title here", "en-us": "Title goes here", ... }, "name_text_key_hint": { "en-gb": "A page to display x", "en-us": "Edit x here", ... } "options": { "option_1": { ... }, "option_2": { ... } } }, "example_page": { ... } } } ``` #### Overview Buttons in the JSON are Console command options these can run on a server, or can be added to the start-up arguments All button attributes in the JSON are under a name this button name is the full name of the command. Please also refer to Server configuration file (server.cfg) section. All buttons contain the following attributes: * ***`button_type`*** * This indicates the button type and how it will be used. * Values (Can also see headers below for explanations) * inputfield * multiinputfield * toggle * slider * multiselect * select * ***`name_text_key`*** * This is to describe the name of the button. * See the Translations section for the format. * ***`name_text_key_hint`*** * This will describe what this option is used for. * The provider may choose how this will display for the user, such as: when the button is highlighted, under / above the option, or when editing. * See the Translations section for the format. * ***`default_value`*** * Default value of the option. * ***`data_type`*** * This is the type value which will be inputted by the user * Values * alphabetic * This is text * numeric * This is a number * alphanumeric * Combination of text and numbers * ***`modify_action`*** * This is the name of the action to take when the value is modified * Please note that other wipe types exist which options do not use (See Wipes and Backups). * Values * none * Must then be ran on the server through RCON websocket (See the RCON (Remote-Console) section) * restart * The modified value is added to the ***`server.cfg`*** (See the Server configuration file (server.cfg) section) * Then see the Restart section * wipe\_save * The modified value is added to the (See the Server configuration file (server.cfg) section) * Then see the Save Wipe sectiom * wipe\_map * Then see the Map Wipe section * All buttons can have these additional attributes: * ***`min / max / step`*** * If present means this option can be randomised * The provider may wish to present an option to randomise. * Sliders also use these values (See the sliders section). * Uses the int data\_type. * Values * Any step value between min (inclusive) and max (inclusive). * It is important to note that values of presets may exceed the given bounds of the option. * ***`required`*** * This specifies this option is required to be modified by the player for the server to be able to startup. * This value is always written to the ***`server.cfg`*** (See the Server configuration file (server.cfg) section) * If the option is not required we use the ***`default_value`***. * Values * true * false #### inputfield #### Notes: This is a generic input box the user will write a value into an input box. Quotes should not be escaped and left for the user to input. ***`max_chars`*** is a special attribute * This is the maximum amount of characters the input box can hold * E.g 128 * Optionally, the provider can add visual markers to show this max #### JSON Example: ``` "hostname": { "default_value": "Default", "button_type": "inputfield", "name_text_key": { "en-gb": "Server Name", "en-us": "Name!", ... }, "data_type": "string", "required": true, "name_text_key_hint": { "en-gb": "Server name here", "en-us": "A different name here", ... }, "max_chars": 512 } ``` #### multiinputfield #### Notes: The user will write a value into a input box which allows new lines. Quotes should not be escaped and left for the user to input. To treat console commands correctly, each line of this will be added into the ***`server.cfg`*** (See the Server configuration file (server.cfg) section) as a separate line. #### JSON Example: ``` "hostname": { "default_value": [ "value1", "value2" ], "button_type": "multiinputfield", "name_text_key": { "en-gb": "Server Name", "en-us": "Name!", ... }, "data_type": "string", "required": true, "name_text_key_hint": { "en-gb": "Server name here", "en-us": "A different name here", ... } } ``` #### toggle #### Notes: The user will interact with a toggle to change a Boolean value. This can also be displayed as a checkbox if desired. It will write ***`true`*** or ***`false`*** depending on the checked state. #### JSON Example: ``` "immortalserver": { "button_type": "toggle", "data_type": "numeric", "default_value": "false", "name_text_key": { "en-gb": "PVP Control", "en-us": "PVP Control", ... }, "name_text_key_hint": { "en-gb": "Restrict the in-game time each day for PVP (Player vs. Player)", "en-us": "Restrict the in-game time each day for PVP (Player vs. Player)", ... }, "modify_action": "none", "required": "false", "order": 0 } ``` #### slider #### Notes: The user will interact with a slider to change a value between min (Inclusive) and max (Inclusive), this is moved by each step. It is not required to be displayed as a real slider, and should always have an input box. ***`slider_suffix`*** is a special attribute * This is to describe the unit of measurement for the slider * E.g 3KM * This will display to the right of the value. * This is an optional value which may not be added when nothing needs to be displayed. * See the Translations section for the format. #### JSON Example: ``` "worldsize": { "modify_action": "none", "default_value": "2000", "button_type": "slider", "name_text_key": { "en-gb": "Worldsize", "en-us": "World Size", ... }, "data_type": "int", "max": "3000", "min": "1000", "step": "500", "slider_suffix": { "en-gb": "KM", "en-us": "km", ... } "name_text_key_hint": { "en-gb": "The size of the map to generate", "en-us": "Size of the world to generate", ... } } ``` #### select #### Notes: The user will interact with a combo-box to select a single value from a dropdown. The ***`default_value`*** attribute will be the value of one of the objects in ***`special_values`*** ***`select_values`*** is a special attribute: * This will contain an array of objects. * Each object contains the following attributes: * ***`value`*** * This is the value of the option when it is selected * ***`name_text_key`*** * This is the name that will be shown to the user. * This will display in the combo box * See the Translations section for the format. * ***`name_text_key_hint`*** * This will describe what this option is used for. * This will display when the button is highlighted or adjacent. * See the Translations section for the format. #### JSON Example: ``` "blueprint_wipe_schedule": { "modify_action": "none", "default_value": "", "button_type": "select", "name_text_key": { "en-gb": "Blueprint wipe", "en-us": "BP wipe", ... }, "data_type": "string", "select_values": [ { "value": "", "name_text_key": { "en-gb": "None", "en-us": "Nothing", ... }, "name_text_key_hint": { "en-gb": "No Blueprint wipes", "en-us": "Blueprints will not wipe", ... } }, { "value": "monthly", "name_text_key": { "en-gb": "Month", "en-us": "Monthly", ... }, "name_text_key_hint": { "en-gb": "Monthly Blueprint wipes", "en-us": "Blueprints will wipe once a month", ... } }, { "value": "weekly", "name_text_key": { "en-gb": "Week", "en-us": "Weekly", ... }, "name_text_key_hint": { "en-gb": "Weekly Blueprint wipes", "en-us": "Blueprints will wipe once a week", ... } }, { "value": "daily", "name_text_key": { "en-gb": "Daily", "en-us": "Day", ... }, "name_text_key_hint": { "en-gb": "Daily Blueprint wipes", "en-us": "Blueprints will wipe once a day", ... } } ], "name_text_key_hint": { "en-gb": "How often will blueprints wipe?", "en-us": "Wen wipe?", ... } } ``` #### multiselect #### Notes: The user will interact with a combo box to select multiple values. Once a value is selected, this must not show in the list anymore as the number of options may be large. Every option selected will add a separate line to the the ***`server.cfg`*** (See the Server configuration file (server.cfg) section) file unless the `flags` attribute is specified. The ***`default_value`*** attribute will be an array values for each selected value in the ***`special_values`*** objects ***`select_values`*** is a special attribute: * This will contain an array of objects. * Each object contains the following attributes: * ***`value`*** * This is the value of the option when it is selected * ***`name_text_key`*** * This is the name that will be shown to the user. * This will display in the combo box * See the Translations section for the format. The `flags` attribute will change the behaviour of how the options are parsed and written to the ***`server.cfg`*** (See the Server configuration file (server.cfg) section). * This is a bitmask value. * Each bit indicates the following * `0 (0)` * This is a regular default behaviour multiselect. * `1 (1)` * This is the flag for `Combing` the result of the multiselect. * This means that the values are numeric in nature * All the final values must be added together into one final value * One line must written to the the ***`server.cfg`*** (See the Server configuration file (server.cfg) section). * Please ensure to respect bit 3. * `2 (2)` * This is the flag for `Concatenation` of the results of the multiselect. * All the final values must be added together into one line with spaces separated each value. * One line must written to the the ***`server.cfg`*** (See the Server configuration file (server.cfg) section). * `3 (4)` * This is the flag for indicating that the values of the multiselect are `Bitmask Values.` * This means that the values are numeric in nature * These must be bit-shifted left \[1 << value] before writing to the the ***`server.cfg`*** (See the Server configuration file (server.cfg) section). #### JSON Example: ``` "addoffshoremonument": { "button_type": "multiselect", "data_type": "int", "default_value": [ "", ... ], "name_text_key": { "en-gb": "Enabled ofshore monuments", "en-us": "Offshore monuments", ... }, "name_text_key_hint": { "en-gb": "Select your offshore monuments here", "en-us": "Select your monuments here", ... }, "modify_action": "wipe_map", "required": "false", "order": 0, "flags": "1", "select_values": [ { "value": 0, "name_text_key": { "en-gb": "Oilrig Large", "en-us": "Large Oilrig", ... }, }, { "value": 1, "name_text_key": { "en-gb": "Oilrig Small", "en-us": "Small Oilrig", ... }, }, { "value": 2, "name_text_key": { "en-gb": "Cargoship that ships", "en-us": "Shipping Cargoship", ... }, }, { "value": 3, "name_text_key": { "en-gb": "Military Cargoship", "en-us": "Cargoship Military", ... }, } ], "name_text_key_hint": { "en-gb": "What offshore monuments are enabled?", "en-us": "Toggle sea monuments", ... } } ``` ## Presets Presets are currently provided and compressed inside of the game server build files, multiple presets can be in the build and may be unique to an environment. A preset name is found in the file name and follow the following formats. > ***`preset_.7z`*** Inside of the compressed file will always contain these files: * ***`cfg.json`*** * This is the Preset object JSON for the options to be applied when selected. * ***`combined.png`*** * The icon to display when showing a list of presets. * The provider may want to convert this to a format which suits them best (E.g .webp) The preset can optionally contain: * ***`.map`*** * ***`.sav`*** When a user selects a preset this must apply all the preset options to the current ***`server.cfg`*** (See the Server configuration file (server.cfg) section). If specified, an option may become locked, which must prevent the user from changing the option as it may exceed the bounds of the option. The provider is expected to track the selected preset in the event that the user wishes to remove it. ### Preset Object #### Notes: A preset in the JSON are under a name, this is the unique name of the preset. The preset will contain “preset options”, many options can be present in the object as these specify the values of the options to be added to the configuration file. #### JSON Example: ``` { "preset_1": { "option_preset_1": { ... }, "option_preset_2": { ... } } } ``` ### Preset Options #### Notes: All preset options contain the following attributes: * ***`value`*** * This is the value to update the ***`server.cfg`*** (See the Server configuration file (server.cfg) section) to when the preset is selected. * It is important to note that values of presets may exceed the given bounds of the option. * ***`locked`*** * This indicates whether the user can change the value on the webpage when the preset is applied. * This option is unlocked when the preset is reset. * Values * ***`true`*** * ***`false`*** #### JSON Example: ``` "hostname": { "value": "This is an awesome server name", "locked": "true" } ``` ### Translations #### Notes: Translations can be mapped to any language the site supports. If the site supports a language that is not supplied from RCE, the site should default to the core demographic of the site while the provider collects the translation. The provider should be aware that due to automatic page generation, new translations might be required at any time. All translations added are from all the languages the game supports and are identified by the language code as follows: * ***`de-de`**** ****(German)*** * ***`en-gb`**** ****(English UK)*** * ***`en-us`**** ****(English US)*** * ***`es-es`**** ****(Spanish)*** * ***`fr-fr`**** ****(French)*** * ***`it-it`**** ****(Italian)*** * ***`ja-jp`**** ****(Japanese)*** * ***`ko-kr`**** ****(Korean)*** * ***`nl-nl`**** ****(Dutch)*** * ***`pl-pl`**** ****(Polish)*** * ***`pt-br`**** ****(Portuguese)*** * ***`ru-ru`**** ****(Russian)*** * ***`sv-se`**** ****(Swedish)*** * ***`zh-ch`**** ****(Simplified Chinese)*** * ***`zh-hk`**** ****(Traditional Chinese)*** #### JSON Example: ``` "name_page_title": { "de-de": "Server-Einstellungen", "en-gb": "Server settings", "en-us": "Server settings", "es-es": "Configuración del servidor", "fr-fr": "Paramètres du serveur", "it-it": "Impostazioni del server", "ja-jp": "サーバーの設定", "ko-kr": "서버 설정", "nl-nl": "Server instellingen", "pl-pl": "Ustawienia serwera", "pt-br": "Configurações do servidor", "ru-ru": "Настройки сервера", "sv-se": "Serverinställningar", "zh-cn": "服务器设置", "zh-hk": "伺服器設定" } ``` ## Important Note There are some requirements which are not visible on this page which involve the platforms we support due to being sensitive data, please contact the RCE team to discuss these further.