Page 11 of 19 FirstFirst ... 9 10 11 12 13 ... LastLast
Results 101 to 110 of 181

Thread: Dota 2 Demo File Format

  1. #101
    Basic Member
    Join Date
    May 2012
    Posts
    10

    Smile

    Quote Originally Posted by Domitori View Post
    How to know what item players purchasing? If there is no "EDotaUserMessages" events in parsed dem?
    Maybe this will help you but I dont know how to use it..

    https://bitbucket.org/VoiDeD/steamre...rotobufs/dota/

  2. #102
    Quote Originally Posted by papa_pointnet View Post
    https://developer.valvesoftware.com/...rking_Entities
    Finding CSVCMsg_SendTable is easy, you just have to find the CDemoSendTables and read his "data" property has if it was a CDemoPacket. (not included in Zoid sample).
    Has anyone had any luck with this advice? Taking papa_pointnet's guidance literally, I should be able to parse the "data" property of a CDemoSendTables message as a CDemoPacket. But when I do this my protobuf library gives me a "yo bro this isn't a CDemoPacket" error. I've tried inspecting the data and figuring out which protobuf message it goes with, but none of the messages I've tried will parse it.

    I'd really appreciate any info about what's in this "data" member--it's blocking me from continuing with a really nifty idea!

  3. #103
    Basic Member
    Join Date
    Sep 2011
    Location
    Lille, France
    Posts
    52
    Quote Originally Posted by onethirtyfive View Post
    Has anyone had any luck with this advice? Taking papa_pointnet's guidance literally, I should be able to parse the "data" property of a CDemoSendTables message as a CDemoPacket. But when I do this my protobuf library gives me a "yo bro this isn't a CDemoPacket" error. I've tried inspecting the data and figuring out which protobuf message it goes with, but none of the messages I've tried will parse it.

    I'd really appreciate any info about what's in this "data" member--it's blocking me from continuing with a really nifty idea!
    Code:
    item.Datas.Protobuf<CDemoSendTables>().data.Protobuf<CSVCMsg_SendTable>();

  4. #104
    Quote Originally Posted by papa_pointnet View Post
    Code:
    item.Datas.Protobuf<CDemoSendTables>().data.Protobuf<CSVCMsg_SendTable>();
    Thank you! Now, to attempt to reverse engineer the packet entities. >

  5. #105
    Basic Member
    Join Date
    Sep 2011
    Location
    Lille, France
    Posts
    52
    some informations regarding svc_PacketReliable that appears in the last patch ?

  6. #106
    Basic Member xXAVx's Avatar
    Join Date
    Apr 2012
    Posts
    43
    Hello everyone!

    Sorry to chime in all of a sudden, but I am extremely interested in the position of players at any given time. Zoid himself mentions in his post that this positional data is stored within Packet Entity frames. Did any of you find out a way to extract (X,Y) coordinates out of the (encoded) Packet Entity frames? I have read papa_pointnet posts very carefully, and I am able to read DEM_StringTable packets (again, thanks to papa_pointnet). These tables give big hints about the content stored within the entities, for example the DT_BaseEntity has X,Y and Z positions:

    Code:
    props {
      var_name: "m_cellX"
      flags: 1
      priority: 32
      num_bits: 8
    }
    props {
      var_name: "m_cellY"
      flags: 1
      priority: 32
      num_bits: 8
    }
    props {
      var_name: "m_cellZ"
      flags: 1
      priority: 32
      num_bits: 8
    }
    Right now, I am looking on how to access the Entity data, without success. So far, I have developed my own Java parser for research purposes. So I would be more than happy to provide my code to anyone who would be interested in it.
    Last edited by xXAVx; 07-09-2012 at 08:52 AM.

  7. #107

    Everything I know about Packet Entities (or, how to get banned from this forum!)

    Welp, I doubt I know enough to be dangerous, so I'll spill what I know about the packet entities.

    I've never once done anything involving the Source engine, so this post will probably be riddled with inaccuracies. Also, if I'm divulging too much, I'm sure we'll all know in short time.

    Games built on the steam engine exchange data over the network to talk about in-game "entities." These entities are defined in two places, from two different perspectives: once on the server, and once in the client. These are defined in both places so that both can know if they're speaking the same language.

    In the case of Dota2, almost every game decision (if not all of them) resides on the server. The server makes the decisions about whether a stun lands, where the entities (i.e. players, creeps, effects, etc.) are. The client handles input events from the user, of course, but all game decisions are made on the server. Consequently, when you're looking at the replay, you're seeing a history of everything that the server knew about the game as it was played. The client did *not* have all this information while the game was being played.

    The replay protobuf messages Valve released *do* go so far as to define the "send table" messages, eg. the protobuf specifications of data the server will send to the client. This is what the "send tables" messages refer to. They are decodeable with the SDK that Valve released for parsing "demo" files. And if you parse them, you will see that they do specify a lot. It's easy to parse them:

    1. Find and parse the DEM_SendTables.
    2. Grab the data from the DEM_SendTable's 'data' field.
    3a) read the first varint, which is the 'message type' (in this case, 9, or svc_SendTable from netmessages.proto)
    3b) read the second varint, which is the 'message size'
    3c) read an amount of bytes equal to 3b
    3d) parse the bytes from 3c with the protobuf-generated class that corresponds to the 'message type'. In my case, this was a class called CSVCMsgSendTable.

    (The process for parsing DEM_Packet messages is basically identical to the above steps, but you'll have many more than one message in a packet, so you'll need to loop over the substeps for #3!)

    You'll get data remarkably like what xXAVx shared above.

    Here's my version: http://pastebin.com/N5sBjDXV. All you have to do after that is look at the Valve documentation for Networking Entities to realize that you're really close: https://developer.valvesoftware.com/...rking_Entities

    Unfortunately, one of the properties of a SendTable is whether or not it the table needs a 'decoder'. I suspect that this is where we'll all get stuck. Let me skip ahead a bit--about the packet entities packet itself.

    Finally, what I know about svc_PacketEntities messages. Here's the protobuf message format provided by valve:

    Code:
    message CSVCMsg_PacketEntities
    {
    	optional int32 max_entries = 1;
    	optional int32 updated_entries = 2;
    	optional bool is_delta = 3;	
    	optional bool update_baseline = 4;
    	optional int32 baseline = 5;
    	optional int32 delta_from = 6;
    	optional bytes entity_data = 7;
    }
    If you parse the 'packet entities' message in a DEM_Fullpacket packet, you'll see that the 'is_delta' flag is *false*. Meaning, full packets contain the state of every entity in the game at that moment. All the 'packet entities' messages in DEM_Packets are deltas: they only specify how entities have changed since a reference point. So, in my opinion, they're the best place to start.

    The 'entity data' bytes are what I suspect you'll need to 'decode.' I'm not sure that I can figure out how. What I do know is this:

    1. All svc_PacketEntities messages I've seen start with four identical bytes. 0x0102fcff.
    2. The next two bytes, if you look at them bitwise, consist of 5 bits which cycle from 0-31. The next 11 bits (for a total of 16) increment whenever the first 5 bits cycle through their values. Consequently, I think this is time-related information. Or at least not related to positions of entities.
    3. The next two bytes are 16 bits of zeroes.

    All those totaled up are 8 bytes for a header, from what I can tell. The remainder of the packet entities message probably contains just enough information to describe the number of entities updated, which is specified in the svc_PacketEntities message! So at least that's a place to start. How to decode those bits? Well, I don't know.

    Best of luck, and PM me if you figure anything else out.

    And really, finally, a shoutout to the secretive chaps in #dota2replay on irc.quakenet.org. They probably know more than I do, but they sure aren't saying much.

  8. #108
    Basic Member xXAVx's Avatar
    Join Date
    Apr 2012
    Posts
    43
    Many thanks for a fast a thorough reply, onethirtyfive.

    You explained the intricacies of Server/Client entities and SendTables very elegantly. Though, as you very well remarked we are bashing our heads against the (apparently encoded) svc_PacketEntities.

    Now that I know I am not wasting my time (i.e. I am dealing with an unsolved problem), I started looking into the Packet Entities just like you, bit-wise. Indeed, I found the pattern you mention across the Entities. Three consecutive entities looked like this:

    Code:
    0102fcffb1060000708100c402feff1878c78206
    0102fcffb9060000708100ff7f1ecd6441c6
    0102fcffc1060000708100ff7f30de6541c6
    I am sure the structure continues! Just giving you a thumbs up: I will continue working on this for at least a couple of hours.

  9. #109
    xXAVx,

    Any luck or insights?

  10. #110
    Basic Member
    Join Date
    Mar 2012
    Posts
    267
    Someone know if I can find some replay files (.dem) to download somewhere? I don't have the client installed here, and I wanted to try the parser. Thanks!

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •