On a Metin2 server, nothing shapes the economy and the gameplay loop more than correctly configured Metin2 drop settings. Which item drops from which mob, at which level, and with what probability is stored in two main text files: common_drop_item.txt and mob_drop_item.txt. In this guide I walk through the structure of those files, what the columns mean, how to compute the rates, and most importantly how to test your changes safely before pushing them live.
Where the drop files live and what they do
Drop tables are plain text files that the game core reads at startup. They usually sit under share/locale/<language>/ or in the directory where the core runs. Four complementary files exist:
common_drop_item.txt— A generic drop table driven by level range and mob rank. It is not tied to a specific mob; it sets the rule "all monsters around this level may drop this item at this rate."mob_drop_item.txt— Mob-specific drops. It works with groups and lets you define several rules for the same mob through different types such askillanddrop.etc_drop_item.txt— Simple, mob-independent probability entries for individual items (for example a rare material).drop_item_group.txt— Group-based content drops such as digging, fishing and boxes.
Many beginners try to balance everything through mob_drop_item.txt alone, when managing the general material and money flow through common_drop_item.txt is a far cleaner design.
common_drop_item.txt: level- and rank-based generic drops
In this file each line is one item rule. A typical line contains: start level, end level, item name, item vnum, count, and probability columns per mob rank (usually Pawn, S_Pawn, Boss, King in that order, as a percentage). Example:
# Lev_min Lev_max ItemName Vnum Count Pawn S_Pawn Boss King
1 15 Yang_Coin 1 1 30.0 40.0 60.0 100.0
20 35 Healing_Potion 27002 1 2.5 3.0 5.0 10.0
30 50 Stone_Fragment 30019 1 0.5 0.8 1.5 4.0
The logic is clear: the same item drops more often on higher-ranked mobs as the level climbs. Because the column count and order can vary between core versions, verify the layout against your own file's header and existing sample lines; adding an invented column makes the whole line silently ignored. Use underscores instead of spaces in item names and match the vnum exactly to item_proto.
mob_drop_item.txt: groups, kill and drop types
This file is made of brace-delimited groups. Each group is bound to one or more mobs and a Type defines its behaviour. The two most-used types are drop and kill.
With the drop type each item has an independent probability; when the mob dies every line rolls separately, so multiple items can drop from the same group:
Group Wolfman_Drop
{
Mob 2090
Type drop
1 72723 1 30
2 27993 1 5
3 30019 1 1
}
With the kill type the last column is a weight; the core scales those weights against their total and picks a single item per death (or none). It is ideal for handing out boss items on a "one per kill" basis:
Group Boss_Kill
{
Mob 1093
Type kill
1 19 1 1000
2 20 1 500
3 25 1 100
}
The scale of the probability column varies from core to core: in some files 30 means 30% directly, in others a finer scale is used. Do not assume it; verify the scale yourself by using a known item's rate in the same file as a reference.
Calculating and balancing the drop rate
You can roughly estimate how much of an item drops per hour as: effective probability × mobs killed per hour × global drop multiplier. Most server files have an overall drop-rate multiplier (in the core configuration or CONFIG). Always factor that multiplier in when tuning table values; otherwise a "small" looking number wrecks the live market.
- Bind rare items to the relevant boss with the
killtype instead ofcommon_drop_item.txt, so you keep farmability under control. - Scale money and basic material flow through
common_drop_item.txt; it is more sustainable than editing mobs one by one. - If you define the same item in several files the rates add up; make sure you are not duplicating an entry by accident.
Loading and testing your changes
Drop tables are read into memory at core startup, so for a change to take effect you usually have to restart the game core (the in-game /reload command reloads quests, not the drop files on most cores). A safe test flow looks like this:
- Make the change on a test server first, never live. Edit the file, restart
game. - Mass-spawn the target mob with a GM account (
/m <vnum>-style GM commands) and kill it dozens of times to observe statistically. A single kill proves nothing. - Confirm the vnum actually exists by giving the item to yourself with
/i <vnum>; a wrong vnum is silently ignored. - Watch the core's
syslogfile; if a drop file has a parse error you will see a warning line at startup.
While testing, temporarily set the rate to a high value (for example 100%) to confirm the mechanic works, then drop it back to its real balanced value. That way you can tell whether "the item never drops" is a rate issue or a configuration error.
Common mistakes
- Wrong separator: Columns in these files are separated by
TAB; using spaces breaks the line. Set your editor to show tabs. - Invalid vnum: A vnum missing from
item_protoraises no error, it just never drops. Verify the vnum first. - Forgetting to restart: Saving the file and saying "it doesn't work" is the most common mistake; the core is still using the old table.
- Forgetting the multiplier: If the global drop multiplier is 5x, 2% in the table is really 10%.
Frequently Asked Questions
What is the difference between common_drop and mob_drop?
common_drop_item.txt is a generic table driven by level and rank; it is not tied to a specific mob. mob_drop_item.txt defines drops for individual mobs or mob groups and offers finer control through the kill and drop types.
I changed the drop rate but nothing drops, why?
The three most likely causes: you did not restart the core, you separated columns with spaces instead of TAB, or you entered a vnum that does not exist. Check syslog and verify the vnum by spawning the item with /i.
How do I test that the rates are correct?
Kill the same mob many times with a GM account and count the dropped items. A one-off test is misleading; you need at least a few hundred kills for a statistical result. Set the rate to 100% first to verify the mechanic, then validate the balance with the real value.
Want to build your server's drop balance from scratch or clean up existing tables? If you need help with Metin2 server setup, quests and system tweaks, get in touch with me — we can plan the drop tables to fit your economy together.