Exynox

I honestly can't really disagree with you. Of course any abstraction layer comes with a performance penalty. I even have, in the past, ported the network code to Boost.Asio and declared it a lost cause due to its really weird design patterns. Let's say the least, I'm a bit tired of rewriting the network stuff, and settled on libevent which has a decent balance of portability, ease of writing and performance (Chromium, Tor, Transmission, and other projects successfully rely on it). Not to mention that it would be really easy to add TLS to the server (as I've removed the original encryption schemes and communication is now plain). I really, really don't want to discredit you and I truly appreciate a battle-tested solution, especially in my field of work. Metin2 is not that - it's just a hobby of mine, and hobby projects only get hobby amounts of time allocated to them. Still, you are more than welcome to publish your work and I encourage you to do that, as it's healthy for any project. Maybe we could even give people the choice to choose their network stacks one day. Regarding the strange behaviour, I'm aware that certain C/C++ types have variable length based on the word size of the CPU architecture. Therefore, I did replace relevant variables back to their correct int32_t / uint32_t types. It works pretty fine on x86_64, but armv8 is still buggy. More time is needed to squash those bugs (I spent a grand total of 5 minutes on that issue). Please be aware that the db and game cores need to advertise an IP address that clients can use in order to reach (directly or via NAT) the servers. Automatic IP address detection based on RFC1918 addresses does not always work (and IIRC I broke compatibility with Windows as I plan to rewrite config.cpp to use environment variables anyway). Therefore, I think you have to manually set the IP addresses in CONFIG; given your machine's IP of 192.168.1.123, try setting: INTERNAL_IP: 192.168.1.123 PUBLIC_IP: 192.168.1.123 Just keep in mind that my goal was to make this run on Linux, I didn't really have cross-platform and cross-architecture compatibility in mind, even though it would be amazing. And based on your comments, it actually seems in the realm of possibility, so I might have a crack at it.

