LOTV inject tracking

[JP Bonner]

I've been looking into inject events for ggtracker's sc2reader fork (the specific issue discussion is at https://github.com/ggtracker/sc2reader/issues/7 - my question here is more general.) While we can parse replays successfully, we're missing some inject events, presumably due to the lotv inject changes.

We must be discarding these events as we parse the replay. It'd be helpful to know how the reader's EVENT_DISPATCH dict (https://github.com/GraylinKim/sc2reader/blob/master/sc2reader%2Freaders.py#L216) and the event's flags dict (https://github.com/GraylinKim/sc2reader/blob/master/sc2reader%2Fevents%2Fgame.py#L137) were generated. Is there some Blizz-issued event definition floating around somewhere, or have we just been stepping through replays with s2protocol and figuring out which bit means what?

Thanks!

[David Joerg]

To come at this problem another way, it would be helpful if you could identify a specific inject event in a specific replay that occurs in the replay but is not available in the way you'd expect via sc2reader.  That is, you point us to a reference replay file and a particular timestamp where an inject occurred.  You can look at the events using Blizzard's s2protocol to find the specific event and see all its fields.  From there it will be relatively simple (I hope!) to modify sc2reader to make the event available in the way you'd like.

--
You received this message because you are subscribed to the Google Groups "sc2reader" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sc2reader+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[JP Bonner]

Sure thing - linked replay here (https://s3.amazonaws.com/eruditorium/inject_stacking_2.SC2Replay). The type of sequence I'm looking at is an inject, some camera events, and then multiple pairs of command events that aren't used by sc2reader, separated by camera events. In-game, this corresponds to hotkey selecting a queen group, injecting a hatch, base-camera jumping to the next hatch, and shift-injecting it, until all hatches are injected.

Run through s2protocol (`python s2protocol.py --gameevents --details`), the output at `_gameloop: 8573` is the type of event I'm talking about. It's listed as a  `NNet.Game.SCmdUpdateTargetUnitEvent` followed by a `NNet.Game.SCommandManagerStateEvent`. They follow the actual inject, which happens at `_gameloop: 8553`.

We're not storing them in sc2reader - we do have a `command_update_target_unit_event` and `command_manager_state_event` handler, but no corresponding classes, so they don't pass `if event_class is not None:` (https://github.com/ggtracker/sc2reader/blob/upstream/sc2reader/readers.py#L344). For convenience I'm storing them anyway with this branch: https://github.com/j4p3/sc2reader/commit/05c17ba3fd6de9989b62f1500378f661e79f0f15. In that `inject_diagnostics` list, the event in question is `replay.inject_diagnostics[1413]`. The actual inject is at `replay.inject_diagnostics[1408]`, and the intervening events are camera actions.

There's a whole sequence of these. In s2protocol, they look like:

{'_bits': 176,

 '_event': 'NNet.Game.SCmdUpdateTargetUnitEvent',

 '_eventid': 105,

 '_gameloop': 8573,

 '_userid': {'m_userId': 0},

 'm_target': {'m_snapshotControlPlayerId': 1,

              'm_snapshotPoint': {'x': 530432, 'y': 628736, 'z': 49136},

              'm_snapshotUnitLink': 108,

              'm_snapshotUpkeepPlayerId': 1,

              'm_tag': 52690945,

              'm_targetUnitFlags': 111,

              'm_timer': 0}}

Their bytes look like:

0\xc0\t\x06\x0f\x002@\x00\x01\x06\x1c\x87\x06\x00\x98`\x80\x00\x02\xff0

They're all followed by a `command_manager_state_event` that tells us they're meant as injects:

{'_bits': 56,

 '_event': 'NNet.Game.SCommandManagerStateEvent',

 '_eventid': 103,

 '_gameloop': 8573,

 '_userid': {'m_userId': 0},

 'm_sequence': 689,

 'm_state': 1}

Bytes:

\x00\xc0W\x00\x00\x050

Still puzzling out the details and working on a solution. It looks like we can infer hatcheries from `tag` on the `command_update_target_unit_event`. This `command_manager_state_event` is a bit obnoxious - are there other situations that require us to look at two consecutive events to figure out what happened?

Also sorry deleting previous - struggling with Google groups here : p