ggtracker / ggtrackerstack Goto Github PK

How can this event have no location?!
event 09.30 asphyxa         Ability (10C0) - ScannerSweep
Cant figure out which Base this Chronoboost/Scan/etc was for. Ignoring it :(
How can this event have no location?!
event 10.32 asphyxa         Ability (10C0) - ScannerSweep
Cant figure out which Base this Chronoboost/Scan/etc was for. Ignoring it :(
How can this event have no location?!
event 12.44 asphyxa         Ability (10C0) - ScannerSweep
Cant figure out which Base this Chronoboost/Scan/etc was for. Ignoring it :(
How can this event have no location?!
event 14.37 asphyxa         Ability (10C0) - ScannerSweep
Cant figure out which Base this Chronoboost/Scan/etc was for. Ignoring it :(

for this replay: http://drop.sc/replay/3841038

For example in this match: http://ggtracker.com/matches/6617852
income at 3:35 is 1147 for Terran, 1091 for Protoss in the in-game income tab.
However on the GGTracker match page it shows as 823 for both of them.

The reason for this is that internally we store the income as 823 (which is the HotS-style income) but when showing things to users of course we should show them as LotV-style.

Or of course we could actually change our internal data representation to be LotV-style, but that would involve making additional changes throughout the codebase.

See discussion here dsjoerg/ggtracker#26 (comment)

thanks to @nickelsen for noticing.

From @j4p3 on January 10, 2016 17:41

Replays should be analyzed with the new LOTV real time, instead of Blizz time. [bug]

To reproduce:

1. Run any replay

Expected:

• Replay length corresponds to number of elapsed minutes/seconds (or hours if you're playing mech)

Actual:

• Replay length off by 40% due to normal/faster game speed correction

Copied from original issue: ggtracker/sc2reader#6

From @eric-hu on August 13, 2015 21:19

I thought I noticed this last month, was just chatting with a friend and he ran into this issue too. Will post a link once I hear back from him.

Copied from original issue: dsjoerg/esdb#3

From @kpaleniu on January 1, 2016 17:8

The way time is calculated from LotV replays seems to be incorrect. See the following replay. The replay is actually 14:47 long. The graph on the main page says the match lasted 20:43. Is this a known issue?

Copied from original issue: dsjoerg/ggtracker#16

From @dsjoerg on July 16, 2014 18:47

Currently we use an old and behind version of sc2reader: https://github.com/ggtracker/sc2reader/tree/upstream

Which is less efficient, and also not as easily compatible with the newer sc2reader.

Copied from original issue: dsjoerg/ggpyjobs#1

From @dsjoerg on July 16, 2014 18:47

Copied from original issue: dsjoerg/ggpyjobs#2

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

From @dsjoerg on August 17, 2014 20:51

In the same place where we currently show army composition, we could also show upgrades, and perhaps also buildings and the # of currently alive workers.

Copied from original issue: dsjoerg/ggtracker#5

see discussion at https://twitter.com/AicyDC/status/725313634646282240?cn=cmVwbHk%3D&refsrc=email

In this replay: http://sc2replaystats.com/replay/3848059
The race comes through to us not as P but П.
I understand that's Cyrillic for P, but it never happened before and screws up our game processing. How many other languages will start coming in?

Here are the non-standard race counts so far:

C   34
H   2
З  37
П  57
Т  32

And the thing that looks like a T is actually not the standard Latin alphabet T it's some other crazy thing.

using rack-attack we could protect the ESDB API in the same way that we already protect the ggtracker webapp.

We ask people to not hit the API more than once per second, but some people probably are and it probably reduces quality of service for all the innocent users out there.

see ggtracker/sc2reader#10 (comment)

From @dsjoerg on August 20, 2014 18:51

In skillcraft.py we are counting as "Actions" some things that should not be counted as actions.

https://github.com/dsjoerg/ggpyjobs/blob/master/sc2parse/skillcraft.py#L175

The algorithm should ignore the following actions:

               Seld
               Leaving the game
    'Use ability   5f01'
    'Use ability   6e00'
    'Use ability   7b42'
    'Use ability  12940'
    'Use ability  14442'
    'Use ability  15d09'
    'Use ability  17200'
    'Use ability  17801'
    'Use ability  17901'
    'Use ability  1fa0e'

These are the action descriptions used by SC2Gears. So the question is, what are these actions exactly? Next step is to fire up SC2Gears, look for these events in some replays, and figure out what they are.

Copied from original issue: dsjoerg/ggpyjobs#4

From @dsjoerg on August 17, 2014 19:44

This spec breaks: https://github.com/dsjoerg/esdb/blob/master/spec/sc2_identity_spec.rb#L185

When I investigated, it seemed that there might be an actual bug in bnet_scraper (or at least our fork of it, gem 'bnet_scraper', :git => '[email protected]:ggtracker/bnet_scraper.git', :ref => 'battlenetify'
).

bnet_scraper.scrape is called in esdb/games/sc2/identity.rb line 525, and the result comes back with no value for current_solo_league.

Copied from original issue: dsjoerg/esdb#1

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

From @dsjoerg on July 16, 2014 18:48

Copied from original issue: dsjoerg/ggpyjobs#3

From @agwblack on April 8, 2016 14:5

I think a nice feature would be to have a graph that shows Spending Quotient against match number, when Staircase View is enabled. This would let users easily see their progress over time (at the moment you have to mouse over the Spending Skill medal).

Copied from original issue: dsjoerg/ggtracker#18

Some users are reporting that they cannot upload their replays (https://twitter.com/dirak_/status/732745048111087616). Looking at GGTracker, replay uploads have definitely slowed down since the 3.3.0 patch.

From @dsjoerg on August 17, 2014 20:56

and optionally also matchup.

but the primary use case is that a player of race X is wondering which maps to veto on ladder.

i'm imagining the page would work something like http://ggtracker.com/economy_stats#?race=protoss&vs_race=zerg, where the data comes from ESDB, which is updating its stats nightly.

Copied from original issue: dsjoerg/ggtracker#6

From @dsjoerg on August 17, 2014 20:41

As suggested in https://twitter.com/GGTracker/status/478967240046690306

Copied from original issue: dsjoerg/ggtracker#1

From @dsjoerg on August 17, 2014 21:0

This is a very commonly requested feature.

The first and hardest question is how to visually design it in a "GGTracker" way, keeping it clean, light and not overwhelming to the first-time user.

To get some ideas, have a look at how spawningtool, sc2replaystats and sc2gears/scelight do it and see what you do or don't like.

Copied from original issue: dsjoerg/ggtracker#7

From @dsjoerg on August 20, 2014 19:0

Now that Action Latency is being computed for every player in every replay: https://github.com/dsjoerg/ggpyjobs/blob/master/sc2parse/skillcraft.py

What remains is to show it in the appropriate place(s) in the front end.

Action Latency is the average time from when a player looks in a new place to when they take their first action.

http://www.teamliquid.net/forum/starcraft-2/401425-starcraft-2-science-skillcraft-results#5

Of all the variables studied by the Skillcraft.ca study, it is the single most predictive variable of what league you're in: http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0075129#s5

Probably should add it to the main player profile page, but then the profile would have 4 charts and would need a redesign.

Copied from original issue: dsjoerg/ggtracker#10

From @dsjoerg on August 17, 2014 20:44

A commonly requested feature.

Note that, currently, deleting replays is restricted to GGTracker Pro subscribers (the idea being that if you care enough about GGTracker to want to delete a replay, you probably care about it enough that you should be contributing to keeping the server running). So by the same logic, mass delete should be a GGTracker Pro feature.

Copied from original issue: dsjoerg/ggtracker#2

From @dwinchell on February 14, 2016 19:14

This seems low priority given the frequency of motherships in current play, but just FYI in the list of units below the main graph on the match detail page, there is no icon for a mothership when a player builds it.

Copied from original issue: dsjoerg/ggtracker#17

From @gravelweb on April 13, 2016 2:34

Since chronoboost is now permanently cast on buildings, the stat shown (nexus energy maxed) is not helpful. I propose that instead of tracking nexus energy, it would be more useful to track whether the building that is chronoboosted is idle or not.

e.g.1. chrono boosting a robo that doesn't produce any units would show 0%.
e.g.2. chrono boosting warpgates would track the percentage of time where the building isn't on cooldown.

Would that change fit in ggtracker?

Copied from original issue: dsjoerg/ggtracker#21

Currently our submodules are fixed to specific commits.
Would it be better if they automatically tracked the latest?

See http://stackoverflow.com/questions/9189575/git-submodule-tracking-latest for a discussion of how to do this. However I'm no git expert so I'm not sure how "automatic" the resulting solutions really are.

@nickelsen what do you think?

From @dsjoerg on August 17, 2014 20:46

Copied from original issue: dsjoerg/ggtracker#4

For example this one:
Honorgrounds LE (49).SC2Replay.zip

Using this game as an example, I've been trying to figure out why only one hatchery is being tracked. I've narrowed it down the cause to the inject method used by the Zerg player:

1. Select queen control group, shift+inject_hot_key
2. Camera hotkey to first base
3. Left click on the hatchery
4. Camera hotkey to second base
5. Left click on the hatchery

I've dumped the corresponding events w/ data from the replay below. It appears the problem is related to the command_update_target_unit_event not being handled.

03.20: 139730577463632: [class 'sc2reader.events.game.GetFromHotkeyEvent']: {'is_local': True, 'mask_type': u'None', 'frame': 4495, 'pid': 1, 'mask_data': None, 'player': None, 'second': 280, 'update_type': 2, 'control_group': 8, 'hotkey': 8, 'bank': 8}
03.20: 139730577463440: [class 'sc2reader.events.game.CameraEvent']: {'is_local': True, 'distance': None, 'frame': 4501, 'pid': 1, 'player': None, 'second': 281, 'location': (64.5, 158.76171875), 'pitch': None, 'y': 158.76171875, 'x': 64.5, 'yaw': None}
03.21: 139730577463824: [class 'sc2reader.events.game.TargetAbilityEvent']: {'upkeep_player_id': 2, 'target_unit': None, 'frame': 4508, 'pid': 1, 'other_unit': None, 'player': None, 'second': 281, 'target_flags': 111, 'ability_type_data': {'upkeep_player_id': 2, 'unit_tag': 74711041, 'unit_link': 108, 'control_player_id': 2, 'point': {'y': 657408, 'x': 264192, 'z': 40896}, 'flags': 111, 'timer': 0}, 'command_index': 0, 'control_player_id': 2, 'target_timer': 0, 'location': (64.5, 160.5, 40896), 'has_ability': True, 'target_unit_type': 108, 'ability': None, 'ability_id': 3296, 'ability_link': 103, 'other_unit_id': None, 'flag': {'alternate': False, 'target_self': False, 'dispatch_to_other_unit': False, 'data_a': False, 'preempt': False, 'repeat': False, 'user': True, 'subgroup': False, 'data_abil_queue_order_id': False, 'homogenous_interruption': False, 'data_b': False, 'minimap': False, 'is_order': False, 'script': False, 'smart_rally': False, 'ai_ignore_on_finish': False, 'set_autocast': False, 'set_autocast_on': False, 'ai': False, 'data_passenger': False, 'queued': True, 'smart_click': False}, 'ability_type': u'TargetUnit', 'is_local': True, 'target_unit_id': 74711041, 'flags': 258, 'y': 160.5, 'x': 64.5, 'z': 40896, 'ability_name': u'', 'ability_data': None}
03.21: 139730577464208: [class 'sc2reader.events.game.CameraEvent']: {'is_local': True, 'distance': None, 'frame': 4512, 'pid': 1, 'player': None, 'second': 282, 'location': (36.5, 151.7578125), 'pitch': None, 'y': 151.7578125, 'x': 36.5, 'yaw': None}
03.21:     skipped: [bound method GameEventsReader_38996.command_update_target_unit_event of [sc2reader.readers.GameEventsReader_38996 object at 0x7f158f849a10]]: {'target': {'snapshot_control_player_id': 2, 'snapshot_point': {'y': 628736, 'x': 149504, 'z': 32768}, 'tag': 80740354, 'snapshot_upkeep_player_id': 2, 'snapshot_unit_link': 108, 'target_unit_flags': 111, 'timer': 0}}
03.21:     skipped: [bound method GameEventsReader_38996.command_manager_state_event of [sc2reader.readers.GameEventsReader_38996 object at 0x7f158f849a10]]: {'state': 1, 'sequence': None}

It used to be that 640 mineral income was a fully-saturated base. Now it's 896.

Everyplace in the system that uses 640 and multiples of 640 should be updated. For example:
http://ggtracker.com/economy_stats#?race=protoss&vs_race=zerg

And the parallel changes should be made for gas.

And all the same goes for TheStaircase-related code.

If we do #30 this is no longer necessary or relevant.

Every time Blizzard adds new portraits, we get complaints from users who can't authenticate. That's because when Blizzard adds new portraits we have to make code and asset changes to take them in.

So as a quick & easy fix we could change the instructions to tell the person to first change their portrait to one of the standard ones like Kachinsky, and then wait and continue with the standard process. Or we could simply tell them to change their portrait TO Kachinsky unless it's already Kachinsky, in which case we tell them to change it to another one of the standard ones.

From @gravelweb on April 10, 2016 22:36

The mini-map feature is not working properly for 1v1. All activity seems to be happening at the top right, outside the boundaries of the map. This doesn't seem to be an issue in 2v2.

Copied from original issue: dsjoerg/ggtracker#19

@nickelsen how would you like to be credited on the FAQ? I was going to write Anders Nickelsen built ggtrackerstack and initiated active development for the LotV era, with additional contributions from @gravelweb.

@gravelweb how would you like to be credited? Do you have a twitter or should I just refer to you as @gravelweb @ github?

Example match: http://ggtracker.com/matches/6243833

Has been broken since LotV

The old Spending Quotient formula was built for pre-LotV numbers.

For the LotV era, the formula should be updated to have a 1.4 in it, the pages that mention the formula should be changed, and the calculator page should be changed too:

http://ggtracker.com/spending_skill_stats#?race=protoss&gateway=am

Fabian writes "... but for a few weeks in all games that I upload the particular time I reach 1 Base Mineral Income is calculated wrong (so I get the bronze badge all the time). At the twitter accunt you told at April 8th that economic benchmarks should be OK again, but not for me. I tried to delete all games I uploaded so far and uploaded a few new ones, but this didn't change the behavior.

I play HotS, maybe it is calculated wrong because of the increased worker number you start with in LotV?

My account: http://ggtracker.com/players/1678992/farbeyon
Example replay from 2 days ago: http://ggtracker.com/matches/6622147

I would be very glad if you could look into this, so that one can rely on the calculations of GGTRACKER again. Thank you very much!"

I took a quick look and I believe the problem is that the wrong abilities are being picked up by the replay. For example, one game I'm looking at has a Terran using the 'ChronoBoost' Ability.

issueYY.SC2Replay.zip

From @dsjoerg on August 17, 2014 20:45

Could be fun to have a counter somewhere on match and player pages saying that this page has been viewed X times.

Copied from original issue: dsjoerg/ggtracker#3

From @dsjoerg on August 22, 2014 11:52

Copied from original issue: dsjoerg/ggtracker#11

From @dsjoerg on August 17, 2014 21:1

A popular request.

Copied from original issue: dsjoerg/ggtracker#8

From @dsjoerg on September 12, 2014 15:38

I've been using github.com/dsjoerg/DorkShrine for ~6 weeks now to practice my builds and it's been quite helpful.

Copied from original issue: dsjoerg/ggtracker#12

From @toff63 on August 19, 2014 19:33

Nicely show the periods when the play was supply cap and the total time during the game he was supply cap. This is a basic mistake for beginner. Fixing this issue will help player to improve

Copied from original issue: dsjoerg/ggtracker#9

From @j4p3 on January 10, 2016 17:47

P macro mechanic should be updated to reflect new usage. [feature]

Efficiency: the % of chronoboosted time that buildings are being utilized, e.g. for research, production, or warpgate cooldown.

Copied from original issue: ggtracker/sc2reader#8

Hey I really appreciate ggtracker but one thing that I wish I could fix is the APM on the summary of your matches screen. It is very different from the APM shown on the in-game screen after a match is finished, but not by the factor of 1.4 that I've seen referenced in other places where there are 3.0/LOTV bugs mentioned.

Is there any way we can get the APM to be the same as what Blizzard shows us?

BTW I'm willing to help out. Setting up ggtrackerstack now. Are there sample replays that are used for reference/unit testing?

From @kpaleniu on January 1, 2016 17:8

The way time is calculated from LotV replays seems to be incorrect. See the following replay. The replay is actually 14:47 long. The graph on the main page says the match lasted 20:43. Is this a known issue?

Copied from original issue: dsjoerg/ggtracker#16

From @toff63 on August 19, 2014 19:33

Nicely show the periods when the play was supply cap and the total time during the game he was supply cap. This is a basic mistake for beginner. Fixing this issue will help player to improve

Copied from original issue: dsjoerg/ggtracker#9

Looks like queueing injects causes the previous inject to be unregistered.

sc2parse/plugins.py:1153 (ZergMacroTracker)

        if target_hatch_id not in owner.hatches:
            target_hatch.injects = [event.frame]
            owner.hatches[target_hatch_id] = target_hatch
        else:
            # If not enough time has passed, the last one didn't happen
            if event.frame - target_hatch.injects[-1] < INJECT_TIME:
                print "Previous inject on {0} at {1} failed".format(target_hatch, target_hatch.injects[-1])
                target_hatch.injects[-1] = event.frame
            else:
                target_hatch.injects.append(event.frame)