Restrictions
Restrictions are the central tool for enforcing server rules in dzbot. They let you decide what happens when a player or faction breaks a rule — and define exactly how the system should respond.
What a restriction does
A restriction connects three things:
- A trigger — what causes it to fire (an in-game event, or a manual decision by staff)
- A target — who it applies to (a specific player, all linked alt accounts, or an entire faction)
- One or more actions — what dzbot does when the restriction triggers (send a warning, deduct balance, issue a ban, post a Discord notification)
This approach replaces the old simple ban system. Instead of just saying "this player is banned", you can now define sophisticated rules like "if a player kills someone in the military zone for the third time, send them a warning DM, deduct 500 coins, and on the fifth offense issue a 7-day ban" — all automatically.
Types of restrictions
Ban (System Restriction)
A ban is a manually created restriction that blocks a player from joining the server. Bans are created by staff and synced to your Nitrado game server when Synchronize player lists is active.
Key properties:
- Has a start date and an optional expiry date (leave expiry empty for a permanent ban)
- Can target a specific player or an entire faction
- Can optionally catch alt accounts automatically (see Alt account coverage below)
- Can trigger actions on creation (for example send a notification to a staff Discord channel when the ban is issued)
Bans are managed in Admin → Restrictions.
Event Restriction
An event restriction fires automatically when specific things happen in the game — kills, deaths, chat messages, or any other imported log event.
You define:
- Which events trigger it (for example: kill events)
- Which players or factions it watches (targets)
- Where on the map it applies (optional zone — only trigger if the event happened inside or outside a drawn area)
- What happens when it triggers (actions)
- How escalation works (warn once, warn on every offense, act on the Nth violation)
Example use cases:
- Warn a player by Discord DM every time they kill in the safezone
- Deduct balance for repeated zone violations
- Automatically issue a temporary ban on the third safezone kill
- Post all kills by a specific faction to your moderator channel
- Alert staff when a particular suspected player does anything at all
Targets: who does it apply to?
Each restriction has one or more targets. A target is either a player or a faction.
Player target
A player target applies the restriction to one specific player.
Faction target
A faction target applies the restriction to all current members of a faction. Useful for monitoring or sanctioning an entire group.
Alt account coverage
When adding a target, you can enable Include all accounts. This tells dzbot to also apply the restriction to any other player accounts that share a device with the target.
This catches alt accounts: if a banned player creates a new character or uses a different account, dzbot recognises the shared device and applies the ban to that account too.
The same option is available on faction targets — if enabled, it covers all device-linked accounts of all faction members.
Actions: what happens when a restriction triggers?
Warning DM
Sends a private Discord message to the player who triggered the restriction. Useful for first or second warnings where you want the player to know they are being watched.
Channel notification
Posts a message to a Discord channel you choose. Ideal for notifying your moderation team when a rule is violated.
Balance penalty
Deducts an amount from the player's in-game balance. Useful as an economic deterrent for repeated violations.
Automatic ban
Creates a new ban restriction for the violating player. Use this as the final step in an escalation chain — after several warnings, dzbot bans automatically without requiring staff to act manually.
Escalation: controlling when actions fire
For event restrictions, you can control exactly when each action fires:
| Trigger | What it does |
|---|---|
| On every violation | Fires every single time the event occurs |
| On the Nth violation | Fires only on exactly the Nth offense (for example only on the 3rd) |
| From the Nth violation onward | Fires on the Nth offense and every one after that |
You can combine multiple actions with different trigger points on the same restriction. For example:
- On every violation: send a DM warning
- On the 2nd violation: deduct 300 coins
- From the 3rd violation onward: issue a 1-day ban
Zones: geographic restrictions
Event restrictions can optionally be limited to a specific area on the map. You draw a zone polygon directly on the map in the restriction editor.
When a zone is set, the restriction only triggers if the in-game event happened inside that area. You can also invert this — so the restriction only triggers if the event happened outside the zone.
Example: draw the military base perimeter as a zone, select "kill" as the event type. The restriction will now only fire for kills that happen inside the base.
Server default actions
Server default actions are actions that apply to all event restrictions on your server unless a specific restriction opts out.
This saves you from adding the same "notify moderation channel" action to every single restriction. Set it once as a server default and it fires automatically for every event restriction that triggers.
Server defaults support:
- Warning DM to the player
- Channel notification to a Discord channel
They do not support balance penalties or automatic bans (those should always be configured explicitly per restriction).
A restriction can opt out of server default actions by enabling Ignore server defaults in the restriction settings.
Violation history
Every time an event restriction fires for a target, dzbot records a violation. You can see the full violation history in the restriction detail view:
- Which player triggered it
- When it happened
- Which target matched
- A link to the original game log entry
This gives you a clear record of repeated offenders and makes it easier to justify escalation decisions.
Restriction states
A restriction can be in one of three states:
| State | Meaning |
|---|---|
| Pending | Start date is in the future — not yet active |
| Active | Currently in effect |
| Expired | End date has passed — no longer enforced |
Expired restrictions and their violation history remain visible in the list for reference.
Case notes
Every restriction has a Case notes field for staff context. Use this to document why the restriction was created, what evidence was gathered, or what the outcome should be. Notes are only visible to staff in the admin area.