teel / stasiscl

Automatically exported from code.google.com/p/stasiscl
0 stars 0 forks source link

RFE: Re-estimation of overheal #90

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
So.. yeah.. overhealing. Who always gets the blame? The guy with the 
slightly longer cast.. and the guy with 0.1s more latency.

Right now it's hard to tell the difference between a flawed strategy (too 
many healers per target) or someone that needs to L2P.

I'm thinking it would be feasible to average out overhealing numbers in an 
offline parser like stasiscl; something along these lines:

Keep track of the needed healing for a target over the past ~0.5s (i.e. on 
the heal that healed him to full, scan heals backwards for 0.5s as long as 
you see non-overhealing). Say you get 10k healing needed after a big nasty 
blow from a boss. Now for the overheal occuring for that heal, and all 
heals for another 0.4s (total 0.9s window i.e. < gcd for uberhasted 
people), compute the factor of actual healing needed vs actual healing 
received and blame all healers equally.

As for the actual algorithm, I'll non-helpfully dump that on you 
squarely :)   Though I imagine it'd be something along the lines of 
keeping a list of the healers+healing done tuples from the start of the 
0.5s+0.4s window and assigning healing/overhealing at the end of it. This 
window would obviously terminate early if a heal is seen to actually 
_heal_ again, and not just overheal.

Yes, it's probably somewhat of a bitch to code. But wouldn't it rock? :)

Original issue reported on code.google.com by mikeclue...@gmail.com on 29 Jan 2009 at 3:56