Users browsing this thread: 1 Guest(s)
Packets related to packets
|
02-12-2011, 12:42 AM,
(This post was last modified: 02-12-2011, 01:15 AM by Parallax.)
|
|||
|
|||
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? |
|||
02-12-2011, 02:16 AM,
|
|||
|
|||
RE: Packets related to packets
I need a servant here .
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? ) 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? . |
|||
02-12-2011, 07:48 AM,
(This post was last modified: 02-12-2011, 02:45 PM by Parallax.)
|
|||
|
|||
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. |
|||
02-12-2011, 08:59 PM,
(This post was last modified: 02-12-2011, 09:03 PM by Morpheus.)
|
|||
|
|||
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. |
|||
02-13-2011, 02:13 AM,
(This post was last modified: 02-13-2011, 02:36 AM by Parallax.)
|
|||
|
|||
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. |
|||
02-13-2011, 05:06 AM,
|
|||
|
|||
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 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? |
|||
02-13-2011, 07:17 AM,
(This post was last modified: 02-13-2011, 07:47 AM by Parallax.)
|
|||
|
|||
RE: Packets related to packets
(02-13-2011, 05:06 AM)Messana Wrote: Still confused... 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. |
|||
02-13-2011, 08:43 PM,
(This post was last modified: 02-13-2011, 08:50 PM by Morpheus.)
|
|||
|
|||
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". |
|||
« Next Oldest | Next Newest »
|