Metin2 Event-systeem: automatische events instellen

Een metin2 event system laat je server elke dag op vaste uren een OX-quiz openen, een double-drop- of double-EXP-periode starten of een visevent aankondigen — allemaal zonder dat een GM een vinger uitsteekt. Een goed gebouwde event-loop trekt spelers met een vast schema steeds terug; een slecht gebouwde blaast de economie op, veroorzaakt lag of denkt dat een event nog "aan" staat na een herstart. In dit artikel behandel ik de event flag-logica die onder elk event ligt, de handmatige GM-commando's en hoe je ze automatiseert met een quest-timer of de cron van het besturingssysteem.

Event flags: de gedeelde taal van elk event

In de Metin2-source draait vrijwel elk event op een event flag. Een flag is een geheel getal dat aan een naam is gekoppeld (bijvoorbeeld double_drop = 1) en dat zowel door de game-core (C++) als door het questsysteem (Lua) gelezen kan worden. De logica is simpel: ergens zet je de flag op 1, de drop/exp/event-code controleert die waarde en past zijn gedrag aan, en als het event eindigt zet je hem terug op 0.

Aan de questkant gebruik je twee kernfuncties:

-- de flag instellen (1 = aan, 0 = uit)
game.set_event_flag("double_drop", 1)

-- de flag uitlezen
local actief = game.get_event_flag("double_drop")
if actief == 1 then
    -- event loopt
end

De kracht van deze aanpak is dat één centrale schakelaar elk systeem aandrijft. Van de dropberekening tot de melding op het scherm, elk onderdeel kijkt naar dezelfde flag, dus een event aan- of uitzetten komt neer op één regel.

Handmatige controle: GM-commando's

Voordat je iets automatiseert, moet je elk event met de hand kunnen omschakelen — essentieel voor zowel testen als noodgevallen. In de meeste sources kan een GM een event flag rechtstreeks met een commando in-game wijzigen:

/event_flag double_drop 1   // double drop aanzetten
/event_flag double_drop 0   // uitzetten

De exacte commandonaam kan per source verschillen (kijk welk commando SetEventFlag aanroept in cmd.cpp). Events met een eigen map en speciale logica, zoals OX, hebben hun eigen commando's — meestal drie aparte GM-commando's om het event te starten, een vraag te stellen en het te sluiten. Zodra je deze commando's met een GM-account hebt geverifieerd, is automatiseren veel veiliger, omdat de timer simpelweg triggert "wat een GM met de hand zou typen".

Automatiseren met een quest-timer

De schoonste in-game automatisering is het eigen questsysteem van de server als scheduler gebruiken. Je start een server-timer die op vaste intervallen afgaat, controleert bij elke tick de klok en zet de flag op het juiste moment om. Het voorbeeld hieronder leest elke minuut de klok en zet het double-drop-event twee keer per dag aan en uit:

quest auto_event begin
    state start begin
        when login begin
            -- start de timer slechts één keer
            if not q.getf("running") then
                q.setf("running", 1)
                server_timer("event_tick", 60)
            end
        end

        when event_tick.server_timer begin
            local t = os.date("*t", get_global_time())
            if t.hour == 20 and t.min == 0 then
                game.set_event_flag("double_drop", 1)
                notice_all("Het double-drop-event is begonnen! Het duurt 2 uur.")
            elseif t.hour == 22 and t.min == 0 then
                game.set_event_flag("double_drop", 0)
                notice_all("Het double-drop-event is afgelopen.")
            end
            -- de timer opnieuw instellen
            server_timer("event_tick", 60)
        end
    end
end

Let op drie dingen hier: start de timer maar één keer (anders opent elke login een nieuwe), stel hem bij elke tick opnieuw in (server-timers zijn eenmalig) en kondig met notice_all aan de hele server aan. Timer- en functienamen kunnen per source licht verschillen; gebruik de bestaande voorbeelden in je eigen questlib.lua als referentie.

De drop- en EXP-multiplier aan de flag koppelen

De quest zet de flag, maar de echte multiplier gebeurt in de game-core. Om de droprate op de flag te laten reageren, voeg je een controle toe aan de dropberekening in char_item.cpp:

int iEventFlag = quest::CQuestManager::instance().GetEventFlag("double_drop");
if (iEventFlag > 0)
    iDropPct *= 2;   // verdubbel de dropkans

Dezelfde logica geldt voor EXP in de ervaringsfunctie in char.cpp en voor yang/geld-drops in de betreffende functie. De meest gemaakte fout hier is de multiplier te agressief maken (zeg x5 EXP) en daarna vergeten de flag te resetten als het event eindigt, waardoor de economie permanent opzwelt. Houd de multipliers gematigd en zorg dat elke flag die je aanzet een bijbehorende uit-conditie heeft.

OX, vissen en andere map-gebaseerde events

Een OX-quiz heeft meer nodig dan een simpele flag: een aparte map (meestal een eigen map-index), spelers daarheen teleporteren, een vraag-en-antwoord-loop en logica om iedereen die fout antwoordt te elimineren. Daarom komt OX in de meeste sources als kant-en-klare quest en map; jouw taak is hem aan de scheduler koppelen. In een geautomatiseerde opzet roept je timer het commando/de functie aan die OX op het juiste uur start, kondigt het aan spelers aan en sluit het event als de tijd om is.

• OX-quiz: spelers verzamelen, vragen stellen en beloningen uitdelen; vereist teleporteren naar een map.
• Visevent: koppel een flag aan het vissysteem om tijdelijk de kans op zeldzame vis/items te verhogen.
• Double drop / EXP / yang: alleen een event flag plus een multiplier-controle in de core — het makkelijkst op te zetten.

Geef je de voorkeur aan automatisering op OS-niveau, dan kun je via Linux cron een klein script draaien dat de flag op bepaalde uren omzet; maar omdat het script veilig met de game-core moet praten, is een quest-timer voor de meeste servers eenvoudiger en minder kwetsbaar.

Persistentie en veelgemaakte fouten

Event flags leven in het geheugen en resetten in veel sources wanneer de server herstart. Daarom is het robuuster om je timer met "houd hem aan als we binnen het event-venster zitten"-logica te schrijven in plaats van alleen "zet hem aan op dit uur"; zo keert een event na een crash vanzelf terug naar de juiste staat. Andere aandachtspunten:

• Geef elke set_event_flag(..., 1) een duidelijke uit-conditie; een per ongeluk "aan" gelaten event breekt de economie.
• Overdrijf de meldingen niet; een notice_all die elke minuut op het scherm verschijnt, irriteert spelers.
• Test teleport-gebaseerde events zoals OX op piekuren; mapcapaciteit en teleportlogica kunnen onder belasting anders reageren.
• Documenteer je flagnamen ergens; consistente namen als double_drop en double_exp voorkomen later verwarring.

Veelgestelde vragen

Event flags verdwijnen wanneer de server herstart — wat moet ik doen?

In de meeste sources leven flags in het geheugen en resetten ze bij een herstart. De praktischste oplossing is de timer met "venster-logica" te schrijven: controleer bij elke tick of de huidige tijd binnen het event-venster valt en stel de flag dienovereenkomstig in. Zo corrigeert de staat zichzelf binnen een minuut of twee na een herstart.

Ik heb het double-drop-event aangezet maar de drops veranderden niet — waarom?

Hoogstwaarschijnlijk zet de quest de flag wel, maar leest de game-core hem niet uit. Je moet de drop-multiplier toevoegen aan de berekening in char_item.cpp en de source opnieuw compileren. Zorg dat de flagnaam in de quest en in de core exact hetzelfde gespeld is.

Moet ik het OX-event vanaf nul schrijven?

Nee. OX komt met zijn map en speciale logica in de meeste sources mee; jouw taak is hem te verifiëren en aan de scheduler te koppelen. Vanaf nul schrijven is alleen zinvol als je een volledig originele mechaniek wilt.

Wil je een stabiel automatisch event-systeem op je server? We kunnen samen werken aan Metin2 event flag-architectuur, OX en double-drop-automatisering. Om over je project te praten, neem contact met me op.