NGemity - An Open Source Rappelz Emulator

[Only registered and activated users can see links. Click Here To Register...]

An Open Source Rappelz Emulator
Aye folks!
In a forum, a long long time ago, actually not that long ago tho, there was a group called NCarbon that started working on a Rappelz Emulator.
Sadly enough that group disbanded and the project has been dropped.

2 years ago (a bit earlier than this threads creation date) I decided to restart this project, however, switching from C# to C++ and using Epic 4 as a base. Sadly enough I had to pause the project for a long time but now we're back: The project grew, members joined and we're making steady progress!

Why Epic 4?
I decided to go with Epic 4 as a base - means that we can always expand it to use for later epics.
Using Epic 4 helps us get a great base running, because it pretty much only contains the base systems of Rappelz itself. Adding to that, Epic 4 is a pretty liked Epic with no official server files released (yet).
Expanding is always easier than downgrading. We'll be able to create an Emulator that's way more customizable than our current server files for literally every Epic!

What's the current state of the Emulator?
So far we have a pretty neat base running and the game is actually playable.
Right now it's pretty stable and running fine on my server, but of course not all systems have been implemented yet.
Quests, all Skills, buffs and so on are working just fine right now, so you can pretty much play every class you want in the state of Epic 4.
Systems that are not implemented yet are guilds, auction house, channels and sieges. I may have forgotten about something tho. ¯\_(ツ)_/¯

How can I participate?
If you are a developer and/or experienced with C++, feel free to check out the Github repository and work with the source code. If you have any questions, just message one of the contributors or members, we're willing to help and teach!

If you are a developer and not experienced with C++, there are still sub-projects like rdb parsing for both Epic 4 Clients (2007 release & 2008 release). Just shoot us a message and we'll let you know what needs to be done.

If you have no experience in programming but still want to contribute, join us on the public test server and "just play the game". If you find any bugs on your journey through the history of Rappelz, please let us know so we can fix it!

Some technical details:
The Emulator is written in C++ and requires a C++17 compiler, preferably GCC, CLang or MSVC.
We use ACE (The ADAPTIVE Communication Environment) boost and the std for networking and general platform independent functionality, e.g. threading.
We also use the Lua library extended by the Sol2 library, a modern C++ wrapper for Lua. Makes code way easier to read and write :^)
So far it runs great on Linux based systems and Windows, we weren't able to check it on MacOS or other stuff yet.

Besides that, the Emulator is "based" on Project SkyFire and/or ManGOS, both open source World of Warcraft emulators. The reasoning for this was to get a proper base for database, networking and other functionality. If you play WoW, please make sure to check them out, they're great!

Some Links to the project:

• Discord Server: [Only registered and activated users can see links. Click Here To Register...]
• GitHub Repository: [Only registered and activated users can see links. Click Here To Register...] DMCA'd, so no public access unless requested on Discord.

If you're interested, please feel free to join us on Discord to either keep up with the current state of the emulator, to join the testserver or just chat with us. :)

Regards,

Xijezu

I hope you re-write how the network and how the class are structured from pyrok...

Because he is good... But his infrastructure was a mess !

Btw nice projet :)

I've got to say, me and Guil trashed the entire network side of the code and content management as it was just a mess. I personally believe Pyrok was converting c++ source to c#. But hey I'll never be able to prove it, just don't follow his example because (C++) innovate, c# can do just as good if not better and let's be real there is no true advantage to running on Linux. I can port to Mono and run on linux just as easily :P

P.S. That's why we aimed our emu @ 6.2 because there is an available 7.1 sframe pdb and 6.2 game-server pdb. Makes things immensely easier :P

Good luck.

But performance speed from C++ and C# is not negligible.

Yeah, he was mostly trying to build the Emu based on the Code he got from the official game server.
That isn't/wasn't the best decision, I'd agree, but I think it was the quickest way of getting the Emu running, and thinking back about how often he was around, I think this was the best way for him.
Also the code was supposed to be open source too, mostly as a base I guess, but as we can see, the project got dropped sadly.

@Smoke Yeah, running C# on Linux via Mono is an idea, but I don't really think that's the best solution. Mono might be good (haven't worked with it, but I've heard lots about it), but I don't think that creating a program which needs to calculate a shit ton as well as handle hundreds of connections in Mono is a good choice.
Well, let's say "better safe than sorry" tho, that's why I decided to hop on the "C++ train".
Oh, and I'd take Linux over Windows as a server every time I can. Simply because Linux as a server is million times better than Windows, that's just my opinion.

