User(s) browsing this thread: 1 Guest(s)
Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Packets related to packets
02-12-2011, 12:42 AM (This post was last modified: 02-12-2011 01:15 AM by Parallax.)
Post: #1
Packets related to packets
So I'm trying to test out some more packets and a thought occurred to me: Do packets rely on other packets being sent first?

I only skimmed Rajko's notes on The Source wiki, but it seemed to me that a "view" packet (03) is like open doors, or a hardline may look unsynced to you, but be synced for someone else. Got it? So my main question for this topic is: Does it matter if I just send 04 packets (the GUI/Ack) to the client, or do I need to send a view first?

For example: assuming we understood the entirety of the 04 packet and/or the 03, if I'm syncing a hardline in Mara C, would I need to send the view (the target packet) before I send the sync packet with the hardline ID?

I guess a sub-question would be: What do I do with the IDs I get in client chat?
Find all posts by this user
Quote this message in a reply
02-12-2011, 02:16 AM
Post: #2
RE: Packets related to packets
I need a servant here Tongue.

Yes and... no.

Ambiguation disolved: You need to send packets first if they spawn and put a ID number to them.
For example, a player in your view needs to be spawned with ID "24" before you send a "ID 24 dances" packet.

The 04 / RPC protocol is not so needed, apart of the effects and gui, but the 03 should be in order to make movement and so "normal".

There is no need on your hardline example because it's probably a static object (like 222333444) and you set it to "1" on the synced hardline list/array. The packet would be something like "SET Hardline as Synced, 222333444".

On the other question, the id you are given, separated in object ID and sector ID has no use for users(players), but if you take that info i give you (Obj ID) and my sql for mxo world blocks, you can get some more "things to do".

Resuming, the sector ID of that object, matches my BlockID, together with the files from the Rajko's extractor leaves you with 5 files (from thousands? Big Grin) where you can search the "Obj ID" to see if it's there (it is) and how world files format is.

The big problem is that most of the Obj ID's are something like "0003" and believe me, that's not a good key to search in a binary file.

Maybe it's too complicated to express it so shortly... but.. that's it. Post again if you got any doubt.

A good cascade-question pack for packet testers with programming skills:
- What happens if you use python + pygame for key bindings for left/right arrow?
- What happens if you mix that with a thing that parses (read + remove spaces/linebreaks) logs files?
- What happens if now you mix the left/right events to "esend" commands to a console?
- What happens if after testing the above you like it too much? Tongue.

[Image: morphsig1.png]
[Image: ubd8457.png]
http://twitter.com/johnkussack [twitter]
Find all posts by this user
Quote this message in a reply
02-12-2011, 07:48 AM (This post was last modified: 02-12-2011 02:45 PM by Parallax.)
Post: #3
RE: Packets related to packets
Do we have 03 packets understood yet? MsgBlocks and counters and stuff? Or do they not have them because they're "unreliable"?

I've been playing around some more with Syncing, I got a couple packets that modify the hardline in my view, but I dunno how to figure out how to get the coordinates to put it in the right place etc. I figured out where it was going and saw the changes. But since it was 03, I'm assuming the whole sync sequence could be broken up over like 10 packets, mixed with other view data (I did spawn a couple NPCs)? I'll do some more poking around with reliable ones and see if I can figure out something different.
Find all posts by this user
Quote this message in a reply
02-12-2011, 08:59 PM (This post was last modified: 02-12-2011 09:03 PM by Morpheus.)
Post: #4
RE: Packets related to packets
Msgblock, counters and so are not 03 related but 04, aka RPC protocol.

03 involves some deserialization properties that, at the moment, only rajko figured out (and not fully).

Of course, to save bandwith, some of the packets can be "joined" together, as long as you respect the 03 rules. (including mixing 03 & 04 packets).

So yes for 04 knowledge, not for 03 yet.

Regarding to reliable ones an to save time, you can get my RPC sql pack and use the rpc command in the console, which has the same params as the others (command handle,data) and where you only need to paste the data column. The system does the msgcount and counters for you.

[Image: morphsig1.png]
[Image: ubd8457.png]
http://twitter.com/johnkussack [twitter]
Find all posts by this user
Quote this message in a reply
02-13-2011, 02:13 AM (This post was last modified: 02-13-2011 02:36 AM by Parallax.)
Post: #5
RE: Packets related to packets
(02-12-2011 08:59 PM)Morpheus Wrote:  Regarding to reliable ones an to save time, you can get my RPC sql pack and use the rpc command in the console...
Getting some "Duplicate" Errors when I set my Id as Primary Key, auto-increment. Is that just the way the database is?
Think I found the problem. I'll do some testing if this run doesn't turn out well. Got it. Testing commencing.
Find all posts by this user
Quote this message in a reply
02-13-2011, 05:06 AM
Post: #6
RE: Packets related to packets
Still confused...

The RPC packets are always in the header right? So..

Quote:send 020401 001d 01 2f 47 00 00 04 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1a 00 06 00 00 00 01 00 00 00 00 01 01 00 00 00 00 00 80 00 00 00 00 00 00 00 00 ;

The the one in bold is a RPC packet and no the one underlined



Also...

rajkosto Wrote:i explained 04 in a thread in "Packets World" forum before the huge downtime thing, now its gone because backup was before that
04 is easy, because its all just RPC (remote procedure call), like setxp (xp), and their subpackets and size is clearly defined
the problem is that 03 are serialized object view dumps (as a bitstream), with no defined size bytes, because the server expects the client to fully understand everything, and stop parsing when its done, then carry on parsing the rest of the packet (in most cases, 04 comes AFTER 03, so if we dont know 100% of 03, we cant just "skip" it and parse the 04, which contains reliable data that cant be skipped)
if 04 only came BEFORE 03, we would have no problem, as we could just parse the 04 at the beginning and skip 03 sections that we dont understand, its all unreliable data anyway, like position and velocity updates, that will be resent anyway

Like the example above (and the ones I've seen) there is no 03 located anywhere. Am I mistaken into how I look into this?
Find all posts by this user
Quote this message in a reply
02-13-2011, 07:17 AM (This post was last modified: 02-13-2011 07:47 AM by Parallax.)
Post: #7
RE: Packets related to packets
(02-13-2011 05:06 AM)Messana Wrote:  Still confused...
The the one in bold is a RPC packet and no the one underlined
rajkosto Wrote:(in most cases, 04 comes AFTER 03,
Like the example above (and the ones I've seen) there is no 03 located anywhere. Am I mistaken into how I look into this?

What we call an 04 (RPC) packet IS the one from your example. That whole packet is an 04 packet. The 04 after the 02 just lets us know that the packet will always be formed like that, and should have the same number of bytes next time it's sent.
I believe the RPC header is a couple of bytes in an 04 packet that do the same thing every time. If you have the admin console running to send RPC packets,
you can send RPC packets for testing when you set up the RPC packet database Morph set up At:
http://mxo.hardlinedreams.com/forum/show...hlight=RPC

02 04 01 00 1d 01 2f 47 00 00 04 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1a 00 06 00 00 00 01 00 00 00 00 01 01 00 00 00 00 00 80 00 00 00 00 00 00 00 00 ; Would be the RPC header.

If it were 02 03 d4 2e etc. it would be an 03 packet, and those are also what rajko was talking about. What he meant when he said that was that usually you will have your 03 packets being sent to the client (or world, depending on the way they're traveling) before your 04 packets.

For example, in many of the logs you read you will see something like:

02 03 df 34 6a ..... Which is your 03 packet, which tells about the view of the world, it can change size.
Followed by your 04 packet:
02 04 4e 6a f7 .....

Also, there can be 04 and 03 packets hiding in what we know as an 82 packet. For example: 82 df e3 f4 a2 04 ..... will be an 04 packet. you ignore the first five byte pairs of an 82 packet to figure out what type of packet you're looking at.

I hope this helps, I got some of my info from QuiDormit's site: http://blog.mxosource.com Sorry it's so long, I just tried to get all the important information down without being too confusing.

I'm still trying to figure this out too, so Morph may be able to explain better.
Find all posts by this user
Quote this message in a reply
02-13-2011, 08:43 PM (This post was last modified: 02-13-2011 08:50 PM by Morpheus.)
Post: #8
RE: Packets related to packets
Rules are:

03 Packet only:
02 03 .....

04 Packet only:
02 04 01 [current counter] [how many RPC in this block] [RPC] [RPC]...

04 with several subpackets:
02 04 0N [counter1] [how many RPC inside this block1] [RPC1][RPC1] .... [counter2][how many RPC inside this block2] [RPC2][RPC2] ... till N

Mixed 03 + 04:
02 03 ......... 00 00 04 0N [counter1] [how many RPC inside this block1] [RPC1][RPC1] .... [counter2][how many RPC inside this block2] [RPC2][RPC2] ... till N

TImed packets (Adjusting client<->server timer):
82 XX XX XX XX 03
82 XX XX XX XX 04
82 XX XX XX XX 03 .... 04

Ignore the first 5 values (timer indicator + time) and replace with a "02", which gives you the same rules as above.


Related example posted above is:

02 04 01 00 1d 01 2f 47 00 00 04 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1a 00 06 00 00 00 01 00 00 00 00 01 01 00 00 00 00 00 80 00 00 00 00 00 00 00 00

which turns into:

Packet structure:

02 04 -> 04 packet / RPC packet
01 -> 1 block inside
00 1d -> till now, "00 1d" blocks sent (aka MsgBlock Counter)
01 -> 1 RPC inside this block only
2f -> block length (2Fh in hex)

Packet Data:
Header: 47h . Should be 80xx BUT only for values above 80h itself (if i'm not wrong), so this, 47h is under 80h, hence, only 1 byte.
Rest: RPC data & values.

As we sent 1 RPC, the next counter we put in the packets OR the next counter we will find will be "00 1d" + 01 ==> "00 1e".

[Image: morphsig1.png]
[Image: ubd8457.png]
http://twitter.com/johnkussack [twitter]
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump: