Page 3 of 14 FirstFirst 1 2 3 4 5 13 ... LastLast
Results 21 to 30 of 138

Thread: Known bugs

  1. #21
    Basic Member jimmydorry's Avatar
    Join Date
    Dec 2012
    Posts
    814
    Glad we are having a discussion to better realise what we want out of the data.

    Quote Originally Posted by adrianlegg View Post
    regarding ward location grouping
    Far better would be to just have a per hero list : wards {is_obs_or_sentry, time, x,y,} and then You can parse it Yourself whether it was "recommended" by any means, or not. (Just do Your own work by finding "zones", no dev should do it for You)
    While it is true that one could go parse the map and figure out where each X,Y is... it would be computationally expensive to do this on millions of matches. I can see some neat things you could do with it though. However, what happens when future maps are made or existing ones modified? You would need to re-do the entire parsing again. I am also unsure how easily player metrics based on warding position could be calculated given just co-ordinates. I think that there should be some degree of facilitation by the API.

    A properly design map would hopefully have many regions in it (Jungle1_Radiant, Jungle2_Radiant, Radiant_Ancient, ...). It would just be a matter of having an enum set and expanding as necessary.


    Quote Originally Posted by adrianlegg View Post
    regarding hero kill breakdown
    I'd much more prefer this simple format: { hero_id; killed_by_player; time }
    Enough to track:
    - number of double/triple kills
    - longest streaks
    - ending someone streaks
    With perhaps 2 special values for neutrals/roshan perhaps instead of player. (denies would be other teammates so it fits)

    Having "dmg dealt", as in "Kill Cam" window, gives low quality of information (for statistic purposes). If You go into a fight, lose 70% hp go jungle, then 1min later, some invi guy deals 200dmg and takes the kill, You would have only 200dmg then.
    While an immediate application would be to track streaks etc, why not expose the same data we get in game too? Too much data in an API can't be bad, as long as it is segregated enough that only the people that want it can get it.

    What happens if someone wants to track how well the team works together?

    What about heroes that are suited to kill-stealing?

    What happens if you want to be able to explore how the teams fair in team fights; starting with initiation all the way to kill?

    By your own specification, the kill would say X dmg by creeps and 200 by bounty hunter.

    Quote Originally Posted by adrianlegg View Post
    regarding spell usage breakdown
    While in theory this sounds nice, in practice without context those means little.
    How would You track did Echo Slam failed, or hit hero?
    What would You gain from non-dmg skills?
    On their own, they are poor information, which takes a lot of space.
    I took Dota Replay Manager and parsed example replay. Sum of all abilities used is 1251. Even with {ability_id, time} it's like 10-12 bytes => 12kB of almost-useless data.
    If You don't have hero position in time and/or combatlog, You might as well just have something like : echo_slam:5times. But then again what's the point.
    Even just a breakdown usage of the number of times the spells were cast (including items) would have direct relevance. Icing on the cake is to get a summary of effect too. (I.E. a cumulative count of total damage inflicted, total stun time, etc.)

    From a pure player evaluation perspective, if you end up only casting Echo Slam 5 times in a game... this is useful to know. Via the API, people could be trying to build a more complete picture of how players are reacting/playing with characters. If we did not need this data, then surely we could be just as happy only knowing win rates?

    Quote Originally Posted by adrianlegg View Post
    Regarding:
    - Damage received
    - Total damage to creeps
    - Total hits (not missed)

    Those I find low priority (nothing personal, I just don't need them at all):
    And that is where constructive discussion ended.

    I am sure you can appreciate that some characters can be more of a "tank". Understanding how much so is useful.

    Some characters are suited to pushing, and not so much teamfights (Brood, NP, etc.)

    Figuring out things like LH to hits on creeps is useful for determining player skill. (Especially if broken down into 10min blocks so we can see early game)

    Figuring out things like number of hits on other players is useful too.

    I don't understand the mentality of trying to separate things that I want from the API from things everyone will want... only to shoot down ideas that in the end only you might not like and others would.

    ------
    Thoughts on your requests. Some of those seem quite useful. However, I won't shoot down the ideas I think are stupid, as that is not what a wishlist is about.

  2. #22
    Basic Member
    Join Date
    Nov 2011
    Posts
    37
    I'm going to add something terribly simple in comparison, but given that ability level times are timestamped in seconds after the replay began, it would be really nice to have a "game_start_time" field saying how far along the replay the game actually starts (0:00 clock time, or -1:30, whichever sounds best) , as particularly in CM matches, there's a big difference between replay time and game start time.

    Cheers!

    Bruno

  3. #23
    Basic Member adrianlegg's Avatar
    Join Date
    Mar 2012
    Posts
    568
    At start: I do not want any other ideas to shut down, I just want other issues to have priority.

    And once again - You can't "zone" wards to closed set.
    Here are all valid observer wards locations I put at least few times in my life (green boxes, ignore dots)
    There are obvious ones, situational ones, and those I'd put when I know enemy got sentries to dodge.
    But I'm not restricted to those. (sentries would have way more possible locations) I'd prefer to have my own enums then rely on finding dev, who want's to name them all. (did You check demoinfo replay parser? They already hate their life.)

    Those arguments are invalid:
    - computationally expensive.
    In above image I have probably 30-50 boxes, let's take 50 different zones + even 60 wards per game (unlikely, unless end game picture in base).
    Even in javascript bruteforce check it takes about couple of ms; can be optimized, can be cached for current match.
    It's no way near the 3s it takes to gather WebApi data; and if You care about top-notch perf, You go for binarysearch/kd-trees in any goodJIT/compiled language and got results of microseconds.

    - what happens when future maps are made or existing ones modified?

    Exactly same stuff which would happen with WebApi enums. -> someone has to update their data-scheme. It's not specific to simple list solution.
    You might try to impose it on devs, but there's no need for this. You would just need first match_id that is in "changed" map.

    It's not like I wouldn't like "some degree of facilitation ". I just think it's not possible in any correct way, and prefer simple solution on which I can work.

    why not expose the same data we get in game too?
    To cut it simply: because it would take less work to provide a copy of replays with all personal data/chats/maplines/steamaccounts stripped out.
    Again - I'm not against it. I just think there are 3-5 simple features we can get this week, and I'd prefer those (like Bruno's!)

    What happen..
    What about..
    What happen..
    Nothing. I can accept I can't not do that yet, and without full (combat_log+ units position over time), I won't be able to track team performance ever.

    By your own specification, the kill would say X dmg by creeps and 200 by bounty hunter.
    Which is useless, but I implied it myself - no need to copy my words. You do not provide any "simple" alternative, and as such, I would postpone this feature. I'm not offensive, but if there are no arguments/other solutions, then there's nothing to dispute about.

    casting Echo Slam 5 times in a game... this is useful to know.
    This is example, where our opinions differ. For me, without context (this case: at least other heroes/units position) You can't make anything out of this information. (mb Bruno can!)

    When it comes to any API design I stand by opinion that "good interface" = "provide as little as neccesary, and don't change what You provided". (like in a month, remove skill usage count(echoslam:5) , but provide complete list with all effects, targets,etc )

    And it does speed things up, imagine this week we could have:
    A) wards usage coords, items, roshans
    or
    B) wards fancy enum zones
    It's not unlikely - people who work on WebApi/servers doesn't have to be proficient with map enough to call those zones by themself, so they ask designers, who are busy, delays sums up, etc.

    And that is where constructive discussion ended.
    I just stated my own priorities.
    I also value 10th min mark -cs as good indicator of laning phase performance, but I don't think that every_10_mins_cs field is good API design.
    It's too arbitrary because perhaps in super calculated china-doto they use 6 mins night/day timecycles to determine performance (which makes sense, as heroes laning power depends on vision), not 10mins - You can't come to agreement here.

    And by contrast having all creep kills times seems too over excessive in terms of space(bandwith) used. Ask API about match: 99946042, 2888 total cs (doubt it's highest total) - it's fit either for some additional GetMatchDetailsVerbose, or again, some stripped replays.

    Let's focus on simple stuff, that's my point.
    You gotta FIGHT!
    For Your RIGHT!
    To BUUUGFIX!

  4. #24
    Basic Member
    Join Date
    Nov 2011
    Posts
    149
    jimmydorry I'm inclined to agree with adrianlegg on most of his points. Given how many games are played every minute reducing the size of each report from the API is important and thus data which is of dubious use should not be included.

    The number of times an ultimate was cast is useless without context, more useful would be number of "successful" ultimates used, but that is really subjective. Early game a successful ravage is one which hits 1 or more hero, but late game you want to be hitting at the very least 3 and ideally 5. Ignoring that using a count to estimate performance encourages sitting in the fountain and hitting R every minute, this data is also completely useless on a lot of heroes:
    • Passive abilities (SA, tiny, PL, meepo, ...)
    • Low cd abilities (TS, BH, qop, timbersaw, lifestealer, kotl, TA, ursa, enchantress, ...)
    • Hard to judge impact (kunkka, tide, weaver, VS, DS, Storm, Shadow shaman, 2hd, rubick, Invoker, SD, Bat, Disruptor)

    This feature is something I'd love to see come out of replay parsing, where the full data is available. In the webAPI I don't think it has a place.

    Damage done statistics... This is probably a personal opinion, but I don't see it as useful. Like KDR their main use is to bolster epeen while missing out on a lot of what determines skill, and getting laning phase only statistics is problematic as it's subjective again, and roaming/jungling/solomid/safelane/hardlane hero will have vastly different measures of success. I've added early last hit statistics to the wishlist, but I suspect given the recent Dotabuff fiasco information which is easy to convert into some measure of skill is unlikely to come out any time soon. Again, I think these statistics are far more likely to be useful as part of a replay analyser.

    With regards to wards, the X/Y position is CONSIDERABLY more useful, scalable and easier for all involved. If the devs have to define zones they're liable to miss a few sections - the image adrianlegg posted had a couple of ward placements I've used not included and I'm sure there are plenty more neither of us noticed. If the map changes whatever system is used is going to need adapting, but I'd rather have the full information needed than rely on the Valve devs to get it instantly and perfectly correct - they are after all busy adding a host of other features!

    Bruno - nice suggestion, added to list. I am right that all the other (ie not CV/reverse CM) modes have a set time to start? AP/AR/SD/RD all count down to 0 so there isn't any variation possible I believe...

  5. #25
    Basic Member
    Join Date
    Sep 2012
    Posts
    23
    How to figure out "tower_state" in GetLiveLeagueGames?
    And in general, WHY not the same format as in GetMatchDetails: "tower_status_radiant" and "tower_status_dire"?
    Valve, please start using some standards.
    Same with API call retun's.
    ISteamUser/GetPlayerSummaries return's "response": "players" array, and if there is nothing - array is empty and http status code 200
    IDOTA2Match_570/GetMatchHistory return's "result" and have "status" (which in my opinion is the right approach) + "statusDetail" if something wrong.
    IDOTA2Match_570/GetMatchDetails return "result" and don't have "status". So if i request not existing match "api.steampowered.com/IDOTA2Match_570/GetMatchDetails/v0001/?match_id=1&key=xxxx" i'm getting onlu "{ }" and 500 http error - the same when the API was down.
    ISteamRemoteStorage/GetUGCFileDetails returns "data" and have "status" only if bad request. And for not existing file "api.steampowered.com/ISteamRemoteStorage/GetUGCFileDetails/v1/?key=XXX&appid=570&ugcid=1" i'm getting status: { "code": 9 } and http 404 error.

    And so on....

    Why not have one standard?

    why end user can't check for valid result with 1 if:
    Code:
    $data = json_decode($response);
    if (isset($data->status) && $data->status == 1) {
        if ($data->status == 1) {
            // All OK.
        } else {
            // API problem
        }
    } else {
       // Connection problem
       // Chach http status
    }
    instead i nead specify root node for each api call function, and 101 function to check if something goes wrong - one returns http error, one status with code, one status as array with code in it, and so on.
    API should be simpler! I think Steam API need to implement some kind of standard.
    Last edited by JohnnyAjax; 02-05-2013 at 09:20 AM.

  6. #26
    Basic Member
    Join Date
    Oct 2011
    Posts
    72
    Feature request: In addition to "radiant_name": "Invasion.GiGaByte", (or maybe instead of) have a "radiant_team_number" and "dire_team_number" for each team and an API where we can link the team_number to the name, logo, etc of the team. Then maybe add an option that lets us get match history by team_number.

    Woot! They added it:
    WEBAPI:
    - Added Team query to WebAPI. Query is GetTeamInfoByTeamID, params are start_at_team_id and teams_requested.
    Guess I can call off my hunger strike.
    Last edited by Razumov; 02-06-2013 at 06:29 PM. Reason: API updated
    datdota.com -- Dota 2 Stats for the Professional Scene

  7. #27
    Basic Member MuppetMaster42's Avatar
    Join Date
    Nov 2011
    Location
    Australia
    Posts
    585
    Minor Bug:
    GetLiveLeagueGames uses league_id but GetLeagueListing and GetMatchDetails uses leagueid

  8. #28
    Basic Member RJackson's Avatar
    Join Date
    Sep 2011
    Posts
    121
    Quote Originally Posted by JohnnyAjax View Post
    How to figure out "tower_state" in GetLiveLeagueGames?
    And in general, WHY not the same format as in GetMatchDetails: "tower_status_radiant" and "tower_status_dire"?
    Valve, please start using some standards.
    Same with API call retun's.
    ISteamUser/GetPlayerSummaries return's "response": "players" array, and if there is nothing - array is empty and http status code 200
    IDOTA2Match_570/GetMatchHistory return's "result" and have "status" (which in my opinion is the right approach) + "statusDetail" if something wrong.
    IDOTA2Match_570/GetMatchDetails return "result" and don't have "status". So if i request not existing match "api.steampowered.com/IDOTA2Match_570/GetMatchDetails/v0001/?match_id=1&key=xxxx" i'm getting onlu "{ }" and 500 http error - the same when the API was down.
    ISteamRemoteStorage/GetUGCFileDetails returns "data" and have "status" only if bad request. And for not existing file "api.steampowered.com/ISteamRemoteStorage/GetUGCFileDetails/v1/?key=XXX&appid=570&ugcid=1" i'm getting status: { "code": 9 } and http 404 error.

    And so on....

    Why not have one standard?

    why end user can't check for valid result with 1 if:
    Code:
    $data = json_decode($response);
    if (isset($data->status) && $data->status == 1) {
        if ($data->status == 1) {
            // All OK.
        } else {
            // API problem
        }
    } else {
       // Connection problem
       // Chach http status
    }
    instead i nead specify root node for each api call function, and 101 function to check if something goes wrong - one returns http error, one status with code, one status as array with code in it, and so on.
    API should be simpler! I think Steam API need to implement some kind of standard.
    I've documented tower_state here: http://wiki.teamfortress.com/wiki/We...es#Tower_state - though one thing I'm not 100% on is the order of the ancient towers in that (for both tower_state and GetMatchDetails' tower_status_(?:radiant|dire)), so I'm looking for games that've been won with only 1 ancient tower remaining so I can verify that.

    On the topic of inconsistency, all of the IDOTA2Match methods return different data and in a few cases - some you've pointed out - with different key names. To list a few inconsistencies, because I suppose it's helpful:
    • GetMatchHistoryBySequenceNum returns practically the same data per match as GetMatchDetails (barring one attribute iirc), whereas GetMatchHistory is more just a list of appids to be parsed by GetMatchDetails. By it's name, I would've expected it to return results in a more similar format to GetMatchHistory.
    • GetLiveLeagueGames' tower_state vs GetMatchDetails' (tower|barracks)_status_(radiant|dire)
    • GetLiveLeagueGames returning team information but none of the other methods doing so
    • GetMatchHistory has 'num_results', 'total_results', 'results_remaining', whereas GetMatchHistoryBySequenceNum has none of those.
    • GetMatchDetails -> results -> picks_bans, has the attribute "team" with the values 0 and 1; but instead of a 'winner' attribute matching that format there's the boolean "radiant_win".


    I was also talking with Netshroud and the issue of versioning came up - some changes have been implemented without incrementing the method's version, which could cause some applications that run on the API to cease functioning (properly) without warning. Given the game and API are beta this is somewhat understandable, but nevertheless a concern; I would personally like to have a mailing list where API additions or changes are announced (which would also help me, Lagg, and others' that try to document the WebAPI on the TF2 Wiki), as well as a grace period before changes are implemented so people can plan and update their applications accordingly.

  9. #29
    Basic Member
    Join Date
    Oct 2011
    Posts
    72
    Is there a way to access the in game calendar? If not that would be a nice API feature to have.
    datdota.com -- Dota 2 Stats for the Professional Scene

  10. #30
    Basic Member MuppetMaster42's Avatar
    Join Date
    Nov 2011
    Location
    Australia
    Posts
    585
    Quote Originally Posted by RJackson View Post
    I would personally like to have a mailing list where API additions or changes are announced (which would also help me, Lagg, and others' that try to document the WebAPI on the TF2 Wiki), as well as a grace period before changes are implemented so people can plan and update their applications accordingly.
    +1 - or in stead of a mailing list - a forum that only mods/devs can post in each week that has a list of specific api changes.
    I mean, zoid and danielj and whomever else have been great in posting about changes on these forums, but the problem is that the posts are in different threads and can often get hidden beneath responses - which means that if you don't check the forums for a day or two, it can be easy to miss them.

    So a specific thread in which there can be only update posts from the mods/devs (i.e. no responses from people - if people want to talk about changes they can start a new thread about it!).
    imo this would be better than a mailing list as it will be here (consolidated with all the resources), and it would be available to everyone without needing a subscription - so nobody can complain about missing it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •