Kinetic Hosting - quality hosting for low prices, 24/7 support, mod support Looking for a great server host? Get your Kinetic server with our link!
Click the banner to get your server now!

Staff Standard Operating Procedures

How the DMZ Ragnarok staff team works: the chain of command, tickets, rule enforcement, evidence, the custom systems, approved commands and emergencies.

← Back to the staff page

Version 1.0. Last updated 21 September 2026. This version number is part of the document. Staff are asked to confirm they have read a specific version, and that record means nothing if the wording can change underneath it. When this document changes in a way that matters, the version goes up and the team is told.

There are two documents, and they do different jobs. This one is how the work is done: who is in charge of what, how tickets are handled, how rules are enforced, what evidence you keep. The Staff Agreement is what you personally agree to when you accept a role: confidentiality, volunteer status, and what happens if you break it. Read this one first, then accept that one.

Everything here is written in plain English on purpose. If something is unclear, ask a head of staff before you act on it. Asking first has never once got anybody in trouble.

Use the search box to jump to a section, or open the whole document and read it start to finish.

The whole document 13 sections

1. What staff are for

Staff exist so that players get a fair, safe and welcoming server. Everything below is downstream of that. If a procedure here ever gets in the way of that goal in a way nobody anticipated, do the right thing and then tell a head of staff what you did and why.

Consistency is the point

Two players who do the same thing should get the same answer, whoever picks up the ticket and whatever time of day it is. A player who cannot predict what staff will do stops trusting staff. That is why we have procedures at all: not to make the job rigid, but to make it the same job in everybody's hands.

If you genuinely do not know what the consistent answer is, ask instead of guessing. One delayed ticket is much cheaper than a precedent nobody wanted.

Professional, but not a robot

  • Be approachable. Most people opening a ticket are confused, not malicious.
  • Stay calm, especially when the other person is not. You are the one who sets the tone.
  • You can be friendly, you can joke, you can have a personality. You represent the server while you do it.
  • Never make a player feel stupid for asking something basic. Every one of us asked it once.
  • If you are too annoyed to answer well, hand the ticket over. That is a professional thing to do, not a failure.

2. Chain of command

The team runs top to bottom like this:

  • Owner. Final say on everything. Owns the project, the direction and the money.
  • Server Manager. Runs the server day to day, the infrastructure and the staff team itself.
  • Head Admin. Leads the administrators. Final word on the day to day in game: punishments, appeals and anything contested.
  • Head Moderator. Leads the moderators. Owns the ticket queue, the rotas and moderator training.
  • Admin. Handles systems and the harder cases.
  • Moderator. Handles routine moderation and the bulk of the tickets.
  • Helper. First responders. Answer questions and triage.

Who does what

  • Helpers are the front line. Answer player questions, point people at the wiki and the guide, greet new players, and take the first look at a ticket. Sort out what is a question, what is a bug and what is a rule problem. Hand anything that needs a punishment, a rollback, an item or a data change to a Moderator or above. A Helper who says "let me get someone who can fix that" is doing the job exactly right.
  • Moderators handle routine moderation: chat, behaviour, griefing, warnings, mutes, kicks and bans within the ladder in section 5. Moderators close most tickets.
  • Admins handle systems and anything a Moderator cannot do: reimbursements, account and data problems, region and protection issues, and cases that need more than the standard ladder. Admins also back up Moderators on contested calls.
  • Heads and above own policy, appeals, staff conduct and anything that affects the whole server.

Escalating

Go up one step first as a default, because that is usually the fastest answer. It is not a rule you have to obey while the server burns.

Escalate directly to a Head Admin, the Server Manager or an Owner, skipping whoever is in between, when:

  • Something is affecting the whole server right now (see section 10).
  • An exploit or dupe is being used, or is about to be.
  • A staff member is the subject of the complaint.
  • Player data, payments or account security are involved.
  • You are being asked to do something you think is against this document or the Staff Agreement.

    Nobody is offended by a justified escalation. Going around somebody to get a softer answer is a different thing, and that is not allowed.

3. Staff conduct

You are the server

Once you hold a staff rank, players stop reading you as a player. What you say in chat, in Discord and in other communities is read as the server's position, whether you meant it that way or not.

  • Follow every rule you enforce. Staff are held to the rules more tightly than players, not less.
  • Do not badmouth the server, its players, its staff or its decisions in public or in other communities. Bring it to a head of staff instead. Disagreement is welcome, in the right room.
  • Keep your account clean and your name and avatar appropriate.

No favouritism

  • Do not action, punish, reward or reimburse anybody you are personally involved with. Friends, guildmates, people you are in an argument with: hand those to another staff member.
  • Do not give anybody an advantage because you know them. Not items, not currency, not a softer punishment, not early information.
  • Your own accounts and alts get no special treatment either.
  • If somebody asks you for a favour "because you're staff", the answer is no, and you tell a head of staff if they keep pushing.

Never argue in public

  • Never argue with a player in public chat. Take it to a ticket or a direct message, and if it is going nowhere, hand it to a head of staff.
  • Never argue with another staff member in front of players. If you think a colleague made the wrong call, do not reverse it in public and do not contradict them in chat. Take it to a private staff channel, and if it needs a decision, take it to a head of staff.
  • A public staff disagreement costs the team more trust than the original mistake ever could.
  • If a player is trying to get a reaction out of you, disengage. Winning an argument in chat is not a win.

4. Player reports and tickets

Everything goes through a ticket

  • If it needs a staff action, it needs a ticket. No exceptions for friends, for "quick" things, or for something someone mentioned in a direct message.
  • A ticket is the record. It is what lets the next person see what happened, what lets a head of staff review a call, and what protects you if somebody says you did something you did not.
  • If a player asks you for something in a direct message or in chat, ask them to open a ticket. If they cannot for some reason, open one yourself and note why.

How a ticket moves

  • Helpers respond first and triage: answer it if it is a question, hand it on if it is not.
  • Whoever takes a ticket owns it until they hand it over explicitly. Do not assume somebody else picked it up.
  • Do not action a report without hearing both sides, unless the evidence is conclusive on its own.
  • Close the ticket with a short note saying what was decided and what was done. The next person reading it should not have to reconstruct it.

Reimbursement claims

  • A reimbursement needs evidence. Screenshots, a recording or a log line that shows what was lost and how. See section 6.
  • No evidence means no reimbursement. That is not us calling anybody a liar, it is the only rule that works when we cannot see what happened.
  • Reimbursements are an Admin action, not a Moderator one.
  • Never reimburse yourself or anybody you are personally involved with. Hand it over.
  • If a claim looks inflated, do not argue about it in the ticket. Log what you saw and escalate.

When a ticket stays open

Leave a ticket open, with a note, when:

  • You are waiting on the player for evidence or an answer.
  • It needs a rank you do not have, and that person is not online.
  • It is a bug and it has gone to the bug tracker. Link the tracker entry.
  • It is contested and a head of staff has to decide.

    Do not close a ticket to tidy the queue. An open ticket with a note is information. A closed one that was never resolved is a player who thinks nobody listened.

5. Rule enforcement

Match the punishment to what actually happened. The ladders below are the normal path, not a sentence chart, and the notes at the end matter as much as the ladders do.

In game

  1. Verbal warning. Tell them what the problem is and what to do instead.
  2. Formal warning. Logged, so the next staff member can see it.
  3. Mute, for chat offences. Length according to what was said and what came before.
  4. Kick, to break up something happening right now.
  5. Temporary ban.
  6. Permanent ban.

Discord

  1. Verbal warning.
  2. Formal warning, logged.
  3. Timeout or mute.
  4. Kick from the server.
  5. Temporary ban.
  6. Permanent removal.

Mutes are for chat, bans are for behaviour

If the whole problem is what somebody is saying, a mute is the tool. Spam, insults, arguments that will not stop, bad language after a warning: mute it and let them keep playing. Do not reach for a ban because chat annoyed you.

Skipping the ladder

Some things do not get a verbal warning. Go straight to a ban or a removal, gather your evidence and escalate, for:

  • Cheating, hacked clients and exploit or dupe use.
  • Revealing somebody's real identity or personal information.
  • Threats, sexual content involving minors, or anything that puts a person at risk.
  • Advertising another server or trying to poach players.
  • Scamming through an official system.
  • Evading a ban or a mute.

Always

  • Say why. A punishment nobody understands teaches nothing and comes back as a ticket.
  • Log it, with evidence, every time. See section 6.
  • One incident gets one punishment. Do not stack a mute, a kick and a ban on the same event because you are annoyed.
  • If you are not sure it warrants a ban, it does not yet. Escalate instead.
  • Appeals go to a head of staff, never to the person who issued the punishment.

6. Evidence

Every staff action needs evidence

Screenshots, video or log lines. Attach them to the ticket or the punishment record at the time, not later from memory.

This protects three people at once: the player, who can appeal against something real rather than somebody's recollection; the team, who can review a call without relitigating it; and you, when somebody claims you did something you did not.

