Announcement

Collapse

Forum Rules

  • No flaming or derogatory remarks, directly or through insinuation.
  • No discussion, sharing or referencing illegal software such as hacks, keygen, cracks and pirated software.
  • No offensive contents, including but not limited to, racism, gore or pornography.
  • No excessive spam/meme, i.e. copious one liners in a short period of time, typing with all caps or posting meme responses (text/image).
  • No trolling, including but not limited to, flame incitation, user provocation or false information distribution.
  • No link spamming or signature advertisements for content not specific to Dota 2.
  • No Dota 2 key requests, sell, trade etc.
  • You may not create multiple accounts for any purpose, including ban evasion, unless expressly permitted by a moderator.

  • Please search before posting. One thread per issue. Do not create another thread if there is an existing one already.
  • Before posting anything, make sure you check out all sticky threads (e.g., this). Do not create new threads about closed ones.
  • It is extremely important that you post in correct forum section.

  • Balance discussion only in Misc.
  • All art related (such as hero model) feedbacks go to Art Feedback Forum.
  • All matchmaking feedback should go here: Matchmaking Feedback
  • All report/low priority issues should go here: Commend/Report/Ban Feedback
  • No specific workshop item feedback. These should go to workshop page of that item.
  • When posting in non-bugs section (such as this), use [Bugs], [Discussion] or [Suggestion] prefix in your thread name.



In case you object some action by a moderator, please contact him directly through PM and explain your concerns politely. If you are still unable to resolve the issue, contact an administrator. Do not drag these issues in public.



All rules are meant to augment common sense, please use them when not conflicted with aforementioned policies.
See more
See less

