Metin2 Mob Proto : Ajouter un Nouveau Monstre

Tôt ou tard, en gérant un serveur privé, vous voudrez ajouter vos propres créatures, et au cœur de cette tâche se trouve le fichier metin2 mob proto. Le mob proto est la « carte d'identité » de chaque monstre, PNJ et boss du serveur : un grand tableau qui rassemble le niveau, les points de vie, les dégâts, la race, les résistances et les objets lâchés. Dans ce guide, nous expliquerons les champs en langage clair, puis nous créerons notre propre monstre sur un VNUM libre et l'enregistrerons correctement côté serveur et côté client.

Qu'est-ce que le mob proto et où se trouve-t-il ?

Dans les serverfiles officiels et les anciens basés sur 40k, les données des monstres sont stockées de deux manières. La méthode classique utilise un fichier lisible mob_proto.txt ; les installations modernes conservent les mêmes données dans la table MySQL player.mob_proto, et l'outil dump_proto en génère le fichier mob_proto chiffré que le client peut lire. Quel que soit le système, la logique est identique : chaque ligne est un monstre, et chaque colonne est l'une de ses propriétés.

N'oubliez pas qu'il y a deux côtés. Le serveur lit le proto pour les calculs de combat (vie, dégâts, résistances, IA). Le client a besoin de sa propre copie pour connaître le nom, le modèle et le dossier du monstre. Si les deux côtés ne reconnaissent pas le même VNUM, le monstre sera invisible ou le client plantera.

Les champs les plus importants

Une ligne de proto comporte des dizaines de colonnes, mais quelques-unes définissent le caractère d'un monstre :

VNUM — L'identifiant unique. Tout le système communique par ce numéro ; il ne doit jamais entrer en conflit.
NAME / LOCALE_NAME — Le nom vu par le joueur. Pour la localisation, on utilise aussi mob_names.txt.
RANK — PAWN, S_PAWN, KNIGHT, S_KNIGHT, BOSS, KING. Indique s'il s'agit d'un monstre ordinaire ou d'un boss.
TYPE — MONSTER, NPC, STONE (pierre metin), WARP, DOOR, etc. Pour une créature, utilisez MONSTER.
BATTLE_TYPE — Style d'attaque tel que MELEE, RANGE ou MAGIC.
LEVEL, MAX_HP, ST/DX/HT/IQ, DAMAGE_MIN/MAX, DEF — Les statistiques de combat de base.
AI_FLAG — Drapeaux de comportement comme AGGRESSIVE, COWARD (fuit) et NOMOVE (reste sur place).
RACE_FLAG — Race telle que ANIMAL, UNDEAD, DEVIL ou ORC. Certains objets et compétences infligent des dégâts bonus selon elle.
IMMUNE_FLAG — Immunités comme STUN, SLOW et POISON.
RESIST_* / ENCHANT_* — Résistance aux types d'armes et à la magie, plus les effets ajoutés aux attaques (poison, étourdissement, critique).
EXP, GOLD_MIN/MAX, DROP_ITEM — Récompenses et lien vers son groupe de butin.
FOLDER — Le nom du dossier du modèle côté client. Une erreur ici et le client ne trouve pas le modèle.

Choisissez un VNUM libre pour votre nouveau monstre

La première règle est d'éviter les conflits. Écraser un VNUM existant casse tous les regen et quêtes liés à ce monstre. La plage à partir de 20000 est généralement libre pour le contenu personnalisé. Vérifiez que le numéro est vraiment vide dans la table actuelle :

-- Sur une installation basée sur MySQL
SELECT vnum, locale_name FROM player.mob_proto WHERE vnum = 20801;

Si le résultat est vide, ce numéro est à vous. Si vous travaillez avec le fichier texte, cherchez le même VNUM dans mob_proto.txt pour vous assurer qu'il n'est pas pris.

Construisez la ligne

Une approche pratique consiste à copier la ligne d'un monstre existant proche du vôtre et à l'ajuster, pour ne pas remplir chaque colonne à partir de zéro. Par exemple, basons un « Loup d'Ombre » amélioré sur un loup ordinaire. Dans le fichier texte, la ligne est séparée par des TAB et doit respecter exactement l'ordre de la ligne d'en-tête :

