LOTV update: inject stats

[j4p3]

Z macro mechanics should be broken into 2 stats, 'consistency' and 'efficiency'. [feature]

Consistency: % of game time hatches spend injected.
Efficiency: % of total injected time hatches have injects queued.

[j4p3]

To update on this:

There's an issue where some injects aren't read into 'events'. Still haven't nailed down the exact conditions - when the inject is queued, certainly, and possibly when it's shift-queued behind other injects. I'm looking specifically at the reader's command event parser (https://github.com/ggtracker/sc2reader/blob/upstream/sc2reader/readers.py#L1755), which is getting its data from the decoder.

Clearly the sc2 engine is storing these inject somewhere. We could be missing them in a few places:

• event_type of queued injects not 27 and ends up unused - a few hundred of these in every replay (https://github.com/ggtracker/sc2reader/blob/upstream/sc2reader/readers.py#L340)
• flags modifier carrying additional data indicating queued injects (https://github.com/ggtracker/sc2reader/blob/upstream/sc2reader%2Fevents%2Fgame.py#L184)

Plenty of other possibilities, too. Work continues - will update here, or Google group.

[EHadoux]

Are you trying to read them at the time the hatching occur or when the injection is performed by the player?

[j4p3]

This issue is actually too specific for sc2reader, it belongs on https://github.com/dsjoerg/ggpyjobs. All we need to resolve the issue here is for command_update_target_unit_event and command_manager_state_event to leave a record in replay.events. Working on a PR now.

To answer your question, though, I'm looking to log injects into events at the time they occur, and inferring when they pop in ggpyjobs ZergMacroTracker. In that implementation, consistency won't care when inject commands go down, just the inferred total-time-injected. Efficiency will total the delta between inject commands and the inferred larva pop, remove one INJECT_PERIOD per inject, and present the result as a % of total-time-injected.

[dsjoerg]

This issue was moved to ggtracker/ggtrackerstack#13