I'm surprised to learn that it actually compiles on macOS -- I guess that's one point for having the network code implemented in libevent and not epoll, as @wolfhelm kindly suggested. (But in order to give Caesar the things that are Caesar's, the original kqueue code should have also worked on macOS) Also, expect really weird behaviour on ARM, I tried using armour on my character and when I'd right click on it, it would just vanish. It surely needs some polish.

It's possible that you might have mixed spaces and tabs in that file. In Notepad++, press the button with a pilcrow (¶) symbol (or View->Show Symbol->Show All Characters), and see if you have the same number of characters of the same type. You can't have some spaces and some tabs, otherwise the Python interpreter will be upset. Google is your friend: [Hidden Content]

Hi there, Your favourite mad-lad is back! As I hinted over a year ago, I had a port of the Kraizy serverfiles in the works, with the goal of having the Metin2 Server run on Linux. Progress was slow, as 10 years passed since the Kraizy days, and now we all have education and jobs to deal with, and any free time I had was promptly allocated to sleep with the same passionate love Google Chrome eats any free RAM on a 1km radius. Jokes aside, I still had this project on the back of my mind and still managed to bring it to a state where I feel I can release to you, guys. So I raise you The Old Metin2 Project, a more sensible attempt at continuing the work of others before us and having modern-ish serverfiles which run on modern technology, while still preserving the 2014 (or earlier) gameplay. What needs to be said right away: This project is freely available for everyone to use, modify, and pretty much everything you'd like. You are invited to contribute any ideas, changes and improvements to the project on the git server. I don't have too much time but I'm willing to work on it as much as I can. The project is currently VERY experimental and should not be used in order to host private servers for now. Not many known bugfixes were applied to the project, and it is vulnerable to a lot of known attacks, another reason for it being unfit for production. Improvements The binaries run on 64-bit x86-64/arm64 Linux with the network stack being partially rewritten in Libevent. CMake build system mainly based on vcpkg. Docker-friendly architectural approach. HackShield and other proprietary binaries were successfully yeeted, the project only has open-source dependencies. Included gamefiles from TMP4's server files. Modern logging system. Other updates and small refactorings. The project's home The project is currently hosted on a private Gitea instance. More instructions are available in their respective README.md files. Server: [Hidden Content] Client: [Hidden Content] Deployment files: [Hidden Content] AIO: (Last update by ASIKOO: 2024-03-03 19:29:00) [Hidden Content] I might require people to sign up in order to access the source in order to avoid trouble with Gameforge and other IP holders. Future plans A Laravel website + item-shop + patch server based on my older work is also in the cards, yet I need to translate everything to English so that y'all don't jump on me. Refactoring the configuration code so that we could easily configure the gamecores from Docker-friendly environment variables (and .env files!). General refactoring of the old C++ code: memory safety, string formatting, UTF-8 Adding all the known bugfixes Maybe releasing an alternate version with some quality-of-life systems Ending notes I am looking for any help in organizing, contributing and growing the project! I'll try to help you guys as much as I can, but time is tight, so my dream is for this to become a community effort. This project wouldn't have been possible without the help and work of these amazing people: My good friend @ Sonitex, who morally helped me and also provided me with some special sauce. @ TMP4's serverfiles - it's a great resource and he deserves all the kürtőskalács we can get him: @ arves100's great guide on using vcpkg for Metin2 library management: @ Vanilla, who I'd argue was a pioneer in improving the gamecore and inspired me to start this. A lot of other members of this community whose posts provided me with a lot of crucial information. Yours, Exynox

I consulted a lawyer and pretty much came to the same conclusion. There's no legal way to operate a Metin2 server without infringing on the trademark and intellectual property. And I think it's for the better, these laws have a purpose and it's only natural for a company to (be able to) protect their work and their business. (Well, maybe operating in a country that doesn't really care about foreign intellectual property could be an option, but I doubt anyone would like to do business with Russia and China right now, not to mention the crappy ping times) Growing older and wiser, I realised what a waste of time a complete server rewrite would be, and moved on to other, perfectly legal endeavours. This game still lives in my and my friends' hearts though. I'm also still being inspired by the core rewriting efforts on this forum (especially looking at Vanilla's core, the QuantumCore project, and other "clean" serverfiles projects). Therefore, I worked on and off in my free time to collect as many original files and try to recreate the game (Website + ItemShop + Game + Client) as it was at the end of 2013, where I personally think Metin was at its best (also because it implies the least amount of work). The idea is to have a ready-to-go all-in-one solution to spin up a server when I feel like playing with my friends, and maybe do some improvement work on the original "kraizy" leaked files. The network stack was already ported to linux (under WSL) and it kinda works, but I'm still dealing with some weird bugs that need squashing: For now, I'm using some random files and client I found on my computer, but I'll for certainly revert everything back to the GF original files. Some other ideas: Adding GitLab CI/CD flows for automatically building the server binaries and Docker images, the client binaries and automatically packing the .eix/.epk files Removing unnecessary code Merging all tables into one singular database Rewriting the configuration system to use .env files Rewriting the weird way the protocols handles IP addresses (and therefore requiring the configuration of "public" IP addresses and "private" IP addresses for the P2P communication). Maybe also TLS (i removed all packet encryption to make my life less miserable) & IPv6 support, it should be pretty easy with libevent. Making use of an archive system I wrote years ago in order to yeet YMIR's EterLib/EterPack overly-complex crap. Just a simple file table header that points to the data (stored raw, using lz4 or zstd). For all I care, maybe a better idea would be to just use .7z archives and call it a day if the speed is tolerable, it's not like any of these files are secret anymore. Maybe upgrading the client to 64-bit? I do have pretty much all needed SDKs in 64-bit debug/release formats, but they are newer versions and I guess it's going to take some trial and error. Possibly upgrading the python interpreter to 3.x. I did that years ago and it went surprisingly well. Trying to use DirectX 9 - but it's a deep rabbit hole... Rewriting the server's admin API to a REST API. Maybe writing a plugin API for the server in Python or something so as to make the process of adding systems much easier (and to circumvent bad C++ code from crashing servers). This is a titanic project in itself though, and who is going to write plugins if this doesn't become a widely adopted gamecore? Also banning all C-style pointers, strings and functions. Passing smart pointers and using references is much safer and hopefully won't lead to weird undefined behaviour. Releasing the source code when I deem this ready for the public (not necessarily including all those things above). The thing is that I'd like this hosted on some publicly accessible Git repo, so that the community could work on it... ... but it's copyright infringement all over again. It's pointless, all of it. The copyright pretty makes our work irrelevant, and I don't even have hope that anything will come out of my work.

That sounds like a monumentally bad idea, and the root cause of the error should be addressed.

(information moved to main post)

I did some work by using The Wayback Machine and I managed to get the files from YMIR's servers. It seems, though, that they are only basic installers and the actual client would have been downloaded over a bittorrent connection. I fount the "mcs/metin2_low.wmv" video really interesting, you can see some elements of the old Metin2 UI. DOWNLOAD LINK: [Hidden Content] I think that our money is on: Manually trying download links on the Wayback Machine: [Hidden Content] Searching any filenames for old clients on [Hidden Content] Using the Wayback Machine in order to search if by any chance there are archived M2 clients. It's not that far of a stretch, given that I've been able to do that for some relatively new, yet not available anymore OnGame clients. You can search entire websites by using wildcards, for example: [Hidden Content]* . I hope that somebody can pick up a lead on the information I've got here. EDIT: bonus screenshot I found:

May I ask why the project is licensed under GPLv3? From my understanding, that would mean that anybody who uses the code commercially should make their source code publicly available. I doubt there would be many people who will use this emulator for their servers and do that. What's the rationale behind this? Did some other library force you to pick GPLv3? Something like the MIT license would work much better for what the metin2 community expects.

Hey, why did you keep this project a secret until now? ? I bet there would have been more people, like myself, willing to help out. Anyway, amazing work, can't wait to see more technical details.

@Vanilla, Sorry if I got the wrong idea through - I do not see anything wrong with FreeBSD and I really quite like it. I had to implement some new kernel syscalls as a university project and its simpler structure really appealed to me. As I said, it stood the test of time, and that says something in an ever-changing world. My rant is not about FreeBSD in itself, but that we don't have the option to run the same code base on multiple operating systems. Of course, you could port the kqueue code to use epoll or maybe libevent or Boost.ASIO (I tried using it once and it felt like masochism). It's not a dealbreaker though and more of a "nice thing to have". I'm also a very big fan of C++ and I tend to use it quite a lot for projects where I need high performance. I suggested Rust-lang as a language to rewrite the server into for the following reasons: It would force a complete code base rewrite since you can't simply borrow code from the existing server. Hence, no (obvious?) copyright infringement. I'm no lawyer but it seems fine to me. If we do manage to complete a working rewrite, but in C++, people will be tempted to re-use the existing code for all the systems we see on this forum. And to put it lightly, there's a lot of code that's poorly written. I do trust myself to only use memory-safe containers, but I can't trust everybody who forks the code to do the same. It's a choice for the greater good of not having buggy servers in the case the port gains popularity. Yes, I know that people will be weirded out by the new language, and that's why have in plan to write a well-documented Python API so that everyone could write plugins without the fear of breaking the code. Maybe some of the more unnecessary stuff in the game could be rewritten for this API, like for example the OX event or the pet system. Or maybe even the quests!??, though I think it would break too much stuff and it wouldn't be nice to require everybody to rewrite the quests. At any rate, this would give people some examples to get started with. The amount of tools Rust provides out-of-the-box are quite impressive. From what research I've done, I can quite safely say that it's as good as Python in this regard. And it's a good thing, because any library you include is another point of failure. It compiles down to machine language, yet it's cross-platform. This means that I write it once on Windows and be certainly sure that it's going to also work on Linux, FreeBSD, be it x86, AMD64, MIPS or ARM. (It would be funny to see the Metin2 server running on a Raspberry Pi.) Multi-threading seems to be fairly easy to do, and I really want to make use of this, now that CPUs with 10+ cores are fairly common. It achieves 2-4 with little difference in performance compared to C++. Yes, it surely has its downsides and I feel guilt not to do it in C++. It's going to be a learning experience nonetheless. This is exactly what it is. A call to action to see if people are interested in seeing something like this happen. And what better way to push people into replying than ranting about things? I really appreciate your advice and be sure that I'm well aware of the hurdles that await. If anything, this is firstly a learning experience, like everything in life. I will write a thorough development plan now that I saw there's some interest in this. Thank you for your feedback. @Akronis, Sure, as pointed above by both Vanilla and me, this is basically doomed to fail without a really, really good and thorough plan. I plan to document the architecture and the features the server will have. I'd like to keep only the base mechanics in the game itself and have all the various other systems (e.g. marriage, costumes, pets) be written in Python. This would mean that the server won't be bloated and can focus on the performance of what's performance-sensitive, and can leave the other stuff to the slower, albeit more versatile API.

Awesome! I'm a bit busy with university & work right now, but I'll try to come up with a development plan in the days to come. I'm thinking of implementing only the features up to 2011-2012, with plugin support for those who want the newer maps and mobs. Having a custom client is pretty much necessary in order to make any meaningful progress, and having its code public might be tricky. Maybe we'll use an invite-only Git repository for that. Also, maybe it's a bit too much to ask now, but it would be nice to have a standard client for all servers, and based on the plugins installed on that server, to have the client download only the files it needs. That would mean the end of downloading a thousand clients. Of course, if somebody doesn't like it, it could be disabled. I'll stop now, I have a lot of ideas and I know a lot of them mean really hard work. I'll set up a GitLab/Gitea instance.

So... let's say that Gameforge still hosts some old clients on their webserver. Let's also say I have fast internet. Here's a sneak peek: Sadly, from what I can see, not all versions have been kept. I've tried the following timestamps: 20080811, 20081204, 20090526, 20091214, 20100421, 20100528, 20111216. I'll be uploading the clients soon. If anyone's curious, here's the small Python script I used for brute-forcing the URLs: [Hidden Content] Edit: I bruteforced all the timestamps from January 1st, 2008 to January 1st, 2013 for the most common clients. So more clients incoming! ? Cheers, Exynox

M2 Download Center Download Here ( CN ) - Download Here ( DE ) - Download Here ( ES ) - Download Here ( KR ) Download Here ( GR ) - Download Here ( IT ) - Download Here ( NL ) - Download Here ( HU ) Download Here ( PL ) - Download Here ( RO ) - Download Here ( SG ) - Download Here ( US ) Download Here ( AE ) - Download Here ( CZ ) - Download Here ( DK ) - Download Here ( FR ) Download Here ( PA ) - Download Here ( PT ) - Download Here ( RU ) - Download Here ( TR ) Download Here ( BR ) - Download Here ( BETA ) - Download Here ( EN ) - Download Here ( MX ) Hey guys, I've stumbled upon some old Metin2 clients on an old DVD, so I thought I'd share them with you. I also included some of the already existing clients on this forum. Table of Contents: Gameforge June 2007: EN December 2008: DE, ES, FR, IT May 2010: DK, EN, ES, FR, GR, HU, NL, PL, PT, RO, TR, US August 2010: PA (Beta) March 2011: TR April 2011: DK, EN, ES, FR, GR, HU, NL, PT, RO, TR, US December 2011: AE, CZ, DE, DK, EN, ES, FR, GR, HU, IT, MX, NL, PL, PT, RO, RU, TR, US March 2012: MX March 2013: EN (13.03.2013), EN (28.03.2013) April 2013: CZ, DE, ES (16.04.2013), ES (17.04.2013), FR (16.04.2013), FR (17.04.2013), IT, PL, RU June 2013: TR September 2013: DK, GR, HU, NL, PT, RO, US, PA (Beta) July 2015: CZ, DE, DK, EN, ES, FR, GR, HU, IT, NL, PL, PT, RO, RU, TR, US Singapore (TEC) April 2012 May 2012 US (G4Box/Z8games) November 2007 April 2008 (repacked) (Original topic here) October 2008 October 2009 April 2011 September 2011 Brasil (Ongame) 2015 (v14) 2016 (v15) April 2018 (v16) July 2018 (v17) February 2019 (v18) April 2019 (v19) May 2019 (v20) August 2019 (v21) Other August 2005: CN Beta client (YMIR) (Original topic here) December 2012: KR (Webzen) (repacked) (Original topic here) 2015 (ver. 0.0.0.1): Gameforge Beta 2019 (ver. 0.0.0.2): Gameforge Beta Pictures: Download Links: Archive.org: [Hidden Content] Torrent download (also using archive.org as a webseed): [Hidden Content] GameForge direct links: Should you have other clients (installers would be great!), please leave a reply to this topic with a download link and I'll happily add them to the collection. Edits: April 20th, 2020: Added many clients from Gameforge's web download server. April 21st, 2020: Added more clients that I've discovered on GF's download server. April 21st, 2020: Added all the clients I could find on GF's server. December 30th, 2023: Reuploaded the collection on archive.org, added Metin2 SG (14.04.2012) client thanks to @ForgiveN March 20th, 2014: Added 2011 & 2012 Gameforge Mexico clients, US April 2011 client, Gameforge August 2010 beta client Cheers, Exynox.

Don't forget WhatsApp. The point I was trying to make is that their only realistic options were Windows Server 2003 and FreeBSD. Of course they made the right decision. The thing is that it's better to have the option to install the server to whatever operating system you wish. A rewrite would pretty much solve that. Just imagine actually developing the game on Windows and behaving the same on FreeBSD. No weird RNG bugs, no skill issues, it would just work. I'm up to it, but I doubt I could do it alone (and still be sane after that). That's why I'm asking to see if there's an interest for it.

That's pretty nifty. I actually like this version of the logo with the serif font more than the ones used by GameForge. It manages to suggest that Metin2 really is a proper, serious RPG game.

Ladies and gentlemen, on behalf of Metin2Dev Airlines we would ask you to kindly follow this safety announcement. Please take your assigned seat, mentioned in your boarding pass. When sat down, please fasten your seat belt at all times, as turbulence can occur during the flight. We ask you to make sure that your luggage is properly stored in the overhead bins. In the unlikely case you won't like this topic, please take a moment and locate the nearest back or exit button of your browser. Should you be utterly disgusted at what I'm saying, a vomit bag is located in the seat in front of you. It's going to be a long read. I think it's been almost 10 years since I first opened Metin2. Ten years! I was still playing Club Penguin at the time, I mean that's how I've heard about the game in the first place - from an ad on Club Penguin's page! And if I sit down and think of it, the game was 6 years old 10 years ago! I'm really curious, what other 16-year-old pieces of software do you guys use? If you do, how do you manage to use that piece of software nowadays? I know I've struggled a fair share to get Borland C++ 4.52 to run reliably in DOSBox. My point is that in 2004 we didn't even have multi-core CPUs yet! The only way you could do multi-threading was by physically chucking as many CPUs onto a motherboard as you physically could. Or by distributing the computing load. The latter is what YMIR did. Initially, Metin2 was intended to run each core on their own server. One for the database cache, one for authentication, and a couple more for the maps (depending how far down you could reach in your pockets - we didn't have $5 DigitalOcean or AWS containers back then, servers were expensive). That's why nowadays we have to fiddle around with peer-to-peer TCP/IP configuration on all the Metin2 server cores. Metin2's architecture aged like milk. To give credit where credit is due, parts of it were updated with time. But I'll bet you a coffee that libthecore hasn't changed much since the initial version. It's quite awesome that we actually can run this code quasi-reliably. Kudos to C++, in a world where JavaScript breaks backwards compatibility whenever wind changes direction. Other than the dated architecture, the other problem I have with the Metin2 server is the code itself. I don't say it's easy to code such a dinosaur, but if you pay attention to the coding style and mistakes, you can actually see how YMIR devs improved over time. Which is perfectly fine, we all learn. The terrible part is that we can see their progress in acquiring this skill. They never fixed their silly mistakes, or did so very, very late (remember the /dice bug?). The final nail in Metin2's coffin is BSD. At the time when they decided upon the architecture, Linux was nothing more than a toy, a fun gimmick like Docker and Kubernetes are today. Sure, you could have used Linux in production environments, but you would have been regarded a maniac if you did. Sure, some companies saw its potential and became early adopters. But the standard was still to use the tried and battle-tested, UNIX-certified BSD, which hails from 1977. In my country's 1977, we couldn't even talk about how dumb our leaders were without risking being beaten by the police, yet others were making huge technological advances. There's nothing wrong with FreeBSD nowadays either. It's just that it's way, way easier to code for Linux. It has become the de facto standard. So we've got an old, half-baked and out-of-spec server on our hands. Great! To me, working on the Metin2 server has become like one of those relationships in which you don't really like your partner, you fight all the time, yet you still stay together because you feel attached to them. It's plainly bad and it must go away. Just look at this forum, it's full of hotfixes, and whenever an actual feature release comes up, you have to find and replace tons of stuff and you don't even know if it will break any other system you have installed. Why can't we have some sort of plugin system so that we end this agony? The topic of porting Metin2's server to Linux has come up numerous times here. Yet it has to be done underground, because God forbid making your code public, because daddy Gameforge is going to knock on your door like it's 1977. I don't want to get into this discussion, but it's their right. A light has shined before my eyes, though. Recently, a friend has asked me to help him out with hosting a Lineage 2 server. I don't know pretty much anything about this game, but I've found out one thing: there are two big classes of server software: the OFF, meaning the original server files NCSOFT developed, and L2J, a Java-written emulator for the same server files. And the thing is, people have been sued for running the original server files, but not for using the Java edition. Not to mention that the Java edition is publicly available in its various forks on GitHub and Bitbucket. I guess you see where this is going. If we're all stuck at home, why don't we come together, join our efforts and rewrite the server in a more future-oriented, sensible way? This would mean less risk of being thrown in jail by Gameforge. Not to mention that we don't need to do any reverse engineering as the source code is readily available, and this is a huge, a monumental advantage. The official Metin2 is going to be dead in a matter of years, but Gameforge not so much. This means that any future support and development for the game lies within the open-source community. If we're going to do this, we should aim for the future. We should take into account the architecture of current systems. We should think of built-in redundancy in case one of the server crashes. And as much as I like C++ and its power, with great power comes great responsibility. It's simply too easy to make mistakes in C++. Not to mention the hell you must go through to simply include a library (In a way, it's a good thing since it forces you to think, not blindly include another library for adding two numbers like you would do in JS). C++ is one of those toxic relationships and I suggest moving to a tool more fit for the job. A language like Rust would do the job, for instance. It compiles down to machine code, it includes a network stack by default, it can read JSON and XML files, and it has many more features I didn't hear about yet. I never wrote anything in Rust, but it's just syntax. Real programming is about tackling problems, not about syntax. I'm open to any ideas or suggestions. Maybe I'm talking sh*t and Metin2 deserves to die. But I'm looking at you, Vanilla, Shogun, MartySama, Sanchez and all others who genuinely contributed to the community with original work but I can't name because I'm a stupid prick with 32kB of memory. What do you think? It's a huge task, yet manageable if we all give our best. Don't take anything I wrote here for granted, if you come with a good reason on why we should rewrite the game in MIPS Assembly and run it on PS2s, I'm open for it. Thank you for choosing Metin2Dev Airlines.

I did a quick translation using DeepL: What the actual fu*ck!? ?

Boys and girls, I think it's time to move metin2.dev onto a .onion host ?. Just in case.

Here's my take at making an analogy of what happened with the source code. Let's say that your family owns a cookie store. They make the best cookies in town, children are flocking after school just to grab a cookie. It's great for your family, you make tons of money etc. Then, one night, when everyone's at home and the store's empty, somebody sneakily breaks into the store and sets up a hidden camera in the store's kitchen. The next day, business as usual, grandma is working on baking those cookies, but unbeknownst to her, the camera is silently recording the recipe: what ingredients she uses, how long the cookies stay in the oven etc. The bad guy then opens another cookie store, and bakes the cookies using exactly the same recipe as your family does. And sells them at half the price. Naturally, you'll start losing money as everyone is now getting their sweet cookies from the bad guy's store. Now, your store sits empty and you look at the stack of unpaid bills on your desk. Is it fair? Of course not. This is called intellectual property theft and there are laws made specifically to protect the guys who invested time and effort into creating something from others stealing their work. In this case, the cookie recipe is the source code and your family's store is Gameforge/Webzen. It's their game afterall, and there's no changing that. Does it suck? Duuuuh! Of course it does. We worked so hard to create nice versions of the game, but at the end of the day, most of the community is doing that for money and on the backs of other people who worked on this game. (This is why I seriously considered making a non-profit server once, it's just not ethical to do this...) Of course it would be nice for Gameforge to just let it slide, and maybe licensing the game to third parties or even making it open-source. But there's no forcing them into this. This is the sad truth, private servers can't exist legally and we have to own this fact.

I feel like there's a huge crisis of manpower which prevents us from doing anything awesome though... This is why I take this chance to tell you that you just go above and beyond with the improvements you make on the gamecore. It's just plain impressive to see what you achieve alone. Thank you for your service ^^ I'm pretty sure they have the resources to reach out far and wide across the EU. For all I remember, there were some raids here in Romania some time ago as well. Though you're probably right when you say that they can't take down all the servers. They just go for the big fish. As someone already said in the thread, I wonder how WoM is still standing... To be fair, given how popular the game was, I feel like there will always be a demand for it, maybe even just for nostalgia reasons. People are still playing GTA:SA and CS1.6 in 2019. That's why I say the official Metin2 servers will be long gone by the time private servers finally die. But if we keep the spirit of just having fun, even silly dumb fun like on those PvP servers on which you start with the max level and give 100k of damage per hit with a FMS+9, if we do all this we just might be able to keep the game alive.

Well, it seems like it's time to dust off my old account... Another m2dev user and I have been working for the past almost two years in our free time in order to create a new server concept (with a lot of technical improvements etc. It's still not ready if you're asking). This is a major roadblock for us. At least for me, Metin2 is the game that taught me a lot about programming. I always experimented with P Servers and have been in the field for almost eight full years now. In these eight years, I never, not even once had any account greater than lvl. 30 on any GF server. I don't have a clue how to get a horse on an official server. And frankly, I don't care. Because it's not fun and private servers offered a much better and complete experience, including everything from the community to gameplay. To me, private servers are what define Metin2's culture, and I guess it's normal to be this way: there's a lot more room to experiment with the game when you can make your own pserver. You're not tied to the hands of all-mighty Gameforge. In a sense, what Gameforge is trying to achieve here can be compared to a dictatorship of sorts. They're dying and, like a cornered animal, are desperately trying to keep their "monopoly" and squeeze every last euro-cent out of the player's pockets. Just look at those stupid updates which came out in the past... idk, 4 years? Do they have anything to do with the essence of Metin2? It depends on one's taste, of course, but I think the majority would argue that those updates are no more than a money-grabbing technique. I'm not sure if many people look at the Pserver scene this way, but what we are is essentially a modding community. A game which can't be modded becomes dull after a while, be it a couple of months or a year. Yet games that are moddable still thrive. What GF & Webzen (or whoever owns Metin2 nowadays) don't realise is you can't have a free market without options. By each day, we're seeing Gameforge marching centimetre by centimetre towards killing Metin2 alltogether. Unless they'll come up with a way of accepting PServers on the market, they'll die. I'm aware that you could argue that M2 is their Intellectual Property, yet you could as well argue that laws serve the people, and if people want change, then it's rightful to do so. Enough ethics in this rant. I guess if we have to stay underground, pre-paid credit cards and Russian/(maybe even Swiss?) servers are an option. Or we could go back to the old days to a Hamachi-like experience. Maybe hosting servers through a large, community-owned VPN server? Maybe we're just being angry for no reason. GF will die one day and the PServer community, albeit shrinking, will outlive them, and then it's free real estate for all of us. Le roi est mort, vive le roi. </rant>

I made a custom item_proto (un/)packer for this guy. I provided him photo proof that my software works, then I packaged all the necessary stuff for him in a .rar archive. I sent him the password-protected archive and we came to an agreement that after he would've sent me 10$ via PayPal, I would give him the password to the archived software. To this day, no matter how many messages I would send him, he wouldn't reply or send the money. Long story short, working for this dude was a waste of time and I advise everybody else to stay away from him.

Hello, I cannot find you with the Skype ID you have posted. Please check your private messages

Nice job! I'm really proud that there still are people interested in enhancing the serverfiles ^^ What did make you remove all the boost dependencies in the code? I mean, as boost is cross-platform, you could've ported all the BSD-only parts of the code to their boost counterparts, and then you would've had the possibility of compiling on Linux. Also, I'm quite interested in those security issues, what do they most consist of? SQL injection vulnerabilities?