Jump to content
  • We need you!

    You must register to discover all the features of our community!

[DISCUSSION] How about we don't go to jail?


Recommended Posts

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.

  • Love 6
Link to post
  • VIP
3 hours ago, Exynox said:

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.

 

Man... you let marty release v10 first.

  • Love 4
Link to post
6 hours ago, Exynox said:

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.

The plan is to make a Metin2Dev files ?

I totally agree with you but that's a really good amount of work and i don't know if someone who have the skills for that want to spend his time on it for free (i don't have the skill for that) but it's not impossible and it would be really nice to give a second life to our old school loved Korean Game 

Link to post
  • VIP

FreeBSD is the best decission YMIR made. I don't get the obsession with porting it to a system just because it's more popular. There's a reason Netflix, Apple and Sony use it.

  • Love 4

 

 

Link to post
1 minute ago, Shogun said:

FreeBSD is the best decission YMIR made. I don't get the obsession with porting it to a system just because it's more popular. There's a reason Netflix, Apple and Sony use it.

 

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.

 

52 minutes ago, Ayslow said:

The plan is to make a Metin2Dev files ?

I totally agree with you but that's a really good amount of work and i don't know if someone who have the skills for that want to spend his time on it for free (i don't have the skill for that) but it's not impossible and it would be really nice to give a second life to our old school loved Korean Game 

 

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.

  • Love 1
Link to post
  • VIP

To be legal is not enough just to re-write the game i think. I remeber The days when i was using old tribal wars leaked version. You need to change the game design too. 

  • Love 1

Trying to bring the old metin2 to life.

@Caramelito

Link to post
4 hours ago, tierrilopes said:

I was reading until i saw this mentioned: "java". See ya.

 

There is a game called Lineage 2 , it is a way bigger than Metin2 and there are many private servers using java emu ,

but yeah you will be limited ,

 

 

 

 

 

 

Edited by jeddawee (see edit history)
  • Love 1
Link to post

 

Spoiler


On 4/18/2020 at 9:16 AM, Exynox said:

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 totally agree with you.

I myself, not long ago, tried to port to Linux with another person (who turned out to be totally unreliable), and I would gladly help you with this open-source project.

I think that Rust-Lang is the `one-and-only` language we should use, in order to achieve high performances and memory safety. I've already done some project with it, it's really awesome and clean.

 

Hope to hear something more about this project!

Hype mode: ON

 

------------ EDIT 1 ------------

Using "Rust-Lang" would also be a great idea for its integrated documentation maker, which we should also pay particular attention to.

 

------------ EDIT 2 ------------

Wrong quote

Edited by Akronis (see edit history)
  • Love 1
Link to post
On 4/21/2020 at 4:08 PM, Akronis said:

 

  Reveal hidden contents

 

 

 

 

 

I totally agree with you.

I myself, not long ago, tried to port to Linux with another person (who turned out to be totally unreliable), and I would gladly help you with this open-source project.

I think that Rust-Lang is the `one-and-only` language we should use, in order to achieve high performances and memory safety. I've already done some project with it, it's really awesome and clean.

 

Hope to hear something more about this project!

Hype mode: ON

 

------------ EDIT 1 ------------

Using "Rust-Lang" would also be a great idea for its integrated documentation maker, which we should also pay particular attention to.

 

------------ EDIT 2 ------------

Wrong quote

 

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.

Link to post

Hi @Exynox,

I'm glad to hear that.

 

In order to make a real good job, we must follow a rigorous software engineering process.
Before even writing a single line of code, we better start thinking of a proper design for this project (it would be great if we could make some UML diagram, requirements analysis and all the other stuff).

 

The time we spend in this, is gonna be saved for the next steps.

Link to post

Interesting, but big project.

 

I do agree with some stuff, but highly disagree with other points.

In fact I do like the c++ part. I don't have any experience with rust but I do know that a mighty c++ version along with current standards is not a disadvantage at all. Things like memory management were an issue back then. Today with stuff like smart pointers you even have more tools to avoid memory corruption. Though yes, Rust is definitely not bad at all and a rust-port would be interesting to see.

 

What I don't agree is the "rant" about BSD. It doesn't matter if there was no big choice back then. If you wanna rewrite the game then it's mandatory what matters today, not in the past. And nowadays FreeBSD is a very stable, fast and reliable system. Yet I even happened to catch more errors in linux than in BSD (like faulty pkg installations and stuff, but that doesn't matter much for this project). What matters is: Speed, security and reliability. So, why the heck should BSD be an issue there? Why even bother porting it to linux if BSD does the job quite well? I often see people not setting up their system correctly and then wonder about issues they wouldn't have if they read a bit about it. Heck, even now many people are still using BSD versions from years ago.

 

Though yes, a complete rewrite that actually focuses on more stability and speed, utilizing the more recent tools we have (threading, etc.) would be very benenificient for this. But it's also a big task and don't be fooled - if you rewrite it from scratch, there WILL be bugs. A game project as big as a metin2 server will potentially cause bugs. Where there are humans, there's also error. That's a fact and yeah, you can obviously fix those. What I wanna say is: I'm reading this text like "hey, let's all get together and set up a project" but I think the project isn't thought through well enough. And to completely rely on the devs makes it sound like "I wanna create something huge, come all devs and help me do it". Don't get me wrong, it's not bad to somewhat unite the people who know about development. But it makes the project sound kinda fishy.

 

I'd love to see such a project come to live. But to do so it takes more than a bright idea. Or, to quote a well-known meme: "One cannot simply rewrite a whole game". You'd think this through and if there's a plan, a concept and if you brainstormed well enough then the project has a chance of success. For now it more looks like an idea, something you had in mind and want to present. But it lacks the core thoughts about it. The first post is more about "ranting" about the stuff the old source has - supposedly - done wrong and how to fix it. And yes, some points do count. But there's high disagreement on other things and as much as it'd look cool to have e. g. a linux port.. It's basically pointless given what we already have. I hope you understand what I'm trying to say, no offense intended here.

  • Love 2

We are the tortured.
We're not your friends.
As long as we're not visible.
We are unfixable.

Link to post

@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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.)
  5. 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.
  6. 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.

 

1 hour ago, Vanilla said:

What I wanna say is: I'm reading this text like "hey, let's all get together and set up a project"

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.

 

  • Love 1
Link to post
  • 3 months later...

I've been long gone from the Metin2 scene however, today I decided to take a look at Metin2Dev and this thread was a joy. I do feel the same as @Exynox and I gotta say, you took the words out of my mouth, what you've said, word by word is what I feel about the Metin2 server core.

Just as a context, I was a Metin2 Player since 2007, been in the private server stuff since the release of the Metin2 Rain Files, been author and "ghost" author of several metin2 servers, been through every process (client, server, website, quest's), a lot of different programming languages, however 5/6 years ago I decided to leave and focus on my professional career. Nowadays  I work in the IT field, been working professionally in several different roles since 2016 (Golang, Javascript/Typescript, Kubernetes, Docker, CI/CD, Code Review, ...) This are all terms of my day to day life.

The choice of the Rust language is for sure the best bet, did some small projects back in the beginning of 2019 and it's for sure a language that deserves its credit.

I was just wondering if any progress was made, unfortunately I don't have the time I would like to put a decent amount of effort into this, now a days the free time that I have (not much) is just to enjoy life outside.

Link to post
  • VIP

Is having a completely rewritten server enough to not get sued by Gameforge though? Even if you do rewrite the client side from scratch, you are still gonna use their 3D models, textures, sound effects etc. If you use these without permission that should be enough for them to sue you. And if you have plans to remake those assets too why don't you just make a new game at this point? I don't know but this doesn't sound like a project two or three hobbyist can do in their spare time.

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×
×
  • Create New...

Important Information

Terms of Use / Privacy Policy / Guidelines / We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.