RedM admin tools: permissions, menus, blips and the habits that keep a roleplay server fair

Good moderation is mostly invisible. Players notice it when it fails: a report nobody answered, an admin who spawned his friends a wagon of gold, a ban with no evidence behind it. RedM admin tools make the job possible, but the tools are the easy half. This guide covers what txAdmin already gives you, how ACE permissions decide who is staff, what admin menus and admin blips are for, how to handle reports and evidence, and a checklist for a staff team players trust.

What txAdmin gives you out of the box

txAdmin comes with the RedM server build, and it is the tool you will use most. From its web panel:

• A live console. The server's own output, with a command line. Script errors appear here first.
• The player list. Everyone online, with their identifiers and history. Kick, warn or ban from the player's page.
• Bans that stick. A ban is stored against the player's identifiers, not their name, so a new character does not get round it.
• Scheduled restarts, with warnings to players before each one. Every six to eight hours is normal; the performance guide explains why.
• Admin accounts with their own permissions. Give each staff member their own login. With a shared password you can never tell who did what.

txAdmin does not replace an in-game menu. It can remove a player, but it cannot teleport to them or revive them. That is the framework's job.

ACE permissions: who counts as staff

ACE is the permission system built into the server, set in server.cfg. Two lines do almost everything. add_ace gives a principal (a group or a player) permission to an object (a command, or a permission a script checks). add_principal puts a player in a group, or puts one group inside another so it inherits everything that group has.

## What each rank may do
add_ace group.admin command allow              # every command
add_ace group.admin command.quit deny          # except shutting the server down
add_ace group.admin poggy.settings allow       # open the /poggy settings hub

## Admins inherit everything moderators have
add_principal group.admin group.moderator

## Who holds each rank (your staff's real identifiers)
add_principal identifier.fivem:1234567 group.admin         # owner
add_principal identifier.discord:123456789 group.moderator # moderator

Three things catch people out:

• Identifiers, not names. A display name can change; a fivem, license or discord identifier does not. txAdmin shows every identifier on the player's page.
• Resources need permission too. A script that restarts other scripts needs its own line, for example add_ace resource.poggy_core command.ensure allow.
• ACE is not your framework's admin group. VORP keeps its admin group on the player's user record in the database. RSG Core and QBCore RedM grant their ranks as ACE principals such as rsgcore.admin or qbcore.admin. A player can be admin in one system and nobody in the other, which is why "no permission" is the most common staff complaint on a new server.

Keep the staff lines in one block with a comment naming each person, so removing someone is one line.

Framework admin menus

Each framework has an in-game admin menu: VORP has vorp_admin, RSG Core has rsg-adminmenu and QBCore RedM has qbr-adminmenu. They differ in detail, but most cover teleporting, reviving, spectating, and giving items or money. Two rules make them safer to hand out:

• Split the powers by rank. Moderators need teleport, revive and spectate. Giving items and money belongs to one or two senior admins, because it is the power most often abused and the hardest to undo. If your menu cannot split its powers, give it to fewer people.
• Log the giving. If the menu can post to a Discord webhook, turn that on. If it cannot, staff write each spawn in the staff channel themselves.

Admin tools inside your scripts

Scripts carry their own staff commands, and each decides who may use them. Here is where the Poggy ones look. All of them are free, and all run on VORP Core, RSG Core and QBCore RedM through the free Poggy Core (Free).

Poggy Multijob (Free)'s panel is the one staff use most: every character with saved jobs, online and offline, with the active job, grade and label editable, and job presets applied in one click. Poggy Storage (Free) adds a Storages tab to /poggy: every storage in one table, to move, re-own or delete, manage who holds a key, and see what is inside. Its /adminshop is a free shop with every item on the server, so treat it as an item spawner and keep that ACE to senior staff. Poggy Util (Free)'s /removeobjects and /cleandead clear props and dead entities when an area fills up.

Seeing where players are: RedM admin blips

Admin Blips (Free) puts every player on an admin's map, labelled with their server ID and character name. Only staff see them. It is the fastest answer to "where is the player who just reported being stuck". It is also the tool most likely to cost you your players' trust if it is used for anything else.

Fair uses: answering a report, finding a stuck or bugged player, running an event, and checking a claim during an investigation. Not fair: an admin playing their own character with blips on. Their character now knows where the gang is hiding and where the sheriff is riding. Make it a written rule that blips are off while in character; each admin hides them with /ahb. Config.ALLOWED_NAMES narrows access to named admins. Blips update every 500 ms by default, and there is no reason to go lower.

Reports and evidence

Every ban should survive an appeal. That means evidence before action, written down.

1. One place for reports. A Discord ticket channel is the usual choice. Reports made in game chat are gone by the next restart.
2. Ask for the clip. Players who record are your best witnesses. Ask for the video and the time before you ask anyone for their side.
3. Check the logs. The txAdmin console, the player's history, and any Discord webhook your scripts post to. Poggy Storage can log job storages and armories to Discord; give the ones that matter, such as police evidence, a webhook.
4. Hear both sides, then decide. A staff member who is friends with either side hands the ticket to someone else.
5. Write down what you did and why, in the ticket or the player's txAdmin notes. The next admin to deal with that player needs it.

Settings changes leave a trail too. The /poggy hub keeps a history of every change: who, when, the old value and the new one, with undo. When the economy suddenly pays double, look there first.

Staff structure and rules

• Staff roleplay under the same rules as players, with admin powers off while in character.
• Nobody handles a case they are part of.
• Every item or money spawn has a reason written down.
• Every ban has evidence; a permanent ban gets a second opinion.
• Access goes the day someone leaves: the server.cfg line, the txAdmin login and the Discord role.

Remote management and backups

Most moderation happens from a home PC or a phone, not at the server. txAdmin's web panel covers players and the console. For the machine itself, Server Controller (from $2.99/mo) is a Windows app that runs beside the server, not a resource. The free version starts, stops and restarts the server and makes database and file backups with one-click restore. The paid version adds remote control from your home PC behind an auth key, an IP whitelist and optional per-device PINs, and Discord alerts when something fails.

Take a backup before any large admin action: a rollback, a wipe of a player's items, a round of bans after an exploit. How to back up a RedM server covers what to include.

Diagnostics for Poggy scripts

When a player reports that a Poggy script is broken, check it before opening a ticket. From the server console:

poggycore

Version, detected framework, what the framework can do, and the containers registered.

poggycore scripts

Every Poggy script that registered, with its version.

poggycore dependents

The scripts that stop when poggy_core stops, and their state.

poggycore selftest

Tests every framework call the scripts make, read-only.

/poggycore test

In game: a read-only check against your own character.

In chat these need the ACE command or poggycore, or a framework admin group. Updates and database changes run from the console only.

A moderation checklist

1. Every staff member has their own txAdmin login and their own server.cfg line.
2. Ranks are written down, with what each may do.
3. Item and money spawning is limited to senior staff and logged.
4. Admin blips are off while staff are in character.
5. Reports go to one channel, with clips and times.
6. Every ban has evidence and a note.
7. Restarts are scheduled and announced.
8. A backup runs nightly, and another is taken before any rollback.
9. Access is removed the day someone leaves.