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

Figure out the meaning of marker #1 in player and turret segments #17

Open
Zero3 opened this issue Jul 14, 2014 · 4 comments
Open

Figure out the meaning of marker #1 in player and turret segments #17

Zero3 opened this issue Jul 14, 2014 · 4 comments

Comments

@Zero3
Copy link

Zero3 commented Jul 14, 2014

The player segment wiki page states the following about player segment headers:


!! !! C3 !! 11 00 [00 00 00]

Similarly, the turret segment wiki page states:


!! !! 4A 9C                  // Marker #1 & #2
++ ++ ++ 40                  // Base entity ID, only for the first turret
++ ++ ++ 40                  // Entity ID
40

Perhaps 0x93 indicates the start of a new type of segments (player / turrets) and 0xB3 indicates another segment of same type. If true, this could be useful for knowing which kind of segment we are parsing (... how do we actually know this at the moment? Do we just check byte 3 which is known to be 0xC3 / 0x4A depending on segment type?)

@themasch
Copy link
Member

I'm pretty sure that the 0x93 = new type, 0xB3 = same type thing is wrong because i've seen replays where the first player header starts at 0x10 with [ 0xb3 0x00 0xc3 0x4c 0x00 ]

I'll try to fix my parser and see if i get more information about this.

[update]
Most keyframes i've seen in the last games where of this 0xb3 0x00/0x01 0xc3 0x4c type. The second byte seems to be changing most frequently.

i've seen some keyframes where some of the players "suddenly" had 9300c34b0-keyframes and these had an additional space between the end of the previous player segment and the header that contains
930001df01.

@Divi
Copy link
Member

Divi commented Jul 26, 2014

0x93 and 0xB3 are not constant. Since the patch 4.11 I found a few keyframes with other hex (see #15). I don't know why. Same for the next 0x00 or 0x01.

Here the regex I use to found the header : /C3(?:4B|4C)00(?:000000)?[A-Z0-9]{6}40[0-9]{2}00000040/.

@jaagupkymmel
Copy link
Contributor

Take a look at https://gist.github.com/jaagupkymmel/8939b876dd164b71ad9f. It seems to make sense so far.

@themasch
Copy link
Member

@jaagupkymmel at first glace this looks pretty good. I hope I'll find some time to check this. could be huge if thats correct an valid for all (more) headers. finally some structure!

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

No branches or pull requests

4 participants