[SRC] Metin2 on LINUX - The Old Metin2 Project

[EnneGi 4]

Thanks OP for this release, i was excited to try it and it just works. Fantastic!

I have a question: i know that for the linux version to work, it was changed the network library to libevent.

I would like to implement in the source the Target Info System; do you know if that could work without problems? Or maybe there are compatibility issues

 

Thank you in advance

[.NyanCat 31]

On 4/24/2024 at 11:00 AM, EnneGi said:

Thanks OP for this release, i was excited to try it and it just works. Fantastic!

I have a question: i know that for the linux version to work, it was changed the network library to libevent.

I would like to implement in the source the Target Info System; do you know if that could work without problems? Or maybe there are compatibility issues

 

Thank you in advance

There should be no issue implementing that. The changes are related to the networking layer. The package transport should be untouched.

[EnneGi 4]

Just now, .NyanCat said:

There should be no issue implementing that. The changes are related to the networking layer. The package transport should be untouched.

Thanks sir! I implemented that with no issue.

[Jira 736]

I found a mistake here 

This is the hidden content, please

• Sign In
• or
• Sign Up

 

Additionally, from what I observed, there doesn't appear to be a buffer input limit for client session.

Thanks for sharing. 

[Exynox 3520]

On 6/25/2024 at 1:08 PM, Jira said:

I found a mistake here 

This is the hidden content, please

• Sign In
• or
• Sign Up

 

Additionally, from what I observed, there doesn't appear to be a buffer input limit for client session.

Thanks for sharing. 

Nice catch, thanks! I'll keep it in mind!

[Sokus 0]

What is the current preferred way to get this running? I've tried the docker method but it throws errors after running docker compose.

On default (master) branch I quite quickly get errors while vcpkg installs boost: https://pastebin.com/H6EJmwjp
When checked out to nightly branch it runs for much longer but eventually I get errors because "flame_dungeon.quest" is missing: https://pastebin.com/dXH469vD
I've also tried checking out to the 0.2.2 tag but it fails almost instantly (no candidate found for python2 package) so I won't even post the output.

PS. If there is a better place to discuss/debug, for example some sort of discord server I would be glad to join - I've got an invitation but it expired on me 

 

[Sokus 0]

17 hours ago, Sokus said:

it throws errors after running docker compose.

I've meant docker build, not docker compose - couldn't find a way to edit the original message.

[Koray 3316]

21 hours ago, Sokus said:

What is the current preferred way to get this running? I've tried the docker method but it throws errors after running docker compose.

On default (master) branch I quite quickly get errors while vcpkg installs boost: https://pastebin.com/H6EJmwjp
When checked out to nightly branch it runs for much longer but eventually I get errors because "flame_dungeon.quest" is missing: https://pastebin.com/dXH469vD
I've also tried checking out to the 0.2.2 tag but it fails almost instantly (no candidate found for python2 package) so I won't even post the output.

PS. If there is a better place to discuss/debug, for example some sort of discord server I would be glad to join - I've got an invitation but it expired on me 

 

I haven't tried it with the files in thread, but AFAIK there is no need for a library that uses Boost. You can use them as header-only, which will also significantly reduce the build time. Remove the Boost packages from vcpkg and manually load them through the extern folder, or to automate the process, try using

This is the hidden content, please

• Sign In
• or
• Sign Up

as shown below;

set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
CPMAddPackage(
  NAME Boost
  VERSION 1.85.0
    URL https://boostorg.jfrog.io/artifactory/main/release/1.85.0/source/boost_1_85_0.tar.gz
    DOWNLOAD_ONLY True 
)
if(Boost_ADDED)
    # Define the header-only Boost target
    add_library(Boost::boost INTERFACE IMPORTED GLOBAL)
    target_include_directories(Boost::boost SYSTEM INTERFACE ${Boost_SOURCE_DIR})
    
    # Disable autolink
    target_compile_definitions(Boost::boost INTERFACE BOOST_ALL_NO_LIB=1)

    # Find the required Boost components
    find_package(Boost 1.85.0 REQUIRED COMPONENTS ${Boost_COMPONENTS})
endif()

 

[Exynox 3520]

On 7/4/2024 at 5:56 PM, Sokus said:

What is the current preferred way to get this running? I've tried the docker method but it throws errors after running docker compose.

On default (master) branch I quite quickly get errors while vcpkg installs boost: https://pastebin.com/H6EJmwjp
When checked out to nightly branch it runs for much longer but eventually I get errors because "flame_dungeon.quest" is missing: https://pastebin.com/dXH469vD
I've also tried checking out to the 0.2.2 tag but it fails almost instantly (no candidate found for python2 package) so I won't even post the output.

PS. If there is a better place to discuss/debug, for example some sort of discord server I would be glad to join - I've got an invitation but it expired on me 

 

Hey, I'm currently working (in my very little free time) to releasing the nightly branch(es) of the project, together with a complete usage guide. The master branch is currently broken due to an old version of CMake, but I honestly don't know why you're getting that flame_dungeon.quest issue. Have you edited locale_list? that \r control character shouldn't be there on a UNIX system (\r\n is the line ending for a Windows system). At any rate, here's a discord invite: https://discord.gg/RtTSdUhK
 

19 hours ago, Koray said:

I haven't tried it with the files in thread, but AFAIK there is no need for a library that uses Boost. You can use them as header-only, which will also significantly reduce the build time. Remove the Boost packages from vcpkg and manually load them through the extern folder, or to automate the process, try using

This is the hidden content, please

• Sign In
• or
• Sign Up

as shown below;

Thanks for the suggestion, but the thing is that I plan on completely removing boost all-together, it's only currently used for some funky string manipulation which I think could be handled by libicu. There's no need for such a huge library when most of its features are now implemented in the C++ standards and/or supported by lighter libraries.

[Sokus 0]

On 7/5/2024 at 2:18 PM, Koray said:

I haven't tried it with the files in thread, but AFAIK there is no need for a library that uses Boost. You can use them as header-only, which will also significantly reduce the build time. Remove the Boost packages from vcpkg and manually load them through the extern folder, or to automate the process, try using

This is the hidden content, please

• Sign In
• or
• Sign Up

as shown below;

set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
CPMAddPackage(
  NAME Boost
  VERSION 1.85.0
    URL https://boostorg.jfrog.io/artifactory/main/release/1.85.0/source/boost_1_85_0.tar.gz
    DOWNLOAD_ONLY True 
)
if(Boost_ADDED)
    # Define the header-only Boost target
    add_library(Boost::boost INTERFACE IMPORTED GLOBAL)
    target_include_directories(Boost::boost SYSTEM INTERFACE ${Boost_SOURCE_DIR})
    
    # Disable autolink
    target_compile_definitions(Boost::boost INTERFACE BOOST_ALL_NO_LIB=1)

    # Find the required Boost components
    find_package(Boost 1.85.0 REQUIRED COMPONENTS ${Boost_COMPONENTS})
endif()

 

I had to remove boost-system and libmysql from vcpkg install for it to progress further (both were depending on Boost), CPMAddPackage seems to be working for Boost - how can I do the same for libmysql? CMake is throwing errors because it cannot find unofficial-libmysql.

[Koray 3316]

7 minutes ago, Sokus said:

I had to remove boost-system and libmysql from vcpkg install for it to progress further (both were depending on Boost), CPMAddPackage seems to be working for Boost - how can I do the same for libmysql? CMake is throwing errors because it cannot find unofficial-libmysql.

it's time to switch to MariaDB, MySQL connector is pure cancer and not worth spending any time on it...

[Exynox 3520]

5 hours ago, Sokus said:

I had to remove boost-system and libmysql from vcpkg install for it to progress further (both were depending on Boost), CPMAddPackage seems to be working for Boost - how can I do the same for libmysql? CMake is throwing errors because it cannot find unofficial-libmysql.

That's really weird, the nightly build works fine for me. Check out my earlier post (it was only now approved).

5 hours ago, Koray said:

it's time to switch to MariaDB, MySQL connector is pure cancer and not worth spending any time on it...

I agree, this is on my immediate to-do list, not to mention that MySQL deprecated OPT_RECONNECT which the current codebase seems to depend on.

 

All being said, I guess all these issues will be no more once nightly gets merged into master and I start distributing official builds and guides.

[Koray 3316]

27 minutes ago, Exynox said:

I agree, this is on my immediate to-do list, not to mention that MySQL deprecated OPT_RECONNECT which the current codebase seems to depend on.

 

All being said, I guess all these issues will be no more once nightly gets merged into master and I start distributing official builds and guides.

Seems like MariaDB still

This is the hidden content, please

• Sign In
• or
• Sign Up

 to it, but to avoid potential issues in the future, I'm highly recommended to keep the packages to specific working versions with vcpkg.json override feature, for example; https://pastebin.com/a7FcMatT and the guide for it; https://devblogs.microsoft.com/cppblog/take-control-of-your-vcpkg-dependencies-with-versioning-support/

 

 

Edited July 6, 2024 by Koray

[Exynox 3520]

