History Enhancements

[GoogleCodeExporter]

I've been thinking about the history worker, and how to improve it.  I don't 
really use it as is, and I'm not sure others do either.  Here is what I would 
like see for it:

Change time unit from hourly to daily.  I'd like to see my stats on a daily 
basis.
Add chart for monsters killed per day - I've already added the tracking data 
into the Monster worker.  Just needs to be graphed with purty colors.
Add levels per day chart.  Average levels/day would be great to see.
Add FP earned per day chart
Change income to show income per day instead of hourly.
Add income from land sales into income chart.  A large portion of my income is 
from Land

Do these sound good?  Other thoughts?

Original issue reported on code.google.com by 0Artifi...@gmail.com on 2 Jan 2011 at 6:48

[GoogleCodeExporter]

I think some things are still useful as hourly values vs daily values, but why 
not both? Small resource pool players may have more use for hourly than large 
resource pool players. Plotting overall level ups would be best handled by a 
daily or even a weekly graph. There could be hourly granularity data stored in 
one element off the root of data, say h72, another for daily, say d60, yet 
another for weekly, say w52.

I know that the income estimation in Bank and Land currently make some use of 
History data for hourly income to plan short term income gains, things that may 
not be handled as well with larger granularity increments. LevelUp uses it to 
guesstimate the hourly experience gain, which can fluctuate in the short term 
depending on your use of energy on quests or monster, or whether or not you are 
buying refills in a given span or not. I wouldn't want my income or level up 
planning skewed for a month or two because of my play patterns during Arena or 
some such, but certainly it should reflect that during Arena, without needing 
weeks to gather enough history.

I think there's a good case for several granularities of data storage there.

Original comment by lur...@hotmail.com on 2 Jan 2011 at 7:28

[GoogleCodeExporter]

I think changing storage to per-day (or some other granularity) would be 
difficult to do if it was for some data and not others.

On the other hand - the only thing that cares about the "per xyz" display is 
the user, so how about improvements to the Charts / dashboard page itself.

Having a quick look at History.makeGraph - might change the third arg to an 
object, then it can have better per-graph options.

The graphs that are in there currently are the "coded this cool new thing and 
we need something to show for it" ones - so they definitely could do with some 
tweaking.

I'd like to see the graphs in there maybe have two select boxes. The first 
would be the list of known graphs (so need to come up with more) - the first 
option being a dash etc, and the second being "per hour / per day". When you 
turn on one graph you get another pair of options below for another graph so 
users can have as many, or as few, graphs as they want.

There's a definite positive reason for getting it done - and I'm sad to say 
that some of it has been on my todo list for a while lol

Original comment by RycochetTM on 2 Jan 2011 at 1:14

• Added labels: Component-UI, Worker-History

[GoogleCodeExporter]

i think a good idea for history is the storage of all loot drops with % for 
every monster killed... if all is storaged in a central online server db, 
sended from all scripter user is really great

Original comment by carlo.so...@gmail.com on 2 Jan 2011 at 11:41

[GoogleCodeExporter]

History itself is a purely number-orientated worker. It's designed to let you 
perform mathematical operations on things that have happened (and will probably 
remain so). Storing other types of data, such as types of loot drops (as 
opposed to X common, Y uncommon, Z rare) is outside it's abilities etc.

Talking about this with lurgid definitely makes it worth adding different 
granularities.

Currently it stores 168x hour (1 weeks worth), but thinking it might be worth 
adding 31x day and 52x week granularity.

There is also a strong case for untyped data - ie, a FIFO type queue of 
undetermined length.

I'm planning to change the storage from the current Object(hour:{key:value, 
...}) type to an Array based system.

Access to types should remain almost identical, however a "setup" function will 
exist for new types - to specify whether it's hour/day/week and several other 
options to be determined for display etc.

Original comment by RycochetTM on 9 Jan 2011 at 7:38

• Changed title: History Enhancements
• Changed state: Started