Announcing Co3mu

[sskwidowmaker]

You've heard of CoEmu, CoEmu v2, and CoEmu v2 [NANO]; now, the next generation of CoEmu servers is here: Co3mu.

Co3mu is going to start as an open-source, community built project. This is a little different than what we've done before. CoEmu 1 was designed as a community-sourced project, 2 was closed-source, and 3 will once again be open source.

Here's the punch-line: the entirety of Co3mu will be written in D.
D is a powerful "extension" of C/C++. The easiest way to describe D to those of us familiar with C++ and C# is that D is a merge of C# and C++, with of course some additions and deletions. D can be fully mapped to C++, and is thus backwards-compatible. You can write a library in C++ and use it in D.

At current, the project is aimed at version 5518, with plans to support newer versions of the Conquer client at a later date.

What's done so far:
libopenssl implemented into D
rc5 cipher for password working, login working
XML file structure for data storage
Logging in fully works
GameServer encryption/decryption implemented
Character creation hard-coded implementation (reworking required)
Login to the game world

D is compatible with Windows and Linux out of the box; however, this server is being aimed at Linux-central capability. Therefore, some practices you see in coding will not be in-line with Windows performance, but will rather use Linux improvements where available.

If you would like to contribute, if you have any questions, or so on, please feel free to PM me.

Setting up D is straight-forward. The only issue you may run into is creating the needed library imports for libopenssl(if you're using Windows). I can explain this to you, if you require.



Co3mu and CoEmu related organizational marks used with consent.

[andyd123]

I fully support this post.

[diedwarrior]

Wow, this D seems nice, will look into it later, good luck with the project .

[InfamousNoone]

Skimming the source I see this turning out to be as horrendous and unscalable as all the other past CoEMU revisions. On a more humorous-offtopic note you still owe me $50 andy u scammer

Ok, never mind, looking it over indepth... seriously Andy if this is your work -- what the ****? Have you learned NOTHING in regards to programming in the x-years since your last source? In the more likely scenario this isn't completely your work, oh hi, you're not dead after all.

[turk55]

Goodluck with the server.

[Spirited]

I really see a lot of potential in D and I'm glad you chose it. I hope you take full advantage of its abilities to call native C functions and use native pointers. It's really something different (a managed, cross-platform language like Java but with the ability to call native C like C#). Good luck.

[IAmHawtness]

I'm happy to see someone's actually using D, I believe a server written in D would be fantastic.

I looked through the code though, and that made me less happy. I'm hoping that this is just some temporary code to test out the server, and that you wil refactor the hell out of it later. Even though this is D, there's still certain conventions you should follow.

For example:

• ALWAYS use pascal casing for class names: C3Client, not c3Client.
• ALWAYS be consistent. If you choose a specific coding style, STICK WITH IT.
• Encapsulation!
• Aim for low coupling and high cohesion

I also noticed a very disturbing habit, not sure if intended or you're re-making it later, but:

public class c3Core {

	public static bool continueServer = true;

	// ........

	public static bool shouldContinue() {
		return continueServer;
	}

}

There's properties in D, too, you know.

public class C3Core {

	private static bool continueServer = true;

	// ........

	@property
	public static bool shouldContinue() {
		return continueServer;
	}

}

Same goes for the C3Char class. Public member variables is generally a bad design.

Now I'm no saint when it comes to following conventions either, most of my projects end up being a big mess too, but when you're making a public source, you really, really need to be well aware of all of this and more.

I'm not sure what IDE you're using, but if you're using MonoDevelop with the Mono-D plugin, using the @property keyword for properties will also make the IDE aware that it's properties and not just regular methods.

[Zeroxelli]

Ohai, Andy still exists. Thought he died from all the stupid questions years ago.

[sskwidowmaker]

Originally Posted by IAmHawtness

I'm happy to see someone's actually using D, I believe a server written in D would be fantastic.

I looked through the code though, and that made me less happy. I'm hoping that this is just some temporary code to test out the server, and that you wil refactor the hell out of it later. Even though this is D, there's still certain conventions you should follow.

For example:

• ALWAYS use pascal casing for class names: C3Client, not c3Client.
• ALWAYS be consistent. If you choose a specific coding style, STICK WITH IT.
• Encapsulation!
• Aim for low coupling and high cohesion

I also noticed a very disturbing habit, not sure if intended or you're re-making it later, but:

public class c3Core {

	public static bool continueServer = true;

	// ........

	public static bool shouldContinue() {
		return continueServer;
	}

}

There's properties in D, too, you know.

public class C3Core {

	private static bool continueServer = true;

	// ........

	@property
	public static bool shouldContinue() {
		return continueServer;
	}

}

Same goes for the C3Char class. Public member variables is generally a bad design.

Now I'm no saint when it comes to following conventions either, most of my projects end up being a big mess too, but when you're making a public source, you really, really need to be well aware of all of this and more.

I'm not sure what IDE you're using, but if you're using MonoDevelop with the Mono-D plugin, using the @property keyword for properties will also make the IDE aware that it's properties and not just regular methods.

Thanks for the heads up, I'm pretty bad about doing just that.
Right now, I'm focusing on getting the server to a running state above getting the code behind it to the perfect state. However, when I go through and edit for code-correctness, I'll be sure to take that into consideration.

Thanks for the support everyone!

[KraHen]

Just my 2 cents regarding public variables in class design, there are environments in which this approach is actually strongly recommended, for instance in Java when under the Dalvik VM (Android), where public variables are MUCH faster than using properties, and on mobile any minor performance gain is a game-breaker. Also in Actionscript 3 developers use this approach lots of times, sincerely I don`t know why, nor do I care about it that much, I suppose there`s something like the Dalvik problem here as well, or it`s just Flash programmers are script kids.

Although I fully support IAmHawtness with the tips in general, and specifically this instance.

[Zeroxelli]

I don't see the purpose for having the method (/property) in the first place. I mean, if you're going to have the original boolean set as public, you may as well just rename it to shouldContinue and use just that (or go with properties as IAmHawtness proposed.) Seems like a waste of code to have all these different references/methods/etc that all point back to one variable.. but that could just be because of all the books I've read, which all suggest against that particular habit.

Anyway, nice to see D actually used. I haven't heard of it since I was working with servers.