Manage your servers by talking to an AI

Who you act for, the project this connection works in, its plan, and exactly what your role allows (permissions). Call it first.

Every game server of the project: id, game, status, how linking commands reach it, and for Rust servers of the Control Center their live state (online, players, map, framework, next wipe). Use the id with the other server tools.

One game server in detail. For a Rust server of the Control Center, "live" holds what the collector last saw: players, queue, FPS, entities, uptime, map, framework and version, connection level, RCON state and the next wipe.

Rename a game server, or turn it on or off. A server turned off runs no linking command and, for Rust, leaves the Control Center collection until it is turned back on; turning one on counts against the plan's server limit. Connection settings (addresses, passwords) are never changed here: they are typed in the panel. Confirm with the person before turning a server off.

Run the linking commands of every linked player again on one server, for instance after a wipe when players lost their rewards. At most once every 5 minutes per server.

The linking commands of a server: what runs on it when a player links (auth) or unlinks (deauth) a provider (steam_group_member, discord_guild_member, discord_guild_nitro, twitch_follower, twitch_subscriber). Commands use the placeholders {SteamID} and {SteamName}.

Add a linking command to a server: the console command run when a player links (auth) or unlinks (deauth) one provider. It runs for the next players who link, not for those already linked (resync-server does that). Placeholders: {SteamID} and {SteamName} (the linked player).

Change a linking command of a server (its command, event, provider) or turn it on or off.

Delete a linking command of a server. Players who link afterwards no longer get it; to stop it for a while, turn it off with update-linking-command instead. Confirm with the person first.

History of linking commands, newest first: the command sent, its status (awaiting, executed, failed, waiting_for_join), the server's answer and the player. Filter by server and/or player: the answer to "why did this player not get his reward?".

Send one linking command of the history again (3 tries at most per entry; not for servers on the Plugin connection, the plugin sends those itself).

Players who linked their accounts on the website (Steam, Discord, Twitch), newest first, with the result of each check (Steam group, Discord member and booster, Twitch follower and subscriber). Search by name or by any id.

One linked player by SteamID, Discord id or Twitch id: the linked accounts, the result of each check, whether they are banned from linking, and their last 10 linking commands.

Check a linked player again on every check the project uses (Steam group, Discord member and booster, Twitch follower and subscriber): rewards are given or taken back by the result, as when the player clicks "check" on the website. Once a minute per player.

Ban a linked player, like the Ban button of the Players page: they can no longer link, lose their rewards (deauth commands, Discord role) and, when the Control Center is on and your role may ban permanently, are also banned permanently from every Rust server. For a timed or partial game ban, use ban-player instead.

Lift the ban of a linked player, like the Unban button of the Players page: they can link again and their checks run again. When your role may unban in the Control Center, their game bans and mutes are lifted too; otherwise those stay.

The Discord notification cards of the project (links, support, and with the Control Center: server alerts, moderation alerts, wipe announcements, live server status, kill feed): on or off, who should read the channel (public or staff), the webhook (masked) and the events each card sends.

Turn a Discord notification card on or off, change its webhook, or choose the events it sends. Staff cards (links, support, server alerts, moderation) carry personal data: never point them at a public channel.

The players on a Rust server right now (asked over RCON): SteamID, name, ping, time connected, health. "live": false means the server did not answer and this is the last known list. IPs only for roles allowed to see them.

