Metin2 Server CONFIG File Explained: What the Classic Game Core Actually Reads

Tue Jul 21, 2026 2:47 am

Metin2 Server CONFIG File Explained: What the Classic Game Core Actually Reads

Every guide tells you how to install Metin2 server files. Almost none of them tell you what the game core's CONFIG file actually does — so the first time a channel refuses to start, or syserr shows TABLE_POSTFIX not configured use default, you're left grepping forum threads.

This article covers the classic game core CONFIG as implemented in the publicly mirrored classic game source on GitHub (cCorax2/Source_code). Metin2 itself is operated by Gameforge — its official site is metin2.gameforge.com — and running private servers is a matter between you and the rights holders; this article only documents what the widely mirrored source code does. If you run a different build, verify each directive against your own game/config.cpp before relying on it.

How the file is read: the game core parses CONFIG as plain key/value tokens at startup. Keys the parser does not recognize are skipped without any error, which is why a typo like MAP_ALOW produces no message — just a core that hosts no maps. Your build's game/config.cpp is the single source of truth for which tokens exist.

1. Core identity: HOSTNAME, CHANNEL, PORT, P2P_PORT

Each running game binary is one core, and every core needs its own CONFIG:

Code: Select all

HOSTNAME: channel1_core1
CHANNEL: 1
PORT: 13001
P2P_PORT: 13091

HOSTNAME — a label for this core, used in logs. In this source, a core with no HOSTNAME refuses to start (HOSTNAME must be configured.).
CHANNEL — the channel number this core belongs to. A core with CHANNEL unset exits at startup with CHANNEL not configured.
PORT — the TCP port clients connect to for this core.
P2P_PORT — the port cores use to talk to each other.

Use distinct PORT/P2P_PORT values per core on the same machine; duplicated ports when copying a core folder is a classic self-inflicted startup problem.

2. Database wiring: PLAYER_SQL, COMMON_SQL, LOG_SQL, DB_ADDR, DB_PORT

The three SQL lines each take host user password database, with an optional fifth token for a MySQL port:

Code: Select all

PLAYER_SQL: localhost mt2 password player
COMMON_SQL: localhost mt2 password common
LOG_SQL: localhost mt2 password log

In addition, this source recognizes DB_ADDR and DB_PORT, which point the game core at the db-cache daemon — and DB_PORT is not optional: a core with DB_PORT unset exits at startup with DB_PORT not configured. You need both the db-cache wiring and the SQL lines set correctly.

The famous TABLE_POSTFIX not configured use default

This message does not come from the game core's CONFIG at all. It is emitted by the db-cache daemon (DB/Main.cpp in the same source) when its config file has no TABLE_POSTFIX entry. It is non-fatal: the daemon logs the message via sys_err and continues with an empty table postfix, which is exactly what a typical single-server setup wants. The game core also accepts its own table_postfix token. Only chase this message when tables genuinely aren't being found.

3. Map routing: MAP_ALLOW

MAP_ALLOW lists the map indexes a core is allowed to host:

Code: Select all

MAP_ALLOW: 1 3 21 23 41 43

Two behaviors are hard-coded in this source:

Listing the same map index twice on one core is fatal. The core prints !!! FATAL ERROR !!! multiple MAP_ALLOW setting!! and exits.
An auth core hosts no maps. When a core runs as the auth server, its map-allow lookup always returns false, so any MAP_ALLOW entries on it are effectively ignored.

As an operational convention, give each map index in a channel to exactly one core, and split maps by expected population rather than by count.

4. Special cores: auth and guild marks

AUTH_SERVER — takes two arguments in the form <ip|master> <port>; anything else prints AUTH_SERVER: syntax error: <ip|master> <port>. Passing master makes this core the auth master (AUTH_SERVER: I am the master); passing an IP and port points the core at the auth master elsewhere.
MARK_SERVER — toggles the guild-mark server flag for this core. In this source it defaults to on (guild_mark_server = true), so cores that should not hold the role need an explicit MARK_SERVER: 0.
MARK_MIN_LEVEL — sets the guild-mark minimum level; the default in this source is 3.

5. Tuning and debug flags: handle with care

The source also recognizes TEST_SERVER (test-server mode), PASSES_PER_SEC, and SAVE_EVENT_SECOND_CYCLE. Practical advice: keep TEST_SERVER off on anything public, and treat the timing directives as engine internals — if you change them at all, change them on a throwaway core first and compare behavior, because the shipped defaults are what the rest of the code was built against.

6. A modern alternative

If the flat token file feels archaic, Quantum Core X is an open-source reimplementation of the Metin2 server written in C# on .NET (MPL-2.0). If you're starting fresh rather than administering existing classic files, it's worth evaluating before committing to the classic stack.

For everyone running the classic files: keep one pristine reference CONFIG, diff against it whenever a core misbehaves, and treat game/config.cpp as the manual the files never shipped with.

Information