- Joined
- Jun 2, 2006
- Messages
- 344
- Reaction score
- 123
Ok, seeing as this section has calmed down on the matter of flaming/fighting/disorganization/ranting/censoring/stupidity I somehow found myself compelled to contribute something to this community, hoping it will grow like the MU community. Or maybe I just want to see how this goes... Lol...
So I decided to create this pretty basic guide that hopefully will teach something to those who know a bit of C/C++ but dont have a clue of where to start in the vast universe (maybe I'm exaggerating) that is this game's source.
I must say that this is in development and I will be posting updates as I make them.
I also reserve the right for myself to only do this when I feel like it, I will not take this as an obligation or something I have to do.
Here I will approach the very basics such as:
But I must warn you, to be able to understand anything at all here you must have prior knowledge of objects, classes, pointers and basic stuff, as well as the C++ language syntax.
I also heavily recommend you study the hungarian notation as it will make the understanding of variable names MUCH easier.
The 8 Flyff Pillars
So, as you might have noticed while running your server/testserver Flyff runs based on 8 programs, which are:
WorldServer:
Well, this is where stuff happens, here is where the player objects, masquerpet objects and everything else is, as well as where they interact. This is also why this program might take a long while to load on some machines, it usually has over 9000 objects! (not kidding)
For example: if a masquerpet attacks you, your life will first be reduced in the WorldServer and just then a packet will be sent to the client to update your hp (actually its a bit more complex than this, but I'm not gonna enter in detail).
This is done so that the client will have as little as possible control over what is actually happening.
Imagine if I could use a memory editor to make my HP one million in my client and it updated the WorldServer so that it would be your true HP… That would mean that anyone with little knowledge would be able to easily hack the server to have infinite HP, MP, Items or worse.
But thankfully the client and the server are built in a way that the client will have as little as possible influence in the server. To illustrate this, think about when you attack a masquerpet… When you right-click it you're not actually attacking it, you're telling the server "I want to attack masquerpet X". Then the server proceeds to see if thats possible, and if it is the attack procs on the server before and just then a packet is sent to the client to inform what happened (if the attack happened or not).
However as all this happens within milliseconds, it is barely noticeable except when you're having lots of lag (the attack animation will begin but no damage will be done, cuz the server didn't send the damage packets).
Neuz:
The Neuz is obviously the client, but going a little bit deeper into that, I would define it as "A plataform for data visualisation and choice-making for the player". And what does that mean? Well, basically that very little happens in the client, it is just a way of showing to the user what is going on and letting him make decisions based on what he is seeing.
Now you might be asking yourself why am I emphasizing this so hard, and the answer to that would be simply because I want you to have this mindset when creating your own stuff, be it events, systems, edits, whatever, so that whatever you do will be as safe as possible.
One thing you have to have in mind is that the user is stupid, and I dont mean it in a bad way, but more often than not users will have unpredictable behaviors and try to exploit whatever they can, so security is never enough. Give them as little control as possible on whatever you do, and make sure that that little control you are giving them is well secured by being supervised by the server all the times.
Two good examples of that are the chat crash where you would type "!9999999999998" and the penya hack where you would send a mail with 33 nines worth of penya. Why on earth would someone ever try that? I don't know, but what I know is that it happens, as I said before, more often than not.
I'm not asking you to be a god, no one is perfect, all I'm asking is that you don't overlook something just because you think it might not happen.
The CMover class
Now you must be asking why I decided to talk about this next and not something else. Well, to be honest, because this is the class you will be using the most while doing your stuff.
You will always have to use this class for almost everything and I'll tell you why. Because basically ANYTHING that moves is a CMover or at least has a CMover object to represent it, hence the name. (except for moving scenario objects)
This includes players, masquerpets, npcs, pets, etcetera.
Of course that as it can be so many things, there are variables that wont be used in some cases, such as mana on masquerpets for example.
Here are some examples of variables this class has:
(I will only explain the non-obviously named ones)
And some useful functions:
So, basically, get used to using this class, you will see it a ton of times while doing anything that has any interaction with players, monsters or npcs.
I will tell you more about it in the Good Practices section where I will also explain how are these objects stored, what is the meaning to all those "->"'s and some other stuff such as object casting for example.
Also, note that these objects are used in both the WorldServer AND the Neuz, meaning that they are the standard object to store mover data in both programs, however, there are some functions and variables that wont make a difference if altered client-sidedly. (mainly because of what I explained in the chapter "The 8 Flyff Pillars")
I feel like I have left a lot behind in this chapter but again, this is a simple guide to start coding flyff's source.
I highly encourage you to search stuff, lose hours looking into things, trying to understand how these, that and those works, as this is how I learned EVERYTHING I know about flyff source editing.
Never have I read any guides on this nor have I asked anyone about stuff, so you should really try to learn stuff on your own, as this guide will spoonfeed you the least possible.
Also, I will go back to this chapter in other sections and maybe edit it if I feel the necessity to.
So I decided to create this pretty basic guide that hopefully will teach something to those who know a bit of C/C++ but dont have a clue of where to start in the vast universe (maybe I'm exaggerating) that is this game's source.
I must say that this is in development and I will be posting updates as I make them.
I also reserve the right for myself to only do this when I feel like it, I will not take this as an obligation or something I have to do.
Here I will approach the very basics such as:
- What do all those server programs do (account, cache, world, database, etc)
- The CMover class
- How to find stuff in the source
- Good practices
- Debugging
- Communication between server-client
- The CArchive class (how packet data is serialized)
- Chat commands
But I must warn you, to be able to understand anything at all here you must have prior knowledge of objects, classes, pointers and basic stuff, as well as the C++ language syntax.
I also heavily recommend you study the hungarian notation as it will make the understanding of variable names MUCH easier.
The 8 Flyff Pillars
So, as you might have noticed while running your server/testserver Flyff runs based on 8 programs, which are:
- Account Server
- Cache Server
- Database Server
- Certifier
- Core Server
- Login Server
- World Server
- Neuz
WorldServer:
Well, this is where stuff happens, here is where the player objects, masquerpet objects and everything else is, as well as where they interact. This is also why this program might take a long while to load on some machines, it usually has over 9000 objects! (not kidding)
For example: if a masquerpet attacks you, your life will first be reduced in the WorldServer and just then a packet will be sent to the client to update your hp (actually its a bit more complex than this, but I'm not gonna enter in detail).
This is done so that the client will have as little as possible control over what is actually happening.
Imagine if I could use a memory editor to make my HP one million in my client and it updated the WorldServer so that it would be your true HP… That would mean that anyone with little knowledge would be able to easily hack the server to have infinite HP, MP, Items or worse.
But thankfully the client and the server are built in a way that the client will have as little as possible influence in the server. To illustrate this, think about when you attack a masquerpet… When you right-click it you're not actually attacking it, you're telling the server "I want to attack masquerpet X". Then the server proceeds to see if thats possible, and if it is the attack procs on the server before and just then a packet is sent to the client to inform what happened (if the attack happened or not).
However as all this happens within milliseconds, it is barely noticeable except when you're having lots of lag (the attack animation will begin but no damage will be done, cuz the server didn't send the damage packets).
Neuz:
The Neuz is obviously the client, but going a little bit deeper into that, I would define it as "A plataform for data visualisation and choice-making for the player". And what does that mean? Well, basically that very little happens in the client, it is just a way of showing to the user what is going on and letting him make decisions based on what he is seeing.
Now you might be asking yourself why am I emphasizing this so hard, and the answer to that would be simply because I want you to have this mindset when creating your own stuff, be it events, systems, edits, whatever, so that whatever you do will be as safe as possible.
One thing you have to have in mind is that the user is stupid, and I dont mean it in a bad way, but more often than not users will have unpredictable behaviors and try to exploit whatever they can, so security is never enough. Give them as little control as possible on whatever you do, and make sure that that little control you are giving them is well secured by being supervised by the server all the times.
Two good examples of that are the chat crash where you would type "!9999999999998" and the penya hack where you would send a mail with 33 nines worth of penya. Why on earth would someone ever try that? I don't know, but what I know is that it happens, as I said before, more often than not.
I'm not asking you to be a god, no one is perfect, all I'm asking is that you don't overlook something just because you think it might not happen.
The CMover class
Now you must be asking why I decided to talk about this next and not something else. Well, to be honest, because this is the class you will be using the most while doing your stuff.
You will always have to use this class for almost everything and I'll tell you why. Because basically ANYTHING that moves is a CMover or at least has a CMover object to represent it, hence the name. (except for moving scenario objects)
This includes players, masquerpets, npcs, pets, etcetera.
Of course that as it can be so many things, there are variables that wont be used in some cases, such as mana on masquerpets for example.
Here are some examples of variables this class has:
(I will only explain the non-obviously named ones)
PHP:
m_nHitPoint
m_nManaPoint
m_nFatiguePoint
m_vDestPos
// Vector with coordinates X,Y,Z of the of the destination of this CMover in the space.
m_nRemainGP
// Remaining skill points
m_nJob
m_szName
m_nStr
m_nSta
m_nDex
m_nInt
m_nLevel
m_nExp1And some useful functions:
PHP:
GetName( BOOL bNickname )
// Gets the name of the CMover, obviously.
HasBuffByIk3( DWORD dwIk3 )
// Checks whether the CMover has a determinate buff by the buffs Id.
// Id example: IK3_ANGEL_BUFF or pItemProp->dwItemKind3
DoDie( CCtrl *pAttackCtrl, DWORD dwMsg )
// Now this one is very useful. This function is called everytime the
// mover dies, so you can add stuff to the end of it to do something
// after the mover dies.
// The best part of it is that it shows the last mover to attack the CMover,
// the one who delivered its killing blow, by receiving the argumment pAttackCtrl.
"I'm not gonna go much further into this, because this guide's purpose
is to teach you how to find yourself in the source and how to learn it
instead of just spoonfeeding".So, basically, get used to using this class, you will see it a ton of times while doing anything that has any interaction with players, monsters or npcs.
I will tell you more about it in the Good Practices section where I will also explain how are these objects stored, what is the meaning to all those "->"'s and some other stuff such as object casting for example.
Also, note that these objects are used in both the WorldServer AND the Neuz, meaning that they are the standard object to store mover data in both programs, however, there are some functions and variables that wont make a difference if altered client-sidedly. (mainly because of what I explained in the chapter "The 8 Flyff Pillars")
I feel like I have left a lot behind in this chapter but again, this is a simple guide to start coding flyff's source.
I highly encourage you to search stuff, lose hours looking into things, trying to understand how these, that and those works, as this is how I learned EVERYTHING I know about flyff source editing.
Never have I read any guides on this nor have I asked anyone about stuff, so you should really try to learn stuff on your own, as this guide will spoonfeed you the least possible.
Also, I will go back to this chapter in other sections and maybe edit it if I feel the necessity to.
Last edited:
