Chat auto-moderation lets your Arma Reforger server police its own chat. You write a rule — a word, a phrase, or a pattern — and tell it what to do when someone types something that matches: kick them, or ban them for a set time. The panel watches the live chat feed, checks every message against your rules, and acts for you, so a slur or a spam line gets dealt with at three in the morning whether or not an admin is online. This feature is built around safety: a brand-new rule never bans anyone until you have watched it work and explicitly armed it, and several backstops sit underneath so a clumsy rule can never mass-ban your server. This guide walks through what Triggers are, how to build a rule, the match types, and — most importantly — the log-only-then-arm workflow that keeps you in control. Whether you searched for Reforger chat moderation, auto-kick on a word, or an auto-ban bot for Arma, everything you need is below.
What Chat Triggers Are
A trigger is a single rule that pairs a pattern with an action. The pattern is the text you are watching for in chat; the action is what happens to a player whose message matches. The panel reads your server’s chat feed on a short loop, runs each message past every enabled rule, and — once a rule is armed and the feature is switched on — automatically kicks or bans the player who sent it. You can have as many rules as you like, each with its own pattern, action, channel filter, and protections, all listed together on one screen for the server.
Rules only ever act on real chat messages from a connected player. A system line, a join notice, or any message the feed can’t tie back to a specific player identity is read and ignored — the panel can’t kick or ban someone it can’t identify, so those lines never trigger anything.
Note: A trigger is one rule = one pattern + one action (kick or ban).
Note: Triggers act only on chat from an identifiable player — system and unattributable lines are skipped.
Note: This feature is Arma Reforger only. It does not appear on other game types.
Before You Start: RCON and WCS_Commands
Two things have to be in place before Triggers can do anything, because the feature borrows them to see chat and to act.
First, RCON must be enabled on the server. Kicks and bans are sent over RCON, the same admin channel the RCON console uses, so a server without RCON set up has no way to carry out an action. The panel has a one-click Enable RCON setup on the RCON console screen that claims a port, sets a strong password, and prepares the config for you; you restart once and RCON is live.
Second, the server needs the WCS_Commands integration active. That is the mod that writes the structured chat-event feed the panel reads — without it, there is no chat stream to watch. The Triggers screen shows a WCS status so you can see at a glance whether it is active. If it isn’t, the panel can add WCS_Commands to your mod list for you from the RCON console’s compatibility section; you restart the server so Reforger downloads and loads the mod, and the status flips to active. The auto-moderation worker quietly does nothing on any server where WCS isn’t active — it never errors, it just waits.
Note: RCON must be enabled (kicks and bans travel over it).
Note: WCS_Commands must be active — it is the source of the chat feed the rules read.
Tip: Both prerequisites have one-click setup on the RCON console screen; each needs a single server restart to take effect.
Building a Rule: The Match Types
When you create a rule you give it a name and choose how its pattern is matched against chat. There are four match types, and the one you pick decides how strict the match is.
Contains is the loosest: the rule fires if the pattern appears anywhere inside a message. It is the default and the easiest to reason about — “free vbucks” as a contains rule matches any line that includes that phrase.
Exact is the strictest: the whole message, trimmed of surrounding spaces, must equal the pattern. Use it when you want to catch a specific one-word spam line and nothing else.
Word is the false-positive killer, and it is the right choice for slur and bad-word lists. It matches your pattern only as a whole word, so a rule for “ass” matches “ass” on its own but never fires on “class” or “pass”. This is usually what you want for profanity, because a plain contains rule on a short word catches a lot of innocent messages.
Regex is for advanced patterns — a regular expression you write yourself, for things like “any of these five spellings” or “a phrase with numbers mixed in”. The panel checks your expression the moment you save it: it has to actually compile, and it refuses anything that would match every line (a bare .*, ^, an empty match, and similar catch-alls are rejected with a clear message). At runtime the engine runs your expression defensively and fails closed — if a pattern ever misbehaves, the result is “no match”, never “match everyone”. That guard is deliberate: a greedy regex must never be able to ban the whole server.
Each rule also has a case-sensitive option, which is off by default. Left off, “BadWord”, “badword”, and “BADWORD” all match the same rule; turn it on only when capitalisation actually matters.
Tip: Use Word for profanity and slur lists — it won’t fire on “class” or “pass”.
Tip: Use Contains for advertising and spam phrases.
Tip: Keep case-sensitive off unless you genuinely need to tell “Word” from “word” apart.
Note: Every pattern — contains, exact, word, or regex — is capped at 512 characters.
Note: Regex patterns are validated when you save — one that won’t compile, or a catch-all that would match every line, is rejected on the spot.
Channels: Where the Rule Listens
Reforger chat is split into channels, and a rule can listen to all of them or just some. The channels are GLOBAL, TEAM, SQUAD, DIRECT, VEHICLE, and GROUP. By default a rule is set to “any”, meaning it watches every channel. If you set a channel filter instead, the rule only fires on messages sent in the channels you chose — for example, you might enforce an English-only rule on GLOBAL but leave TEAM and SQUAD alone so squads can talk freely.
When a rule has a specific channel filter, a message the feed can’t attribute to a channel is treated as out of scope and won’t match — the rule only acts when it can confirm the message was sent in one of its selected channels.
Tip: Leave the channel filter on “any” for slur and spam rules — you want those caught everywhere.
Tip: Use a channel filter for rules that should only apply in public chat (GLOBAL) and not in team or squad comms.
Kick or Ban (and the Reason)
Each rule does one of two things when it fires: kick or ban.
A kick removes the player from the server immediately; they can reconnect. It is the gentler choice for a first offence or for spam.
A ban keeps them out. When you choose ban you also set a duration in seconds — and a duration of zero means a permanent ban. A timed ban lifts itself when the clock runs out. Bans are placed against the player’s durable identity rather than their current connection slot, so the ban sticks even after they disconnect.
You can attach an optional reason — a short single line — to a rule. For a ban, the reason is sent along with the ban and saved to the server’s durable ban record, so it shows up where bans are listed and gives a stated cause. For a kick, the reason is stored on the rule but is not sent to the game — a kick goes out as a bare kick command — so there the reason is really just a note to yourself on the rule definition.
Note: Ban duration is in seconds; 0 = permanent.
Note: The reason is only transmitted for bans (and saved to the ban record). A kick does not carry the reason to the server.
Tip: Start most rules as a kick. Reserve bans for repeat or serious offences, and use a finite duration unless you really mean “never again”.
The Safety Model: Log-Only, Arming, and the Master Switch
This is the most important part of the whole feature, and it is what stops auto-moderation from being dangerous. Nothing your rules do reaches a real player until three separate gates all line up.
Every new rule starts in log-only mode. No matter what you put in the form, a freshly created rule is a dry run: it watches chat and records every match, but it kicks and bans absolutely nobody. The panel even tells you so when you create it — the rule is created “log-only”. This is on purpose, so you can build a rule and watch it work with zero risk.
Arming a rule is a separate, deliberate step. To make a rule actually act, you switch it from log-only to enforce. That is its own action with its own confirmation, kept apart from ordinary editing precisely because it is the dangerous toggle. The panel confirms it back to you in plain words — an armed rule reports as “ARMED (enforcing)”, and switching it back reports “set to log-only”.
The master switch sits over everything. There is one per-server on/off switch for the whole auto-moderation feature, and it defaults to off. Even a fully armed, enforcing rule does nothing while the master switch is off. So the complete path to a live auto-ban is: create the rule (log-only), watch it, arm it (enforce), and then turn the master switch on. Turn the master switch off at any time and the entire feature goes quiet instantly, every rule with it — it is your kill switch.
There is one more piece of built-in care, with one nuance worth understanding. The very first time you turn auto-moderation on for a server — and again whenever the server restarts (Reforger rotates to a fresh log) — the panel marks its place at the current end of the chat feed and starts from there, so a brand-new rule never reaches back and acts on chat that happened before it existed. This “start from now” seeding is tied to that first enable and to server restarts, not to the master switch itself: if you turn the master switch off and then back on without restarting the server, the panel resumes from where it left off and will work through any chat that arrived while it was paused (as far back as is still inside the recent feed window). So a re-enable is not a fresh “start from now” — if you want auto-moderation to forget everything before this moment, restart the server.
Note: Three gates must all line up before anything happens: the rule must be in enforce, the master switch must be on, and the rule must be enabled.
Note: New rules are always log-only. Arming (enforce) is a separate confirmed action.
Tip: The per-server master switch is your kill switch — turning it off silences every rule at once.
Note: The first enable (and every server restart) seeds the feed position to “now”, so a new rule never acts on older chat. Turning the master switch off and back on without a restart does not re-seed — it resumes from where it left off and can act on chat that arrived while it was paused. Restart the server for a hard “start from now”.
Watch It First: The Dry-Run History
Because every rule starts in log-only, you get a free preview of exactly what it would do. Each rule keeps a history of its recent matches, and you can open that list to see who matched, in which channel, what their message was, and the outcome the panel recorded for it. While a rule is in log-only, every match shows up with a “logged” outcome — meaning “this would have matched, but I did nothing”. Once a rule is armed, the same history shows real outcomes: “kicked” or “banned” when it acted; a suppressed outcome when one of the safety limits held the action back — recorded specifically as “suppressed_cooldown” (the player was inside the cooldown window), “suppressed_cap” (the per-tick action cap was already hit), or “suppressed_no_guid” (the message had no identifiable player to target); or “error” if the kick or ban couldn’t be delivered to the server.
This dry-run history is the confidence-builder. The right workflow is to create a rule, leave it in log-only for a while, open its match history, and confirm it is catching what you want and nothing innocent. Only when the logged matches look clean do you arm it. Each rule also keeps simple counters — how many times it has matched in total, how many times it has actually acted, and the text of its most recent match — so you can tell at a glance which rules are doing the work.
Tip: Leave a new rule in log-only until its match history looks clean, then arm it. The dry run costs you nothing.
Tip: A “logged” outcome means the rule matched but took no action — that’s the dry run working.
Cooldowns, Caps, and the Circuit Breaker
Underneath the obvious controls sit several automatic backstops that bound how much any rule can do. You don’t have to configure most of them; they are always on.
Per-player cooldown. Each rule has a cooldown, in seconds, that stops it from acting on the same player over and over in quick succession. After a rule kicks or bans someone, further matches from that same player within the cooldown window are suppressed. The cooldown defaults to 60 seconds and can never be set below 10 — a deliberate floor so a single chatty player can’t be hit again and again in one breath. You can raise it as high as a full day.
Per-burst limits. On any single pass the panel will execute only so many actions, and it will act at most once per player per pass — so a spam flood arriving all at once can’t turn into a wall of bans in one go. Anything held back simply gets reconsidered on the next pass.
The circuit breaker. This is the big one for protecting yourself from a rule that is broader than you realised. If a single rule ends up acting against more than ten different players inside a five-minute window, the panel decides the rule is mis-scoped and automatically disarms it — it drops the rule back to log-only and leaves it enabled, so it keeps watching and logging but stops banning. The action is recorded so you can see it happened. In other words, a rule that suddenly starts catching everyone trips its own breaker and stands down before it can do real damage.
Note: The per-player cooldown floor is 10 seconds; the default is 60. One player can’t be ban-stormed.
Note: The circuit breaker auto-disarms any single rule that acts on more than 10 distinct players in 5 minutes, dropping it back to log-only.
Tip: If a rule keeps disarming itself, it is matching far more than you intended — narrow the pattern (try word instead of contains) and watch its log-only history again.
Protecting Admins with the Allowlist
Every rule can carry an allowlist of player identities (GUIDs) that it must never act on. The allowlist is checked first, before anything else — if the player who sent a message is on the rule’s allowlist, the rule simply does not match them, full stop. Put your admins, staff, and trusted regulars on the allowlists of your harsher rules so an auto-ban can never catch the very people running the server. You enter identities one per line, and the panel tidies them up for you.
Tip: Add your admins and staff to the allowlist of any ban rule — the allowlist wins over everything, so they’re untouchable by that rule.
Who Can Manage Triggers
Auto-moderation is split into two permission levels so you can let a moderator watch without letting them change how the server polices itself.
Viewing the rules, their settings, and their match history needs only the basic moderation view permission — the same low bar as reading the player roster or the ban list. A moderator can see what the rules are and what they’ve been doing.
Changing anything — creating a rule, editing one, arming or disarming it, deleting it, or flipping the master switch — sits behind the higher Startup permission tier, the same level that controls Enable RCON and other server-configuration changes. The server owner has all of this by default, as do panel staff. Every create, edit, arm, delete, and master-switch flip is written to the server’s activity log, so there is a clear record of who changed the server’s auto-moderation and when.
Note: Reading rules and history needs moderation view; creating, editing, arming, and the master switch need the Startup permission tier.
Note: Every change to a trigger is logged to the server’s activity log.
Putting It Together
The whole feature is designed so the cautious path is the easy one. Enable RCON and make sure WCS_Commands is active. Create a rule — a word, phrase, or pattern, with a kick or a ban and an optional reason — and remember it begins life as a harmless log-only dry run. Watch its match history until you trust it, add your admins to its allowlist if it bans, then arm it and turn on the master switch. From there the panel handles the chat for you, with the cooldown, the per-burst caps, and the circuit breaker all standing guard underneath so a single bad rule can never run away with your server. And if you ever want it all to stop, the master switch turns the entire thing off in one click.