Système d'événements Metin2 : configurer des events auto

Un metin2 event system permet à votre serveur d'ouvrir un quiz OX à heures fixes chaque jour, de lancer une période de double drop ou de double EXP, ou d'annoncer un événement de pêche — le tout sans qu'un GM ne lève le petit doigt. Une boucle d'événements bien construite ramène les joueurs à intervalle régulier ; une mauvaise gonfle l'économie, provoque du lag, ou croit qu'un événement est encore « actif » après un redémarrage. Dans cet article, je couvre la logique des event flags qui sous-tend chaque événement, les commandes GM manuelles, et comment les automatiser avec un timer de quête ou le cron du système d'exploitation.

Les event flags : le langage commun de chaque événement

Dans la source de Metin2, presque tous les événements reposent sur un event flag. Un flag est un entier associé à un nom (par exemple double_drop = 1) lisible à la fois par le cœur du jeu (C++) et par le système de quêtes (Lua). La logique est simple : quelque part vous mettez le flag à 1, le code de drop/exp/événement vérifie cette valeur et change de comportement, et à la fin de l'événement vous le remettez à 0.

Côté quête, vous utilisez deux fonctions essentielles :

-- définir le flag (1 = activé, 0 = désactivé)
game.set_event_flag("double_drop", 1)

-- lire le flag
local actif = game.get_event_flag("double_drop")
if actif == 1 then
    -- l'événement est en cours
end

La force de cette approche tient à ce qu'un seul interrupteur central pilote tous les systèmes. Du calcul du drop à l'annonce à l'écran, chaque partie regarde le même flag, si bien qu'activer ou désactiver un événement se résume à une seule ligne.

Contrôle manuel : les commandes GM

Avant d'automatiser quoi que ce soit, vous devez pouvoir activer chaque événement à la main — indispensable aussi bien pour les tests que pour les urgences. Dans la plupart des sources, un GM peut changer un event flag directement avec une commande en jeu :

/event_flag double_drop 1   // activer le double drop
/event_flag double_drop 0   // le désactiver

Le nom exact de la commande peut varier selon la source (vérifiez quelle commande appelle SetEventFlag dans cmd.cpp). Les événements dotés de leur propre carte et d'une logique spéciale, comme OX, ont leurs propres commandes — généralement trois commandes GM distinctes pour démarrer l'événement, poser une question et le clôturer. Une fois ces commandes vérifiées avec un compte GM, mettre en place l'automatisation est bien plus sûr, car le timer ne fait que déclencher « ce qu'un GM aurait tapé à la main ».

Automatiser avec un timer de quête

L'automatisation interne la plus propre consiste à utiliser le système de quêtes du serveur comme planificateur. Vous démarrez un server timer qui se déclenche à intervalle régulier, vous vérifiez l'horloge à chaque tick, et vous basculez le flag au bon moment. L'exemple ci-dessous lit l'horloge chaque minute et active puis désactive l'événement double drop deux fois par jour :

quest auto_event begin
    state start begin
        when login begin
            -- démarrer le timer une seule fois
            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("L'événement double drop a commencé ! Il dure 2 heures.")
            elseif t.hour == 22 and t.min == 0 then
                game.set_event_flag("double_drop", 0)
                notice_all("L'événement double drop est terminé.")
            end
            -- réarmer le timer
            server_timer("event_tick", 60)
        end
    end
end

Notez trois points ici : démarrer le timer une seule fois (sinon chaque connexion en ouvre un nouveau), le réarmer à chaque tick (les server timers sont à usage unique) et annoncer à tout le serveur avec notice_all. Les noms de timers et de fonctions peuvent varier légèrement selon les sources ; référez-vous aux exemples existants dans votre propre questlib.lua.

Relier le multiplicateur de drop et d'EXP au flag

La quête définit le flag, mais le vrai multiplicateur agit dans le cœur du jeu. Pour rendre le taux de drop sensible au flag, ajoutez une vérification au calcul du drop dans char_item.cpp :

int iEventFlag = quest::CQuestManager::instance().GetEventFlag("double_drop");
if (iEventFlag > 0)
    iDropPct *= 2;   // doubler la chance de drop

