For Server Owners

How to Give GM Rights in Metin2: GM Levels and Safe Use

How to Give GM Rights in Metin2: GM Levels and Safe Use

Giving GM rights on a Metin2 server takes a few lines of database work; the hard part is giving the right person the right level and preventing abuse. This guide covers where GM rights are defined, the GM levels, granting and revoking them, and security measures. The information is based on the publicly available Metin2 server source code and SQL files; details may differ depending on the version of your server files and the changes made to them.

Where are GM rights defined?

Rights are stored in the gmlist table of the common database. The db core reads this table and sends it to the game cores; a character's GM level is set from this list when the character is loaded into the game.

Column Meaning
mAccount Username of the GM's game account
mName Name of the character receiving the rights
mContactIP Allowed connection IP (see the warning below)
mServerIP The game server it applies to; ALL means all of them
mAuthority GM level

Rights are tied to the character, so another character on the same account doesn't become a GM. With the source's Turkish and European locale settings, the account name is compared as well: even if the GM character is deleted and its name is taken on another account, that account doesn't gain the rights.

GM levels

In the source, the levels are ordered from lowest to highest, and each level can also use the commands of the levels below it:

Level Example commands added in the stock command table
LOW_WIZARD /warp, /goto, /transfer, /dc, /invisible, /notice_map
WIZARD /purge, /respawn
HIGH_WIZARD /notice, /mob, /kill, /eventflag, /shutdown
GOD /item, /advance
IMPLEMENTOR /reload, /set, /who

In some SQL files, WIZARD isn't among the options of the mAuthority column; even though the code recognizes the value, you can't assign that level if the column doesn't allow it. For descriptions of the commands, see our GM commands list.

Granting GM rights step by step

  1. Create a separate account: Make a game account and character for the GM, separate from your own player account.

  2. Add it to the list: In the common database, run this query with the values changed to your own:

    INSERT INTO gmlist (mAccount, mName, mContactIP, mServerIP, mAuthority)
    VALUES ('gmaccount', 'GMCharacter', '', 'ALL', 'LOW_WIZARD');
    
  3. Reload the list: Type /reload a in the game with an IMPLEMENTOR-level character, or restart the server. In the source, the reload also applies right away to listed characters who are online at that moment.

  4. Test it: Log in with the GM character and run a harmless command that fits its level, such as /state.

Revoking rights

Delete the row of a GM whose job is done and reload the list:

DELETE FROM gmlist WHERE mName = 'GMCharacter';

Then type /reload a. One important detail: in the source, the reload doesn't lower the level of a character that was removed from the list but is online at the time; the rights stay until the character is loaded again. So disconnect the person with /dc and change the GM account's password.

Narrowing command levels with the CMD file

The CMD file in the game core's folder lets you change the level each command requires. Each line holds one command and one level, and DISABLE closes the command to everyone:

item IMPLEMENTOR
shutdown IMPLEMENTOR
full_set DISABLE

In the stock table, even LOW_WIZARD, the lowest level, can use test commands such as /full_set and /all_skill_master, which give the GM's own character full gear, bonuses and skills, so don't assume the lowest level is harmless. In the source, a faulty line keeps the core from starting, so try your changes on a test server first.

Recommendations for safe use

  • Least privilege: Give each GM the lowest level that lets them do their job; for the support team, LOW_WIZARD is usually enough.
  • Strong, unique passwords: GM account passwords shouldn't be used anywhere else or shared within the team.
  • IP restriction: There is an mContactIP column, but in the source we examined, the Turkish and European locale settings don't check the IP, only the account name. If you want one, have your developer build it into the server files, or apply it to admin access such as the database, SSH and panels.
  • Test mode off: When the TEST_SERVER setting in the game core's CONFIG file is on, everyone gets IMPLEMENTOR rights in the source. Check this line's value in the CONFIG files that come with ready-made server files, and make sure it's off on a live server.
  • Review the logs: In the source, GM logins and items created with /item are written to the log database; with the Turkish and European settings, GM commands also land in the command_log table. Look through these logs once a week.
  • Regular cleanup: Promptly delete the records of GMs who've left the team or gone inactive.

Once your team and files are ready, you can list your server for free, and use our forum to share experiences with other server owners.

Frequently asked questions

I gave GM rights, but the commands don't work. Why?

If you haven't reloaded the list with /reload a or restarted the server, the rights don't take effect. Check that the account and character names match the gmlist row exactly and that the level is high enough for the command.

Can I give one GM rights on more than one character?

Yes, you need to add a separate row for each character. Still, every extra character is a new risk, so stick to one unless you really need more.

Why is everyone a GM on the test server?

In the source, every character gets the highest level while TEST_SERVER is on. That's meant for test environments; never leave it enabled on a live server.

Can GM rights be given from inside the game?

The stock source has no in-game command for this; rights are granted through the gmlist table and reloaded with /reload a. Some server files may include extra tools for the job.

0 Likes

More posts

Comments 0

No comments yet.