Everyone likes to use that tired trope of 'Oh c++ can handle blah blah blah blah better' this is just that, conjecture. C# has show in many situations to be just as reliable in calculation intensive and network intensive operations. You simply have to know what you're doing and not throw a million assemblies at a JIT based program. Keep the calls down to base libraries instead of wrappers (unless the wrapper has proven to be faster/more efficient) and hate to disagree with you on your point Gr4ph0s but...without setting off another infernal c++ vs c# debate (the net is littered with them already) but you in many senses are wrong :)

Let's just put it this way, c# is better at higher end function, the only true advantage that c++ has over c# is pointer management aka raw memory management, but this comes as somewhat of a double edged sword, because where you have that raw and unrestricted access/management of memory you when you code thousands upon thousands of lines of code across 100 classes, you will run into memory leaks and memory over-runs without a dedicated qa team-member (ugh).

While in c# many of these hassles are tidied up by GC (BUT DROW GC IS BLER BLER BLER.) Sure GC can be a pain unless you know how to turn it's knobs...OHHH BABY. I have proven my point by writing a rdb editor that vastly outperforms it's c++ counterpart. Yes, I have beaten glandu's editor speed. (Not a point of pride, just goes to show with good dedication and knowledge c# can contend with and in some cases surpass c++.

TL;DR

Don't let preconceived notions about a code platform shy you away from obvious advantages, also...I see cheaper linux hosting being an advantage but it's not really a deal breaker for me.

Eitherway much luck and I hope to see your emulator make it to the end, this community needs more variation, a c++ emu a c# emu, two different epic emu's a CLIENT emu. If I can ever be of use (unlikely as I don't know C++) just drop me a line, busy constantly but I'm never too far.

Quote:

Originally Posted by SilentWisdom Everyone likes to use that tired trope of 'Oh c++ can handle blah blah blah blah better' this is just that, conjecture. C# has show in many situations to be just as reliable in calculation intensive and network intensive operations. You simply have to know what you're doing and not throw a million assemblies at a JIT based program. Keep the calls down to base libraries instead of wrappers (unless the wrapper has proven to be faster/more efficient) and hate to disagree with you on your point Gr4ph0s but...without setting off another infernal c++ vs c# debate (the net is littered with them already) but you in many senses are wrong :) Let's just put it this way, c# is better at higher end function, the only true advantage that c++ has over c# is pointer management aka raw memory management, but this comes as somewhat of a double edged sword, because where you have that raw and unrestricted access/management of memory you when you code thousands upon thousands of lines of code across 100 classes, you will run into memory leaks and memory over-runs without a dedicated qa team-member (ugh). While in c# many of these hassles are tidied up by GC (BUT DROW GC IS BLER BLER BLER.) Sure GC can be a pain unless you know how to turn it's knobs...OHHH BABY. I have proven my point by writing a rdb editor that vastly outperforms it's c++ counterpart. Yes, I have beaten glandu's editor speed. (Not a point of pride, just goes to show with good dedication and knowledge c# can contend with and in some cases surpass c++. TL;DR Don't let preconceived notions about a code platform shy you away from obvious advantages, also...I see cheaper linux hosting being an advantage but it's not really a deal breaker for me.

[Only registered and activated users can see links. Click Here To Register...]
I don't mind both languages, but after all, as I said earlier, I'd rather do something I know instead of developing everything with Mono C# and then falling on my face because it's not working as intended. ;)

Quote:

Originally Posted by SilentWisdom [...]a CLIENT emu.

If I just weren't too lazy to read into 3D Development (OpenGL/DirectX)....
You know how many times I was about to do that but dropped that just because I didn't want to bother with the models? Jeez, that's almost insane.

Quote:

Originally Posted by SilentWisdom If I can ever be of use (unlikely as I don't know C++) just drop me a line, busy constantly but I'm never too far.

You should've received a PM from me a few days ago, but well... :P

Quote:

P.S. That's why we aimed our emu @ 6.2 because there is an available 7.1 sframe pdb and 6.2 game-server pdb. Makes things immensely easier :P

Yeah, that's exactly why I want an unpacked SFrame. Armadillo prevents me from debugging the SFrame and this is just plain dumb.
I'm currently working with the 5.2(?) Herlock and its PDB but some things changed drastically.
I'm happy that I got the inventory working by now, that was a pain in the ass just doing trial-and-error debugging until I got it to work.
Same thing applies to the warp packet - for some reason the SFrame crashes as soon as it receives the warp packet, it doesn't matter what I'm sending - it just crashes. And I literally have no idea why. I gave up on that part and I'm hoping right now that somehow I'll be able to get a copy of an unpacked SFrame to get the structure of that packet.

if you get the link for the client (or at least sframe + all dll loaded) upload it, I could give a shot into this for unpacking it ;)

Moreover remove hackshield in this epic is pretty easy as I remember you just need to nop the call of the dll.

Quote:

Originally Posted by gr4ph0s if you get the link for the client (or at least sframe + all dll loaded) upload it, I could give a shot into this for unpacking it ;) Moreover remove hackshield in this epic is pretty easy as I remember you just need to nop the call of the dll.

I reuploaded it to mediafire a few days ago, but the client I'm using is the one linked in the rappelzdc: [Only registered and activated users can see links. Click Here To Register...]

Glad to see this is happening! If I were to do it again I'd probably stick with C++ simply because I've worked with it for years before Rappelz existed. I decided to do most of my tools in C# as a learning experience. There were definitely parts that were done in a "C++" way that should have been done differently. My plan for the emu originally was to get it working and then basically redo it once I better understood how things worked internally.

I'll take a look when I'm get home and see if I have anything for Epic 4 but I think the earliest server I have is 5. What I did to help figure out the packets is create a thunk server that just took traffic from the client and server, dumped the packet info to a log, and passed it on to the real destination. It came in real handy when trying to determine what changed between epics, etc. Although that may not help as much in this case since there isn't an Epic 4 server to run it against.

Nice to see you still lurking Pyrok, I have a good base knowledge of c++ (in theory) but I don't have much time to actually put it into practice. I am however still going to code on the 6.2 emu in my spare time. That being said I think it's great to see an active dialogue about emulators (be they c++ or c#) I think if we could get a good documentation going about packet, packet management, good networking practices, communication protocol, encryption and more it would go a long way to maybe putting a spark back in this community.

Anyway, bed time. Gotta work tonight. Blerggg :(

Wow, I'm quite surprised that you're still around, great to see you again!

Quote:

Originally Posted by Pyrok What I did to help figure out the packets is create a thunk server that just took traffic from the client and server, dumped the packet info to a log, and passed it on to the real destination. It came in real handy when trying to determine what changed between epics, etc. Although that may not help as much in this case since there isn't an Epic 4 server to run it against.

Yeah, I did the same with the Epic 5 server files (that was a "shorter version" of the XChat I released earler, I got some interesting stuff from an IDA dump and the packets itself, but sadly nothing to the warp command as example.

coming pserver e4? :D

If you have any issue tell me ;)
[Only registered and activated users can see links. Click Here To Register...]

SFrame_unpacked_ => the untouched unpacked
SFrame_unpacked_noHackShield => I remove the loading of the DLL normally it should fix it but since I can't test it on a server I can't be sure.

Btw I also unpacked the EhSvc.dll (hackshied dll) she is lunched with dat in argument 1C7DF61A08F7C881CECEBA22

Btw gangor have developped a client who listen all connection and it print all packet information to a console. He use the auth system from glandu so he his able to log into all auth version (normally ^^), so if you are interested feel free to ask ;)

Funny fact the sframe seem to date to the 19 Jully 2007. 9 Year ago...

Quote:

Originally Posted by gr4ph0s If you have any issue tell me ;) [Only registered and activated users can see links. Click Here To Register...] SFrame_unpacked_ => the untouched unpacked SFrame_unpacked_noHackShield => I remove the loading of the DLL normally it should fix it but since I can't test it on a server I can't be sure. Btw gangor have developped a client who listen all connection and it print all packet information to a console. He use the auth system from glandu so he his able to log into all auth version (normally ^^), so if you are interested feel free to ask ;)

Oh jesus, you're a god!
How in the hell were you able to do that this fast? I literally threw everything on that stuff I had and I didn't even came close to unpacking it (note: I suck at such things, but still).
Thanks! That'll help a lot!

Quote:

Originally Posted by gr4ph0s Funny fact the sframe seem to date to the 19 Jully 2007. 9 Year ago...

We're getting old. :/ 2007, it's like it was last week :D