+ Reply to Thread
Results 1 to 15 of 15

  Click here to go to the first Rift Team post in this thread.   Thread: ClickBoxHealer - Inspect.TEMPORARY.ROLE

  1. #1
    Soulwalker
    Join Date
    Apr 2012
    Posts
    19

    Default ClickBoxHealer - Inspect.TEMPORARY.ROLE

    I know Inspect.TEMPORARY.ROLE is a temporary solution but for now it's what we have. So the issue I'm having is figuring out at what point this Inspect (or any I suppose) is available to actually be called and pull something that isn't nil. I need it to be at the beginning. Before it loads my config window for the addon but not have to be wrapped in a system.update event. Doing the inspect during an initial login reads back nil values. But doing a /reloadui brings back the proper value. Just not sure what event I can use to get a good value at the initial login.

    Hopefully that makes sense.

    Thanks,

    ~Solsis

  2. #2
    RIFT Guide Writer Noshei's Avatar
    Join Date
    Feb 2011
    Posts
    1,886

    Default

    I would think Event.Unit.Available should be what you want.

    or maybe Event.TEMPORARY.Role would work, as it should trigger during login when the system detects the players role.

  3. #3
    Soulwalker
    Join Date
    Apr 2012
    Posts
    19

    Default

    Should would be the keyword there. On initial login it comes back as nil. I have tested it in Addon.Load.End and Addon.Startup.End. It comes back as nil. It doesn't quit being nil until it hits System.Update.Begin. But when you do a reloadui it is available immediately. So I'm just trying to better understand what is happening so I can get what I need for my addon to do what I want. I'm going to look at some of the other Unit Frame addons and see what else I can find. But right now I'm stumped.

    My workaround is wrapping it in an if then check inside my system.update.begin function, but that's more un-needed work the addon shouldn't have to do every 0.25 seconds.

  4.   Click here to go to the next Rift Team post in this thread.   #4
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Watch for Event.Unit.Available triggering on the player ID. Most of the "inspect stuff about the player" functions require that the player has full availability. Note that due to a bug in the live Availability code, this won't work properly in a party - this is what the 1.9 breaking changes are intended to fix.

    That said, this is a bug, I'll go poke it to make the role event fire appropriately.

  5. #5
    Soulwalker
    Join Date
    Apr 2012
    Posts
    19

    Default

    I'm still kind of new to all of this so I'm not sure how I would use Event.Unit.Available to accomplish this. If I put .Available in my event table then it's going to trigger on every unit that is available all the time. Again causing un-necessary work I would think. Am I making sense? Or am I just not understanding what you are saying I should do? I'm not necessarily asking to have someone code it for me but an example, a reference, anything would be helpful. I'm a little confused.

    Any help is appreciated or any details I can give that would help would be appreciated.

  6. #6
    Soulwalker
    Join Date
    Apr 2012
    Posts
    19

    Default

    Or I can just wait. I wrapped it in some if then checks like I said so it should be fine for now. I'm just trying to make sense of it. Still learning learning learning.


    Quote Originally Posted by Solsis View Post
    I'm still kind of new to all of this so I'm not sure how I would use Event.Unit.Available to accomplish this. If I put .Available in my event table then it's going to trigger on every unit that is available all the time. Again causing un-necessary work I would think. Am I making sense? Or am I just not understanding what you are saying I should do? I'm not necessarily asking to have someone code it for me but an example, a reference, anything would be helpful. I'm a little confused.

    Any help is appreciated or any details I can give that would help would be appreciated.

  7.   Click here to go to the next Rift Team post in this thread.   #7
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Solsis View Post
    I'm still kind of new to all of this so I'm not sure how I would use Event.Unit.Available to accomplish this. If I put .Available in my event table then it's going to trigger on every unit that is available all the time. Again causing un-necessary work I would think.
    Technically, yeah, but it's not nearly as expensive as you'd think. Computers are fast. You want to be careful of things that take a huge amount of computation, but you've just got a few simple conditionals here and nothing more.

    I feel like people tend to put too much work into optimizing the parts of the code that won't make a significant contribution to runtime. A single extra frame displayed on the screen is going to slow things down more than an extra Event.Unit.Available hook, and the UI system is specifically intended for people to toss extra frames everywhere for layout purposes.

    In this case, I'd worry about making it work first, and making it fast later. I'd wager hard money that 95% of your runtime will end up being eaten by ~5% of your code, and this particular part will be such a minor drain that you'll never get around to improving it.

    Be scared of Event.System.Update handlers, not of Event.Unit.Available handlers

  8. #8
    RIFT Guide Writer Noshei's Avatar
    Join Date
    Feb 2011
    Posts
    1,886

    Default

    Quote Originally Posted by ZorbaTHut View Post
    Be scared of Event.System.Update handlers, not of Event.Unit.Available handlers
    That and Inspect.Unit.Detail() it's not bad a couple of times, but get too many in there and you will see a huge drain.

    With my rangefade addon I eliminated a single point where I called Inspect.Unit.Detail() and it saved me about 5-10% cpu usage.

  9.   This is the last Rift Team post in this thread.   #9
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Noshei View Post
    That and Inspect.Unit.Detail() it's not bad a couple of times, but get too many in there and you will see a huge drain.

    With my rangefade addon I eliminated a single point where I called Inspect.Unit.Detail() and it saved me about 5-10% cpu usage.
    Yeah, all the Inspect.*.Detail() functions can be quite expensive - Item is bad as well.

    In theory it should always be possible to avoid calling those functions frequently, the various Event.*'s should be enough to keep your internal state updated. If one of those turns out to be unavoidable, it may be a sign of a missing event or API call.

  10. #10
    Sword of Telara DoomSprout's Avatar
    Join Date
    Apr 2011
    Posts
    876

    Default

    Quote Originally Posted by ZorbaTHut View Post
    Be scared of Event.System.Update handlers, not of Event.Unit.Available handlers
    Zorba, just out of interest, is there something special about System.Update, or are you just referring to the fact that most System.Update handlers tend to be doing expensive polling rather than cheaper event handling?

    I've wondered for a while whether or not processing in System.Update.Begin would cause a bigger hit on FPS than other event handlers, if the game loop was sat waiting to render the frame and not doing much else in parallel.

    - Wildtide
    Last edited by DoomSprout; 06-13-2012 at 11:19 PM.

    Gadgets: Unit Frames and Other Stuff for RIFT

  11. #11
    Soulwalker
    Join Date
    Apr 2012
    Posts
    19

    Default

    See.. this is the part where I start going huh?!

    So I know I dropped the CPU by approx 20% overall from it's original state that I copied off of when I first started learning. I grabbed Rift Healer when the guy quit updating. Started tearing it apart and learning what different functions and events and syntax etc were capable of and how to use them. I cut a lot of the crap out of the core function that is triggered by Event.System.Update.Begin and moved them into other more specific events such as aggro indication, los checks etc. I'm sure there are lots of things I could still do that would help a lot. I'm really at a point where I am going to have to dive deeper and really understand the core of these functions/events and how everything talks to each other etc.

    So just off the top of my head... Should I do something like this:

    Code:
    table.insert(Event.Unit.Available, {cbhUnitAvailable, ClickBoxHealer, "UnitAvailCheck"})
    local cbhua = false
    function cbhUnitAvailable(units)
    if unitLookup("player") == units and not cbhua then
           cbhua = true
           temprole = Inspect.TEMPORARY.Role()
           cbhValues.roleset = temprole
           cbhLoadOptions()
    end
    end
    The problem I'm having is everything in my config window (cbhLoadOptions function and beyond) relies on cbhValues.roleset having a value. So it has to not be nil before I can load the rest of the addon. Which all that's left at this point is the config window and keybinds that are saved for the heal clicking. I store these based upon the role number you are currently in.

    So the root problem of all this and why I'm trying to accomplish this is this: Let's say the last time you were logged in you were using your 3rd role. You stumble across my addon and install it. Well the default value of the roleset variable is 1. But you are in role 3. This obviously causes a mismatch of where it stores anything that you change until you change roles so it will get an accurate role number.

    Hopefully this will kind of help give an overview of what I'm trying to do.

    Thanks for all the responses btw. Sorry I'm kind of slow to understand this.
    Last edited by Solsis; 06-14-2012 at 03:00 AM.

  12. #12
    Plane Walker Imhothar's Avatar
    Join Date
    Feb 2012
    Posts
    439

    Default

    Quote Originally Posted by ZorbaTHut View Post
    In this case, I'd worry about making it work first, and making it fast later. I'd wager hard money that 95% of your runtime will end up being eaten by ~5% of your code, and this particular part will be such a minor drain that you'll never get around to improving it.
    Lies!
    Pareto said 80/20, you can't just throw in your own numbers! That's not part of the deal

  13. #13
    Champion Lorandii's Avatar
    Join Date
    Jun 2011
    Posts
    516

    Default

    First, local, local, local! That means local to your addon, or file.
    local function cbhUnitAvailable(units)

    While this is not exactly what is happening, it is close enough: without the word "local", your function gets called every time the event fires, regardless of whether your addon or someone else's event registration occurs. Say we have MyAddon and YourAddon; in MyAddon I don't have your function, but your function runs when MyAddon's event handler fires. I don't want the data in your function!

    Plus it is faster and cheaper on CPU.

    On a side note, I'm not sure what your confusion is, but taking a stab in the dark, System.Update runs all the time regardless of addon or base UI hooks. Event.SomethingHappens only runs when said thing actually happens: a buff gets added, player logs in, damage is done, etc.

    Polling System.Update to see if you gain a buff is a massive CPU sink, because your addon would be checking hundreds(?) of times per minute. Registering for Event.Buff.Add only fires when the unit you are checking gains a buff, which could be a few times a second all the way to never. Much better, don't you think?

  14. #14
    Plane Walker Imhothar's Avatar
    Join Date
    Feb 2012
    Posts
    439

    Default

    Quote Originally Posted by Lorandii View Post
    While this is not exactly what is happening, it is close enough: without the word "local", your function gets called every time the event fires, regardless of whether your addon or someone else's event registration occurs. Say we have MyAddon and YourAddon; in MyAddon I don't have your function, but your function runs when MyAddon's event handler fires. I don't want the data in your function!
    I'm not sure whether I get it right what you're saying, but as far as I know there is only one global table per event shared by all addons. The event dispatcher doesn't care whether this function is local to an addon or not, all event handlers in the event table are called every time the event fires. Once a reference to the function is copied to the event table it doesn't matter speed-wise anymore, as a reference is just a reference no matter whether it's pointing to a local or global function.

    So, each time "MyAddon's event handler" fires then "YourAddon's event handler" fires as well as do all the handlers of all the other addons registered for that same event.

    Localling stuff is always the way to go, but for the right reason, which is primarily to avoid name clashing resulting in unintended sharing of variables amongst addons.

  15. #15
    Champion Lorandii's Avatar
    Join Date
    Jun 2011
    Posts
    516

    Default

    Imhothar, I was trying to say that, but you said it better. Thank you. Now I'm going to stumble on some more words... *trip, fall, faceplant*

+ Reply to Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts