[Discussion] My two cents about IGCN source code.

[ptr0x]

Hi,

My intention with this thread is to create an open respectful debate around the reasons and motivations ppl keep using IGCN (and IGCN related) src codes.

I'm mainly talking about the S9 source that seems to start this trend (http://forum.ragezone.com/f197/release-igcn-season-9-5-a-1125721/) and about the "MuEmu" S12 source (that is basically the same S9 code).

I have some experience as a developer but very new to the Mu Online community and I'm still learning its interim but as I already analysed some things I want to better understand why, in the name of the loving god, people use those source codes (igcn s9/s12).

It is not my intention to flame igcn team, far from that, but let's talk real. These source codes are in a very poor state. From very basic programming issues like coding-standard (that seems to be inexistent there) to logic problems (like comparing boolean variable with values that differ from 0/1) to more complex problems like using the win api to create mutexes for multi threading management instead of using c++ STD (that to not even mention the lack of use of boost) to structural problems (like having some code files with 30k+ of LoC).

There are some other problems, but I think the above issues are enough for me to do not understand why the heck one decides to use and maintain that source codes instead of using the x-team S6 source, which seems to be light-years ahead in terms of overall code quality.

I can only imagine the pain one have when faced with a complex problem that need delve deep in that code.

In other hand however, I see the value of those sources on the client-server communication protocol (packet structs and stuff). But yet as a source code of a server emulator I find those sources almost unusable.

And you? What you think about that? Is something very big I'm missing here?

 

[Natzugen]

Actually, thise source codes as far as i know are not their original sources, just old stuff muemu pl stole, same x-team sources wich is a pretty old version compared to their current files.

Before them there was only zteam s8 source code wich was pretty unstable and incomplete and since most lf people here can't develop or upgrade to newer seasons they just stick to released stuff that are actually better than webzen code.

 

[nevS]

Well, all sources are more or less based on the decompilation of an original game server, done many years ago by Deathway. People use it, because there are no real alternatives and probably don't care about how the code looks like. Additionally, there are not many good developers left here which would take big task to upgrade a x-team source or to clean up the mess in the igcn code. I guess they would rather sell their work (closed source) or don't even think about it at all.
From my experience in the "professional" software business, you can sell the biggest junk piece of software as long as it looks nice and shiny on the surface and has the required features :laugh: So I guess, the same applies here, too.

 

[ptr0x]

Actually, thise source codes as far as i know are not their original sources, just old stuff muemu pl stole, same x-team sources wich is a pretty old version compared to their current files.

Before them there was only zteam s8 source code wich was pretty unstable and incomplete and since most lf people here can't develop or upgrade to newer seasons they just stick to released stuff that are actually better than webzen code.

Ye I imagined that code was not the real one used by IGCN because it is too messy to a team maintain for so many years. It is like it was coded by someone whom just learned the very basic aspects of the C language.

Well, all sources are more or less based on the decompilation of an original game server, done many years ago by Deathway. People use it, because there are no real alternatives and probably don't care about how the code looks like. Additionally, there are not many good developers left here which would take big task to upgrade a x-team source or to clean up the mess in the igcn code. I guess they would rather sell their work (closed source) or don't even think about it at all.
From my experience in the "professional" software business, you can sell the biggest junk piece of software as long as it looks nice and shiny on the surface and has the required features :laugh: So I guess, the same applies here, too.

Well, I just started to work with the x-team src code (that one which is compatible with S4, S6 and S8) and I can confirm that the overall code quality is very, very, very much better than the IGCN one. The only big real problem I faced with the x-team src code is one that is present in IGCN too: they just don't use boost and there is heavy use of direct windows api. However this isolated does not bring too much trouble, this is something we can cope with certain ease.

Considering the x-team src is open to the community and is used for so many years, I can consider that code is stable at a minimum.

