Register for your free account! | Forgot your password?

Go Back   elitepvpers > MMORPGs > Rappelz > Rappelz Private Server
You last visited: Today at 06:44

  • Please register to post and access all features, it's quick, easy and FREE!

 

[WIP] Rappelz Epic 4: Revolution Emulator

Reply
 
Old   #1



 
elite*gold: 0
Join Date: May 2011
Posts: 4,826
Received Thanks: 3,206
[WIP] Rappelz Epic 4: Revolution Emulator

EDIT:
PLEASE GO HERE FOR AN UPDATE


Good evening my friends,

Edit: I'm removing the small talk here to get straight to the point:




Feel free to contribute to the Emulator or join the Discord to get access to an up2date Testserver
Read through the thread for more information


Thanks for reading,

Xijezu



Xijezu is offline  
Thanks
10 Users
Old   #2
 
elite*gold: 0
Join Date: Aug 2012
Posts: 312
Received Thanks: 252
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


gr4ph0s is offline  
Old   #3
 
elite*gold: 0
Join Date: Jul 2015
Posts: 273
Received Thanks: 365
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.
SilentWisdom is online now  
Old   #4
 
elite*gold: 0
Join Date: Aug 2012
Posts: 312
Received Thanks: 252
But performance speed from C++ and C# is not negligible.


gr4ph0s is offline  
Thanks
1 User
Old   #5



 
elite*gold: 0
Join Date: May 2011
Posts: 4,826
Received Thanks: 3,206
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 **** 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.
Xijezu is offline  
Thanks
1 User
Old   #6
 
elite*gold: 0
Join Date: Jul 2015
Posts: 273
Received Thanks: 365
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.
SilentWisdom is online now  
Old   #7



 
elite*gold: 0
Join Date: May 2011
Posts: 4,826
Received Thanks: 3,206
Quote:
Originally Posted by SilentWisdom View Post
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.

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 View Post
[...]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 View Post
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.
Xijezu is offline  
Old   #8
 
elite*gold: 0
Join Date: Aug 2012
Posts: 312
Received Thanks: 252
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.
gr4ph0s is offline  
Old   #9



 
elite*gold: 0
Join Date: May 2011
Posts: 4,826
Received Thanks: 3,206
Quote:
Originally Posted by gr4ph0s View Post
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:
Xijezu is offline  
Old   #10
 
elite*gold: 0
Join Date: Oct 2010
Posts: 297
Received Thanks: 449
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.
Pyrok is offline  
Thanks
6 Users
Old   #11
 
elite*gold: 0
Join Date: Jul 2015
Posts: 273
Received Thanks: 365
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
SilentWisdom is online now  
Old   #12



 
elite*gold: 0
Join Date: May 2011
Posts: 4,826
Received Thanks: 3,206
Wow, I'm quite surprised that you're still around, great to see you again!
Quote:
Originally Posted by Pyrok View Post
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.
Xijezu is offline  
Old   #13
 
elite*gold: 0
Join Date: Jan 2013
Posts: 94
Received Thanks: 3
coming pserver e4?
Cocahaha is offline  
Old   #14
 
elite*gold: 0
Join Date: Aug 2012
Posts: 312
Received Thanks: 252
If you have any issue tell me


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...
gr4ph0s is offline  
Thanks
4 Users
Old   #15



 
elite*gold: 0
Join Date: May 2011
Posts: 4,826
Received Thanks: 3,206
Quote:
Originally Posted by gr4ph0s View Post
If you have any issue tell me


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 View Post
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


Xijezu is offline  
Thanks
1 User
Reply



« Previous Thread | Next Thread »



All times are GMT +1. The time now is 06:44.


Powered by vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.

Support | Contact Us | FAQ | Advertising | Privacy Policy | Abuse
Copyright ©2018 elitepvpers All Rights Reserved.