46 replies to this topic

[evilC]

Personally, I would separate the technique used to assemble the data, and the technique used to turn that data into a graph.
ie have one bit of code that rips the data out of the game, then release that raw data (or the code to rip it) plus the bitmap renders as you do.
It should be then fairly easy for website owners to take that data and use it to make nice interactive graphs.
One of the nicest ones I have found is this - lets you pan and zoom the graph like it were a google map.

[evilC]

Oh hang on, just stumbled on this.
Panning and zooming of charts with google charts: https://code.google....e_configuration

Plus this one is in google code playground, so you can just edit code to make your graph right in that web page.

[Phaesphoros]

For anyone interested in helping evilC and me making some interactive graphs,

here's the github repo

and a preview

[Tolkien]

Bump and thank you for assembling this information.

[evilC]

Sorry for being so absent on this, had some other stuff come up.
I had a look to see about adding tooltips, and it is maybe not quite as simple as I had imagined - especially as we allow pan and zoom.
The only data I can get on hover over a line is mouse x/y pos within the chart pane, so we would need to come up with some way to convert mouse coordinates to the value at that point on the line.
One solution may be to pre-generate dots on the line which can be mouseovered to show a tooltip. I found an example of that here, so we may be able to use a technique like this as the only values that would be relevant would be the ones for each engine size (ie hovering near 301 is pointless as there is no 301 engine).
The dots could get cluttered though, so we may need code to detect when one dot is on top of another and merge the overlapping tooltips into one.

[Phaesphoros]

evilC, on 08 August 2013 - 04:54 AM, said:

Sorry for being so absent on this, had some other stuff come up.
I had a look to see about adding tooltips, and it is maybe not quite as simple as I had imagined - especially as we allow pan and zoom.
The only data I can get on hover over a line is mouse x/y pos within the chart pane, so we would need to come up with some way to convert mouse coordinates to the value at that point on the line.
One solution may be to pre-generate dots on the line which can be mouseovered to show a tooltip. I found an example of that here, so we may be able to use a technique like this as the only values that would be relevant would be the ones for each engine size (ie hovering near 301 is pointless as there is no 301 engine).
The dots could get cluttered though, so we may need code to detect when one dot is on top of another and merge the overlapping tooltips into one.

I've already thought about this and implemented it slightly different: If those points overlapped, there seems to be no way to propagate the mouseover-event in svg from one to the other, as they're siblings hierarchically. One could make an exhaustive hierarchy out of this by grouping all lower z-order levels ([pre]<g><path /><g><path /> <!-- ... --> </g> </g>[/pre]), but this isn't nice either nor does it help deciding which node is closer to the cursor.

Therefore, I've just made an invisible rect overlay for the mousemove (and scroll) events and find the data point closest to the mouse cursor. This solves the problem but for one data point, where there's an exact match of speed AND payload between CTF and DRG/QKD o.O
But as the algorithm iterates over all lines, it's simple to find all points closer than, say, 5 px, and merge their information.

See github repo / preview, links above.

[pulupulu]

looking forward to KTO update. Very curious where 55 tonner place.