Known bugs

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    More ability stuff that I'm not 100% sure is a bug yet

    I can't figure out what the "time" under abilities actually corresponds to. Results seem inconsistent using both the Replay clock and the In-Game clock

    First I looked at

    match: http://api.steampowered.com/IDOTA2Match_570/GetMatchDetails/v001/?key=<>&match_id=119646674
    Slot: 132, Treant Protector
    Level 1 Ability Time: 143
    Mode: All Pick

    In the replay he skills his ability at 2:11 on the Replay Clock, -1:13 on the game clock. No indication of any swapping occurring after the first skill point.

    match: http://api.steampowered.com/IDOTA2Match_570/GetMatchDetails/v001/?key=<>&match_id=119654298
    Slot: 132, Faceless Void
    Level 1 Ability Time: 153
    Mode: All Pick

    In the replay he skills his ability at 2:01 on the Replay Clock, -1:02 on the game clock. No indication of any swapping occurring after the first skill point.

    Replay Clock should have been 2:21, so it's out. Game Clock appears potentially working here. 62 more seconds should be 0:00, so any entry with Ability Time: 215 should skill their ability at 0:00.

    match: http://api.steampowered.com/IDOTA2Match_570/GetMatchDetails/v001/?key=<>&match_id=119638552
    slot: 4, Riki
    Level 1 Ability Time: 215
    Mode: All Pick

    In the replay he skills his ability at 3:16 on the Replay Clock, -0:21 on the Game Clock. No indication of any swapping occurring after the first skill point.

    Expected roughly 0:00 on Game Clock but did not get it. Replay Clock should have either been 3:23 relative to game 1 or 3:03 relative to game 2.

    Whatever the case, Ability Time definitely takes into account pre-game setup. http://api.steampowered.com/IDOTA2Match_570/GetMatchDetails/v001/?key=<>&match_id=114355828 is a CM game and every ability time is over 600.

    Ideally, I would prefer Time entries to be relative to a fixed point that is the same in every game regardless of the game mode, like 0:00 on the Game Clock. First Blood appears to follow this, but it appears to get recorded as 0 for every game where First Blood takes place before 0:00. If negative numbers aren't possible then there's a trade off to this recording scheme, but personally I wouldn't mind losing the ability to detect how long a player delays their first point if in exchange I can now do something like create an accurate distribution of ult pickup timings for a given hero over a wide range of games.

    Besides, as far as I can tell I can't even detect how long a player delays their first point because I can't tell what portion of the Time entry is match setup.

    Comment


    • #62
      I can't figure out what the "time" under abilities actually corresponds to. Results seem inconsistent using both the Replay clock and the In-Game clock
      Did a quick check on match 125419697 . Looked at Brewmaster level 3 (time 285) and Anti-Mage level 9 (time 1012). Looks like those times are the timestamps that are available in the combat log in the replay parser Valve created. I'm not sure if there is a quick and easy way to relate the timestamps to the actual game time or replay time (the way I do it is neither quick nor easy due to lousy coding on my part). I'd start with testing out Bruno's replay parser (available on CyborgMatt's blog... I'm not sure if it has been updated since the initial post) and seeing if you can use the "pause" output from his parser to piece the timestamps to the actual game time. If not, maybe that's something Bruno can add to future iterations or something that someone who is working on a parser in this thread http://dev.dota2.com/showthread.php?t=21268 can help out with.

      Hopefully there's an easy solution. If there's no easy bridge from timestamp to game time and if the time in the abilities_upgrades depends on knowing how many pauses are in the game and that pause data is not available in the API then the API time won't be that useful unless the replay salt is added back in.
      datdota.com -- Dota 2 Stats for the Professional Scene

      Comment


      • #63
        Originally posted by Wyrm View Post
        [*]When using XML in GetMatchDetails and GetMatchHistoryBySequenceNum, <ability> gets used as both the grouping for each skill point selection as well as the listing for what ability gets selected.It would be convenient if they could use different tags (eg "ability_id" and "ability").
        Actually this one is pretty major -- this breaks deserialization using the XmlSerializer class. Basically what happens is you need to create your classes contract like so:

        public class player
        {
        <.etc.>
        public ability[] ability_upgrades;
        }

        public class ability
        {
        public int ability;
        <.etc.>
        }

        but you can't do this because you can't have a variable called "ability" when the class is called "ability". To work around this I've had to push every xml response containing this through a fixer that changes it to match what we get with the players nodes (ie <abilities> <ability> </ability> </abilities>). I'm sure people would scream in horror if they saw how I was doing this.

        Another thing I've run into is data inconsistency. For example when trying to create constraints in my database to ensure I'm inserting clean data, specifically related to a FK constraint on hero_id with data from the getHeroes API and match details data hero_id. Some match players from earlier matches are shown as playing hero_id 0 which doesn't exists. So far I've seen about 61 matches like this (#497, #501, #2943, etc etc).

        I've also run into weird edge cases on data values. I was using int (both in code and sql type size) for things like tower_damage and hero_healing but had to convert to long/bigint when I ran into matches where those values overflowed. See match #240299 or match #59622. For match 59622, apparently Earthshaker did 4294967295 tower damage, ending at level 16 with items 34, 178, 73, 1, 29 (don't know what items those are yet as I haven't added this to my database). I suspect this might be a valve dev pushing a custom "fun" button or something.

        Comment


        • #64
          Looks like you're using .NET. You can save yourself some headaches with http://msdn.microsoft.com/en-au/libr...attribute.aspx and it's friends.

          Comment


          • #65
            Have added demand to everything in there, and a few reasonings - post if you think I'm vastly wrong on anything. Will work on putting detailed descriptions into separate sheets over the next week or so hopefully (any other volunteers to help still welcome!)

            Comment


            • #66
              Originally posted by Phantasmal View Post
              Ideally, I would prefer Time entries to be relative to a fixed point that is the same in every game regardless of the game mode, like 0:00 on the Game Clock. First Blood appears to follow this, but it appears to get recorded as 0 for every game where First Blood takes place before 0:00. If negative numbers aren't possible then there's a trade off to this recording scheme, but personally I wouldn't mind losing the ability to detect how long a player delays their first point if in exchange I can now do something like create an accurate distribution of ult pickup timings for a given hero over a wide range of games.
              Fixed point ? In fact, you just need to know the relative point. Ask Valve to include DT_DOTAGamerules.m_flGameStartTime in the API.

              Code:
              tick(5667) type(Preserve) name(DT_DOTAGamerulesProxy)
              	DT_DOTAGamerules.m_fGameTime: 207,0486
              	DT_DOTAGamerules.m_nGameState: 5
              	DT_DOTAGamerules.m_flGameStartTime: 207,0486
              	DT_DOTAGamerules.m_iFoWFrameNumber: 6

              Comment


              • #67
                What I mean by fixed point is that I want a way to convert the time related API results to something that is consistent across games. For instance, if I can know precisely how long after 0:00 a player skills their 8th skill point I can estimate whether they had been receiving solo exp, duo exp, or support exp (ignoring the hopefully rare cases of players substantially delaying their point assignment). If item purchases/selling were included in a similar manner to skill assignments you could also generate an approximate farm acceleration rate for every match without having to parse all of them.

                But anything like this would be dependent on some way of being able to establish the API timings relation relative to the game clock. If what you're suggesting can easily accomplish this then great. I'm not picky about the method so long as it's practical to repeat over a large set of matches. If GameStartTime is what it appears to be then that should be fine.
                Last edited by Phantasmal; 02-19-2013, 12:42 PM.

                Comment


                • #68
                  barracks_status_dire is a copy of barracks_status_radiant again.

                  Comment


                  • #69
                    Originally posted by takua108 View Post
                    barracks_status_dire is a copy of barracks_status_radiant again.
                    Is it? I 'm not seeing any incorrect data. When was it causing a problem, what matches showed as copies?

                    Comment


                    • #70
                      Originally posted by Aardvarki View Post
                      Is it? I 'm not seeing any incorrect data. When was it causing a problem, what matches showed as copies?
                      Well either I'm insane or it's fixed now. I'm working on a dotabuff-like stat website thing and my buddy played a game last night where he was on the radiant, and they won, destroying all dire buildings, but the radiant had their top and bottom rax taken down. When I pulled up his game on my stats site thing, it showed that the radiant and dire both had top and bottom rax up.

                      So I deleted that database row and checked it again this morning and now it looks fine... so either somebody saw by bug report and fixed it, or it was never broken all along and I'm a crazy person, or it's a weird, intermittent bug that only happens sometimes.

                      Comment


                      • #71
                        Okay no, I'm not crazy, the bug is happening intermittently. Check http://api.steampowered.com/IDOTA2Ma...h_id=152325463 . I'm seeing 51 for both barracks_status_radiant and barracks_status_dire right now.

                        Comment


                        • #72
                          You're right. I see 51 for both barracks_status teams and upon watching the reply, the dire did have all of their barracks destroyed by the end of the game.

                          You said the other case you found was showing both 51's too (mid rax down, others up), right? Is it only occurring on 51's? Is there any link between the games that are incorrectly reporting?

                          I see that the same match is showing both 51's in GetMatchHistoryBySequenceNum too. Everything else looks correct, however.

                          Comment


                          • #73
                            I'll update the first post when someone can narrow down exactly what the new behaviour is xD

                            Comment


                            • #74
                              Originally posted by Aardvarki View Post
                              You're right. I see 51 for both barracks_status teams and upon watching the reply, the dire did have all of their barracks destroyed by the end of the game.

                              You said the other case you found was showing both 51's too (mid rax down, others up), right? Is it only occurring on 51's? Is there any link between the games that are incorrectly reporting?

                              I see that the same match is showing both 51's in GetMatchHistoryBySequenceNum too. Everything else looks correct, however.
                              Well I was talking about the same match, actually. And as of this exact instant, that match is back to 51 for the radiant, and 0 for the dire. I'm so confused...

                              Comment


                              • #75
                                "season": 7,
                                "radiant_win": true,
                                "duration": 4020,
                                "start_time": 1363675157,
                                "match_id": 152325463,
                                "match_seq_num": 138763169,
                                "tower_status_radiant": 4,
                                "tower_status_dire": 0,
                                "barracks_status_radiant": 51,
                                "barracks_status_dire": 51,
                                "cluster": 122,
                                "first_blood_time": 51,
                                "lobby_type": 0,
                                "human_players": 10,
                                "leagueid": 0,
                                "positive_votes": 0,
                                "negative_votes": 0,
                                "game_mode": 3
                                Odd. I still see 51/51. Wyrm, I don't think there's any rhyme or reason to it. This match is definitely showing incorrectly for me. Can you update the first post?

                                Comment

                                Working...
                                X