Help with an addon i am making.
Im making an addon that tracks combat stats for a hunter such as agility, ap, crit, mastery, haste, etc.
i have it displaying correctly, but my only problem is i have no way for it to update at a reasonable rate. local function updateFunction() AgilityLine.text:SetText("Agility = ".. getRangedAgility()) AttackPowerLine.text:SetText("AP = ".. getRangedAttackPower()) CritLine.text:SetText("Crit = ".. getRangedCrit() .."%") MasteryLine.text:SetText("Mastery = ".. getRangedMastery()) HasteLine.text:SetText("Haste = ".. getHaste() .."%") end i have this function that updates it correctly, but i have no idea how to impliment a way to make it only update when it should, and not 60 times a second. any help would be appreciated |
You have update on OnUpdate?
|
Quote:
|
For now, you need to create a frame that'll run the code in its OnUpdate handler.
lua Code:
In WoD, we'll be getting a new C_Timer system to handle this. When this happens, your code would look like this. lua Code:
Note: To enable Lua syntax highlighting on these forums, surround the code with [highlight=lua] [/highlight]. This is also visible as a Lua button on the right side of the formatting toolbar in the message editor. |
I'm pretty sure there are events that fire when these stats changed, so there's no reason to use an OnUpdate script here. Just register for the event(s) that tell you when your stats change, and update when they fire:
Code:
local f = CreateFrame("Frame") |
The event you looking for is "UNIT_STATS".
|
You will also need COMBAT_RATING_UPDATE since UNIT_STATS will only cover changes in agility.
|
I feel that it is a good practice to always check which events you want to listen to before beginning with the code.
Wowwiki has a list of all the events: http://www.wowwiki.com/Events_A-Z_(Full_List) You can try adding something like this to your code: Lua Code:
|
That code is incomplete, as you didn't actually tell the frame what to do in response to events. Also:
- There's no need to use separate functions for the two events, as you want to do the same thing in response to both. - You should use RegisterUnitEvent instead of RegisterEvent with UNIT_STATS so you don't have to manually filter out all other units. - If your frame isn't a UI object shown the user, there's no need to give it a parent. - A frame is already a table, so there's no need to create a separate table to hold functions. Code:
-- updateFunction here |
Quote:
For a small AddOn like this I guess it doesn't really matter though. |
Quote:
|
What I mean is you could have something in your table named the same as an existing function or value, which means what was previously defined is overwritten with your stuff. That could lead to bugs or unexpected behaviour. What if you make a SetScript method in your AddOn that is used for something, which then overrides Frame's SetScript method?
|
Quote:
|
It's still not exactly good practice I'd say to just modify a table from CreateFrame with your own methods, at least for addons larger than a single file. I've never really come across a design pattern like that outside of WoW addon development (granted, most of my experience is with OOP languages where you typically place your code in a namespace/package named after you or a company).
Keeping it separated in that way makes it more clear what code is yours and what code comes from default libraries, and can in some cases also make code more readable for an outside developer, they wouldn't have to check if the method someframe:SomeMethod() that is defined in file1.lua and used in file2.lua comes from the WoW Frame or a custom method in file1.lua. |
I'm guessing you've never heard of Monkeypatching. :D
|
Well monkeypatching isn't exactly a good thing most of the time is it? :P
|
If you're a code slob it can be bad, but that's true with any software technique.
|
Quote:
|
One reason could be if you make something that you want to behave like a Frame's event/script system. Say you want custom callbacks for some object you have, like:
lua Code:
Yes, there's CallbackHandler lib for this kind of stuff, but sometimes you just want to roll your own when you don't utilize near half the features of an existing library or don't like the particular way they implemented things. Implementing the above on a Frame wouldn't really work while making sure there aren't any problems with the Frame's own SetScript and related types of events/triggers. Forwards compatibility can also be a concern, why put your addon at risk of being made incompatible with a future patch when it's preventable with little effort? Using different names would work, but why not choose a method that lets you use whatever name you feel fits best. And if you're just blindly using a Frame to put all your methods in, you could be unknowingly replacing something that the Frame actually uses for whatever purpose if you don't check the documentation before implementing a method. I like to have the comfort of knowing that whatever I'm putting in my tables, won't directly conflict with anything and lives in its own space. I do sometimes put things in Frames, but mostly for one-off objects. An example being in the options file of one of my addons (code is in MoonScript, but should be relatively readable I hope). |
Quote:
Quote:
Quote:
|
All times are GMT -6. The time now is 05:42 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI