|
1 | 1 | """ Game Event Parsing Debugger
|
| 2 | + =============================== |
2 | 3 |
|
3 | 4 | Recursively searches for unique replays specified by command line argument
|
4 | 5 | and attempts a parse in order to catch the ReadError. The ReadError will
|
|
29 | 30 | 3) Alter the reader code to make it happen
|
30 | 31 | 4) Repeat
|
31 | 32 |
|
| 33 | + In the example above: |
| 34 | +
|
| 35 | + 00 22 ac 00 02 f4 00 00 | 00 0c a1 89 00 10 00 00 00 21 0b 01 00 01 5c 01 00 0c 22 0b |
| 36 | +
|
| 37 | + The boundaries should be here: |
| 38 | +
|
| 39 | + 00 22 ac 00 02 f4 00 00 00 | 0c a1 89 00 10 00 00 | 00 21 0b 01 00 01 5c 01 00 | 0c 22 0b |
| 40 | +
|
| 41 | + So the correct bytes for the failed event are these: |
| 42 | +
|
| 43 | + 00 22 ac 00 02 f4 00 00 00 |
| 44 | +
|
32 | 45 | To figure out how to alter the reader code you'll probably need to compile
|
33 |
| - lists of failed events with the correct bytes and look for patterns that |
34 |
| - would help you read them the right way. Sometimes it also helps to think |
35 |
| - about what that event represents and what would make its content length |
36 |
| - vary. Cross checking against a replay can also be useful. |
| 46 | + lists of failed events with these correct bytes and look for patterns that |
| 47 | + would help you read them the right way. |
| 48 | +
|
| 49 | + Sometimes it also helps to think about what that event represents and what |
| 50 | + would make its content length vary. Cross checking against a replay can |
| 51 | + also be useful. |
37 | 52 |
|
38 | 53 | When altering the reader code, NEVER change code in an older game events
|
39 | 54 | reader unless you really really know what you are doing. Instead copy the
|
40 | 55 | function you'd like to change into the GameEventsReader_22612 class and
|
41 | 56 | make your changes there.
|
| 57 | +
|
| 58 | +
|
| 59 | + Pointers for finding boundaries |
| 60 | + ================================== |
| 61 | +
|
| 62 | + The easiest way to find the right boundary is to scan the following bytes |
| 63 | + until you see a clear marker for a different event and then work your way |
| 64 | + backwards until you can't anymore. |
| 65 | +
|
| 66 | + The first part of a new event is always a timestamp and usually, maybe |
| 67 | + 9/10 times, the timestamp will only be 1 bye long and therefore a multiple |
| 68 | + of 4 (including 0). |
| 69 | +
|
| 70 | + Immediately following the timestamp is a byte with bits split 3-5 for |
| 71 | + event_type and player_id. The event type is never more than 5 and the |
| 72 | + player_id is generally less than 4 for ladder games. |
| 73 | +
|
| 74 | + The next byte after that is the event code. Common event codes include: |
| 75 | + AC, XD, 61, and XB where X is any number. You can find a list of event |
| 76 | + codes in the sc2reader.readers.GameEventsReader_Base class. |
42 | 77 | """
|
43 | 78 | import sys
|
44 | 79 | import sc2reader
|
|
0 commit comments