If I decide to use the x-team src I'll "fork" the project and share the fixes as I find them in my server. When I get in time to upgrade the code to a bigger Season I can open that too. Hopefully the community will get together again and accomplish big things together. It's very sad to see the actual state of the open source codes related to server files.

 

[-UnicorN-]

Well it would be so awesome if a good open source mu server project finally appears.

 

[Cinu]

Well it would be so awesome if a good open source mu server project finally appears.

Forget about it, it's impossible :junglejane:

 

[nevS]

Forget about it, it's impossible :junglejane:

Why so negative?

Well it would be so awesome if a good open source mu server project finally appears.

Check out my signature. Not claiming that my project is awesome already, but it's on the road to it... will take a lot of time to finish it, though ;-)

 

[ptr0x]

Why so negative?


Check out my signature. Not claiming that my project is awesome already, but it's on the road to it... will take a lot of time to finish it, though ;-)

That's a nice initiative but may I ask why not developing in top of the xteam src?

 

[nevS]

Well, that’s a good question and I have my reasons.
1. I don’t know how the xteam source looks like but my bet would be that it’s the same architecture as all the others - based on the decompilation of Deathway with the original style of connected service processes. Not something I would put my hands on in my free time - I maintain a lot of legacy software at work and want to actually build something new.
2. I have some visions which are not achievable (at least by me) in the c++ ecosystem in a reasonable time.
3. I want to sharpen my skills in tools and frameworks which could be useful in my job.
4. I like open source and these sources have closed source dependencies - MSSQL, binaries, etc.

See also

You must be registered to see links

 

[ptr0x]

Well, that’s a good question and I have my reasons.
1. I don’t know how the xteam source looks like but my bet would be that it’s the same architecture as all the others - based on the decompilation of Deathway with the original style of connected service processes. Not something I would put my hands on in my free time - I maintain a lot of legacy software at work and want to actually build something new.
2. I have some visions which are not achievable (at least by me) in the c++ ecosystem in a reasonable time.
3. I want to sharpen my skills in tools and frameworks which could be useful in my job.
4. I like open source and these sources have closed source dependencies - MSSQL, binaries, etc.

See also

You must be registered to see links

Hmm I see...

I just can't see why C# would be better than C++ to develop a server emulator though. C# have a lot of limitations regarding memory management compared to C++.

Nice work there though. Hope it goes through

 

[nevS]

I think people overestimate the limitations of C# and its ecosystem. For example, there is a high performance NoSql database system (RavenDB) written entirely in C# - it makes use of pointers and partly manages memory itself.
.NET Core adds a lot of convenience if you want to optimize memory management. Span<T>, System.Buffers.MemoryPool and System.IO.Pipelines are really a game changer in this aspect.

 

[ptr0x]

I think people overestimate the limitations of C# and its ecosystem. For example, there is a high performance NoSql database system (RavenDB) written entirely in C# - it makes use of pointers and partly manages memory itself.
.NET Core adds a lot of convenience if you want to optimize memory management. Span<T>, System.Buffers.MemoryPool and System.IO.Pipelines are really a game changer in this aspect.

The big problem regarding C# and memory management IMHO is that if you go with pointers you will find yourself in serious problems regarding code scalability and maintainability (you are forced to use structs. Structs have to be blittable. Blittable structs are always passed by value. The list goes on...). If you choose to use Marshal class to cast raw data into classes you will feel pain when doing inheritance on your data classes. Ofc you can always goes to the Stream.ReadByte method of doing things, but I think I don't need to talk about scalability in this case, because it will be inexistent lol

All this because C# runs managed code, which is a very nice feature for a lot of system architectures, but in a client/server application such as a Mu server emulator I think you will limit yourself very much going with C#.

However as a tech enthusiastic I think your project is very nice I like exotic projects.

Best regards.

 

[solarismu]

Sorry bro, I have to admit that I'm anti fan of any Mu C# game engine as well... ptrox got the points.

