core
core copied to clipboard
odota
Improve item timing data aggregations (histogram?)
Was directed here by one of your guys on reddit, no idea how this place works and created an account just to type this out so forgive me if I'm doing something wrong here. To my suggestion;
The only item timing data for all games collectively (which can of course by search on a per hero basis among a couple of other options) that is available is an average item time, and the number of times that item has been bought. If an item is ever bought in a different order for a certain hero then that average item timing becomes useless in terms of trying to hit targets for items in game.
What I'm after is item timings where the only data points collected would be the ones specified by some sort of similar drop down menus to the ones currently used in other areas.
This could be done in a number of ways, taking the item example of orchid:
-Able to select items that the player already has when orchid is bought. For example ticks to 'power treads and bottle' would only select orchid timings for when the player has only these items. Perhaps items such as tango and stick could have a yes&no option whereby it wouldn't matter whether these items are owned or not in terms of what data points are selected
-Able to select items based on the cost of the current items owned when the orchid is bought. Here you would have a maximum and minimum value to be selected.
Graphs of how these item timings vary over time would also be great.
This would allow for accurate data to be used in item timings, as well as comparisons between item builds as to what helps best in networth progression of a hero - whether item timings are faster with phase boots over treads for example.
Ty for your time :)
The simplest way to do this, I think, would be to assign an "order" for each item purchase, which is the nth "big item" bought by the player (where a big item is >1500 gold or something).
Then a potential filter option would be to compute averages where (orchid, for example), is item 1, 2...n.
There is a potential performance impact, since we need to iterate through the items bought by each player. Doing this for ~2000 matches a player, 10 players a match, ~30 items bought each can take a long time... O(600000) operations? We could attempt to run this at parse insertion time, or run a migration that computes a mapping of item to order in which it was bought.
The problem with the approach you describe above (and somewhat also affecting this approach) is that it limits the sample size drastically. In most cases applying too many filters means that there will only be <10 or so games, which limits its usefulness.
It would certainly be a massive improvement to do it this way, and its something I thought about. I'm not a fan however of defining an item as 'big'. Say if one game I unusually completed treads before I bought orchid, and another I even bought 2 nulls, a wand, an urn and completed treads before finally buying the orchid- this system would have no idea and the item timing produced would only be a rough figure.
We could attempt to do some kind of computation based on GPM.
You're right that differing item build order makes strict item average build times kind of useless, and that trying to index builds by "big item" misses builds that do a lot of smaller items first.
I think that typing an a max/min networth would be a little unintuitive, although it's one of the easier filters. It would be up to the user to draw the right line so that they include the games they're trying to filter. (I'm also not sure how the UI would look, the user would have to enter a net worth and select an item--"games where I bought an orchid when my networth was less than/greater than x"
Doing the "already have" items approach is computationally expensive. For each player, we have an array that logs all the item purchases they make. We would need to iterate through the array until we hit the target item, and check each element to see if it's one of the user's specified items.
Really, getting item build times is just a way of measuring farm. Perhaps we should just be computing something like the average GPM at the time an item is obtained?
This will require some thought and planning before we can get to work on an implementation.
Hello, I was parsing some replays played by Admiralbulldog, and the screen just kept loading without ever successfully parse it through. This happened before as well. Is this simply a periodic thing, or something is wrong?
The service can sometimes be unavailable. If it happens after several days of retries, there might be an issue.
Thank you for the reply! What do you mean by "after several days of retries"? Like, after several days of parsing, there can be like a "downtime" for the website?
I'm not upset or anything, just trying to make sure that everything on my end is ok.
If you try to parse a replay by ID, and it fails, try again in a few hours. If it keeps failing after 3-4 retries there is probably a problem.
On Thu, May 28, 2015 at 3:15 PM, lulu2199 [email protected] wrote:
Thank you for the reply! What do you mean by "after several days of retries"? Like, after several days of parsing, there can be like a "downtime" for the website?
I'm not upset or anything, just trying to make sure that everything on my end is ok.
— Reply to this email directly or view it on GitHub https://github.com/yasp-dota/yasp/issues/441#issuecomment-106615449.
It will also fail ifbthe replay has expired (7 days since played). On May 28, 2015 6:23 PM, "Howard Chung" [email protected] wrote:
If you try to parse a replay by ID, and it fails, try again in a few hours. If it keeps failing after 3-4 retries there is probably a problem.
On Thu, May 28, 2015 at 3:15 PM, lulu2199 [email protected] wrote:
Thank you for the reply! What do you mean by "after several days of retries"? Like, after several days of parsing, there can be like a "downtime" for the website?
I'm not upset or anything, just trying to make sure that everything on my end is ok.
— Reply to this email directly or view it on GitHub https://github.com/yasp-dota/yasp/issues/441#issuecomment-106615449.
— Reply to this email directly or view it on GitHub https://github.com/yasp-dota/yasp/issues/441#issuecomment-106616816.
Also, please open a new issue rather than adding to this one--this is a different topic.
On Thu, May 28, 2015 at 3:33 PM, lulu2199 [email protected] wrote:
Alright. I will check in a few hours.
— Reply to this email directly or view it on GitHub https://github.com/yasp-dota/yasp/issues/441#issuecomment-106618729.
Alternative approach. . . we could display histograms (similar to those we already have), but each one plots the time an item was built in a match.
Then we get a visual of approximately when an item is built on average, and winrate when it's built at those times.
The thing that's blocked me from implementing this so far is the prospect of programatically adding aggregators to aggregator.js.
Presumably, we would want a histogram for purchase times of every item in the game (there are roughly 200). That's a lot of data to store and could impact load times/cache sizes.
An option is to make a shorter list of items we care about timings for, but this likely differs significantly between heroes.