Command permission checks

Throughout the config file you'll find various commands and their settings. You should be able to identify these from the term "command", which you may wish to search for.

An example command located in the config is titled stopFireCommand = {. This format is used for all commands, such as stopAllFiresCommand = { and startSmokeCommand = {.

Some commands will have additional configuration values within them, which will be covered in a further section.

We'll use the /startfire command as an example in order to explain how to setup permission checks for it. You will need to repeat these steps for each other command.

acePermissions = {
            enabled = false,
            -- This enables ace permissions on the start fire command
},

This first section determines if you want to enable ace permissions on the command. This means that the command will be restricted to those that have the ace permission which would be command.startfire allow.

For a guide on Ace Permissions, see this one here on the FiveM forum.

An example of how to give out this Ace Permission in the server.cfg is:

add_ace group.admin command.startfire allow

This would give the admin group the command.startfire ace, allowing them to use /startfire.

Many servers often use an Ace Permissions resource that links in with Discord permissions, you should be able to easily set this up with that as well, by giving people the right ace permission in the config of that other resource. We can provide assistance to a degree if you experience problems.

ESX / vRP / QB-Core

We've added support for these frameworks right out of the box, see the following information on configuring these for each command.

ESX = {
            enabled = false,
            checkJob = {
                enabled = true, -- Enable this to use ESX job check
                jobs = {"fire", "firefighter"} -- A user can have any of the following jobs, allowing you to add multiple
            }
},

This section allows you to enable the ESX integration for this command only. For ESX, we've added a job check and you can enable this by setting enabled to true in the checkJob section.

The jobs = {} table allows you to name jobs where a player can have any of them to use the command. Each job should be separated by a comma and wrapped in speech marks "".

vRP = {
            enabled = false,
            checkGroup = {
                enabled = false, -- Enable this to use vRP group check
                groups = {"fire", "admin"}, -- A user can have any of the following groups, meaning you can add different jobs
            },
            checkPermission = {
                enabled = false, -- Enable this to use vRP permission check
                permissions = {"player.kick"} -- A user can have any of the following permissions, allowing you to add multiple
            },
},

Similar to the ESX section, you can enable vRP integration for this command only by setting enabled to true.

For vRP however, you can either check for groups, permissions or even both. A user can have any permission specified (if enabled) and also any group specified (if enabled) to use the command.

You can enable groups by setting enabled to true in the checkGroup section and the same for permissions by setting enabled to true in the checkPermission section.

Groups and permissions are both defined in tables and must be separated by a comma, with each permission or group wrapped in speech marks "".

QBCore = {
            enabled = false,
            checkJob = {
                enabled = false, -- Enable this to use QBCore job check
                jobs = {"fire"}, -- A user can have any of the following jobs, meaning you can add different jobs
            },
            checkPermission = {
                enabled = false, -- Enable this to use QBCore permission check
                permissions = {"god"}, -- A user can have any of the following permissions, allowing you to add multiple
            },
},

To enable QB-Core integration, simply set enabled to true.

You can either check for jobs, permissions or even both. A user can have any permission specified (if enabled) and also any job specified (if enabled) to use the command.

To enable the job check, set enabled to true in the checkJob section and the same for permissions, by setting enabled to true in the checkPermission section.

Jobs and permissions are both defined in tables and must be separated by a comma, with each permission or job wrapped in speech marks "".

Last updated