Metin2 Client Source Kompilieren Anleitung (Visual Studio)

Das Metin2 Client Source Kompilieren wirkt auf den ersten Blick einschüchternd, doch wenn man es in der richtigen Reihenfolge angeht, ist es weit berechenbarer, als man erwarten würde. Die Metin2-Client-Source ist eine ältere C++-Codebasis; sie hängt von einer großzügigen Menge externer Libraries ab, und die meisten Fehler entstehen nicht aus der Build-Logik selbst, sondern aus falsch konfigurierten Pfaden, einer inkompatiblen Compiler-Version oder einer fehlenden .lib-Datei. In dieser Anleitung gehe ich die Schritte durch, um das Client-Projekt (meist das UserInterface-Projekt) von Anfang bis Ende mit Visual Studio zu kompilieren, welche Einstellungen wichtig sind und wie man die Fehler löst, auf die man am häufigsten stößt.

Bevor du loslegst: was du brauchst

Eine gesunde Umgebung für das Metin2 Client Source Kompilieren erfordert ein paar Kernkomponenten, die du vorab bereitstellst. Zu wissen, für welche Compiler-Version dein Source-Paket geschrieben wurde, beseitigt von vornherein die Hälfte der Probleme, in die du sonst später geraten würdest.

Visual Studio — Achte auf die Version, auf die die Source abzielt. Ältere Client-Sources wurden meist für Visual Studio 2008/2010 geschrieben; sie lassen sich auch mit einem neueren Visual Studio (2017/2019/2022) bauen, doch dafür musst du das Platform Toolset und die SDK-Einstellungen anpassen.
Externe Libraries — Der Client hängt typischerweise von Python (eingebetteter Interpreter), DevIL (Bildladen), Granny (Animation/Skinning) sowie Hilfslibraries für Kompression und Verschlüsselung ab. Ihre Versionen müssen exakt zu deinem Source-Paket passen; die falsche Python-Version etwa kann dich in der Link-Phase Stunden kosten.
Vorgebaute Abhängigkeiten — Die meisten Source-Pakete liefern die verwendeten Libraries entweder als fertige .lib-Dateien oder als separate Solutions mit. Der sicherste Weg ist, zuerst diese Sub-Libraries und danach das Client-Projekt zu bauen.

Die Solution öffnen und die Projektstruktur verstehen

Wenn du das Source-Paket entpackst, findest du meist eine .sln-Datei (Solution) mit mehreren Projekten darin. Auf der Client-Seite ist das Hauptprojekt, das dich interessiert, jenes, das die finale Executable (den Game-Client) erzeugt, neben statischen Library-Projekten wie EterLib, GameLib und ScriptLib.

Öffnest du die Solution in Visual Studio, schlägt eine Solution im alten Format eine einmalige Konvertierung (Upgrade) vor. Eine Sicherung der Source vor dem Konvertieren ist dringend zu empfehlen.
Prüfe die Abhängigkeitsreihenfolge zwischen den Projekten (Build → Project Dependencies / Build Order). Statische Libraries müssen vor dem Hauptprojekt gebaut werden.
Wähle die richtige aktive Konfiguration und die richtige Plattform. Der Client wird klassisch für das Ziel Win32 (x86) gebaut, nicht x64. Du brauchst außerdem die 32-Bit-Builds von Python und den anderen Libraries.

Platform Toolset, SDK und der C++-Standard

Beim Kompilieren einer alten Source mit einem modernen Visual Studio bündeln sich die kritischsten Einstellungen hier. Sieh dir in den Projekteigenschaften (Properties) Folgendes an:

Platform Toolset — Mit Visual Studio 2019/2022 kannst du das Toolset v142/v143 wählen; willst du jedoch Inkompatibilitäten im alten Code verringern, sorgt das Installieren und Auswählen eines passenden älteren Toolsets (z. B. v141) über die Build Tools für weniger Überraschungen.
Windows SDK Version — Wähle eine SDK-Version, die tatsächlich installiert ist. Fehler vom Typ "Cannot find Windows SDK" kommen meist daher, dass das Projekt auf ein nicht mehr vorhandenes SDK zeigt.
Character Set — Ältere Metin2-Sources laufen meist mit dem Multi-Byte Character Set. Unicode zu erzwingen kann Kompilierfehler in String-Funktionen erzeugen.
Runtime Library — Stelle sicher, dass jedes Projekt (Sub-Libraries und Hauptprojekt) dieselbe Runtime nutzt: für Release muss /MT oder /MD konsistent sein. Gemischte Runtimes sind die häufigste Ursache für LNK2005-Fehler ("already defined").

