Metin2 Boss System: Grandboss Spawn and Drop Setup

A solid metin2 boss system defines a private server's most-played content: players know when a grandboss will appear, gather on the map at that hour, and compete for rare drops. But behind that experience, three separate files have to work in harmony — the regen.txt or quest Lua that triggers the spawn, the mob_drop_item.txt that sets the drops, and the announcement messages that alert players. In this guide I walk through configuring boss spawn timers, the drop table and announcements from scratch.

The difference between a boss and a grandboss

Technically both are just a monster row in mob_proto; the difference is the rank/type field and the spawn logic. A normal boss usually lives permanently on a map and respawns shortly after it dies. A grandboss is a rare, powerful entity that often spawns on a schedule — for example at fixed times every day or when a certain condition is met.

• Boss: defined in regen.txt with a fixed position and respawn timer. The server core handles the rest automatically.
• Grandboss: usually spawned by a quest, driven by a timer or event flag, with a server-wide announcement the moment it appears.

Clarifying this distinction up front tells you which tool to use. Managing a constantly patrolling boss with a quest adds needless complexity; conversely, trying to build a scheduled grandboss with regen.txt alone robs you of flexible control.

Setting boss spawns with regen.txt

Every map has its own regen.txt file in its folder (for example map_a1/regen.txt). To spawn a boss permanently, you only add a single line. The column order is:

# type  aggressive  x     y    x_range  y_range  z  dir  time  percent  count  vnum
m       1           512   480  0        0        0  0    30m   100      1      2492

What the fields mean:

• m: a single monster (use g for a group, r for a regen group).
• aggressive: 1 means it attacks on sight, 0 means it is passive.
• x / y: the map's local coordinates (relative to the map's top-left corner).
• time: respawn delay after death — written as 5s, 10m, 1h.
• vnum: the monster ID in mob_proto.

After saving the file you must either restart the server or refresh the data with a GM command like /reload for the change to take effect. The easiest way to find the right coordinates is to log in, stand on the target spot and read the local x/y with a GM command such as /where.

Scheduled grandboss spawns with quest Lua

For a scheduled grandboss we use the quest system. The core tool is the game.spawn_mob(vnum, x, y) function, which spawns a monster at the given local coordinate on the map where it is called. The example below builds a simple skeleton that watches for the boss kill and announces it on death:

quest grandboss begin
    state start begin
        function spawn_meley()
            local x, y = 1023, 875
            game.spawn_mob(2493, x, y)
            notice_all("[Grandboss] Meley Lady has appeared on the map!")
        end

        when 2493.kill begin
            notice_all("The grandboss has been hunted! Prepare for the next spawn.")
            server_timer("meley_respawn", 6 * 60 * 60)  -- in 6 hours
        end

        when meley_respawn.server_timer begin
            grandboss.spawn_meley()
        end
    end
end

Here the when 2493.kill block fires when the monster with vnum 2493 is killed. server_timer starts a server-wide countdown that is not tied to any player — this is the heart of grandboss timing, because the boss must spawn even if no one is online. If you want a real-clock spawn (for example every day at 21:00), you can check the hour with os.date in a login trigger and use an event flag:

when login begin
    local hour = tonumber(os.date("%H"))
    if hour == 21 and game.get_event_flag("meley_today") == 0 then
        game.set_event_flag("meley_today", 1)
        grandboss.spawn_meley()
    end
end

This method is simple and readable; on larger, more robust servers a separate "boss timer" quest that manages the spawn from a single point is preferred, so the same boss never spawns twice.

Drop setup: mob_drop_item.txt

Boss drops are largely managed by groups in mob_drop_item.txt. Each group is bound to a Mob vnum, and each line within it defines an item, its quantity and its drop chance (as a percentage, not per mille):

Group GrandbossMeley
{
    Mob     2493
    Type    drop
    1   71001   1   30.000000
    2   72003   5   15.000000
    3   50300   1   2.500000
}

The lines read: index item_vnum quantity chance. The Type field controls drop behaviour:

• drop: each line rolls independently by chance; a boss can yield several items.
• kill: only one item is picked from the group; suitable for loot-pool logic.
• limit / level_limit: used for drops tied to a level range.

When setting chances, account for player count and server rate: on a high-rate server a 30% rare item quickly causes inflation. Keeping rares low (say 1–3%) and frequent drops reasonable keeps the economy healthy. After editing the file you must apply the change with a GM command like /reload d or a server restart.

Spawn and drop announcement messages

A good boss system keeps players informed. The two most-used functions are:

• notice_all("..."): sends a yellow info message to every player on the server — ideal for a grandboss spawn.
• notice("..."): sends a message only to the player who triggered the quest.

A much-loved feature is announcing to the server when a rare item drops. You can build this in a drop quest by checking the dropped item:

when kill with npc.is_pc() == false begin
    if npc.get_race() == 2493 then
        local player = pc.get_name()
        notice_all(string.format("%s looted a legendary item from Meley Lady!", player))
    end
end

Announcements like this reinforce the "I should be there too" feeling and boost server turnout at boss hours. Just don't overdo it — if you announce every ordinary drop, the messages become noise and lose their impact.

Testing and common mistakes

Before going live, test with GM commands: /mob 2493 spawns the boss in front of you, /notice test tries an announcement. The most common problems:

• Wrong coordinate: regen.txt wants the map's local coordinate, not the global one. If the boss doesn't appear, this is almost always the cause.
• vnum mismatch: mob_proto, regen.txt and mob_drop_item.txt must use the same vnum. A single-digit error leaves the boss "drop-less".
• Forgetting reload: saving files isn't enough; the data has to be reloaded into the core. When in doubt, restart the server.
• Checking syserr: quest errors land in the syserr logs. If a grandboss won't spawn, that's the first place to look.

As long as you keep these three files (spawn, drop, announcement) consistent, you'll have built scalable boss content that players eagerly wait for.

Frequently Asked Questions

Will the grandboss spawn when no one is online?

If you use server_timer or a real-clock mechanism, yes — the spawn is independent of players. However, the map must be loaded by the core at the moment game.spawn_mob is called; on most servers the main maps are always loaded, so this isn't an issue.

Do I write drop chances per mille or as a percentage?

In mob_drop_item.txt the chance is written as a percentage (30.000000 = 30%). With decimal places you can define very small chances (0.100000 = 0.1%). Other files like common_drop_item.txt may use a different format, so don't mix them up.

Why does the same boss spawn twice?

Usually both regen.txt and a quest are spawning the same boss, or the event flag isn't being reset properly. Manage a scheduled grandboss from a single source and make sure you reset the flag before respawn.

Want a balanced boss and grandboss system for your server? We can set up spawn timing, drop economy and the announcement flow in a way that retains your players. To talk about your project, get in touch with me.