Population of a Rust server: the peak number of players for each hour over the last days (at most the plan's history). Use it to answer "when is my server busy?" or to compare before and after a wipe.

Console lines of a Rust server kept by Servycore, oldest first: the latest ones, or those after an id (to follow what a command printed). IPs are masked unless your role may see them.

Run one console command on a Rust server over RCON and read its answer. Any command for roles with console:execute; only the quick read commands (serverinfo, server.fps, server.save, bans, mutelist, users, buildinfo…) for console:quick. Every command is in the activity log. Never guess a command: an unknown one gets no answer, a wrong one can kick, ban, wipe or stop the server.

In-game chat of a Rust server (global and team), newest first, within the plan's history. Filter by player or text: useful to review a report or a toxic player before acting.

Write in the in-game chat of one Rust server, as SERVER. For the same message on several servers, use announce.

Show the same SERVER message in game on several Rust servers at once (every active server of the Control Center when server_ids is left out). Each server answers on its own.

Restart a Rust server over RCON with an in-game countdown and message (players see it, everyone is disconnected when it ends; the server is usually back in a few minutes). cancel-restart stops the countdown.

Stop the restart countdown of a Rust server (started from the panel, an automation or restart-server).

Plugins installed on a Rust server (Oxide or Carbon), read over RCON: version, author, loaded or failed with its error, hook time and memory. With check_updates, the latest release on uMod or Codefling and whether an update is available.

Search the uMod catalog (free) or Codefling (free and paid) for Rust plugins to install: name, title, author, version, downloads, page URL. Codefling results carry the file id install-plugin needs.

Install a plugin on a Rust server: from uMod by its name, or from Codefling by its file id (free, or paid ones the project's Codefling account bought). A plugin of the same name is replaced (its file kept in plugins/backups, its config and data stay). Needs host access and a plan with server files. Only install what the person named: name the plugin, its author and the server back to them first.

Update an installed plugin to its latest release, from where it is (uMod or Codefling), only when the release is by the same author. The old file is kept in plugins/backups. Needs host access and a plan with server files.

Load, reload or unload a plugin on a Rust server (oxide.* or c.* commands): reload applies a changed config, unload turns a plugin off until the next load or restart.

Every player seen on the project's Rust servers (linked on the website or not), most recently seen first: SteamID, name, first and last seen, sessions. Search by name or SteamID. get-player gives one in detail.

Everything the Control Center knows about one player by SteamID: names, first and last seen, where they are online, linked Discord and Twitch, time played, kills, deaths and reports over the plan's history, active bans and mutes, in-game staff roles and groups, staff notes and possible alt accounts (for roles allowed to see them). Read it before any moderation.

Kick a player from a Rust server (the server where they are online when server_id is left out), with the reason they see.

Ban a player from the project's Rust servers by SteamID: kicked if online and refused before they connect, on every server or only some. Timed with duration_minutes, permanent without it (a permanent ban, or one longer than a year, needs players:ban-permanent). The reason is shown to the player.

Mute a player in the in-game chat by SteamID, for a time (duration_minutes) or until unmuted, on every server or only some.

Lift every active game ban of a player (network-wide and per server). Their mutes stay: unmute-player lifts those.

Lift every active mute of a player.

Add a private staff note to a player (never shown to players): what happened, a warning given, evidence. Notes appear in get-player for roles allowed to read them.

Rust's combat log of a player on one server (the last hits given and taken: attacker, target, weapon, distance, body part, and the server's projectile checks). Evidence for a cheating report; needs a role that may ban.

Game bans and mutes of the network, newest first: who, why, until when, which servers. Active ones by default.

The F7 report inbox: reported players, the most reported first, with how many reports, how many different reporters, when, and the last reports (reason and message). Open reports by default.

Mark every open report against a player as handled (after checking or acting on them), or reopen the reports of the last days. Players are never told.

In-game roles and groups given from Servycore and still in force: staff roles (owner, moderator, skip queue) and groups (VIP and others), on which servers, until when, and whether they are applied yet (a grant waits until the player joins).

Put a player in an Oxide / Carbon group (a VIP group, for instance) for a time or for good, on every server or some: applied when the player is online or at their next join, removed by itself when it ends. Giving the same group again extends it.

Give a player an in-game staff role on the Rust servers: owner (full admin: ownerid), moderator (moderatorid) or skipqueue. An owner can do anything on the server, including ban other admins: only give it to someone the person named and trusts. Refused for a banned player.

Take back an in-game staff role or a group given from Servycore (ids from list-staff or get-player): removed from the servers now, or when the player is next seen.

The Control Center automations of the project ("when X happens, do Y"): name, on or off, trigger, actions, servers, last and next run, and the plan's limit of active automations. They are created and edited in the panel.

Turn an automation on or off, or run it now on its servers (not for triggers that need a player). What it does then happens on the servers (messages, commands, kicks…): read its actions in list-automations and confirm with the person first.

The Control Center activity log, newest first: staff actions (bans, kicks, messages, notes…, from the panel, the API or this assistant), console commands, automation runs, wipes. Answers "who did what, when".

Wipes, read only: the next Facepunch forced wipe, each Rust server's auto-wipe schedule (on or off, its rules, the next dates), its last wipe runs and how population grew over the last wipes. Wipes are scheduled and started in the panel only: this server never creates, changes or starts one.

Support tickets of the website: title, status, whether the staff answered, category, the player, the server, last reply. Open tickets by default; "unanswered" lists those waiting for the staff.

One support ticket with its whole conversation (player and staff messages), the player's Steam and Discord, the server and the custom fields of its category.

Reply to a support ticket as the staff, under the name of the person you act for: the player reads it on the website (and is notified). Read the whole ticket first, show the person the exact reply and wait for a yes. Players see it the moment it is sent: confirm first.

Close a support ticket once it is solved (the player can no longer reply), or reopen it.

Posts of the website blog, last edited first: title, published or draft, category, excerpt, the public url and the panel page. Drafts are included unless "status" narrows the list. The text of a post is left out here: read it with get-blog-post.

One blog post with its whole text (HTML, as the website shows it: to edit it, rewrite it as Markdown, never send HTML back), its category, its search engine title and description, whether it is published, the public url and the panel page.

Categories of the website blog (News, Patch notes, Events…) with how many posts each has. A post can be filed in one of them.

Write a post on the website blog (wipe notes, patch notes, events, rules). The text is Markdown (headings, lists, links, bold); HTML is dropped. It is saved as a draft the staff can review in the panel (dashboard_url). Set "publish" only when the person asked for it: show them the title and the whole text first and wait for a yes, because a published post is public at once.

Change a blog post: only the fields you send change. "content" replaces the whole text: read the post with get-blog-post first and send the whole text back rewritten as Markdown (HTML is removed, so HTML sent back would empty the post and is refused). "publish": true publishes a draft, false takes a post back to draft. A published post changes for every visitor at once: show the person the change and wait for a yes before editing a published post or publishing one.

Delete a blog post for good, with its images: it cannot be brought back. To hide a published post for a while, take it back to draft with update-blog-post instead. Name the post to the person and wait for them to confirm first.

Add a category to the website blog (for example "Patch notes"). Check list-blog-categories first: a category of the same name is refused.