Command Manager Variables
The chips under every text box insert a placeholder, not a value. What each one becomes, when it is filled in, which two need editing afterwards, and why {playerNames} is not the Send to every online player checkbox.
The one thing to understand first
Underneath every text box in the Command Manager there is a row of chips: Players online, Player names, Server name, Time, Date, Next run, One of these, Random number.
A chip inserts a placeholder, not a value. Clicking "Players online" puts the text
{players}into the box. It does not look up how many people are on and paste the number in. That is why the box still shows{players}after you click, and why it is meant to.
The real value is filled in on our side at the instant the command is sent to your server.
A message you write today has to still be right every time it goes out for the next six months. So what gets stored is the question, not one afternoon's answer.
The eight variables
| Chip | Inserts | What arrives at the server | Complete as inserted? |
|---|---|---|---|
| Players online | {players} | The number of people online right now | Yes |
| Player names | {playerNames} | Everyone online, comma separated. Empty when nobody is on | Yes |
| Server name | {server} | This server's name | Yes |
| Time | {time} | The current time, in the schedule's timezone | Yes |
| Date | {date} | Today's date, in the schedule's timezone | Yes |
| Next run | {nextRun} | When this schedule fires next | Yes |
| One of these | {randList:a,b,c} | One of your options, chosen at random | No - replace `a,b,c` |
| Random number | {randNum:1:100} | A whole number inside the range | No if you want a different range |
Six of the eight are finished the moment you click them. The last two carry example arguments you are meant to overwrite:
{randList:Build a bed before dark,Bank your loot,Repair your gear}
{randNum:1:6}Separate randList options with commas. Do not put a space after a comma unless you want that space in the output.
You can type any of these by hand rather than clicking, and use as many as you like in one message. Anything that is not a recognised variable is left exactly as you typed it, so text that happens to contain braces for another reason is safe.
When they are filled in
Values are worked out per step, at the moment that step runs - not once when the schedule fires, and not when you save it.
On a single-command schedule the difference is invisible. On a multi-step sequence it is the whole point.
| Step | Wait | Message | {players} reads |
|---|---|---|---|
| 1 | — | "Restart in 30 minutes - {players} online" | 12 |
| 2 | 20 min | "Restart in 10 minutes - {players} online" | 7 |
| 3 | 9 min | "Restart in 1 minute - {players} online" | 3 |
Each step reads the count when *it* runs, so the numbers fall as people log off.
Some scheduling tools resolve their equivalents once, when the trigger fires, and hand the same snapshot to every step. That makes the sequence everyone actually wants - "warn, wait five minutes, and if nobody is left, shut down" - impossible to write, because the player count the last step reads is five minutes stale. Ours re-reads it.
{nextRun} is the one worth learning
A hand-written "the server restarts in 30 minutes" is wrong the moment the run happens a few minutes late, and wrong again the day you change the schedule and forget the message.
{nextRun} reads the answer from the same schedule that will do the restarting. It cannot drift away from the thing it is counting down to, and it stays correct when you move the schedule.
Restart at {nextRun} - {players} online, log out safelyWrite that once and leave it alone.
{playerNames} is not the Send to every online player checkbox
These two get mixed up more than anything else in the Command Manager, and they do opposite things.
| What it is | What it sends | |
|---|---|---|
| `{playerNames}` | A variable inside a piece of text | One command, with the list of names written into it: say Online now: Ada, Bob, Cy. Nobody is targeted |
| Send to every online player | A checkbox beside a player parameter | The command once per person. Ten players is ten commands and ten log rows |
Announcing who is online is the variable. Giving every player an item is the checkbox. They do not interfere, so one schedule can use both.
The checkbox, including which identifier each game uses, is covered in the Command Manager Guide.
When a value cannot be read
{players} and {playerNames} both need the online roster.
| Token | If the roster is unreadable |
|---|---|
{players} | Resolves to ? |
{playerNames} | Resolves to nothing at all |
Reporting
?tells a reader the number is unknown. Reporting0would announce that nobody is online because a socket blinked - which is a lie your players will believe.
The other six do not depend on your game server, so they are always available.
Worked examples
A restart warning that stays true
Restart at {nextRun} - {players} online, log out somewhere safeA rotating hourly tip
Tip: {randList:Build a bed before dark,Bank your loot,Repair your gear at the anvil}Pair it with Run this set to "Only when players are online" so it is never shouted into an empty world.
A daily welcome
{server} - {date}. {players} adventurers online right now.A random giveaway amount
Lucky drop: {randNum:50:250} coins to whoever is onlineVariables work in any text parameter, not only in messages. If you want the amount granted to vary as well, put the variable in the command's own amount field.
Per-game notes
| Game | Worth knowing |
|---|---|
| Windrose | No broadcast, say or chat command exists, so variables are only useful inside a Custom Command |
| Minecraft | Roster questions go over RCON, not the one-way console - which is why {players} works even though commands come back unconfirmed |
| Palworld | Needs AdminPassword set, or the roster cannot be read and {players} resolves to ? |
| Valheim | Reads the roster from the GameGrid Bridge plugin. No bridge, same ? |
| 7 Days to Die | Reads it over telnet |
From Discord and the API
Variables are resolved on our side, so they behave identically however the schedule was made. {nextRun} typed into /command-schedule create works exactly as it does in the panel.
Over the API they travel as ordinary text inside commandParams:
{ "commandType": "say",
"commandParams": { "message": "Restart at {nextRun} - {players} online" } }See Command Manager API.