About IGCN, I agree with you that their released codes are uncomfortable or some said it's a mess
And if you try to clean up a combination mess between IGCN and MUEMU... You know, that will be the worst nightmare.

Anyway, IT WORKS. That's enough for them to make money. The nicer code don't bring money to them, user can't look at the code to judge their works.
And bugs? Of course , but a bug only is true bug if people knew about it... then they will fix it later ) use time to code "more bugs" (new features) will bring more money to them... fixing bugs? NO ^^

IGCN also has many great sides... such as:
1. their .xml config is super user friendly, -> I've never back to GetToken config style since ...^^
2. they have Essential+Premium tools -> even a noob can make a Mu Server
3. big community, have more friends as well as rivals to deal with
...

 

[-UnicorN-]

Check out my signature. Not claiming that my project is awesome already, but it's on the road to it... will take a lot of time to finish it, though ;-)

Yea i saw your blog As i said it would be awesome. Many projects started like this and afaik unfortunately no one came close to conclusion. But i hope yours does

 

[siksamees]

Yea. Considering pro's and con's its a even situation. either way people gona run into issues.
My friend and i tried to make server using IGCN premium files. i wasnt that dissappointed of the files condition but their team it self.
Some basic things that works well on free repacks did not work on theirs. yet they had things that you couldnt find in any public free repacks.
The support from them was slow as hell, and some minor bugs seemed not to be worthy of their time. Advertising new features that should be considered equal to scamming.
its a difficult situation where people like new trends ( latest seasons/features ) and this is why i think igcn files are so common amongst current servers.

 

[bramdebouvere]

I don't agree with everyone bashing on C# here. I must agree that there are limits to memory management. But if your code doesn't look like a total trainwreck you should actually never have too much memory issues on a server like this (unless you have a leak somewhere). I've coded servers in C# that received more than Gbps in traffic and never used more than 25MB of memory.
Of course, if you start using third party crap and some crappy frameworks provided by Microsoft, you might have a bad time.

nevS, nice project you have going there!

 

[ptr0x]

Yea. Considering pro's and con's its a even situation. either way people gona run into issues.
My friend and i tried to make server using IGCN premium files. i wasnt that dissappointed of the files condition but their team it self.
Some basic things that works well on free repacks did not work on theirs. yet they had things that you couldnt find in any public free repacks.
The support from them was slow as hell, and some minor bugs seemed not to be worthy of their time. Advertising new features that should be considered equal to scamming.
its a difficult situation where people like new trends ( latest seasons/features ) and this is why i think igcn files are so common amongst current servers.

Altough the post does not concern the files IGCN sell nowadays, I agree with you here.

I was a customer of IGCN too, before paying them everything is great. I was told that the files were very customizable through Lua scripts, a lot of options could be changed through XML, there was the possibility to pay for custom requests, etc. So I paid for their so called "premium service". I felt nothing but scammed. Their customer support is by far the worst customer support I have had the unhapiness to deal with. The S13 files are very buggy. And, well, their so called "Lua scripting" is done like if my 8 years old cousin programmed it. They provide no documentation regarding the API exposed to Lua scripts and the things you can actually tweak using their existent scripts is virtually 0. Their "lua scripting" is probably what most shocked me. It's not more than a fancy way to set values to variables.

I don't agree with everyone bashing on C# here. I must agree that there are limits to memory management. But if your code doesn't look like a total trainwreck you should actually never have too much memory issues on a server like this (unless you have a leak somewhere). I've coded servers in C# that received more than Gbps in traffic and never used more than 25MB of memory.
Of course, if you start using third party crap and some crappy frameworks provided by Microsoft, you might have a bad time.

nevS, nice project you have going there!

I don't think anyone is bashing on C#. Also I think you missed the point of what we were talking, but I will speak only for me here.

I did not meant that you can not do such things using pure C#. I just pointed out that there are far better languages to use in cases like a server in a client-server application. I take this for a fact: C++ is way better to do such an application than C# for tons of reasons - limitations regarding memory management is just 1 of those reasons.

However I think you missed what was told. By stating C# have memory management limitations (remember that I was always comparing its capacity to work with memory to C++ capacity to do the same) I was implying different problems than the ones you seem to got from what I told. I was not talking that the memory management limitations of C# imply in the incapacity of handling a large number of data bytes. These limitations results in a lot more problems in aspects as code readability and code maintainability. Imagine things like taking an address in memory and treating it in the code as a data structure in C# results in a code that is difficult to read and to maintain. Besides that, C# will execute codes regarding memory management a lot slower than any (ok, almost any) unmanaged language - this is just not a big problem nowadays due to the growing hardware power in average PCs nowadays.

Yet, C# is the language I like the most. I can create the cleanest code with a very high maintanability and readability using this language (overall, these aspects tend to be very much higher in C# codes than C++ codes). This is just not the truth in this particular case we are discussing.

 

[bramdebouvere]

Imagine things like taking an address in memory and treating it in the code as a data structure in C# results in a code that is difficult to read and to maintain.

That's all good and well. But I don't see why you would use structs and pointers in the first place. Classes are very optimized in .net. I don't see the need of using structs and pointers everywhere if you're not running on embedded systems / have legacy libraries that you need to call / need to interface with specific hardware / need exotic tricks to make more optimized code. I personally think that if you are using a lot of code like that to create a game server, something is terribly wrong (i'm talking if you're using c# specifically, not c++). I can totally see why one would do it in unmanaged languages, but in a managed language like c# it just seems like unnecessary complication to me, with little to no benefit in performance. And you are very correct to say that it would probably result in a lot of issues down the line. So the only thing I can really say to that is "just don't do that"..

But I realise that we're going offtopic, so maybe it's better if we keep this conversation going elsewhere.

 

[ptr0x]

That's all good and well. But I don't see why you would use structs and pointers in the first place. Classes are very optimized in .net. I don't see the need of using structs and pointers everywhere if you're not running on embedded systems / have legacy libraries that you need to call / need to interface with specific hardware / need exotic tricks to make more optimized code.

Data structures does not ends up in structs. Classes are as data structures as structs are. They are both very similar to each other - the main differences around classes and structs revolves around how each of them are managed in memory. So when I say "data structures" I'm referrring to any data structure in the code, both classes and structs. Well, while you should use classes in the majority of cases. You can only do pointer arithmetics with structs. There are a lot of cases where one should use structs over classes besides the cases you pointed out.

I personally think that if you are using a lot of code like that to create a game server, something is terribly wrong (i'm talking if you're using c# specifically, not c++). I can totally see why one would do it in managed languages, but in an unmanaged language like c# it just seems like unnecessary complication to me, with little to no benefit in performance. And you are very correct to say that it would probably result in a lot of issues down the line. So the only thing I can really say to that is "just don't do that"..

I can't disagree more here. All these features are what makes C# so great. The possibility to manage memory in a managed application, even with some limitations, are awesome. There are a lot of cases where you should use a lot of "code like that" to create a game server. There are A LOT of benefit in performance if you do things using pointer arithmetics instead of relying entirely in the CLR.Net; almost every code will execute very much faster if you code it the right way inside an unsafe block and make heavy use of pointers. That to not even mention particular cases where you can save hundreds of LoC using that approach instead of sticking 100% with managed code.

TL;DL If I was doing such a project in C# I would certainly not stick myself with managed C#. I would use C++/CLR where it fits and certainly would use a lot of unmanaged code (like pointers and structs) in the code where it is better applied.

But I realise that we're going offtopic, so maybe it's better if we keep this conversation going elsewhere.

Ye, lets get back to the topic ^^

 

[ptr0x]

Just a little adendum to the c# vs c++ discussion:

I somehow saw a post I wrote in codereview.stackexchange showing a simple wrapper to marshal raw data into marshalable c# classes. Link:

You must be registered to see links