Scratchpad for some ideas I've had after hacking on this, these are future looking ones and would be part of a revamp branch. Some of these might be doable during the Ace3 conversion since that will entail a lot of changes anyway.
There's a lot of duplication, both in code and in data structures, no doubt from growth and evolution of the code to accommodate new features. Should separate out as much as makes sense into helper functions to put into the main core, while keeping the specialized logic in the individual modules.
A good example of this is the overlapping buff info. Ideally, the core would have a simple list of all buffs that ZOMG knows about, whether it tracks them or not. Basically just spell ID and buff category (%Stats, +Strength, etc.). The individual modules would have a way to register one of these buffs to themselves and take ownership of it, while providing richer information about it to the core.
Efficiency. A buff scan iterates through 40 raid members, checking 40 buff slots on each one. It may repeat this process several times depending on which module is involved and what it's checking for. Every time the status window is painted, it checks all 40 buff slots to find the one it's looking for, for each icon, even though it just did the same thing for the previous icon on the row.
IMO, it would be better to have ZOMGBuffs maintain its own internal state table of all raid members and which buffs are on them, along with references to its buff info for quick lookups. That way the scan only needs to happen once, then everything that needs it has easy access to all the info it might require.
This can be made even more efficient by watching for aura events and updating the table incrementally, while only doing a full scan every once in a while or if it suspects that it's out of sync with reality (someone just came into range for example).
Configurability. Once ZOMGBuffs is set up it works wonderfully, but sometimes figuring out where the options are scattered around can be difficult. Need to better organize this.
It would also be nice to have more options, and a generic framework for buffs to register them.
Every single-target buff that ZOMG knows about should have the option to have the tracker icon enabled (or disabled) on a per-buff basis. Try to be smarter about the default positioning, too.
This should be a lot easier to accomplish in a config dialog than with a Dewdrop menu, though the menu still should exist and provide quick ways to turn on/off certain buffs and switch templates.
Better (more configurable) handling of what happens to templates when you switch specs.
A pass should be made on the default options to make sure that a new user on a fresh install just has to click the button and go. Probably a whitelist of certain "major" buffs per class that come pre-learned rather than requiring you to cast them.
ZOMGTotems - Probably needs to be a separate module because it almost seems like it will need a blessings-manager like interface. Maybe not quite that involved, will have to think on it.
When I installed this addon again, I wondered why Ace2 was reinstalled. When I tried to delete it, the Curse Client mentioned that Ace2 is used by ZOMGBuffs ... wasn't ZOMGbuffs an Ace3 Addon?
I don't think it ever used Ace3. It does use a couple Ace3-era libraries now that it didn't used to, but the core has always depended on Ace2.
I'm a little confused - is this just temporary?I changed from Pally Power to ZOMGBuffs to get rid of Ace2 in the first place :)
Moving to Ace3 is definitely on the radar. The goal was to get it fixed and working for 4.0.1 so that it doesn't die completely, in order to buy some time to do that.
There's a lot of issues that need to be addressed though, and it will require some significant redesign. The biggest issues that I see from working on it lately:
No more LibDewdrop. The menu will have to be recoded with UIDropDown or something similar, and will likely need to be simplified. Some of this can be moved into Ace3 config dialogs, but the most frequently used options should still be quickly accessible or it negates a lot of the point of the addon.
No more Tablet-2.0. LibQTip can fill in most of the gap (not sure about clickable tooltips though, might have to move some options to the right-click dropdown), but it does mean rewriting a chunk of it.
FuBarPlugin -> recode as LDB plugin. ZOMG practically requires use of the FuBar/minimap icon, so will need to find a library to display this as a minimap icon if there's no LDB host, or write something manually.
Ace2 -> Ace3 transition. Most of the APIs aren't too different, but ZOMG does make use of some of the more esoteric AceDB and AceAddon features for managing its templates. It will take some extra attention here to make sure that it doesn't break in the process.
Any development on this front will most likely be happening in a repo clone or branch as this isn't something that can be resolved to a working state in a few commits. Zeksie has taken renewed interest in the addon so I'm in contact in order to work out the specifics. :)
[...]so I hope you find a way to integrate with MoTW.
This should be working in the latest revs. To be clear, here's what should happen:
Druid, solo, or in a party with no paladin:
Status window shows Mark of the Wild icon only.
Paladin, solo, or in a party with no druid:
Status window shows Kings and Might icons.
Paladin can of course only select one to buff at a time, but multiple paladins could cover both.
Paladin and Druid in a raid together: Status windows shows Mark of the Wild and Might icons (no Kings).
HOWEVER, if a Paladin buffs Kings, the Mark of the Wild column in the status window changes to Kings, and the Druid running ZOMG no longer gets prompted to buff Mark. If Kings falls off, then it will prompt the druid for a rebuff of Mark.
Basically, each buff category has a dedicated column in the window, which shows a "default" icon if no buff is present. I threw Druids a bone since they only have one buff while Paladins have two. :) If a buff is present for that category, however, the icon in the list will reflect which buff is actually on someone. It's entirely possible after a few people rez or come in late to show most of the raid with Kings, but several missing Mark of the Wild in the same column. Buffing either will satisfy it.
It works the same with Fortitude. It will show the icon of Commanding Shout or Blood Pact on raid members that have those, and not bother you to try (futilely) buffing them.
Those are the only two implemented right now, but if people run into issues with other conflicting buffs, the system supports adding them (even if ZOMG normally doesn't track them).
Go to the main please. Zeksie has merged the changes into the main branch and wants to look at it when time allows and continue working on it there. I'll continue making maintenance fixes and fixing bugs.
I closed the cata branch to commits, but want to keep it around for a little while in case I need to refer to the commit history. May rename it as to not confuse people.
Is your rogue using a non-binding weapon? I think the blizz did something funky to keep people from trading poisoned weapons.
Yes, he's super low so it's some white vendor item (balanced throwing dagger, I think).
After applying the poison the tooltip says Soulbound. If I cancel the poison buff it still shows as bound (haven't tried to trade it), but logging out and back in resets it and it doesn't show as bound anymore.
Thelibrarian, Thanks alot for fizixing this wonderful addon :)
It would be possible to add ranged weapons to "buffable" weapons list?
EDIT: Added in r192 -- should be working now.
Noticed some weirdness on my lowbie rogue of getting a "This action will make the item soulbound" prompt the first time I put poison on my ranged weapon after logging in each time, but I believe that's a blizzard issue, and shouldn't affect high-level rogues.
Just updated to r186 after I saw this message. I did a full delete of the previous versions folders before I copied in the new ones. I'm not seeing anything in the log for ZOMGBuffs, and it is showing as enabled. In the options, I can see Fortitude and Shadow Protection, and they are checked, I just never get past Inner Fire. It's as though ZOMGBuffs isn't recognizing that I even HAVE Inner Fire on, so it keeps telling me to cast the spell before I can go on to the next one.
Hmm, so it's repeatedly asking you to buff Inner Fire?
It might be related to it mistakenly thinking it has charges, which I just removed in the latest build. Can you try r187 and see if it's any better?
Still strange that it didn't happen to me when I tested it, as the priest I used was high enough to have Inner Fire and it seemed to be working.
r185 on the cata branch introduces experimental support for trying to "do the right thing" when it comes to buffs that don't stack with each other. The initial implementation flags Mark of the Wild and Blessing of Kings as mutually exclusive.
Now, I don't have a high enough druid or paladin to actually use these buffs, so this is mostly drycoded with some minor testing on low-level alts just to verify that it didn't explode when they joined a group. If you run into any issues with this version, I recommend rolling back to r184, which should be a stable version.
As I won't be able to do much testing tonight due to RL obligations, I would greatly appreciate it if anyone could manage to get a paladin and a druid together for some testing.
Things to try:
Does it show the correct icon for your class when solo?
After both are in a party together, does it only show one icon on the raid buff list when you hover over the icon? For a druid/paladin party, it should show Mark and Might, but not Kings.
Does this icon correctly dim when either buff is applied, and does it reflect which spell the player actually has?
If both players have Mark, and one of them right-clicks it off, does it prompt the paladin to cast Kings? Vice Versa?
(note: ZOMGBuffs currently only scans for buffs after a global cooldown, so you'll need to cast a random spell to get it to notice that they clicked off the buff. I'm contemplating changing this to check on UNIT_AURA, but unsure of the performance impact as its scanning is rather inefficient right now)
I'm not sure if you have any priests testing the alpha or not, but I've tried versions r178 and r179 and it won't let me buff anything except Inner Fire, and says I don't have Inner Fire even though I've just buffed it.
Only my level 43 priest right now, but Fortitude seems to work there.
It almost sounds like the raid buff module isn't loading for some reason. Do you see Fortitude on the list of buffs when you right click and go to the configuration? Do you see the "Group Buffs" menu at all under there?
Did you delete all the ZOMGBuffs directories before extracting the test version? If you could check Logs\FrameXML.log for signs of any problems loading ZOMGBuffs_BuffTehRaid (and make sure it's enabled in the addon list), that would be helpful as well. That reminds me, I need to bump the TOC on those so that they still load when out of date addons are disabled...