Terran macro messed up by LotV?

[dsjoerg]

Hi, I am using ggtracker to hopefully improve my starcraft play. Firstly, I would like to inquire about the coloured rectangles in the race macro graph. As far as I understand, these rectangles show you when your orbital command energy is at 200/200. But when I looked at the replay, I could not find any instances where I was at 200 macro energy. Also, I noted I had 5 orbital commands in the game but the analysis only showed me 4.

http://ggtracker.com/matches/6660913

[nickelsen]

Energy regeneration rate is calculated per frame. Since both regeneration rate per second and frames per second are changed in LotV, the energy regeneration rate per frame is the same as before LotV.

I looked through the replay in-game and compared to the output of the plugin that tracks terran macro. During parsing, 10 calldown-mule events are found while in-game 25 mules were called down. This makes the simulation calculate wrong amount of base energy.

@dsjoerg Have you seen something like that before? Is it expected and I'm looking at the wrong place to fix the macrochart or it is unexpected and this could be the source of the problem?

[dsjoerg]

@nickelsen, this is unexpected and could be the source of the problem.

[dsjoerg]

@nickelsen i haven't seen something quite like this before, but like issues #49 and #50 it could be that the precise method used by the player to call down the MULE might create events that the plugin is currently not looking for or recognizing.

in general i expect it will be something like this.

[nickelsen]

Thank you, @dsjoerg! I'll keep investigating in that direction.

[gravelweb]

Hey @nickelsen, if this is related to "shift clicking" down mules, I think I have a fix hacked up on my end. Could you provide link to said replay, and I'll check if it fixes the number of mules called down?

[nickelsen]

That sounds really good, @gravelweb! You can find the replay at http://ggtracker.com/matches/6660913.

[gravelweb]

Yeap, nice Macro HikkiMan!

[dsjoerg]

Very exciting @gravelweb !

[gravelweb]

While creating unit tests, it looks like 29 CalldownMULE events are being processed, and I've double checked the replay to confirm that only 25 should be present. I'm guessing this is due to insufficient energy in the orbitals. @nickelsen @dsjoerg what should we do here? This has the potential of skewing the stats for spammer types. I'll do a quick look see if I can't factor that information in the sc2reader engine, but may not have time to address this until July.

[dsjoerg]

@gravelweb I've seen things like this before; the replay contains the commands issued by the user, regardless of whether they succeed or not.

In the case of MULEs, however, one way to work around the problem is to look for the creation of a new MULE unit. Every time a unit is created, there's a tracker event for that, and we know who the owner is, and we know how much energy that costs.

Would that work around the problem?

[gravelweb]

That would work for the MULEs I think. Would that be at the ggpyjobs level or at the sc2reader level? Maybe it's better that sc2reader picks up all events, and it's up to ggpyjobs to find the events that it cares about. If that's the case, then perhaps the unit_test in sc2reader needs to pick up 29 calldowns (there's just no way to confirm where those come from).

We'll need to consider how to solve this for scans (and maybe SpawnLarva?) problems as well.

[dsjoerg]

With energy tracking we can probably do a decent job of estimating the base energy and then guessing whether or not the command succeeded or failed. Have a look at ggpyjobs/sc2parse/plugins.py ProtossTerranMacroTracker. Maybe that's already close to what we need?

So the sc2reader layer's responsibility is strictly to parse events (which are player-generated and may have succeeded or not), and the ggpyjobs layer figures out what was actually happening in the game.

[dsjoerg]

fix deployed thanks @gravelweb @nickelsen !