View Single Post
05-04-15, 04:43 PM   #4
zaifon
A Defias Bandit
Join Date: May 2015
Posts: 3
Originally Posted by SDPhantom View Post
What's happening is all the events are firing at the same time, but as the UI engine only runs on one thread, it can only process one at a time in completely random order. One thing I'm seeing though is all the bounces are using the same timestamp, perhaps you can use that to differentiate the separate casts.
The problem (and please correct me if I've understood wrong) is that I'm looking for a heavily event-based functionality. The best way I could explain this would be the following schema:

1. Addon detects a successful Chain Heal.
2. Store each of the chain heal hits inside a table (since I'll otherwise have to react on each hit individually)
3. Display the total amount of hits, within the timeline this would be preferable to happen as soon as possible after the UNIT_SPELLCAST_SUCCEEDED event.

I could do a check for a timestamp from each combat log event, but I wouldn't get the data regarding the previous cast until I've finished the next one (as that particular function only fires once a combat log event has fired).

I attempted to gather a timestamp from the UNIT_SPELLCAST_SUCCEEDED, but I couldn't find a way of getting one without generating one myself, through the time() api, which seems highly unreliable. I'm also not quite sure what I would do with the results.

Please let me know if I've misunderstood you, or perhaps aiming for an impossible solution.

Originally Posted by sirann View Post
One thing you may want to do, completely unrelated to the problem you're trying to tackle, is switching to:
local _, _, _, _, _, etc = ...
the code may not look as tidy with all of the empty _ variables, but the cpu impact compared to using select(#, ...) should be pretty noticeable, especially if you're poling for chain heal hits in the combat log
This is great, I will definitely try this out, see if I can perhaps squeeze a couple more hits from the combat log before the UNIT_SPELLCAST_SUCCEEDED fires.

On a separate note, whilst still on the general topic. I stumbled upon the OnUpdate functionality, and perhaps a separate solution. I'm not quite familiar with resources and how heavy certain functionality will be on the target system, but my briefly planned solution could perhaps be the following.

Remove the UNIT_SPELLCAST_SUCEEDED event-listener, instead provide a OnUpdate function, perhaps tie it in to half of the approximated cast-time of Chain Heal or whatever seems appropriate. Save the chain heals by their timestamp and keep updating the actual frame (the UI component) with the latest set of hits/data.

I'd probably need to decide around garbage collection and more, unless that's taken care of by the engine.

Could this approach perhaps work? Whilst considering it, the only potential issue would be jerkyness of the data displayed on the screen, since it wouldn't be updated after a cast, but from 0 seconds to whatever interval it ends up being.
  Reply With Quote