Metin2 Client Source Compilation Guide (Visual Studio)

Metin2 client source compilation looks intimidating at first, but when you work through it in the right order it is far more predictable than you might expect. The Metin2 client source is an older C++ codebase; it depends on a generous set of external libraries, and most errors come not from the build logic itself but from misconfigured paths, an incompatible compiler version, or a missing .lib file. In this guide I walk through the steps for compiling the client project (typically the UserInterface project) end to end with Visual Studio, the settings that matter, and the fixes for the errors you are most likely to hit.

Before you start: what you need

A healthy Metin2 client source compilation environment requires a few core pieces prepared in advance. Knowing which compiler version your source package was written for eliminates half of the problems you would otherwise run into later.

Visual Studio — Mind the version the source targets. Older client sources were mostly written for Visual Studio 2008/2010; they can also build with newer Visual Studio (2017/2019/2022), but you will need to adapt the platform toolset and SDK settings to do so.
External libraries — The client typically depends on Python (an embedded interpreter), DevIL (image loading), Granny (animation/skinning), plus helper libraries for compression and encryption. Their versions must match your source package exactly; the wrong Python version, for example, can eat hours of your time at the link stage.
Prebuilt dependencies — Most source packages ship the libraries they use either as ready .lib files or as separate solutions. The safest path is to build those sub-libraries first, then the client project.

Opening the solution and understanding the project layout

When you extract the source package you usually find a .sln (solution) file with several projects inside it. On the client side, the main project you care about is the one that produces the final executable (the game client), alongside static library projects such as EterLib, GameLib and ScriptLib.

When you open the solution in Visual Studio, an old-format solution will prompt a one-time conversion (upgrade). Taking a backup of the source before converting is strongly recommended.
Check the dependency order between projects (Build → Project Dependencies / Build Order). Static libraries must be built before the main project.
Select the correct active Configuration and platform. The client is classically built targeting Win32 (x86), not x64. You also need the 32-bit builds of Python and the other libraries.

Platform toolset, SDK and the C++ standard

When compiling an old source with a modern Visual Studio, the most critical settings are gathered here. In the project Properties, check the following:

Platform Toolset — With Visual Studio 2019/2022 you can pick the v142/v143 toolset; but if you want to minimise incompatibilities in old code, installing and selecting an appropriate older toolset (e.g. v141) via the Build Tools tends to produce fewer surprises.
Windows SDK Version — Select an SDK version that is actually installed. "Cannot find Windows SDK" type errors usually come from the project pointing at an SDK that no longer exists.
Character Set — Older Metin2 sources mostly run with the Multi-Byte Character Set. Forcing Unicode can produce compile errors in string functions.
Runtime Library — Make sure every project (sub-libraries and the main project) uses the same runtime: for Release, /MT or /MD must be consistent. Mixed runtimes are the leading cause of LNK2005 "already defined" errors.

Setting the include and library paths

For the compiler to find header files and the linker to find .lib files, you must define the paths correctly. Setting these per project is cleaner than spreading them machine-wide.

C/C++ → General → Additional Include Directories — Add the include folders of Python, DevIL, Granny and the other libraries here.
Linker → General → Additional Library Directories — Add the folders containing the .lib files of those same libraries.
Linker → Input → Additional Dependencies — List the required .lib names here. A missing entry leads straight to an LNK2019 (unresolved external symbol) error.
Where possible, write the paths as relative paths or with macros (e.g. $(SolutionDir)); that way you do not have to fix everything by hand when you move the source to another folder.

Common build errors and their fixes

Most of the time-wasting errors when building the client are at the link stage. Here are the typical examples and where to look:

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

LNK1104 (cannot open file) — The linker cannot find a .lib. Check the Library Directories path and whether the file really exists there in that version (e.g. the right Python version, the right 32/64-bit build).
LNK2019 (unresolved external symbol) — Usually a library is missing from the Additional Dependencies list, or one of the static libraries has not been built. Build the sub-libraries first.
LNK2005 (already defined) — Generally caused by an inconsistent Runtime Library setting or the same symbol being defined in two places. Align the runtime across all projects.
Compiler (C-prefixed) errors — Errors such as C2065 or C2664 are usually a sign of the wrong toolset/SDK or a Unicode/MBCS mismatch; review the character set and include paths first.

General rule: always read errors from top to bottom. The dozens of lines below the first error are often derivatives of the same root cause; fix the first line and the rest tend to fall away.

Frequently Asked Questions

Which Visual Studio version should I use?

The safest route is to use a toolset close to the version the source was written for. It can also build with a modern Visual Studio 2019/2022, but you will need to adapt the platform toolset, SDK and character set settings. If you run into trouble, installing the appropriate older Build Tools resolves most incompatibilities.

Do I really have to build x86 (Win32)?

Classic Metin2 client sources are designed for a 32-bit target and expect the 32-bit builds of their dependent libraries (Python included). Porting to x64 is an advanced undertaking; for a start, sticking with Win32 will be far smoother.

Where and in which version should I get the libraries?

The healthiest option is to use the versions that ship with your source package. For libraries like Python, DevIL and Granny, version compatibility is critical; random up-to-date versions can cause ABI mismatches and link errors.

Stuck on an LNK error? If you need help with Metin2 client and server compilation, source editing, or issues on the C++ side, get in touch with me — let's solve it together.