La même logique s'applique à l'EXP dans la fonction de gain d'expérience de char.cpp, et au drop de yangs/argent dans la fonction concernée. L'erreur la plus fréquente est de rendre le multiplicateur trop agressif (par exemple x5 EXP) puis d'oublier de réinitialiser le flag à la fin de l'événement, gonflant l'économie de manière permanente. Gardez des multiplicateurs modérés et assurez-vous que chaque flag activé possède une condition de désactivation correspondante.

OX, pêche et autres événements liés à une carte

Un quiz OX demande plus qu'un simple flag : une carte dédiée (généralement un index de carte distinct), la téléportation des joueurs, une boucle de questions-réponses et une logique pour éliminer ceux qui répondent mal. C'est pourquoi OX est livré dans la plupart des sources sous forme de quête et de carte prêtes à l'emploi ; votre travail consiste à le relier au planificateur. Dans une configuration automatisée, votre timer appelle la commande/fonction qui démarre OX à la bonne heure, l'annonce aux joueurs et clôture l'événement à l'expiration du temps.

• Quiz OX : rassembler les joueurs, poser des questions et distribuer des récompenses ; nécessite une téléportation vers une carte.
• Événement de pêche : lier un flag au système de pêche pour augmenter temporairement la chance de poissons/objets rares.
• Double drop / EXP / yang : juste un event flag plus une vérification de multiplicateur dans le cœur — les plus faciles à mettre en place.

Si vous préférez une automatisation au niveau du système, vous pouvez exécuter un petit script via le cron de Linux qui bascule le flag à des heures précises ; mais comme le script doit communiquer en toute sécurité avec le cœur du jeu, un timer de quête est plus simple et moins fragile pour la plupart des serveurs.

Persistance et erreurs fréquentes

Les event flags résident en mémoire et, dans de nombreuses sources, sont réinitialisés au redémarrage du serveur. C'est pourquoi il est plus robuste d'écrire votre timer avec une logique « maintiens-le actif si nous sommes dans la fenêtre de l'événement » plutôt que simplement « active-le à telle heure » ; ainsi, après un crash, un événement revient seul au bon état. Autres points de vigilance :

• Donnez à chaque set_event_flag(..., 1) une condition de désactivation claire ; un événement laissé « actif » par mégarde casse l'économie.
• N'abusez pas des annonces ; un notice_all à l'écran chaque minute agace les joueurs.
• Testez les événements avec téléportation comme OX aux heures de pointe ; la capacité de la carte et la logique de téléportation peuvent réagir différemment sous charge.
• Documentez vos noms de flags quelque part ; des noms cohérents comme double_drop et double_exp évitent la confusion plus tard.

Questions fréquentes

Les event flags disparaissent au redémarrage du serveur — que faire ?

Dans la plupart des sources, les flags résident en mémoire et sont réinitialisés au redémarrage. La solution la plus pratique est d'écrire le timer avec une « logique de fenêtre » : à chaque tick, vérifiez si l'heure actuelle tombe dans la fenêtre de l'événement et définissez le flag en conséquence. Ainsi l'état se corrige tout seul une ou deux minutes après un redémarrage.

J'ai activé l'événement double drop mais les drops n'ont pas changé — pourquoi ?

Il est probable que la quête définisse le flag mais que le cœur du jeu ne le lise pas. Vous devez ajouter le multiplicateur de drop au calcul dans char_item.cpp et recompiler la source. Assurez-vous que le nom du flag est écrit exactement de la même façon dans la quête et dans le cœur.

Dois-je écrire l'événement OX de zéro ?

Non. OX est livré avec sa carte et sa logique spéciale dans la plupart des sources ; votre travail consiste à le vérifier et à le relier au planificateur. L'écrire de zéro n'a de sens que si vous voulez une mécanique totalement originale.

Vous voulez un système d'événements automatique stable sur votre serveur ? Nous pouvons travailler ensemble sur l'architecture des event flags Metin2, l'OX et l'automatisation du double drop. Pour parler de votre projet, contactez-moi.