Discussion Server Packets (Information Only)

[AccessDenied]

Hello i just want to ask an information from experienced members.

When we say in a game "change packets" lets say we have a game that its version is 2.0

but then a client come with 3.0 version so we need change our server Packets to version 3.0

what does it mean?

 

I'm not familiar with it so if someone could give a nice explanation i would appreciate.

Thanks a lot!

[Tryskell]

L2 uses particular protocols, depending generally about chronicle, but not only (Interlude client got few internal updates, and so different clients with different protocols).

 

If packets definition have been edited meanwhile by NCSoft, you have to care about the changes (which can go to new packets, different opcode for packet, or packet structure edition).

 

It goes generally in a single way : addition of a packet, packets reorganization and addition of features on existing packet. It's pretty rare than an existing packet becomes unused later on.

 

So for example, from C3 to C4, since new features come, you got for example addition of augmentation information on item related packet, on inventory, etc. When they introduced CP system, they had to edit existing packets to handle CP bar information.

 

Etc etc. About why they edit opcodes, I don't know. Probably reorganization, no clue.

 

Using an outdated client can lead to different fails, invalid/not good packet sent (like you want to send login packet but ends on clan related ones because opcode has been edited meanwhile).

Edited December 4, 2015 by Tryskell

[AccessDenied]

L2 uses particular protocols, depending generally about chronicle, but not only (Interlude client got few internal updates, and so different clients with different protocols).

 

If packets definition have been edited meanwhile by NCSoft, you have to care about the changes (which can go to new packets, different opcode for packet, or packet structure edition).

 

It goes generally in a single way : addition of a packet, packets reorganization and addition of features on existing packet. It's pretty rare than an existing packet becomes unused later on.

 

So for example, from C3 to C4, since new features come, you got for example addition of augmentation information on item related packet, on inventory, etc. When they introduced CP system, they had to edit existing packets to handle CP bar information.

 

Etc etc. About why they edit opcodes, I don't know. Probably reorganization, no clue.

 

Using an outdated client can lead to different fails, invalid/not good packet sent (like you want to send login packet but ends on clan related ones because opcode has been edited meanwhile).

Alright, thanks for the introduce but about the part of downgrade or upgrade lets say i want to make a server

from C6 to c4 what exactly i have to edit (what i touch) to adjust these packets?

Also then these packets are the lines i saw   ReadD(); andcouldnt understand what it is  

 

Example lets say we work on PHP and you ask me "how it works when i click the Login button" i tell you it does this and this

but you're actualy interest in the behind part to create this *.php file with the checks and redirect to a site. 

Edited December 4, 2015 by AccessDenied

[Tryskell]

MMOCore reads it, each packet got a goal and particular infos and/or checks. It's the way client and server communicates and share informations.

[AccessDenied]

MMOCore reads it, each packet got a goal and particular infos and/or checks. It's the way client and server communicates and share informations.

So i understood but in more practical way when you have a free source lets say from Joey (L2java)

which has scripts in different project (Datapack) and core into another (Core)

is there a file that does those checks.

 

I want try in other words manualy downgrade a X chronicle to another or upgrade it.

I don't care which chronicle will be i just want to see it happen, so this mean i dont care for codes, quests or whatever it has inside.

With a search i did i saw people asking this but their answers were kinda no finished like "use wireshark to check what clients sends e.t.c"

which is not helpful.

 

Again im asking the practical way so i can do it, the file maybe that does this or a bit more info.

Thanks

[Tryskell]

It's way beyond your own knowledge. It's not a specific file to edit, it's the whole sources to edit, most notably all packets opcodes and packets structure (simply to make it working). You got features to delete and datapack to edit.

 

About scripts I didn't get it. It's up to scripts engine to do the work, on aCis we reworked it to handle scripts on core, but most packs load them from dp. And you have to edit all files, or adapt the script engine + Quest class (which leads the behavior of any quest and script). Which isn't even related to chronicle downgrade.

 

There isn't a magical file where you edit a number and it edits your source from IL to C3. It's similar to create a .txt and rename it ClickMeToEarn10000Euros.exe. It won't work.

Edited December 4, 2015 by Tryskell

[AccessDenied]

It's way beyond your own knowledge. It's not a specific file to edit, it's the whole sources to edit, most notably all packets opcodes and packets structure (simply to make it working). You got features to delete and datapack to edit.

 

About scripts I didn't get it. It's up to scripts engine to do the work, on aCis we reworked it to handle scripts on core, but most packs load them from dp. And you have to edit all files, or adapt the script engine + Quest class (which leads the behavior of any quest and script). Which isn't even related to chronicle downgrade.

 

There isn't a magical file where you edit a number and it edits your source from IL to C3. It's similar to create a .txt and rename it ClickMeToEarn10000Euros.exe. It won't work.

Thank you, yes you're right that is beyond my knowledge but so far whatever i learned i did it alone by searching

-Php, ajax, Aion (java), l2j (currently)

so is not bad to dig a bit inside to check also the way that client-server communicate. thanks again Tryskel ill search it alone

[*real*savormix]

You can always take a look at NetPro. Of course, the C5 and IL packets I didn't had a chance to take care of, as Underground arrived, and I was sidetracked to move the application to JavaFX due to certain JVM argument issues with Swing, but you can find complete C4 packet structures in it. For example, C4 CharInfo

 

MOREOVER, you can use the [menu bar] -> Packets -> Explain… function to see how a specific byte array will look to the C4 client.

 

Additionally, here's a list of all C4 packet opcodes.

 

And a quick overview:

 

<byte> is equivalent to readC (client packets) writeC (server packets)

<word> is equivalent to readH (client packets) writeH (server packets)

<dword> is equivalent to readD (client packets) writeD (server packets)

<qword> is equivalent to readQ (client packets) writeQ (server packets)

<double> is equivalent to readF (client packets) writeF (server packets)

<string> is equivalent to readS (client packets) writeS (server packets)

Edited December 5, 2015 by _dev_

[AccessDenied]

You can always take a look at NetPro. Of course, the C5 and IL packets I didn't had a chance to take care of, as Underground arrived, and I was sidetracked to move the application to JavaFX due to certain JVM argument issues with Swing, but you can find complete C4 packet structures in it. For example, C4 CharInfo

 

MOREOVER, you can use the [menu bar] -> Packets -> Explain… function to see how a specific byte array will look to the C4 client.

 

Additionally, here's a list of all C4 packet opcodes.

 

And a quick overview:

 

<byte> is equivalent to readC (client packets) writeC (server packets)

<word> is equivalent to readH (client packets) writeH (server packets)

<dword> is equivalent to readD (client packets) writeD (server packets)

<qword> is equivalent to readQ (client packets) writeQ (server packets)

<double> is equivalent to readF (client packets) writeF (server packets)

<string> is equivalent to readS (client packets) writeS (server packets)

Thanks for that, i am more interest in understand how a texture how a model in other words the client communicate with a server and controlled using these packets

than just code in server side without know how handlers work behind the scene.

 

I used to do some gaming develop such as Unreal and i am still up to but again even if you work on it it doesnt really make you understand how client work with the code part, where they meet. I always liked to dig inside things and know how they work even if for now still this does not make big sense to make.

 

Well thanks again for the informations, helps a bit.

[*real*savormix]

It's basic (by this, I mean pretty much direct) application of EDA (Event Driven Architecture).

 

Server is responsible for presenting the dynamic state of the world to the client (the player's character data, including location, equipment, pledge, etc.), other player characters, npc data, and so on and so on. Server does this all the time without any client involvement.

 

Client is responsible for issuing very specific requests to the server. Target selection, movement, item use, or simpler requests, such as 'leave my pledge' or 'show my item list' contain the bare minimum data for the server to understand what the user wants to do.

Target selection will depend on what world objects the server has supplied to the client. Therefore, client will send a target request with an object's identifier (note: in reality, there is no target request, there are action/attack requests, first invocation of each is assumed to be the target selection request, and all further - follow[PC] or interact[NPC]/attack requests, therefore additional information is sent, e.g. SHIFT state (interact/attack without moving towards)).

 

Movement request is filled in with client-side data about the target point XYZ.

 

Item use is similar as target selection.

 

Leave my pledge or show my item list requests require no additional data, thus they are implemented as a packet with a designated opcode and no other data to be transferred.

 

That's how things work at the very essentials. As far as implementation is concerned, there are various ways to implement it, most popular designs being session=thread, socket multiplexing and (more CPU intensive for higher peak throughput) non-blocking socket multiplexing.

[AccessDenied]

It's basic (by this, I mean pretty much direct) application of EDA (Event Driven Architecture).

 

Server is responsible for presenting the dynamic state of the world to the client (the player's character data, including location, equipment, pledge, etc.), other player characters, npc data, and so on and so on. Server does this all the time without any client involvement.

 

Client is responsible for issuing very specific requests to the server. Target selection, movement, item use, or simpler requests, such as 'leave my pledge' or 'show my item list' contain the bare minimum data for the server to understand what the user wants to do.

Target selection will depend on what world objects the server has supplied to the client. Therefore, client will send a target request with an object's identifier (note: in reality, there is no target request, there are action/attack requests, first invocation of each is assumed to be the target selection request, and all further - follow[PC] or interact[NPC]/attack requests, therefore additional information is sent, e.g. SHIFT state (interact/attack without moving towards)).

 

Movement request is filled in with client-side data about the target point XYZ.

 

Item use is similar as target selection.

 

Leave my pledge or show my item list requests require no additional data, thus they are implemented as a packet with a designated opcode and no other data to be transferred.

 

That's how things work at the very essentials. As far as implementation is concerned, there are various ways to implement it, most popular designs being session=thread, socket multiplexing and (more CPU intensive for higher peak throughput) non-blocking socket multiplexing.

Well yes i noticed, right now i'm running Lineage 2 without server so it can run without any server required, but afcourse you cant

talk to npc's or do things like equip armor e.t.c.

I noticed that. Maybe can you be a bit more specific and give me an example like lets say something like handlers in datapack

or more specific the keys that you press like control to attack that server read as _forceControl. 

Thanks

[*real*savormix]

Development mode is used solely to test client-side features, like animations, effects/shaders, move around in the game world, review UI, etc. It will not give you any insight into how the MMO part of the game is designed. It helps client feature developers and UI designers, as well as related QA; that's the whole purpose of that mode (okay, okay, it can allow you to generate geodata and help with a few other things).

 

Modifiers are simply transferred as extra data with an actual request (where applicable).

 

So if you have an item use request, which would be 0x14 RequestUseItem, as extra data you will have the item object identifier and CTRL state.

If you have a special action use request 0x45 RequestActionUse (special action example: servitor attack, servitor skill, pet attack, pet skill, etc.), as extra data you will have the concrete action to be performed (e.g. Mech. Cannon, Parasite Burst, etc.), SHIFT state and CTRL state.

 

Handlers in datapack do not serve any purpose in client/server communication scheme.

Typically, a handler would be fired as a direct result from a currently executed AI desire, which in turn may have been added either by an AI script, or, in special cases, by some specific feature implementation.

 

Of course, you will not find this in l2j. Still, even in l2j, the core-side packet handlers first evaluate each request, and if it is deemed necessary, then one of the datapack handlers is called (after extracting all contextual data needed for that DP handler).

[An4rchy]

Packets are a way to handle the information transfered from server -> client and client  -> server. For example, let's say you press F3 and you request to cast a skill. The client sends this request to the server (RequestMagicSkillUse). The server makes all the necessary checks to see if this is possible (the casting of the specific skill), like check if the player has this skill, if the target is invalid etc. Then, if all the checks are passed, the server sends to the client AND the clients near the client a packet to start the animation and effects of the skill (the damage and effects are calculated in the server and not in the client) (MagicSkillUse).

This is a simple (and not complete I didn't include every packet) communication between the server and the client in order to handle the casting of a skill.

 

Now the writeD, writeS etc stuff you see in the server packets, is the information the client expects to receive from the server, in the specific order. You cannot add more information (actually I think you can but nothing will happen) because the client is not prepared to use this information. For example, the MagicSkillUse packet sends this information: writeC(0x48) - This is the opcode of the packet if I am not mistaken, an identifier of the packet so the client knows what information it is receiving, writeD(_charObjId) - The id of the player casting this skill, so that the animations play on the correct entity (player), writeD(_targetId) - The id of the target that the player is casting the skill on, so that the effects are shown on the correct entity (player), writeD(_skillId) - The id of the skill the player is casting, so that the correct animations and effects are shown, writeD(_skillLvl) - I am not sure why would the client need that, but it is the level of the skill, writeD(_hitTime) - The amount of time the player will be casting this skill for before it finishes, this is used to time the steps in the animation I guess, so that it is not too fast or too slow and it corresponds the players casting/attack speed, etc etc...

 

This is just a very bas​ic explanation of how the communication and the data transfer works, I hope it helped.

[AccessDenied]

Packets are a way to handle the information transfered from server -> client and client  -> server. For example, let's say you press F3 and you request to cast a skill. The client sends this request to the server (RequestMagicSkillUse). The server makes all the necessary checks to see if this is possible (the casting of the specific skill), like check if the player has this skill, if the target is invalid etc. Then, if all the checks are passed, the server sends to the client AND the clients near the client a packet to start the animation and effects of the skill (the damage and effects are calculated in the server and not in the client) (MagicSkillUse).

This is a simple (and not complete I didn't include every packet) communication between the server and the client in order to handle the casting of a skill.

 

Now the writeD, writeS etc stuff you see in the server packets, is the information the client expects to receive from the server, in the specific order. You cannot add more information (actually I think you can but nothing will happen) because the client is not prepared to use this information. For example, the MagicSkillUse packet sends this information: writeC(0x48) - This is the opcode of the packet if I am not mistaken, an identifier of the packet so the client knows what information it is receiving, writeD(_charObjId) - The id of the player casting this skill, so that the animations play on the correct entity (player), writeD(_targetId) - The id of the target that the player is casting the skill on, so that the effects are shown on the correct entity (player), writeD(_skillId) - The id of the skill the player is casting, so that the correct animations and effects are shown, writeD(_skillLvl) - I am not sure why would the client need that, but it is the level of the skill, writeD(_hitTime) - The amount of time the player will be casting this skill for before it finishes, this is used to time the steps in the animation I guess, so that it is not too fast or too slow and it corresponds the players casting/attack speed, etc etc...

 

This is just a very bas​ic explanation of how the communication and the data transfer works, I hope it helped.

ah i see, okey i got it somehow

 

So every file like RequestBypassToServer read specific packets sended by client 

and the method that does this job is the

 

protected void readImpl()

{

}

 

which is override actualy so declared to the parent class.

Still the opacity of it is low like 30% but i start get it even if i cant adjust or do anything yet cause i lack in knowledge

[UnAfraid]

Etc etc. About why they edit opcodes, I don't know. Probably reorganization, no clue.

Opcode changes occurs mostly when new packets are added in-between other packets because all the packets are stored in array, their index is their opcode and when new packet is added in-between those indexes gets shifted