Map Editor Permissions

Two things to decide: which system decides who is staff, and which staff may do what.

The four modes

-- config.lua
Config.Permission = {
    Mode = 'both',
    Ace = 'rm_mapeditor.use',
    VorpGroups = { 'admin', 'moderator' },
}

Mode	Who passes
'ace'	Only players holding the ACE
'vorp'	Only players in one of VorpGroups
'both'	Default. Either one is enough
'everyone'	Everybody

'everyone' is for a private test server

It hands every connected player the ability to place, delete and — depending on your other grants — remove the game's own props for everyone and export your maps. There is no second check behind it.

VORP groups are read from the used character's group. If vorp_core is not started, the VORP half simply never passes, so 'both' degrades to 'ace' rather than locking you out.

The six grants

Each capability has its own ACE:

add_ace group.admin      rm_mapeditor.use    allow   # open the editor and place props
add_ace group.admin      rm_mapeditor.delete allow   # delete placed objects
add_ace group.superadmin rm_mapeditor.world  allow   # remove game world props
add_ace group.superadmin rm_mapeditor.export allow   # export maps
add_ace group.superadmin rm_mapeditor.import allow   # import maps
add_ace group.superadmin rm_mapeditor.manage allow   # create, rename and delete maps

Capability	Config key	Lets them
use	Config.Permission.Ace	Open the editor and place objects
delete	Config.Permission.Delete	Delete placed objects
deleteWorld	Config.Permission.DeleteWorld	Remove the game's own props, for everyone
export	Config.Permission.Export	Export maps
import	Config.Permission.Import	Import maps
manage	Config.Permission.Manage	Create, rename and delete maps

Anything you do not set falls back to rm_mapeditor.use

That is a convenience, not a safety net. Grant someone use and say nothing else, and they can also delete objects, remove world props, export, import and delete maps — because every unset capability resolves to the one ACE they hold.

If you want a builder who cannot destroy things, you have to name the other five explicitly and withhold them.

A builder who cannot break anything

Grant use to your builders and keep the destructive capabilities on a higher group:

add_ace group.builder    rm_mapeditor.use    allow
add_ace group.builder    rm_mapeditor.delete allow

add_ace group.superadmin rm_mapeditor.world  allow
add_ace group.superadmin rm_mapeditor.export allow
add_ace group.superadmin rm_mapeditor.import allow
add_ace group.superadmin rm_mapeditor.manage allow

Because the ACEs are named separately in config.lua, you can also rename them to fit a permissions file you already have:

Config.Permission = {
    Ace         = 'myserver.mapper',
    Delete      = 'myserver.mapper.delete',
    DeleteWorld = 'myserver.admin.world',
    Export      = 'myserver.admin.export',
    Import      = 'myserver.admin.import',
    Manage      = 'myserver.admin.maps',
}

Every action is checked on the server

The interface hides what you may not do, but that is presentation. Each action is re-checked server-side when it arrives, so a modified client gains nothing by drawing a button it should not have.

A refused action is recorded. With the webhook enabled, permission_denied is one of the events it reports — on by default, see Server setup.

Removing world props is the one to think about

deleteWorld does not hide a prop for the person clicking. It removes it for every player on the server, permanently, recorded in rm_mapeditor_removed.

That is the capability most worth keeping on a small group. It is also reversible — removals are rows, and deleting the row brings the prop back — but nobody enjoys finding out which row it was.

Identity

Players are identified by their license: identifier. On a VORP server the character identifier is used instead when one is available, so audit rows and map ownership follow the character rather than the account.

Checking what a player actually has

rm_mapeditor_diag

from the server console reports the permission configuration as the server sees it. If someone is refused and you expect otherwise, check in this order:

1. Is Config.Permission.Mode what you think it is?
2. Does the ACE name in config.lua match the one in server.cfg?
3. Is there an add_principal putting the player in that group? This is the usual answer.
4. On VORP, is the character's group one of VorpGroups?