Yeah, I've already used vcpkg in manifest mode in the client, but with the server, I encountered some issue that prevented me from doing that. Maybe I'll revisit it and try again.

[NightCore.PL 1]

I can't seem to be able to clone the nightly branch of Client:

Quote

fatal: unable to access 'https://git.old-metin2.com/metin2/client.git/': Failed to connect to git.old-metin2.com port 443 after 21054 ms: Couldn't connect to server

Trying to download via these buttons also doesn't do anything:

I think I got everything to work server side - Docker containers are up and running, everything seems active in the stats view and even any client reports CH1 as running. However, with some generic client I get a "WRONGCRD" error so I assume I need to build that modified client.

[NightCore.PL 1]

Alright, the download servers seem to have come back online. Cloned the client, built it, packed .eix and .epk files, client runs, server is visible (CH1 NORM) but I still can't log in. I looked through the server's game src, in db.cpp I don't see any signs of tampering with the hashing system - no SHA512 upgrades or Argon2 visible. It should just be MD5 hashes via the MySQL PASSWORD() function, isn't it? Can't log in when using that.

Edit: Nevermind, I'm helplessy blind. It is Argon2. If anyone didn't know that like I did, now you know.

Edited August 15, 2024 by NightCore.PL

[Macromango 10]

Hello @ Exynox is the project still up?

[Exynox 3520]

17 hours ago, Macromango said:

Hello @ Exynox is the project still up?

Yes, I've had some minor issues with the hosting if that's what you're talking about.

But I guess you guys are due for a small status update:

I'm still working on features when I have time on weekends. Currently I removed any boost dependencies, which also had the side effect of migrating the database library from MySQL to MariaDB.

Further plans are to do some profiling, as I've noticed some slowdowns when there is a lot of network traffic going about, do some bugfixes (one especially weird bug is that if you log in to an already connected account, it won't disconnect the existing player). Once this is done, I'll merge the nightly branches into the master ones and start writing a guide on how to easily get a server up an running, how to develop the project etc.

[Exynox 3520]

Hey, I think you're overdue for an update. The changes that were only on the nightly branches were merged into master and released as version 0.3.x.

Also, Docker images are now officially distributed through Gitea for quick deployment: simply following the Quick start guide here on a Linux machine with Docker should get you up and running in a few minutes:

This is the hidden content, please

• Sign In
• or
• Sign Up

Here's a quick list of everything that was done since the last update:

Server:

• A lot of unused Korean features were removed, only Gameforge-like features were left (credits: @Tr0n).
• Source files were converted to UTF-8 (credits: sdgmt2)
• Source code string literals were translated into English (i.e. locale_string.txt files now provide translations from English into other languages, instead of Korean to other languages) (Credits: @Tr0n)
• Argon2ID is used for password hashing (Credits: WildEgo)
• Used MariaDB connector library instead of MySQL (which in turn removed the dependency for boost and compile times are much better)
• Fixed mishandling of public/private IP addresses in P2P code, which fixed inter-core communication in docker deployment.
• Logout error messages are now displayed to the player.
• Game data is stored in the "gamefiles" directory.
• Various (Docker) build system fixes and improvements.
• Game configuration can now be done through .env files when using Docker.
• Fixed in-game Item Mall authentication.
• The db core no longer crashes on startup when a database connection is not possible.
• CLion run configurations are now shared in the repository.

Client:

• Upgraded client to DirectX 9
• Removed unused libraries and files
• Removed mobile/SMS system
• Added support for Argon2ID hash system
• Changed default client language to English
• Fixed buffer overflow in DXTCImage

Deployment system:

• Added automatic database initialization
• Added support for arm64
• Added a quick start guide in the readme.

Website (work-in-progress):

• Added automatic database migrations in the docker image
• Bumped PHP version
• Added experimental autopatcher support with webseed capability (for official YMIR autopatcher - updated source code with modern libraries coming soon)

----

 

That being said, I've played around with running the docker images on an old Raspberry Pi 2, (32-bit armhf architecture), which turned out to be a big failure since the hardware FPU expects floats to be memory-aligned. Since the original code uses #pragma pack(1) directives, this is not achieved and a "Bus Error" signal is thrown when a non-memory-aligned access to a float (usually in a struct) is attempted.

When removing the #pragma pack directives in order to let the compiler to do proper (armhf-compatible) struct packing, the servers did start successfully, but naturally the network protocol structure is borked (from the POV of a Windows/x86-64 machine) and connecting to the server is not possible.

Which leads me into this - one of the next big things to happen to the project is converting the network protocol to protobuf in order to eliminate relying on simply casting network data into structs. Stopping to rely on the server machine's ability to operate on non memory-aligned structs is the right thing to do, and protobuf will probably fixed some other issues, such as unsafe peeking into network buffers/structs, random mismatched header issues and a lot of peace of mind by essentially banning pointer arithmetic in the core networking code.

Another thing coming up is finishing the website, which is currently in Romanian and only the registration functionality works, making a guide on using a local SMTP server / a Gmail account for the website.

Then I can probably can start writing some video tutorials on how to start up a basic server from start to finish, how to develop on the server, and finally fire up a test/demo server for the curious (and to provide an easy client download).

 

See you soon (as my free time allows),

Exynox

[Exynox 3520]

Here's a little treat for you - a Metin2 Server running on the Raspberry Pi 5:

Since the Pi 5 has a 64-bit armv7 architecture, what I said about the FPU in the previous post doesn't apply to it. Therefore, the published ARM Docker images work without an issue on the Pi 5 as well! Just follow the deployment guide and it should probably work.

Honestly, I'm a bit impressed by the Pi 5's performance as I didn't find any significant slowdowns - the "heaviest" load seems to be caused by the website, not the game itself. Just use a quality SD card or NVMe storage and you're good to go! I'm saying this as I initially tried using a crappy old card which made the Pi freeze all the time while waiting for I/O.

This should also work on the Pi 3, 4, and the Zero 2, though I can't say anything about the performance.

All in all, the Pi 5 should be a great, cheap and power-efficient (3W) solution for you and your 20 friends to play some Metin2 for old time's sake. I suppose never before a M2 server could be hosted for 0,32€/month.

[LongWayHome 2]

@ Exynox thank you for all your support.

I managed to get it also working on my Raspberry Pi 5! Thanks a lot for your hard work.
Seems like the raspberry is indeed bored even with a lot of mobs taken.

Greetings and have a great Christmas!

[SystemCrash 0]

@ Exynox, first of all, congratulations on your work, it's amazing.

I was modifying server files back in 2010, and today I’ve become a cloud architect, starting my adventure with Metin... As a cloud architect, I was thinking: what do you think about making it scalable on a Kubernetes cluster? A few weeks ago, I returned to the Metin world, and the first idea that came to my mind was: 'What if the server could auto-scale and create channels based on traffic needs?' The first big obstacle, of course, was migrating the server files to Linux, but it seems like you’ve already done that. 

Let me know

[Exynox 3520]

Hey, thanks for your interest! Here's my two cents:

I've tried a lot, but I still feel that Kubernetes is impossible for me to understand . Feel free to try playing around with the published images. Autoscaling would be pretty tough in my opinion - such a mechanism would have to be firstly implemented in the server itself. The ""easiest"" way you could truly autoscale would probably be moving all map data to a new worker core and then reconnecting the players in that map to the new core.

An easier toy project would be to simply create a new channel when the existing ones are getting busy.

[Deso 992]

@ ExynoxYour project have inspired me
Basically i wanna  try something like that -> if you have some inputs maybe @SystemCrash we can make a great project.
https://metin2.dev/topic/33548-m2-docker-redis-haproxy-permanent-instance/

firstly i was thinking about k8s, but its just only really needed when you're using 2 physically servers (destinations) and k8s have some overhead.
its not really need for such project.
but i wanted to start something special to keep players active while the core gets updated or crashed.
in the thread i posted i've put some of my thoughts - if you have some informations i can try and share infos back to you how is going on

[SystemCrash 0]

18 hours ago, Deso said:

@ ExynoxYour project have inspired me
Basically i wanna  try something like that -> if you have some inputs maybe @SystemCrash we can make a great project.
https://metin2.dev/topic/33548-m2-docker-redis-haproxy-permanent-instance/

firstly i was thinking about k8s, but its just only really needed when you're using 2 physically servers (destinations) and k8s have some overhead.
its not really need for such project.
but i wanted to start something special to keep players active while the core gets updated or crashed.
in the thread i posted i've put some of my thoughts - if you have some informations i can try and share infos back to you how is going on

It's very interesting, but why the Kubernetes overhead? Imagine adapting the client to receive the list of available channels from the cluster, and the cluster scaling them based on current traffic (with an horizontal pod autoscaler maybe). Cool, right?

Having all configurations in a ConfigMap and making them shared across all pods/channels is something I'd really like... Even more interesting would be integrating some custom CRDs for various utilities.

Also, there would be the possibility to distribute it via Helm, so you could have a ready-to-use server with a simple "helm install metin2".

 

Edited March 18, 2025 by SystemCrash