Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any reference for dem message format and information? #120

Open
ro9er opened this issue Dec 15, 2016 · 6 comments
Open

Any reference for dem message format and information? #120

ro9er opened this issue Dec 15, 2016 · 6 comments
Labels

Comments

@ro9er
Copy link

ro9er commented Dec 15, 2016

Hi,

I have gone through the project for a long time and I learned that you have implement your own reliance injection and event listener injection based on annotation and make the parsing event driven.

Really awesome job and I benefit from your code so much. Thank you!

But I have a question, is there any reference(Webpage link, document etc.) about the meaning of each DEM message and its structure? I found that without these knowledge, it's nearly impossible to understand the parsing process in deep. I have read the wiki page in your repo and know something like the message can be divided into three part(prologue, match epilogue), but that is not enough. Could you share some reference?

Thanks again and looking forward to your reply!
好人一生平安(Good luck all the time in Chinese).

@spheenik
Copy link
Member

spheenik commented Dec 15, 2016

It's more like the replay can be divided into 3 parts, prologue, header and epilogue.

The prologue consists of definitions about how the data following is structured (send tables), string table initialization, etc. The main body contains a data packet for roughly every 2nd tick (15 packets / sec), which contain combat log and entity updates. The epilogue is a single protobuf message containing some overview data for the match.

There is no documentation on each message, but it's property names give you at least a clue of what to expect. The rest of my knowledge I got from here and there (for example I got inspired by @onethirtyfive who wrote the python parser "skadi", and he in turn got inspired by @dschleck who made the first ever Dota 2 parser capable of reading entities, named "edith").

A replay basically is a sequence of protobuf messages. Some of those messages are just containers for embedded messages. Entity data is encoded in a completely undocumented by Valve (why should they?).

I still think the best way to find out how it all works is to read parser code.

Allzeit viel Glück! (Good luck all the time in German)

@aschleck
Copy link

@jgoyvaerts had one before me! I only get to lay claim to making the first open source one :)

@spheenik
Copy link
Member

@dschleck: Oh, I did not know that. Doesn't matter though, there's always a place for you in my shrine :)
Not the least because of Nora, which helped me a lot in a project lately that also is not Open Source.

@aschleck
Copy link

Woohoo! I am super glad to hear Nora was useful for something. I thought I released into the void and no one ever cared.

@rumpfc
Copy link

rumpfc commented Apr 26, 2020

You really did a great job in this Parser. I took my time to understand the relation between proto files and a dem file using your source code. There is one point I still don't quite get: it's the content of a CDemoPacket.

You parse the first 6 bits of a packet to determine it's kind/type, but where do you get the IDs? I tried to google for some documents, without any success of finding the link. Is there an enum within a certain proto file (like in demo.proto to determine the message type to parse by parsing EDemoCommand first)?

Examples:

  • 4 = NetworkBaseTypes.CNETMsg_Tick
  • 51 = S2NetMessages.CSVCMsg_ClearAllStringTables

@spheenik
Copy link
Member

Not sure if I understand your question correctly: You want something like EDemoCommands but for the embedded messages?

There is no single place to do this, that's why I made the mapping myself.

The info is scattered around, for example here and here.

There is no way to derive the actual class that represents a kind from just the proto files.

That's why you have to do it yourself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants