Een solide metin2 boss-systeem bepaalt de meest gespeelde content van een private server: spelers weten wanneer een grandboss verschijnt, verzamelen zich op dat uur op de map en strijden om zeldzame drops. Maar achter die ervaring moeten drie afzonderlijke bestanden in harmonie samenwerken — de regen.txt of quest Lua die de spawn activeert, de mob_drop_item.txt die de drops bepaalt, en de aankondigingen die spelers waarschuwen. In deze gids loop ik stap voor stap door het instellen van boss-spawntimers, de droptabel en de aankondigingen.
Het verschil tussen een boss en een grandboss
Technisch zijn beide slechts een monsterregel in mob_proto; het verschil zit in het rang/type-veld en de spawnlogica. Een normale boss leeft meestal permanent op een map en respawnt kort nadat hij sterft. Een grandboss is een zeldzaam, krachtig wezen dat vaak op een schema verschijnt — bijvoorbeeld op vaste tijden elke dag of wanneer aan een bepaalde voorwaarde is voldaan.
- Boss: gedefinieerd in
regen.txtmet een vaste positie en respawntimer. De serverkern regelt de rest automatisch. - Grandboss: meestal gespawnd door een quest, aangestuurd door een timer of event flag, met een aankondiging aan de hele server op het moment dat hij verschijnt.
Dit onderscheid vooraf verhelderen vertelt je welk hulpmiddel je gebruikt. Een constant patrouillerende boss met een quest beheren voegt onnodige complexiteit toe; omgekeerd berooft het bouwen van een geplande grandboss met alleen regen.txt je van flexibele controle.
Boss-spawns instellen met regen.txt
Elke map heeft een eigen regen.txt-bestand in zijn map (bijvoorbeeld map_a1/regen.txt). Om een boss permanent te laten spawnen voeg je slechts één regel toe. De kolomvolgorde is:
# type agressief x y x_bereik y_bereik z ric tijd procent aantal vnum
m 1 512 480 0 0 0 0 30m 100 1 2492
Wat de velden betekenen:
m: één enkel monster (gebruikgvoor een groep,rvoor een regen-groep).- agressief:
1betekent dat hij aanvalt zodra hij je ziet,0betekent passief. - x / y: de lokale coördinaten van de map (ten opzichte van de linkerbovenhoek).
- tijd: respawnvertraging na de dood — geschreven als
5s,10m,1h. - vnum: de monster-ID in
mob_proto.
Na het opslaan van het bestand moet je ofwel de server herstarten ofwel de data verversen met een GM-commando als /reload om de wijziging te laten ingaan. De makkelijkste manier om de juiste coördinaten te vinden is inloggen, op de doelplek gaan staan en de lokale x/y aflezen met een GM-commando zoals /where.
Geplande grandboss-spawns met quest Lua
Voor een geplande grandboss gebruiken we het questsysteem. Het kernhulpmiddel is de functie game.spawn_mob(vnum, x, y), die een monster spawnt op de opgegeven lokale coördinaat op de map waar ze wordt aangeroepen. Het onderstaande voorbeeld bouwt een eenvoudig skelet dat de bosskill volgt en bij overlijden aankondigt:
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 is op de map verschenen!")
end
when 2493.kill begin
notice_all("De grandboss is verslagen! Bereid je voor op de volgende spawn.")
server_timer("meley_respawn", 6 * 60 * 60) -- over 6 uur
end
when meley_respawn.server_timer begin
grandboss.spawn_meley()
end
end
end
Hier vuurt het blok when 2493.kill wanneer het monster met vnum 2493 wordt gedood. server_timer start een serverbrede aftelling die niet aan een speler is gebonden — dit is het hart van grandboss-timing, want de boss moet spawnen ook als niemand online is. Wil je een spawn op de echte klok (bijvoorbeeld elke dag om 21:00), dan kun je het uur controleren met os.date in een login-trigger en een event flag gebruiken:
when login begin
local uur = tonumber(os.date("%H"))
if uur == 21 and game.get_event_flag("meley_vandaag") == 0 then
game.set_event_flag("meley_vandaag", 1)
grandboss.spawn_meley()
end
end
Deze methode is eenvoudig en leesbaar; op grotere, robuustere servers heeft een aparte "boss timer"-quest die de spawn vanuit één punt beheert de voorkeur, zodat dezelfde boss nooit twee keer spawnt.
Drops instellen: mob_drop_item.txt
Bossdrops worden grotendeels beheerd door groepen in mob_drop_item.txt. Elke groep is gebonden aan een Mob-vnum, en elke regel erin definieert een item, de hoeveelheid en de dropkans (als percentage, niet per duizend):
Group GrandbossMeley
{
Mob 2493
Type drop
1 71001 1 30.000000
2 72003 5 15.000000
3 50300 1 2.500000
}
De regels luiden: index item_vnum hoeveelheid kans. Het Type-veld stuurt het dropgedrag:
- drop: elke regel rolt onafhankelijk op kans; een boss kan meerdere items opleveren.
- kill: er wordt slechts één item uit de groep gekozen; geschikt voor loot-pool-logica.
- limit / level_limit: gebruikt voor drops gekoppeld aan een levelbereik.
Houd bij het instellen van kansen rekening met het aantal spelers en de server-rate: op een high-rate server veroorzaakt een zeldzaam item op 30% snel inflatie. Zeldzame items laag houden (zeg 1–3%) en frequente drops redelijk houdt de economie gezond. Pas na het bewerken van het bestand de wijziging toe met een GM-commando als /reload d of een serverherstart.
Aankondigingen voor spawn en drop
Een goed boss-systeem houdt spelers op de hoogte. De twee meestgebruikte functies zijn:
notice_all("..."): stuurt een gele infomelding naar elke speler op de server — ideaal voor een grandboss-spawn.notice("..."): stuurt een bericht alleen naar de speler die de quest heeft geactiveerd.
Een geliefde functie is de server aankondigen wanneer een zeldzaam item valt. Dat bouw je in een drop-quest door het gevallen item te controleren:
when kill with npc.is_pc() == false begin
if npc.get_race() == 2493 then
local speler = pc.get_name()
notice_all(string.format("%s heeft een legendarisch item van Meley Lady gebuit!", speler))
end
end
Zulke aankondigingen versterken het gevoel "ik zou er ook moeten zijn" en verhogen de opkomst op bossuren. Overdrijf het alleen niet — kondig je elke gewone drop aan, dan worden de berichten ruis en verliezen ze hun impact.
Testen en veelgemaakte fouten
Test vóór livegang met GM-commando's: /mob 2493 spawnt de boss voor je, /notice test probeert een aankondiging. De meest voorkomende problemen:
- Verkeerde coördinaat:
regen.txtverwacht de lokale coördinaat van de map, niet de globale. Verschijnt de boss niet, dan is dit vrijwel altijd de oorzaak. - vnum-mismatch:
mob_proto,regen.txtenmob_drop_item.txtmoeten dezelfde vnum gebruiken. Eén verkeerd cijfer laat de boss "zonder drop". - Reload vergeten: bestanden opslaan is niet genoeg; de data moet opnieuw in de kern worden geladen. Bij twijfel: herstart de server.
- syserr controleren: questfouten belanden in de
syserr-logs. Wil een grandboss niet spawnen, dan kijk je daar eerst.
Zolang je deze drie bestanden (spawn, drop, aankondiging) consistent houdt, heb je schaalbare bosscontent gebouwd waar spelers reikhalzend naar uitkijken.
Veelgestelde vragen
Spawnt de grandboss als niemand online is?
Als je server_timer of een mechanisme op de echte klok gebruikt, ja — de spawn staat los van spelers. Wel moet de map door de kern geladen zijn op het moment dat game.spawn_mob wordt aangeroepen; op de meeste servers zijn de hoofdmaps altijd geladen, dus dat is geen probleem.
Schrijf ik dropkansen per duizend of als percentage?
In mob_drop_item.txt wordt de kans als percentage geschreven (30.000000 = 30%). Met decimalen kun je heel kleine kansen definiëren (0.100000 = 0,1%). Andere bestanden zoals common_drop_item.txt kunnen een ander formaat gebruiken, dus haal ze niet door elkaar.
Waarom spawnt dezelfde boss twee keer?
Meestal spawnen zowel regen.txt als een quest dezelfde boss, of de event flag wordt niet goed gereset. Beheer een geplande grandboss vanuit één bron en zorg dat je de flag reset vóór de respawn.
Wil je een gebalanceerd boss- en grandboss-systeem voor je server? We kunnen de spawntiming, drop-economie en aankondigingsflow zo opzetten dat je spelers behouden blijven. Om je project te bespreken, neem contact met me op.