When you launch a Metin2 server, everything from combat to guilds, from inventories to guild wars actually lives in MySQL. The Metin2 MySQL tables are the persistent memory of the game logic: the core (the db and game processes) reads, writes and caches these tables. The standard Metin2 server source splits the data into two separate databases: account, which holds authentication, and player, which holds everything in-game. In this article I explain the main tables of both schemas clearly and what each one is for.
Two databases: account and player
Separating the data into two logical areas is a deliberate choice in Metin2. Account/login information (login, password, ban status, email) lives in the account database, while characters, items, guilds and quests live in the player database. This split makes it easier to later attach several game worlds (channels) to the same account system and to keep authority boundaries apart.
- account — authentication, payment/cash, bans and security codes.
- player — game state: characters, items, guilds, safebox, quests, friend list.
The account database
The most important table is the account table. Each row represents a player account. Typical columns are:
id— the account's unique primary key;account_idin theplayertable links to it.login— the username (used to log in).password— the password, hashed with MySQL'sPASSWORD()function.social_id— a second security password (used for storage/pin).email— the account's email address.status— account status (such asOKorBLOCK).securitycode,availDt— security code and the account's validity/premium expiry date.
A simple query to see how the password is stored:
SELECT id, login, status FROM account.account WHERE login = 'player1';When creating a new account the password is written as a hash, not plain text:
INSERT INTO account.account (login, password, social_id, email)
VALUES ('player1', PASSWORD('secretPass'), '7777', 'mail@example.com');The heart of the player database: the player table
The player table holds every character as a row. From the player's level to their position, from stats to gold, everything is here. Commonly used columns:
id— the character's primary key (usually referred to aspid).account_id— which account it belongs to (account.account.id).name— character name (unique on the server).job— class (0 warrior, 1 ninja, 2 sura, 3 shaman).level,exp,level_step— level and experience.st,ht,dx,iq— strength, vitality, dexterity and intelligence stats respectively.gold— the character's yang amount.hp,mp,stat_point,skill_point— health/mana and undistributed points.map_index,x,y— the map the character is on and its coordinates.part_main,part_hair— the equipped weapon/armor and hair appearance.skill_group,playtime— the skill tree and total play time.
To read a character's level and gold:
SELECT name, level, gold, map_index
FROM player.player
WHERE name = 'Hero';Character slots: player_index
An account can carry several characters. The player_index table records which account owns which character ids. Typically there is an id (account_id) along with columns pid0, pid1, pid2, pid3, each pointing to a character slot. The character-selection screen reads this table.
Items: the item table
The item table holds every physical item in the game (inventory, equipment, storage) in a single table. Important columns:
id— the item's unique id.owner_id— thepidof the character that owns the item.window— where the item is (INVENTORY,EQUIPMENT,SAFEBOX,MALL).pos— the slot position within that window.vnum— the item's proto number (which item it is; it points toitem_proto).count— the amount (for stackable items).socket0–socket2— fitted stones or special values.attrtype0–attrtype6andattrvalue0–attrvalue6— the item's bonus types and values.
item_proto and mob_proto are the "template" tables: they define the base properties of each item/monster (name, type, price, attack). The vnum in the item table corresponds to a row in item_proto.
Guilds, storage and other tables
Social and progression systems live in their own tables:
guild— guild name, leader, level and experience.guild_member— which character is in which guild and at which rank.safebox— storage password and storage gold; the items themselves still live in theitemtable withwindow=SAFEBOX.quest— each character's quest flags (quest progress as key/value).affect— buff/effect states that persist when a character logs out.messenger_list— friend list relations.
These tables connect to each other through the pid (character id); for example you fetch all of a character's items with the relation item.owner_id = player.id. Once you read the schema with this logic, the apparent clutter turns into a clean relational structure.
Things to watch when working with the tables
An important point: the db process caches character and item data in memory. If you run an UPDATE directly while the player is online, the data the core writes on logout can overwrite yours. So make data edits while the player is offline, always take a backup first (mysqldump), and test in a staging environment.
Frequently Asked Questions
Why are the account and player databases separate?
Separating authentication from game data provides security and flexibility. Several game worlds can attach to the same account system, permissions stay separate, and the login table is not affected by the game load.
Where are all of a character's items?
In the item table of the player database. The owner_id column equals the character's id (pid); the window column tells you whether the item is in the inventory or in storage.
Is it safe to add gold while the player is online?
Usually not. The core keeps the data in cache and overwrites the table on logout. The safe way is to use an in-game command or to update while the player is offline.
Need help editing your Metin2 database or setting up a clean schema? For support with the MySQL schema, performance and server setup, get in touch with me.