Guide de compilation du client source Metin2 (Visual Studio)

La compilation du client source Metin2 paraît intimidante au premier abord, mais lorsqu'on procède dans le bon ordre, elle est bien plus prévisible qu'on ne le croit. Le code source du client Metin2 est une base de code C++ assez ancienne ; elle dépend d'un généreux ensemble de bibliothèques externes, et la plupart des erreurs proviennent non pas de la logique de compilation, mais de chemins mal configurés, d'une version de compilateur incompatible ou d'un fichier .lib manquant. Dans ce guide, je détaille les étapes pour compiler le projet client (généralement le projet UserInterface) de bout en bout avec Visual Studio, les réglages qui comptent et les solutions aux erreurs que vous rencontrerez le plus souvent.

Avant de commencer : ce qu'il vous faut

Un environnement sain pour la compilation du client source Metin2 exige quelques éléments fondamentaux préparés à l'avance. Savoir pour quelle version de compilateur votre paquet source a été écrit élimine d'emblée la moitié des problèmes que vous rencontreriez plus tard.

Visual Studio — Faites attention à la version visée par la source. Les anciennes sources du client ont surtout été écrites pour Visual Studio 2008/2010 ; elles peuvent aussi se compiler avec un Visual Studio plus récent (2017/2019/2022), mais il faudra adapter le platform toolset et les réglages du SDK.
Bibliothèques externes — Le client dépend typiquement de Python (interpréteur embarqué), de DevIL (chargement d'images), de Granny (animation/skinning), ainsi que de bibliothèques d'aide pour la compression et le chiffrement. Leurs versions doivent correspondre exactement à votre paquet source ; une mauvaise version de Python, par exemple, peut vous coûter des heures à l'étape d'édition de liens.
Dépendances précompilées — La plupart des paquets sources fournissent les bibliothèques qu'ils utilisent, soit sous forme de .lib prêts à l'emploi, soit comme solutions séparées. Le plus sûr est de compiler d'abord ces sous-bibliothèques, puis le projet client.

Ouvrir la solution et comprendre la structure du projet

En extrayant le paquet source, vous trouvez généralement un fichier .sln (solution) contenant plusieurs projets. Côté client, le projet principal qui vous intéresse est celui qui produit l'exécutable final (le client de jeu), aux côtés de projets de bibliothèques statiques comme EterLib, GameLib et ScriptLib.

À l'ouverture de la solution dans Visual Studio, une solution au format ancien proposera une conversion (mise à niveau) ponctuelle. Il est vivement conseillé de faire une sauvegarde de la source avant de convertir.
Vérifiez l'ordre des dépendances entre projets (Build → Project Dependencies / Build Order). Les bibliothèques statiques doivent être compilées avant le projet principal.
Sélectionnez la bonne configuration active et la bonne plateforme. Le client se compile classiquement pour la cible Win32 (x86), pas x64. Il vous faut aussi les versions 32 bits de Python et des autres bibliothèques.

Platform toolset, SDK et le standard C++

En compilant une ancienne source avec un Visual Studio moderne, les réglages les plus critiques se concentrent ici. Dans les propriétés du projet (Properties), examinez les points suivants :

Platform Toolset — Avec Visual Studio 2019/2022, vous pouvez choisir le toolset v142/v143 ; mais pour réduire les incompatibilités du vieux code, installer et sélectionner un toolset plus ancien adapté (par ex. v141) via les Build Tools provoque moins de surprises.
Windows SDK Version — Choisissez une version de SDK réellement installée. Les erreurs du type « Cannot find Windows SDK » viennent souvent du projet qui pointe vers un SDK qui n'existe plus.
Character Set — Les anciennes sources Metin2 fonctionnent surtout en Multi-Byte Character Set. Forcer l'Unicode peut générer des erreurs de compilation dans les fonctions de chaînes.
Runtime Library — Assurez-vous que tous les projets (sous-bibliothèques et projet principal) utilisent le même runtime : en Release, /MT ou /MD doit rester cohérent. Des runtimes mélangés sont la cause principale des erreurs LNK2005 « already defined ».

Configurer les chemins include et library

Pour que le compilateur trouve les en-têtes et que l'éditeur de liens trouve les fichiers .lib, vous devez définir les chemins correctement. Les régler par projet est plus propre que de les répandre à l'échelle de la machine.

C/C++ → General → Additional Include Directories — Ajoutez ici les dossiers include de Python, DevIL, Granny et des autres bibliothèques.
Linker → General → Additional Library Directories — Ajoutez les dossiers contenant les fichiers .lib de ces mêmes bibliothèques.
Linker → Input → Additional Dependencies — Listez ici les noms des .lib requis. Une entrée manquante mène droit à une erreur LNK2019 (unresolved external symbol).
Dans la mesure du possible, écrivez les chemins en relatif ou avec des macros (par ex. $(SolutionDir)) ; ainsi vous n'aurez pas à tout corriger à la main si vous déplacez la source dans un autre dossier.

Erreurs de compilation fréquentes et leurs solutions

La plupart des erreurs qui font perdre du temps lors de la compilation du client se situent à l'étape d'édition de liens. Voici des exemples typiques et où regarder :

error LNK2019: unresolved external symbol ...
error LNK1104: cannot open file 'python27.lib'
error LNK2005: ... already defined in ...

LNK1104 (cannot open file) — L'éditeur de liens ne trouve pas un .lib. Vérifiez le chemin Library Directories et que le fichier existe bien dans cette version (par ex. la bonne version de Python, le bon build 32/64 bits).
LNK2019 (unresolved external symbol) — Souvent une bibliothèque manque dans la liste Additional Dependencies, ou l'une des bibliothèques statiques n'a pas été compilée. Compilez d'abord les sous-bibliothèques.
LNK2005 (already defined) — Généralement dû à un réglage Runtime Library incohérent ou au même symbole défini à deux endroits. Alignez le runtime sur tous les projets.
Erreurs du compilateur (préfixe C) — Des erreurs comme C2065 ou C2664 signalent souvent un mauvais toolset/SDK ou un conflit Unicode/MBCS ; revoyez d'abord le character set et les chemins include.

Règle générale : lisez toujours les erreurs de haut en bas. Les dizaines de lignes sous la première erreur sont souvent des dérivées de la même cause racine ; corrigez la première ligne et le reste a tendance à disparaître.

Foire aux questions

Quelle version de Visual Studio utiliser ?

Le plus sûr est d'utiliser un toolset proche de la version pour laquelle la source a été écrite. Elle peut aussi se compiler avec un Visual Studio 2019/2022 moderne, mais il faudra adapter les réglages du platform toolset, du SDK et du character set. En cas de souci, installer les Build Tools plus anciens appropriés résout la plupart des incompatibilités.

Faut-il vraiment compiler en x86 (Win32) ?

Les sources classiques du client Metin2 sont conçues pour une cible 32 bits et attendent les builds 32 bits de leurs bibliothèques dépendantes (Python compris). Le portage vers x64 est un travail avancé ; pour débuter, rester en Win32 sera bien plus fluide.

Où et dans quelle version récupérer les bibliothèques ?

Le plus sain est d'utiliser les versions fournies avec votre paquet source. Pour des bibliothèques comme Python, DevIL et Granny, la compatibilité de version est critique ; des versions récentes au hasard peuvent provoquer des incompatibilités d'ABI et des erreurs d'édition de liens.

Bloqué sur une erreur LNK ? Si vous avez besoin d'aide pour la compilation du client et du serveur Metin2, l'édition de source ou des problèmes côté C++, contactez-moi — résolvons cela ensemble.