LOTV update: inject stats

[dsjoerg]

From @j4p3 on January 10, 2016 17:44

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.

Copied from original issue: ggtracker/sc2reader#7

[dsjoerg]

From @j4p3 on February 29, 2016 21:6

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.

[dsjoerg]

From @EHadoux on March 1, 2016 14:51

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

[dsjoerg]

From @j4p3 on March 1, 2016 21:58

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]

Looks like #49 and #50 might be the keys to resolving this.

[gravelweb]

Oops must have looked over the issue. Anyhow, I'm on it :)

[dsjoerg]

BTW someone posted on uservoice 3 days ago:

First off, thanks for all your hard work on this great tool. I look at it after all my matches.

I've noticed that the inject graph doesn't seem to accurately reflect what's happening in the game. I think it may not know how to correctly handle queued injects?

I wasn't sure, so I recorded this test game: http://ggtracker.com/matches/6673591 If you watch the replay, you can see that once three queens are out, all of my hatcheries have injects going consistently, but the graph doesn't seem to reflect this (the % also seems low, though I'm not sure how this is calculated so that may just be wishful thinking on my part).

Maybe I'm just not reading the graph right, but ever since LotV I've gotten terrible macro scores even on games where it seems like I did ok. As a lower league player this is a big improvement focus for me so if this could be fixed or even just explained it would really help me out.

Thanks again! Love the site!

[jfremer]

Hi @gravelweb,

Thanks for your work on this, I really appreciate it.

I re-uploaded my test replay and the inject graph is now blank: http://ggtracker.com/matches/6673591 . I believe there may be a bug in this implementation.

Thanks again. The Swarm is counting on you! ;)

Josh

[gravelweb]

@jfremer That is interesting! I'll try to investigate this issue ASAP. Unfortunately I will be MIA for 2 weeks as of Thursday, but maybe I can get to it before!

Can you provide details as to how you perform your inject cycles? (hotkeys, control groups, etc.)

[jfremer]

Hi Jonathan,

Thanks for your prompt reply. Here's my method:

• Bind all queens to hotkey 5

1. Invoke the base camera command (I think the default key for this is backspace; I use tilde)
2. Select my Queen group via hotkey 5
3. Tap V (inject larva command key)
4. Click on the centered hatchery in the main screen
5. Repeat steps 1 - 4 as fast as I can for each hatchery

I never use the shift key for injects, and I always re-select my Queen group between each inject (not the most efficient way to do it but it's muscle memory now). In the replay referenced, I think pretty much every inject is done while at least one other inject is still going.

Let me know if there's anything else I can do, I'm happy to help with testing different methods, etc if that'll be valuable. Maybe do a few more test replays.... one with non-queued injects, one with individually selected queens, and so forth?

If I don't talk to you before then, have a great trip! I hope you're going somewhere fun!

Cheers,

Josh

[gravelweb]

@jfremer Thanks for the details. That's all very helpful. The fix I introduced was for shift+clicking injects (with multiple queens selected), which should not have affected you at all. Having your replay will be helpful.

One follow-up question: What did the graph look like before re-uploading with the new "fixes"? As far as I know, the problem with queued injects (which you are doing) existed previously (and still does). That said, given the logic of ggtracker, the LAST injects for each base should be showing up on the graph.

One thing I like to to do before debugging is to collect the time of all the injects for each base, since that's how it's stored internally. Comparing the two usually gives me immediate indication of what is going wrong. Including inject actions where the queen had no energy is useful as well.

[gravelweb]

see #50 for queuing related issue.

[jfremer]

Prior to the latest update, the graph showed sporadic injects on two hatcheries. I think there were maybe around 8 injects graphed. Expected behavior was consistent injects on three hatcheries. The % was low; below 20 IIRC. Sorry; I didn't think to take a screenshot.

[gravelweb]

@jfremer I figured that would have been a lot to ask :) I can always checkout an earlier version of ggtracker to see the graph if I absolutely need to. Thanks for the info. I'll probably have some time tomorrow evening to look into it (always looking for an excuse not to play ladder, anyways!)

[jfremer]

@gravelweb I uploaded a more comprehensive reference replay at http://ggtracker.com/matches/6687647

For this one I just followed a script that included all the different inject variations I could think of, then I plugged in the timestamps as I went through it. That timeline is in the attached txt file.

zerg macro script.txt

I tried to keep as much "noise" out of this replay as I could. Hopefully something in here is useful.

[gravelweb]

Very nice @jfremer! Seems like valuable data indeed. Thank you.

[gravelweb]

OK I did some digging for you, @jfremer. The reason you are not seeing injects is for two different reasons:

Replay 1 (http://ggtracker.com/matches/6673591): Apparently you rocked at injecting, because almost all of you injects were overwritten by the next due to queuing (see issue #50). I said I was expecting the last inject to show up at least, but ggtracker will only track injects that have actually completed, so because the eggs didn't hatch before end of game, the last inject was also discarded. So your replay should work once #50 is taken care of (early July if I'm the first one to get to it).

Replay 2 (http://ggtracker.com/matches/6687647): At the moment, it appears ggtracker does not fully support games without at least two teams. Internally, your injects are being discovered, but we are not publishing them due to the assumption we are making during parsing that num_teams >= 2.

Hope that helps clear things up!

[dsjoerg]

regarding replay 2, is that a vs-AI match? we do support vs-AI, i wonder if vs-AI support got broken somehow recently.

[jfremer]

That second replay is actually one-player. I started a custom game and didn't add an opponent. I was trying to keep the replay data as simple as possible. Guess I was over-thinking it!

On Jun 14, 2016, at 9:52 PM, David Joerg [email protected] wrote:

regarding replay 2, is that a vs-AI match? we do support vs-AI, i wonder if vs-AI support got broken somehow recently.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[gravelweb]

Hey @dsjoerg, I'm looking at a scenario where a queen issues the inject ability, but never reaches the hatch that needs to be injected before being redirected to doing something else. Is there any way to detect a cancelled ability within sc2reader?

I'm thinking the logic behind this would be to figure out how far the queen is from the target hatch, figure out how long it would take to get there, and then remove the inject if it isn't given enough time. This sounds pretty complicated when considering walk-speed on-creep vs off-creep, let alone having to track all the queens + control groups that they belong to.

I'm thinking it's not worth the effort at this time, but was wondering if a simpler solution exists. Thanks!

[dsjoerg]

Hi @gravelweb another way to go is to track the creation of the larva units. I suppose that a large % of the time, larva creation is equivalent to a successful inject. The exception is when the hatch is destroyed before the larva can pop out. Now, I'm not sure which estimate is going to be worse — inject abilities or larva creation? The former is an overestimate and the latter is an underestimate.

[gravelweb]

Good outside the box thinking @dsjoerg. That hadn't even crossed my mind before. Maybe the egg death event could be the solution here? This is assuming that the eggs are units. When an egg dies, it has either spawned larva, or the hatch has been destroyed, no? I'd have to test that out.