The massive function at the end is trying to res chars in a specific order. Did I get it correct?
I need to allow the user to move/resize the bars, but I am lost
Should the addon force users to use the Interface Options pane or keep both that and slash commands?
I know I bungled LibCandyBar-3.0 but I can't see it.
Is this truly disabled in combat, or is something left hanging?
I don't want to see the Druid spell "Rebirth" and hopefully it isn't here
I know math.rand is used in creating random messages to chat, but how do I convert math to strings?
Is my code for LibSharedMedia-3.0 working, or missing something. I am trying to use AceGUIWidgets
Anything else I am missing, or added needlessly that would drive users (or follow up coders) nuts?
EDIT** If anyone can point out efficiency flaws, either in the code, or when the code would run and slowwwwww down WoW, that would also be appreciated. Also, I thought (after the original post) that I don't have the 2 keybindings. I will have to look into how to create those in Cladhaire's and Kaelten's book, since I have no idea off the top of my head. :(
If anybody's head explodes looking at my code, I apologize now, will call an ambulance, and think nice thoughts of and for you.
Your OnEnable and OnDiasable is also incorrect the "event" variable is undifined unless your asking for _G.event, also likely to be undifined or not what you want.
the SR2_OnEnable and SR2_OnDisable Functions are a bit redundant, all that should be in an on Init, you should really never un register those particular functions in general, even if you are in combat.
The only thing i would protect agenst for the whole PRE and PRD events is what your frame's OnClick or button attribs do. Everything else can remain as is always "enabled"
Your Rez_* functions are creating and trashing tables, not too big a consern, but it is a waste.
1) You just save the string for path of the texture. Just like any other setting.
3, 5) LibCandyBar-3.0 is extremely minimal. Not sure it will fill your needs.
7) To filter Rebirth you can do two things. Unregister ResComm_ResStart during combat. Or check with UnitCastingInfo() wether it is Rebirth. I recommend the first.
9) You're not doing anything with LSM. I'm not sure why you would want to use AceGUI
I've always loved the idea, and I think you're halfway there already... but well, he's my thoughts on design:
Look at the HealComm lib, it's neat, it works, and anyone can integrate it with their UFs. I think you should focus on making RezComm a standalone lib, then worry about making an addon that displays it's data. That way the rest of us aren't forced to use your addon... which I think was the biggest pitfall of the old SmartRez addons.
If you want to break the comm stuf fout into a simple lib, I'll gladly help with it.
I've always loved the idea, and I think you're halfway there already... but well, he's my thoughts on design:
Look at the HealComm lib, it's neat, it works, and anyone can integrate it with their UFs. I think you should focus on making RezComm a standalone lib, then worry about making an addon that displays it's data. That way the rest of us aren't forced to use your addon... which I think was the biggest pitfall of the old SmartRez addons.
If you want to break the comm stuf fout into a simple lib, I'll gladly help with it.
Forgive my ignorance, or lack of understanding, Tekkub, but I don't follow. Dathrarhek already make LibResComm-1.0, which is where the ResComm bits come from, into a library that I'm using. Now, if you are suggesting that I make "LibSmartRes" then that sounds like a good idea. Of course, then I would have to write an addon to display the information, but isn't that the point of LibResComm already?
Could you clarify, please? Also, if you do mean alter SmartRes2 to become its own Lib, then yes, I will need help, as I have no idea how on my own.
There is no such thing as "LibSmartRes" ... Methinks that would be an overly large, rather unwieldy library.
LibResComm-1.0 has 3 main functions, and some other neat tricks on top.
ResStart: resser, endTime, target
Ressed: target has been ressed, but not yet accepted the OK
ResEnd: the resser canceled, or res spell completed
LRC1 is "smart" insofar that it assigns the proper name to targets, even if they have released. The first SmartRes could do this. No more "unknown" or blank info when you ressed the corpse of a ghosted player.
What LRC1 won't do, which is why Dathrarhek wrote HealInc, is show you duplicate res casts, nor will it prevent you from casting on someone who has ressed but not accepted, and it has no way of displaying any of this data. The main difference between SR2 and HI is that SR2 doesn't just put the res bars graphically on your screen, it resses units at the press of a button.
Hence, SmartRes2. Just like the original, when you press your res key, it will res someone who is in range, in LoS, and isn't already being ressed. What I want to improve upon is the the original just starting picking dead units at random; I want the new version to res in a specific order, assuming all units are the same level, or where appropriate, the highest level: Priests, Paladins, Druids/Shamans, other Mana users, then the rest.
OrionShock pointed out that I am creating and trashing tables left and right, and would love some help fine-tuning the Resurrection() function.
Tekkub, btw, oRA3, HealInc, and maybe some others all use LibResComm-1.0, and since you seem to be familiar with the original SmartRes, you could understand me wanting to rewrite it rather than fix it. Some really outdated code there, nevermind the antique and depreciated Libs it uses that I very much want to dump.
The ResComm events in LibResComm-1.0 give you the caster, endTime, and target already. Plus it also gives IsUnitBeingRessed, which is a real boon. Assuming the player is using SmartRes2 (um, duh LOL) then I can easily narrow down to an appropriate target to cast the res on.
What my code does, hopefully, is res in the order mentioned in my previous post, or in the comments of the Resurrection() function. I admit my code is a mess, and have rewritten it a couple of times, without being satisfied. The other thing is that I need to return the target unit from said function to the SmartRes2Button, and I'm a bit vague on that.
So, here are the questions: LibBars-1.0 needs to be set up, but as I mentioned in the Libraries thead, I would love some help with the APIs; I would love some input on filtering targets so when the player presses the bound key, the target needs to be quantified (in range, in line of sight, not being ressed already, not ressed yet hasn't accepted the res, and has to be in a specific class order given appropriate level); and after ALL that, return that unit to the button.
Yikes. And I thought I had a hard time coding the options....
Your question comes up way too often. I think I already answered it ten times on these forums, let alone IRC.
When a characters releases after he died the UNIT_SPELLCAST_SENT event for a resurrection on him will have UNKNOWN as target. The only way to know the target is by parsing the tiny tooltip that appears when hovering over a corpse. This is the main reason for the need of a library (LibResComm-1.0)
The other reason for the need of a communication library is soulstones and ankhs. They are also not known from the combatlog. A great way to use this information is in GridStatusRes. It adds status for when someone can pop.
I am looking for "you can't do that!" errors. http://pastey.net/129554 also, I was looking at the AceGUI-Widgets and saw some I'd like to use, such as the edit box, or colorPicker, and I'm a bit lost on how to use them in the options. For example, I want to define the regular res bar as green, and the collision as red, but have them user changeable with the picker.
Can I do that within the options, the way I did for the LSM widgets? Furthermore, I know I must have callbacks to update the profile, but again, I am not sure where/how to use them.
I am not asking anyone to rewrite my code (unless you absolutely must) but rather an example or two, from another addon or just the code brackets here.
The reason I'm posting this now is because I don't want to finish up handling the options with their respective functions (is there an easier way?) and then find out I have to rip it all apart. And on that note, yes, I am mix and matching the handler functions with AceGUI, but want to standardize on AceGUI.
Did any of that make sense?
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorRight, questions:
EDIT** If anyone can point out efficiency flaws, either in the code, or when the code would run and slowwwwww down WoW, that would also be appreciated. Also, I thought (after the original post) that I don't have the 2 keybindings. I will have to look into how to create those in Cladhaire's and Kaelten's book, since I have no idea off the top of my head. :(
If anybody's head explodes looking at my code, I apologize now, will call an ambulance, and think nice thoughts of and for you.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYour OnEnable and OnDiasable is also incorrect the "event" variable is undifined unless your asking for _G.event, also likely to be undifined or not what you want.
the SR2_OnEnable and SR2_OnDisable Functions are a bit redundant, all that should be in an on Init, you should really never un register those particular functions in general, even if you are in combat.
The only thing i would protect agenst for the whole PRE and PRD events is what your frame's OnClick or button attribs do. Everything else can remain as is always "enabled"
Your Rez_* functions are creating and trashing tables, not too big a consern, but it is a waste.
3, 5) LibCandyBar-3.0 is extremely minimal. Not sure it will fill your needs.
7) To filter Rebirth you can do two things. Unregister ResComm_ResStart during combat. Or check with UnitCastingInfo() wether it is Rebirth. I recommend the first.
9) You're not doing anything with LSM. I'm not sure why you would want to use AceGUI
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorIs this better? I haven't had a lot of time to code, which is why the long response time.
Look at the HealComm lib, it's neat, it works, and anyone can integrate it with their UFs. I think you should focus on making RezComm a standalone lib, then worry about making an addon that displays it's data. That way the rest of us aren't forced to use your addon... which I think was the biggest pitfall of the old SmartRez addons.
If you want to break the comm stuf fout into a simple lib, I'll gladly help with it.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorForgive my ignorance, or lack of understanding, Tekkub, but I don't follow. Dathrarhek already make LibResComm-1.0, which is where the ResComm bits come from, into a library that I'm using. Now, if you are suggesting that I make "LibSmartRes" then that sounds like a good idea. Of course, then I would have to write an addon to display the information, but isn't that the point of LibResComm already?
Could you clarify, please? Also, if you do mean alter SmartRes2 to become its own Lib, then yes, I will need help, as I have no idea how on my own.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorLibResComm-1.0 has 3 main functions, and some other neat tricks on top.
LRC1 is "smart" insofar that it assigns the proper name to targets, even if they have released. The first SmartRes could do this. No more "unknown" or blank info when you ressed the corpse of a ghosted player.
What LRC1 won't do, which is why Dathrarhek wrote HealInc, is show you duplicate res casts, nor will it prevent you from casting on someone who has ressed but not accepted, and it has no way of displaying any of this data. The main difference between SR2 and HI is that SR2 doesn't just put the res bars graphically on your screen, it resses units at the press of a button.
Hence, SmartRes2. Just like the original, when you press your res key, it will res someone who is in range, in LoS, and isn't already being ressed. What I want to improve upon is the the original just starting picking dead units at random; I want the new version to res in a specific order, assuming all units are the same level, or where appropriate, the highest level: Priests, Paladins, Druids/Shamans, other Mana users, then the rest.
OrionShock pointed out that I am creating and trashing tables left and right, and would love some help fine-tuning the Resurrection() function.
Tekkub, btw, oRA3, HealInc, and maybe some others all use LibResComm-1.0, and since you seem to be familiar with the original SmartRes, you could understand me wanting to rewrite it rather than fix it. Some really outdated code there, nevermind the antique and depreciated Libs it uses that I very much want to dump.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium*edit* nope: http://wowprogramming.com/docs/api/UnitCastingInfo
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorWhat my code does, hopefully, is res in the order mentioned in my previous post, or in the comments of the Resurrection() function. I admit my code is a mess, and have rewritten it a couple of times, without being satisfied. The other thing is that I need to return the target unit from said function to the SmartRes2Button, and I'm a bit vague on that.
So, here are the questions: LibBars-1.0 needs to be set up, but as I mentioned in the Libraries thead, I would love some help with the APIs; I would love some input on filtering targets so when the player presses the bound key, the target needs to be quantified (in range, in line of sight, not being ressed already, not ressed yet hasn't accepted the res, and has to be in a specific class order given appropriate level); and after ALL that, return that unit to the button.
Yikes. And I thought I had a hard time coding the options....
Last I saw that only had all params for the player... I'll test it here in a min...
Your question comes up way too often. I think I already answered it ten times on these forums, let alone IRC.
When a characters releases after he died the UNIT_SPELLCAST_SENT event for a resurrection on him will have UNKNOWN as target. The only way to know the target is by parsing the tiny tooltip that appears when hovering over a corpse. This is the main reason for the need of a library (LibResComm-1.0)
The other reason for the need of a communication library is soulstones and ankhs. They are also not known from the combatlog. A great way to use this information is in GridStatusRes. It adds status for when someone can pop.
@myrroddin
Your SortDeadByPriority function looks messed up. I think you want
table.sort(self.Dead.class, SortDeadByPriority)
See also
http://lua-users.org/wiki/TableLibraryTutorial
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorCan I do that within the options, the way I did for the LSM widgets? Furthermore, I know I must have callbacks to update the profile, but again, I am not sure where/how to use them.
I am not asking anyone to rewrite my code (unless you absolutely must) but rather an example or two, from another addon or just the code brackets here.
The reason I'm posting this now is because I don't want to finish up handling the options with their respective functions (is there an easier way?) and then find out I have to rip it all apart. And on that note, yes, I am mix and matching the handler functions with AceGUI, but want to standardize on AceGUI.
Did any of that make sense?