Die Include- und Library-Pfade einstellen

Damit der Compiler die Header-Dateien und der Linker die .lib-Dateien findet, musst du die Pfade korrekt definieren. Diese pro Projekt zu setzen ist sauberer, als sie maschinenweit zu verteilen.

C/C++ → General → Additional Include Directories — Füge hier die include-Ordner von Python, DevIL, Granny und den anderen Libraries hinzu.
Linker → General → Additional Library Directories — Füge die Ordner mit den .lib-Dateien derselben Libraries hinzu.
Linker → Input → Additional Dependencies — Liste hier die benötigten .lib-Namen auf. Ein fehlender Eintrag führt direkt zu einem LNK2019-Fehler (unresolved external symbol).
Schreibe die Pfade nach Möglichkeit relativ oder mit Makros (z. B. $(SolutionDir)); so musst du nicht alles von Hand korrigieren, wenn du die Source in einen anderen Ordner verschiebst.

Häufige Build-Fehler und ihre Lösungen

Die meisten zeitraubenden Fehler beim Bauen des Clients liegen in der Link-Phase. Hier sind typische Beispiele und wo du nachsehen solltest:

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

LNK1104 (cannot open file) — Der Linker findet eine .lib nicht. Prüfe den Library-Directories-Pfad und ob die Datei wirklich in dieser Version dort liegt (z. B. die richtige Python-Version, der richtige 32/64-Bit-Build).
LNK2019 (unresolved external symbol) — Meist fehlt eine Library in der Liste Additional Dependencies, oder eine der statischen Libraries wurde nicht gebaut. Baue zuerst die Sub-Libraries.
LNK2005 (already defined) — In der Regel durch eine inkonsistente Runtime-Library-Einstellung oder dasselbe an zwei Stellen definierte Symbol verursacht. Gleiche die Runtime über alle Projekte hinweg an.
Compiler-Fehler (mit C-Präfix) — Fehler wie C2065 oder C2664 deuten meist auf das falsche Toolset/SDK oder einen Unicode/MBCS-Konflikt hin; prüfe zuerst das Character Set und die Include-Pfade.

Allgemeine Regel: Lies Fehler stets von oben nach unten. Die Dutzenden Zeilen unter dem ersten Fehler sind oft Ableitungen derselben Grundursache; behebst du die erste Zeile, fällt der Rest meist von selbst weg.

Häufig gestellte Fragen

Welche Visual-Studio-Version sollte ich verwenden?

Der sicherste Weg ist, ein Toolset zu nutzen, das nahe an der Version liegt, für die die Source geschrieben wurde. Sie lässt sich auch mit einem modernen Visual Studio 2019/2022 bauen, doch dann musst du die Platform-Toolset-, SDK- und Character-Set-Einstellungen anpassen. Bei Problemen behebt das Installieren der passenden älteren Build Tools die meisten Inkompatibilitäten.

Muss ich wirklich x86 (Win32) bauen?

Klassische Metin2-Client-Sources sind für ein 32-Bit-Ziel ausgelegt und erwarten die 32-Bit-Builds ihrer abhängigen Libraries (Python eingeschlossen). Eine Portierung nach x64 ist eine fortgeschrittene Aufgabe; für den Anfang läuft es mit Win32 deutlich reibungsloser.

Woher und in welcher Version sollte ich die Libraries beziehen?

Am gesündesten ist es, die Versionen zu nutzen, die mit deinem Source-Paket geliefert werden. Bei Libraries wie Python, DevIL und Granny ist die Versionskompatibilität entscheidend; beliebige aktuelle Versionen können ABI-Konflikte und Link-Fehler verursachen.

Hängst du an einem LNK-Fehler fest? Wenn du Hilfe beim Kompilieren von Metin2-Client und -Server, bei Source-Anpassungen oder bei Problemen auf der C++-Seite brauchst, nimm Kontakt mit mir auf — lösen wir es gemeinsam.