Mandatory, with no exceptions

  • Reimbursements. What was lost, how, and roughly when.
  • Account and data changes. Stats, ranks, balances, permissions, inventories, anything written to a player's data. Who asked, who approved, what changed, before and after.
  • Bans, temporary or permanent.
  • Anything involving another staff member.

    If you cannot produce evidence for one of those, you do not do it yet. Escalate instead.

What counts

  • A screenshot that shows the chat or the scene, with the name and the context in frame. A cropped line of text proves nothing.
  • A recording, for anything involving movement, combat or a sequence of events.
  • A log line or a lookup result, which beats a screenshot because it cannot be edited.
  • A player's own claim is not evidence. It is a reason to go looking for some.

Keeping it

  • Keep evidence for at least 90 days after the action.
  • Keep it for as long as the punishment lasts, so a permanent ban keeps its evidence permanently.
  • Reimbursement evidence is kept with the ticket, permanently.
  • Store it where the team can reach it, attached to the ticket or the record. Evidence only you can see is not evidence, and a file only on your own machine is against the Staff Agreement.
  • Evidence contains player information. Do not post it anywhere outside staff channels, ever.

7. Player disputes

Private trades are not our problem

The server is not responsible for deals players make outside the official systems. Handshake trades, promises in chat, real money deals, cross server arrangements, "drop it and I will pay you after": if it did not go through an official system, we do not reverse it and we do not reimburse it.

Say that plainly and kindly. The player is usually upset and usually did nothing wrong except trust somebody. Point them at the official systems for next time.

What we do act on:

  • Scams through an official system, where the system did not work as it should have.
  • A bug or an exploit that cost somebody something.
  • A pattern of behaviour, which is the next part.

Patterns, not one offs

One accusation is not a case. Somebody who is annoyed and somebody who was robbed sound identical in a ticket.

  • Log every report, including the ones you take no action on. That log is how the pattern becomes visible.
  • Note the accused name, the date, what was claimed and what evidence there was.
  • Once there is a pattern (the same person, the same trick, several unconnected players), escalate it with the whole log attached. Then it is actionable.
  • Do not warn or punish somebody on a single unevidenced accusation. Do not tell player A that you have reports about player B either. That gets turned into a public accusation within the hour.

Repeat offenders

Somebody who scams repeatedly, even outside the official systems, is a problem for the server whatever the individual deals were. Document it, escalate it, and let a head of staff decide. That decision is made once, by one person, on the whole file, and not by whoever happens to catch the fifth complaint.

8. The Ragnarok systems

The server runs a large custom mod suite: races, forms and transformations, sagas and quests, dungeons, raid bosses, rifts, tournaments, the economy, guilds, ranks, protection and regions, space and the planets, and the multi server network underneath all of it. The wiki explains what each one does.

Do not touch them without authorisation

  • Do not use the content editors, the spawner tools, the dungeon, raid or tournament managers, or any configuration tool unless you have been given that job explicitly.
  • Do not change configs, permissions, regions, protections, ranks or economy settings on your own initiative, however small the change looks.
  • Do not experiment on the live server. If you want to learn a system, ask, and you will be shown it properly.
  • Having access is not authorisation. Some tools are visible to a rank for one narrow task, and everything else in that menu is still off limits.

    A lot of these systems are connected in ways that are not obvious from the screen you are looking at. A change that looks local can reach the whole network.

If you change something by accident

Report it immediately, to a Head Admin or the Server Manager, even if you think you undid it.

Say exactly:

  • What you clicked or typed, as precisely as you can remember it.
  • When, as close as you can get.
  • Which world, region, player or system it touched.
  • What you saw happen, and what you did next.

    An accident reported in the first minute is usually a two minute fix. The same accident found three days later, in a backup, after players have built on top of it, is somebody's whole evening. Nobody has ever been punished here for reporting a mistake straight away. Hiding one is a different matter and is covered by the Staff Agreement.

9. Approved commands

These are the commands staff use, what each one is for, and who should be reaching for it.

They are for your duties only. Never for your own benefit, never for a friend, and never because it is more convenient than playing the game properly. That is section 5 of the Staff Agreement, and it is the most common way somebody loses the rank.

Three things before the list:

  • Not every command exists on every server. Most of these come from our own mod suite, and a server running without the Ragnarok Key, or without the module that provides them installed, simply does not have them. This list describes the live DMZ Ragnarok network.
  • If it is not on this list, you have not been approved to use it. Seeing a command in your tab completion is not approval. Ask first.
  • /warn, /history and /commandlookup read the shared network database. They work across shards and they work when the player is offline. If the database is unreachable they will tell you so rather than giving you a wrong answer.

