Admin commands

A server's administrators, often called game masters (GMs), have a set of chat commands for testing and running the game: moving anywhere, granting experience, items and currencies, starting events, resetting instances and more. This page lists every one of them, taken from the server's code.

They are typed in the chat box like the player commands: /c, a space, then the command, for example /c tp next. A chat line that starts with ! works too (!tp next), and so does /c !tp next. The answer appears in your own chat window as a System line.

Many of these commands come from NexusForever's command set and keep its names and forms; the sections below say which. The rest were added in Bezgelor for testing the systems built here. The commands every player can use (/c bug, /c why, /c stuck, /c remember, /c progress) are in the player guide, Typing commands.

Roles and permissions

Each admin command needs a permission, and an account gets permissions from its roles. The tables below give the permission of every command in their second column. The design is in Roles and permissions; this section is what a server owner needs.

Risk tiers

Every permission belongs to a part of the game (its domain: characters, quests, items, economy, world, housing, guilds, social, mail, accounts, server, portal) and to one of six risk tiers:

The roles

The server comes with seven roles. Each is a rule over the tiers and domains, so a permission added in a later version reaches the right roles by itself.

The built-in roles cannot be deleted and their rules cannot be changed on the website: the server sets them at every start.

Giving someone a role

• Your first administrator has to be made from the server's shell, because nobody can open the admin pages yet. Make the account on the website, then, in the shell scripts/start.sh opens:

  BezgelorDb.Release.grant_role("you@example.com", "Super Admin")

  With a release, run the same function through the release's eval command: bin/bezgelor eval 'BezgelorDb.Release.grant_role("you@example.com", "Super Admin")'.

• Anyone after that can be given a role on the website by a Super Admin: Admin, Users, the account, then Manage Roles. The person must turn on 2-Step Verification (Settings) first: the website refuses any role with a staff permission to an account without it. You can also use grant_role as above, with "Game Master", "Senior GM" or any other role's name.

• Permissions are looked up each time a command is typed, so a new role works at once, without logging out. Removing the role (the same dialog) takes the commands away just as quickly.

• The website's own admin pages (/admin) also need 2-Step Verification on the account, and each page needs its own permission (the menu shows only the pages you may open). The chat commands do not need 2-Step Verification.

A role of your own

When none of the built-in roles fits, make one: Admin, Role Management, Create Role, then Edit on its card. A new role starts with nothing. On the edit page:

1. Tick risk tiers to give them in every domain. Ticking read and assist makes a helper who can look at everything and teleport, revive and whisper.
2. Tick domains to give every tier in them. Ticking social gives all of moderation.
3. Tick or untick single permissions in the list below. Ticking one the tiers and domains do not give includes it; unticking one they do give excludes it. The list shows which are included and excluded.

For example, an event host could have the tier read, the domain world, and characters.teleport included: they can see everything, run public events and zone scripts and move around, but not change anyone's character or create currency. Save, then give the role to people as above. Because the role is a rule, a new world permission in a later version reaches the event host without anyone editing the role.

A role made before roles were rules keeps the list it had until someone edits it; the edit page then shows that list as included permissions.

The development switch

config :bezgelor_world, gm_commands_for_all: true makes every account on the server an administrator, whatever its roles. config/dev.exs turns it on, so a server started with scripts/start.sh (the development setup) lets anyone who logs in use every command on this page. Nothing in the production or runtime configuration sets it, so a release has it off.

Keep the switch off on any server other people play on. With it on, every player can give themselves items, money and levels, switch the death rules for the whole server, close other people's instances and change the store. If you run the development setup for friends, set gm_commands_for_all: false in config/dev.exs, or run a release instead (see Running your own server).

A release refuses to start with the switch on. Outside the development and test setups the world server checks the switch at boot and stops with an error that names gm_commands_for_all if it is true, so a public server cannot be started with everyone an administrator by mistake. Remove the setting to fix it. For a private test server where that is what you want, set the environment variable BEZGELOR_ALLOW_GM_FOR_ALL=1: the server then starts and logs a warning at every boot. In the development setup it starts and logs one line saying that everyone has admin commands.

Commands for everyone, and what is recorded

Without the switch or the permission, an admin command answers "You don't have permission to use this command" and names the permission it needs. A few forms are open to everyone (BezgelorWorld.Services.Commands.public?/2), because they only show your own state or are a stand-in for a store purchase:

The client's own /c command (which sends the ClientCheat message) and a chat line starting with ! run the same code with the same check. Every admin command typed by someone with a role, run or refused, is written to the audit log on the website (Admin, Audit Log; filter by gm_command.*): who typed it, the character, the whole command, the permission it needs and whether it ran. Moderators and game masters can read the audit log. Commands let through only by the development switch are not written there. The server's event stream also records each admin command as gm.command, with its first word only, never its arguments, and whether it was allowed.

The permission each command needs is set in apps/bezgelor_world/lib/bezgelor_world/command_permissions.ex, and the permissions themselves in apps/bezgelor_db/lib/bezgelor_db/authorization/registry.ex.

How to read this page

<id> is a value you must give; [something] may be left out. Most ids are the client's own table ids (a Creature2, Item2 or Spell4 id, a world id). The website's admin pages and the teleport shortcuts below help to find them. /c help prints a short list in the game.

The commands act on your own character, in the zone you are in, unless the line says otherwise.

Getting around

Teleport

From NexusForever's teleport commands. /c teleport can also be typed /c tp, /c tele or /c port.

Example: /c tp quest 5694 to reach a quest's giver, then /c tp next once you have taken it.

NexusForever's /c teleport name <zone> is not ported; it answers with a pointer to teleport location.

Bind point and recall

Character

Level, experience and class resources

From NexusForever's character commands.

Death

Mounts

Achievements, titles and reputation

From NexusForever's achievement, title and reputation commands.

Costumes, dyes and pets

Tradeskills

Items and money

From NexusForever's item and currency commands (the first two lines).

Account-wide currencies (Omnibits, NCoins, service tokens and so on) are under Account and store.

Quests and paths

Quests

For testing a quest without playing the ones before it. Each form takes a quest's number or words from its title; when several quests match you get a numbered list, and /c quest <form> <number> picks one.

prep also sends the earlier quests' accepted and completed events, so achievements that count quests count them. After prep or reset the client's quest log may only catch up after you log out and back in. With /c tp quest and /c tp next (above), testing a quest is /c quest prep <id>, /c tp quest <id>, take it, then /c tp next, or in one line /c quest setup <id> prep go. The Field Kit add-on's tester page runs the same steps from a window.

Paths

From NexusForever's path commands, with mission completion and the path mission test aids added. <path> is soldier, settler, scientist or explorer, or 0 to 3.

Lore, maps and tutorials

World and events

Public events and challenges

Instances

Group finder

Example: /c matching force 27 fast Tester2 starts a one-against-one in Walatiki Temple. In a battleground the players take the two sides in turn (you first, on Red), whatever their faction.

Housing

From NexusForever's house commands (teleport, decor add, decor lookup), with more added.

characters.teleport, the permission of /c house visit, also lets an account visit any residence through the game's own housing window, whatever its privacy.

Loot drops

Account and store

<currency> is an account currency id or a name: credd, realmtransfer, characterrename, essence, mysticshiny, omnibits, ncoins, loyalty (Cosmic Reward Points), servicetoken, protobucks, giantpoints, promotiontoken, promissorynote, redessence, blueessence, greenessence, purpleessence.

In the store's paid mode (the default), the premium currencies exist only through these grants and the website's account pages: there is no payment.

Social

Guilds

These skip the registrar's level, fee and travel, and fill what the game would take hours to earn. "Your guild" is the guild you belong to, or else your first circle.

Debugging

Scripts and creatures

From NexusForever's script commands (reload), with testing aids added.

The event stream

The server's event stream can record a fuller "debug" level of detail for chosen characters for a while.

Each switch is written to the audit log, as the same switch on the website is.