Go to Page... |
Thread Tools | Display Modes |
04-05-12, 09:08 AM | #1 |
Help with creating basic debuff frames.
Hey,
I've just started off with my first little script for WoW. Which I basically want to show debuffs on the default enemy arena frames. I came up with the following code: Lua Code:
This is currently set to work for the target, as I use this for testing purposes mostly. However the error I've run into is; the frames don't hide when the debuff runs off. Hopefully it's an easy fix and I haven't started off going into the wrong direction. Please keep in mind that I'm very new at this, and it's probably pretty poorly written, so any advice is welcome! Thanks |
|
04-05-12, 05:45 PM | #2 |
Your main problem is that every time any buffs or debuffs update on the target, your code is creating 1-10 new frames. You need to create those frames ONCE, outside of your event handler, and then update them when auras change.
Other problems include the fact that while you are showing/configuring buttons when the debuff exists, you aren't hiding buttons when the debuff doesn't exist. Consistent line-breaking and indentation will also make your code more readable, as will omitting the use of semicolons, which are (almost always) useless in Lua. Lua Code:
|
|
04-06-12, 08:13 AM | #3 |
Thanks for the help!
I'm off trying to work out how to add cooldown and debuff type borders! |
|
04-10-12, 06:33 AM | #4 |
Hey,
I've added cooldown, count and debufftype borders. The functionality is fine, however I'd still like it if someone could point out any inefficiencies in my code. As I'm mostly doing this for the learning experience. Here's the code: Lua Code:
Also how would I switch this to working for multiple targets, without repeating the code. I want it to work for arena enemy frames, so would Lua Code:
Any pointers and help is greatly appreciated, thanks! |
|
04-11-12, 05:50 PM | #5 |
1. You do not need to keep calling x:SetParent(f) when f is already the parent of x because you specified that in the CreateFrame call.
2a. I'd strongly suggest using descriptive variable names, so that when you are looking at this code weeks, months, or even years later you can immediately tell what's what instead of having to puzzle out what a single-letter variable like "g" means. 2b. Similarly, you should keep all of the code related to, for example, the border in the same place instead of putting half of it in one place, and the other half 20 lines later for no apparent reason. It might make sense *now* but will it still make sense 6 months from now? Will it make sense to people trying to help you identify and fix bugs, or add features to your code? 3. I'd recommend against giving every frame, texture, and font string a global name. The only real reasons to give anything a global name are (a) the object is a saved variable, or (b) the object is a top-level addon frame/table and you want it to be accessible to other addons or by in-game /run commands, or (c) you will be using Blizzard templates/functions that are designed to work with Blizzard UI objects with specific global names for their regions and children. Since none of those are the case here, global names aren't needed. Lua Code:
|
|
04-12-12, 04:23 AM | #6 |
Thanks Phanx!
|
|
WoWInterface » Developer Discussions » General Authoring Discussion » Help with creating basic debuff frames. |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
Linear Mode |
Switch to Hybrid Mode |
Switch to Threaded Mode |
|
|