Look before you act

  • /seen <player> shows when somebody was last online. Available to everyone, not just staff.
  • /playtime shows playtime, with /playtime top for the leaderboard. Also available to everyone.
  • /locate <player> (aliases /gps, /loc, /playerinfo) finds a player and shows their details.
  • /history <player> lists that player's punishment history, newest first. Takes an optional count and page. Read this before you punish anybody. It is the difference between a first offence and a fourth.
  • /commandlookup <player> shows the commands a player has run. For investigating cheating, exploits, or a staff member's actions.
  • /invsee <player> opens a player's inventory for inspection. Look, do not take.
  • /socialspy shows you players' private messages. Use it for an active investigation and nothing else. Reading somebody's messages out of curiosity is the player information rule in the Staff Agreement, and it is a removal.

Chat moderation

  • /mute <player> mutes indefinitely.
  • /tempmute <player> mutes for a set time. This is the normal one.
  • /unmute <player> lifts it.

    Mutes are the right tool when the whole problem is what somebody is saying. See section 5.

Warnings and punishments

  • /warn <player> <reason> records a formal warning and shows it to the player. The reason is stored, so write it for the next staff member who opens the history, not for yourself.
  • /kick <player> <reason> removes somebody from the server right now. Vanilla command, recorded to our ledger so it appears in /history.
  • /tempban <player> bans for a set time. Expires by itself and syncs across the network.
  • /ban <player> and /ban-ip are the vanilla commands and are also recorded to our ledger. Permanent bans need the evidence in section 6 and, unless the case is one of the immediate ones in section 5, a head of staff.
  • /unban <player> (alias /pardon) lifts a ban. Appeals only, never as a favour.
  • /jail <player> puts somebody in the jail area, /unjail <player> releases them. Useful when you need somebody contained while you work out what happened, without banning them.
  • /setjail manages the jail points themselves, with /setjail delete and /setjail list. Admin work, not routine moderation.
  • /freeze <player> stops a player moving. For holding somebody in place during an investigation.

Getting there and handling the scene

  • /tp teleports you to a player or a place, with safe landing.
  • /tppos teleports to coordinates.
  • /back returns you where you were. Use it after a call so you are not wandering the map.
  • /vanish makes you invisible, and /vanish <player> does it for somebody else. Use it to observe a report honestly. Do not use it to lurk on players for entertainment, and do not use it to dodge people who want to talk to you.
  • /fly and /speed for reaching and inspecting a scene. Not in normal survival play.

Talking to the team and the server

  • /staffchat (alias /sc) is the staff channel in game.
  • /adminchat (alias /achat) is the admin channel.
  • /broadcast <message> announces to the whole server, and /broadcast title <text> puts it on screen. Restarts, events and incidents only, and for an incident see section 10 before you use it.

Shifts, roster and applications

  • /clockin and /clockout for staff shifts.
  • /staff covers the roster, the task board and the staff applications. Its subcommands include list, status, tasks, addtask, deltask, complete, drop, clockin, clockout, and for the people who handle applications review, accept, approve, deny, add and remove. Each branch checks its own permission, so use the ones your rank is meant to use and leave the rest.

Admin only: anything that writes to a player

Everything in this group changes a player's data. Every one of them needs a ticket and the evidence from section 6, every time, including when you are certain.

  • /money give, /money set and /money take adjust balances. /money on its own (aliases /balance, /bal, /zeni) just reads one.
  • /rank setgroup and /rank cleargroup grant and remove ranks. /rank list shows what exists. /rank reloadassets re-reads the rank badge images and is for an owner or the Server Manager.
  • /perm (aliases /sup, /p) is the permission and group editor, and /promote moves a player between groups. These decide who can do what on the whole server. Do not open them to explore.
  • /kit dispenses a kit, and vanilla /give hands over an item.
  • /gamemode (alias /gm), /heal, /god, /kill, /smite and /burn exist and are for handling a situation, not for playing with. Do not use /smite or /burn on a player as a joke, and do not sit in creative mode in a survival world.
  • /doas runs a command as another player. It is impersonation, it is logged, and it is for fixing something that cannot be fixed any other way. If you are not sure you should be using it, you should not be.

There is no reimbursement command

We checked, and there is not one. Reimbursements are done by an Admin with /give, /kit or /money give, against the evidence attached to the ticket. That is exactly why section 6 makes reimbursement evidence mandatory: there is no automatic record of what was handed over and why, beyond the ticket you write.

Tickets and reports are not in game

There is no in game ticket or report command in our suite. That workflow lives in Discord. If somebody tells you to run one, they are wrong or they are testing you.

Event and content commands

The tournament, raid, rift and dungeon commands (the /rg family) run events and build content. They are covered by section 8: do not use them without being given that job. A moderator running an approved event will be shown the exact subcommands for it.

10. Emergencies

An emergency is anything affecting the whole server or a lot of players at once:

  • The server is down, crash looping, or unplayable from lag.
  • An exploit or dupe is being used right now.
  • Mass griefing, or a coordinated raid on the server.
  • Player data loss, a rollback, or a world problem.
  • A compromised staff or player account.
  • Anything involving real money, payments or the store.

What to do

  1. Tell a Head Admin or the Server Manager immediately. If neither answers, go to an Owner. This is the one place where going straight to the top is correct.
  2. Say what you see, where, when it started and how many people are affected. Facts first, theories after.
  3. Preserve evidence: names, coordinates, timestamps, screenshots.
  4. Contain it only if you have been told to, or if it is obvious and reversible (stopping a griefer, for example). Do not attempt a fix, a rollback, a restart or a config change on your own.
  5. Do not announce it publicly until a head of staff decides what is being said. Half an announcement causes a panic and a wrong one costs trust.
  6. If players ask, tell them the team is aware and looking at it. That is true, it is enough, and it is all you should say.

Do not solve it alone

This is not about trust. A server wide problem usually has a cause that is not where it looks, and a well meant fix by one person can destroy the evidence of what went wrong, or make the damage permanent. Report it, then do what you are asked.

11. Confidentiality

Confidentiality is covered in full by the Staff Agreement, which every staff member accepts by version. It is not restated here on purpose: one authoritative copy means there is never a question about which wording applies.

The short version, which does not replace reading it:

  • Staff channels, unreleased content, moderation records, player information, business information and anything that grants access are confidential.
  • Exploits, dupes and security holes are confidential and go straight to an owner or the bug tracker. Never use one, never share one, never sell one.
  • Player information is only for the specific task you are working on.
  • It keeps applying after you leave the team.

    If you are not sure whether something is confidential, it is, until somebody senior tells you otherwise.

12. Activity, resignation and removal

Activity

There are a limited number of staff positions, and each one carries real access and real trust. A position held by somebody who has gone quiet is a position a willing person cannot have, and a team that is bigger than the work is harder to run, harder to keep consistent and harder to trust.

So the staff team sets an activity expectation for each rank, and stands down people who are not meeting it. The current figure is set by the staff team and announced in the staff channels, so it can be adjusted without editing this document.

Be clear about what that is and is not. It is roster management: the team is kept at the size the work needs. It is not hours you owe us and it is not a debt. Staff here are volunteers, nobody is paid, and nobody is billed for a quiet month.

If life gets busy

Tell a head of staff before you go quiet. Exams, a job, family, health, or just needing a break from the game: an absence you told us about is not inactivity, and we will hold your place where we can.

Nobody needs a reason or a doctor's note. "I am going to be away for a few weeks" is a complete message.

Resigning

  • Tell a head of staff or an owner. A message is enough, there is no form and no notice period.
  • Hand back anything you were given and stop using staff tools.
  • Your access is removed, which is standard for everybody and is not a comment on you.
  • You are still welcome as a player, and plenty of people have come back to the team later.

Removal

  • Staff can be removed at any time, by a head of staff or an owner.
  • Removal is documented: what happened, what was decided and by whom. That record exists so the decision can be reviewed, and so it is the same decision for the next person.
  • For a breach of the Staff Agreement, what follows is in that document.
  • Being stood down for inactivity is not a removal for cause and is not recorded as one.

13. Keeping this document current

How it changes

  • This document has a version number and a date at the top. Both are part of it.
  • Changes are made by an owner, the Server Manager or a Head Admin. Not by anybody else, and not by a note in a channel.
  • A change that alters what staff are supposed to do raises the version number and is announced in the staff channels.
  • A correction that does not change any meaning (a typo, a broken link, clearer wording) updates the date and leaves the version alone.
  • The Staff Agreement has its own version and its own acceptance. Changing this document does not change that one.

Announcements

  • Staff announcements are posted in the staff channels and you are expected to read them.
  • Acknowledge one when you are asked to: react, reply, or use whichever method the announcement names. An unacknowledged announcement is treated as unread, and "I never saw it" is not a defence once it has been sitting there for a week.
  • If an announcement contradicts this document, the announcement wins until this document is updated to match. Ask if you are not sure which is current.
  • If you spot something in here that is out of date or wrong, say so. This document is maintained by the people using it.