You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?)
The text was updated successfully, but these errors were encountered:
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.
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 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!
The player segment wiki page states the following about player segment headers:
0x93
or0xB3
Similarly, the turret segment wiki page states:
0x93
for first turret and0xB3
for any otherPerhaps
0x93
indicates the start of a new type of segments (player / turrets) and0xB3
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 be0xC3
/0x4A
depending on segment type?)The text was updated successfully, but these errors were encountered: