Permissions

Description

Permissions control player and administrator access to features that check these identifiers. The configuration assigns Steam IDs to groups and lets you define permissions shared by all players.

Configuration

Default configuration

Permissions.json

{
  "m_Groups": [
    {
      "m_Name": "superadmin",
      "m_ForceName": 0,
      "m_Users": [
        {
          "m_Name": "Player Name",
          "m_Steam": "00000000000000000"
        }
      ],
      "m_Permissions": [
        "root"
      ]
    }
  ],
  "m_Everyone": []
}

Options

Option	Type	Description
m_Groups	array<object>	Player groups. A player can receive permissions from multiple groups; there is no inheritance based on group names.
m_Everyone	array<string>	Permissions granted to every player, including group members. To grant a permission only to administrators, place it in the corresponding group.

m_Groups[]

Option	Type	Description
m_Name	string	Administrative group name. The name "superadmin" does not grant privileges by itself.
m_ForceName	bool	With 0, a matching Steam ID is enough. With 1, the player’s current name must also exactly match m_Users[].m_Name to receive this group’s permissions. Checks the name; it does not rename the character.
m_Users	array<object>	Players belonging to the group. Replace the example entry with the administrator’s actual name and Steam ID.
m_Permissions	array<string>	Permissions added to accepted group members. Use the exact identifiers documented below.

m_Groups[].m_Users[]

Option	Type	Description
m_Name	string	Name associated with the entry. When m_ForceName is 1, it is also used to check the current name. The first accepted group entry with a nonempty name supplies the display name to the permission system.
m_Steam	string	The player’s 17-digit Steam ID, in quotes. The full value is compared: enter only the Steam ID, without comments or suffixes.

How permissions are combined

The player first receives permissions from m_Everyone, followed by those from every group where their entry is accepted. Group order does not remove permissions already received.

Identifiers are compared literally and are case-sensitive. Use lowercase names as documented. Wildcards such as command.* or admin.* are not expanded, and there is no automatic inheritance: admin alone does not grant every admin.* permission.

The root permission makes every permission check return true. Grant it only to users who should have full administrative access; placing it in m_Everyone grants that access to everyone.

Command permissions

Commands submitted through Chat check command.<name>, without the / prefix or arguments. For example:

Permission	Action
command.kick	Use /kick.
command.reload	Use /reload, including reloading permissions and other modules.
command.teleport	Use /teleport.

See Commands for the permissions and syntax of available commands. Granting a permission does not enable a disabled module or replace the command’s requirements.

Admin permissions

Permission	Action
admin	Allows enabling admin mode. The actions below may require this mode to be active as well as their specific permission.
admin.clipboard	Allows copying, cutting and pasting objects through admin tools.
admin.delete	Allows deleting objects through admin tools.
admin.freecam	Allows toggling the admin free camera.
admin.map.players	Allows viewing players on the admin map.
admin.map.teleport	Allows teleporting through the map using the corresponding admin action.
admin.moveobject	Allows moving objects through admin tools.
admin.nvg	Allows toggling admin night vision.
admin.teleport	Allows teleporting to the position indicated by the cursor.

Module access

The modules below check <module>.allow and <module>.deny at the indicated points. These permissions are not a universal rule for every module or operation.

Permissions	Check
chatmenu.allow, chatmenu.deny	Opening the Chat menu.
map.allow, map.deny	Opening the map through the Map module.
garage.allow, garage.deny	Opening the garage menu after receiving its data.
spawnselection.allow, spawnselection.deny	Access to spawn selection checked on the server.

The check follows this priority:

1. If the player has .allow, access is granted.
2. Otherwise, if they have .deny, access is denied.
3. With neither permission, access is granted.

If both are present, .allow wins. Since root also satisfies the .allow check, it grants access even when .deny is present.

To restrict the map to a group, for example, add map.deny to m_Everyone and map.allow to the authorized group. The Banking module does not check banking.allow or banking.deny.

Configuration example

In this example, the owner receives root, the moderator can use /kick and /reload, and the map is available only to these two groups. Steam IDs are illustrative; replace them with actual IDs.

{
  "m_Groups": [
    {
      "m_Name": "superadmin",
      "m_ForceName": 0,
      "m_Users": [
        {
          "m_Name": "Server Owner",
          "m_Steam": "76561198000000001"
        }
      ],
      "m_Permissions": [
        "root"
      ]
    },
    {
      "m_Name": "moderator",
      "m_ForceName": 0,
      "m_Users": [
        {
          "m_Name": "Moderator",
          "m_Steam": "76561198000000002"
        }
      ],
      "m_Permissions": [
        "command.kick",
        "command.reload",
        "map.allow"
      ]
    }
  ],
  "m_Everyone": [
    "map.deny"
  ]
}

Commands

/reload permissions

Reads Permissions.json again and sends updated permissions to connected players. The configuration is stored in $profile:AC/Permissions.json, where $profile: is the server profile directory.

• Syntax: /reload permissions
• Arguments: permissions identifies the permission system to reload.
• Permission: command.reload or root.
• Example: /reload permissions

The initial administrator configuration can be applied by restarting the server. To reload through chat, the player running the command must already have one of the permissions above before reloading.