Exynox

Can't wait to expand my collection ! Jokes aside, I'm honestly thinking of backporting the network protocol of existing server source code in order to allow us to actually get in-game. I wonder if the old r2089/r407/r404 gamecores are compatible with this or even those are too new...

Hi, This sounds like an interesting project, and as a matter of fact, I've been trying to the same lately: I'm doing this from the perspective of a computer scientist: by the nature of our work, we pretty much have to stay on top of things and figure out what the state-of-the-art is, and right know I'm really interested in exploring the limitations of LLMs, and how useful are they really when coding. I used to be a hater of AI and I still consider myself to be mostly so, but for different reasons: it's very commonly wrongly used. I see people everyday vibecoding without any clue for what their LLM actually does. LLMs also tend to not be that elegant in their "thinking" and I've seen them countless times produce bloated output that is hard to read and maintain. When it comes to it, human design is more concise and we can be sure that at least some thinking and consideration took place. That is - if the developers actually think and know what they're doing. LLMs, by the gift of statistics, have the advantage of having "knowledge" of common pitfalls and do in fact usually avoid them. Given the amount of raw SQL, bad memory management, poorly thought out algorithms, memory waste etc. seen only on this forum alone, I can say that an LLM has a slight advantage over a junior developer. (I guess the worst of both worlds is having junior developers use LLMs, since they don't have the experience required for auditing another person's code). Another thing is that AI is expensive, especially Claude Opus - it's surreal how quick you can burn through tokens. And since I can't justify spending huge amounts of money on a hobby project, and since I don't have 4000€ to spend on a 5090, I had to make do with my existing 3060 and running qwen3.6 locally. Getting it work was a PAIN, I spent pretty much all week trying to come up with a setup that is both reliable and needs minimal input or nudging from a human. Having said that, here's what I've confirmed you can do with LLMs: Menial, repetitive work: translating comments, various refactorings such as converting c-strings to std::strings, c-pointers to shared_ptr etc., Security audits: null pointer guards, checking for possible buffer overflows, SQL injection. The really basic stuff that everybody should have in their mind when coding, but Metin2's developers didn't. Clang linting also helps very much here. Coding style: LLMs can help bring code by different developers into the same coding style, formatting etc. Documentation: honestly this is where it excels, having the LLM go through all the files and documenting how they all work and come together (and then maybe making a wiki for a human to use) is extremely valuable. Testing: it seems it can also do testing to an extent, but I feel like the Metin2's codebase is notoriously hard to test. The various systems aren't that self-contained, nor do they use OOP that much so that you could fake various objects for testing purposes. We have the issue of having the server running on Linux (in my case) and the client on Windows. Yes, it can work in Wine, but coming up with a testing setup is pretty hard. CRUD controllers on websites - especially for Metin2, whose website logic is very simple, LLMs can do a pretty OK job at building website logic. Everything I pointed above must be vetted by a qualified human, simply letting LLMs free won't give much results. This was my two cents on this issue. I get where you're coming from, I don't have much time myself to work on the Old Metin2 Project, and whatever time I have, I prefer to use in order to get some rest. I have thought a lot about rewriting the server, once in Rust and once in Go, but: The amount of work required is enormous (especially for a single person or a small team). Interpret this as "one LLM" still has limited capacity, multiple orchestrated LLMs would be required. The orchestration should also be done by a human. Nobody will use it. It's a chicken and egg problem. Pretty much all existing tutorials and guides online for Metin2 assume the existing codebase. Everybody knows it and is familiar with it. Experienced developers usually tend to have a lot of work to do, and don't really have the time required to get familiar with another codebase. Your only users will be just that. Users that want to set up a server and not much more, and existing serverfiles are already pretty painless to set up. As mentioned here before, nicer tooling for customizing game data already exists and/or can be written for the current codebase. Yes, rewriting everything to C# is a nice experiment. I wish you the best of luck, but my opinion is that your time and especially your money is better spent elsewhere. To me, modernizing existing code is the way to go. I have always wondered whether we could use LLMs to port the client from DirectX 8/9 to Vulkan or some sort of wrapper library like dxgl in order to get closer to running the client natively on Linux/macOS etc.

Hey, I've just now seen your comment. Would you be willing to please upload that archive even though it's corrupt? Thanks!

Thanks, the main server has been restored!

Long time no C! I'm happy to have found the time to release the 0.4.x version of the project. Here are the most significant improvements since my last (release) post: Server: Server image size was slightly reduced by only including the core shared libraries. "Server-side" speed hack and combo hack checks were removed, as their naive nature of trusting client input makes them effectively useless; not to mention that clock skew caused players to be mistakenly be kicked off the server. (I have spent some time researching whether the client-server time synchronisation mechanism (i.e. PACKET_xx_HANDSHAKE) could be removed, but it seems like keeping the client's clock in sync with the server is essential for the current move/attack/skill mechanism (& maybe more). The timekeeping should only be done by the server, ideally. This subject has already been touched upon on M2Dev, and I realised that a less trusting mechanism should be implemented instead of the current one, as discussed in that topic.) Client: Added source code of and improved client configuration utility (client locale can be configured, added native French & Romanian UI translations, improved visual styling) Cleaned up .sln files and added a build script (usage coming soon, I promise) Reworked EterPack to be a lot more memory-safe and modular. Support for .eix/.epk archives was dropped, the library currently supporting reading files directly from folders and .zip archives (and you can add support for your own custom archive formats by implementing the extremely simple FileProvider interface). This decision came as it simplifies the development process quite significantly. In Debug & Release mode, the client looks for the Index.dev file, which by default configures the client to read files directly from folders under the pack/ directory, no packing and unpacking necessary. Distribute mode uses the Index file, which is configured to use .zip files. For the .zip archives, you can use any compression mechanism supported by libzip, including the modern zstd algorithm (Use 7-Zip ZS to operate with such archives). Archives with no compression may also be used for maximum performance. If you're interested in compression performance, the pack directory (1,98 GiB) compressed with .eix/.epk takes up 1,14 GiB, compressed with the regular zip Deflate algorithm takes up 1,01 GiB, compressed with the faster zstd algorithm takes up 1,06 GiB. Client source code comments and string literals have been converted to UTF-8 (Credits: @Tr0n) Used anisotropic filtering for upscaling/downscaling various interface textures. This last one is a personal pet peeve of mine, and I'm happy to have solved it. Here are some screenshots to compare: Login screen (before): Login screen (after) - observe how the character's faces, the text in the footer are no longer pixelated: Affect icons (before/after): Minimap texture when zoomed in (before/after): That's it for now, here are some more ideas/things to do for the future: Developement guides/tutorials for building and working on the server & client. Autodiscovery mechanism provided by auth server, which would provide a list of all the channels and their ports, so that we could implement a server manager instead of defining the servers in serverinfo.py Finish up the most critical features in the website. Make the autopatcher source code public once ready. Once all of the above are done, open up a public test server.

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.

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.

If I'm not mistaken, the reason ГОСТ 28147-89 / Magma was used in the source is probably due to the fact that in the early 2000s, when the first bricks of the M2 source code were laid down, the USA was just releasing its strong encryption algorithms from under embargo: [Hidden Content] At the time, using GOST (which is basically DES after a 1 week vacation in Sochi) would have made a lot of sense due to it being a freely available algorithm. Still, this is a testament to how fast things are changes and how maintaining a "modern codebase" is a sisyphean task - there will always be some new language feature or design pattern by each and every passing year, which means having to always update the code and never be finished. Just look at the JavaScript landscape - just one more new framework bro, this will fix everything. That being said, updating the codebase to some common sense 21st century technology such as smart pointers and UTF-8 is very much needed for a project which is basically a hodge-podge of C & C++ and a thousand coding styles.

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: [Hidden Content] 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

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.

"Everything that has a beginning, has an end, Neo" It happened to games before Metin2, it will happen to games after Metin2. Of course, there are still exceptions, such as Counter-Strike 1.6 or Age of Empires II. Probably, in certain countries, Metin2 might join the ranks of these games. I'm not sure what will happen from a financial standpoint, but I'd guess it's going to become harder and harder to run commercial servers. We should really focus on archiving all the progress the community has contributed to the game, so that it's going to be easy for nostalgic players to have fun in the future. This was one of the reasons I started the Old Metin2 Project, with its goal being to be extremely easy for anyone to run a server & clients on a modern system, and I encourage people to try to plan for the future in their community projects. Metin2 Download has been huge in this regard as well, and I hope it can be run for as much as possible - and maybe provide some sort of mirroring system (maybe via BitTorrent?) so that the community could store copies of the public files.

Because being friendly, not judging and building trust goes a long way in life. Publicly releasing copyrighted material can be pretty risky, depending on where you live.

I'm equally baffled, but... VS 5.x/97 is pretty much abandonware and can be easily found: https://winworldpc.com/product/microsoft-visual-stu/97-5x Also you could give this ISO of J++ 1.1 a try: https://archive.org/details/visualjpp96

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.

That's really weird, the nightly build works fine for me. Check out my earlier post (it was only now approved). 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.