# VNUM  NAME          RANK    TYPE     BATTLE_TYPE  LEVEL  ...  MAX_HP  ...  EXP    GOLD_MIN  GOLD_MAX  ...
20801   Shadow_Wolf   KNIGHT  MONSTER  MELEE        42     ...  18500   ...  9200   500       1400      ...

Comme le nombre et l'ordre des colonnes varient selon la version des serverfiles, dérivez toujours la vraie ligne d'un autre monstre du même fichier ; n'inventez pas de colonnes. Côté MySQL, faites de même avec un INSERT :

INSERT INTO player.mob_proto (vnum, name, locale_name, rank, type, battle_type, level, max_hp, exp, gold_min, gold_max)
VALUES (20801, 'Shadow_Wolf', 'Loup d Ombre', 'KNIGHT', 'MONSTER', 'MELEE', 42, 18500, 9200, 500, 1400);
-- les autres colonnes prennent les valeurs par défaut de la table ; ajustez avec UPDATE si besoin

Pour localiser le nom, ajoutez aussi le VNUM et le nom affiché dans mob_names.txt. Définissez ses butins en liant le VNUM dans mob_drop_item.txt / common_drop_item.txt ou via une quête.

N'oubliez pas le côté client

Même si le serveur connaît le monstre, le client doit reconnaître le même VNUM pour qu'il apparaisse à l'écran du joueur. Pour cela, vous générez un nouveau mob_proto client avec dump_proto et le distribuez au client des joueurs. Le dossier de modèle nommé dans le champ FOLDER doit aussi exister réellement dans les packs du client (généralement le modèle .gr2 et ses textures). Si vous n'ajoutez pas un tout nouveau modèle, pointer vers le dossier d'un modèle de loup existant est la voie la plus sûre.

Chargez et testez

Une fois les changements faits, redémarrez les cores concernés (les couches db et game/ch) pour que le proto soit relu côté serveur. Testez ensuite en jeu avec un compte GM :

// Faire apparaître le monstre près de vous avec une commande GM (selon les serverfiles)
/m 20801

Si le monstre apparaît avec le bon nom, le bon modèle et des stats cohérentes, la partie proto est terminée. Pour qu'il apparaisse en permanence sur une carte, ajoutez une entrée de spawn dans le regen.txt du serveur de carte (ou boss.txt pour les boss). Deux erreurs reviennent souvent pendant les tests : le monstre n'apparaît pas côté client (mauvais FOLDER ou proto client obsolète) et le serveur plante au démarrage (le nombre de colonnes de la ligne ne correspond pas à l'en-tête).

Questions fréquentes

Dois-je utiliser mob_proto.txt ou MySQL ?

Cela dépend du système que lisent vos serverfiles. Les fichiers de nouvelle génération s'appuient généralement sur la table player.mob_proto et construisent le proto client avec dump_proto. Sur les installations qui utilisent les deux, la source doit toujours être la même, sinon le serveur et le client voient des données différentes et entrent en conflit.

Mon nouveau monstre apparaît mais ne lâche rien — pourquoi ?

Le mob proto ne contient pas directement les butins ; ils sont définis dans des fichiers séparés comme mob_drop_item.txt et common_drop_item.txt, ou dans des quêtes. Si vous n'avez pas lié le nouveau VNUM à l'un de ces systèmes, le monstre ne lâche rien.

Pourquoi le serveur plante-t-il au démarrage ?

La cause la plus fréquente est que le nombre de colonnes de votre nouvelle ligne, ou le type d'un champ (par exemple du texte là où un nombre est attendu), ne correspond pas à la ligne d'en-tête. Commencez toujours par copier la ligne d'un monstre existant, et ne cassez pas l'alignement des tabulations.

Vous voulez des monstres personnalisés, des boss ou une économie de mobs équilibrée pour votre serveur ? Si vous avez besoin d'aide pour les modifications de proto, de quêtes et de systèmes Metin2, contactez-moi — posons ensemble des bases solides pour votre projet.