[Question] Packets in WorldConquer

[Flake]

Hello everyone, I'm here again I'm using the source WorldConquer v5103 and I'm converting to 5187, I have some doubts maybe someone can show me a way.

I'm guiding myself a lot with the comet 5187 project, in the world conquer source the package structure makes me a little confused in relation to the comet, example:

public MsgSynMember() : base(PacketType.GUILD_MEMBER_INFORMATION, 36, 28)

I would like to know what the value 36 and 28 represent, and about resizing, the name already says, but it is used with which itution?

I've already researched in other sources, most of them totally change the package system, what makes them different from the other in terms of organization and the term easy and difficult to use?

- https://ibb.co/zZFr1tf

In this first photo Player2 is in the correct ninja position and Player1's helmet does not appear.

- https://ibb.co/1876hcK

In the second picture Player1 is wearing the helmet and see Player2 in the trojan position. (Offsett Helmet 30)

When player1 stays away player2 doesn't see him in away as if it were wrong offsets but I put it equal to the project comet and when he observes the player gives wrong level values, bp reborns... Isn't this all MsgPlayer related? This puzzle is cool.

Thank you all for the attention!

[Spirited]

Hey Flake! To answer your question about the two values 36 and 28, those are both lengths. Starting with patch 5018, a packet footer was added to each packet (the string "TQClient" or "TQServer" to indicate where the packet originated from). For whatever reason, TQ decided to not include the length of the string in the total length of the packet (the unsigned short at offset 0). So if the actual packet length is 36 bytes with the footer included, the length written at offset 0 would be 28 (36 - the length of the string). In Comet, this is handled implicitly (meaning you don't have to set both lengths). WorldConquer's 5187 patch predates Comet's 5187 branch, which is why there's the disparity.

In terms of different packet system techniques, I prefer using a Strategy pattern. That's where you have declared virtual methods in the base class that get defined in the parent class and executed by some execution engine (the packet processor in Comet). To me, this simplifies the operations of the server and provides better readability and organization. It's really all that binary protocols boil down to: decode, encode, and execute.

[Flake]

Hey Flake! To answer your question about the two values 36 and 28, those are both lengths. Starting with patch 5018, a packet footer was added to each packet (the string "TQClient" or "TQServer" to indicate where the packet originated from). For whatever reason, TQ decided to not include the length of the string in the total length of the packet (the unsigned short at offset 0). So if the actual packet length is 36 bytes with the footer included, the length written at offset 0 would be 28 (36 - the length of the string). In Comet, this is handled implicitly (meaning you don't have to set both lengths). WorldConquer's 5187 patch predates Comet's 5187 branch, which is why there's the disparity.

In terms of different packet system techniques, I prefer using a Strategy pattern. That's where you have declared virtual methods in the base class that get defined in the parent class and executed by some execution engine (the packet processor in Comet). To me, this simplifies the operations of the server and provides better readability and organization. It's really all that binary protocols boil down to: decode, encode, and execute.

Interesting, I had already looked at some topics about packages but I was very confused about these two values ​​in 1 package, thank you very much I'm managing to learn little by little!