Authors CurseForge

I'd like to compile a list of the (self) buffs and (target) debuffs that are most important for each class and spec, in order to add a sensible default setup to my addon rather than making the user configure it from scratch after installing.

Specifically, I'm looking for raid buffs/debuffs each spec can provide, buffs/debuffs that are part of DPS/tanking spec rotations, DoTs or HoTs that each spec wants to keep refreshed (usually ignoring other people's versions of the same), etc.

As an example I've started with possible setups for feral druids and rogues, but I don't have enough experience with other classes or specs to know what they need to monitor in combat. I'll add others as they're posted; thanks for any contributions!

----------------------------------------------------------------------------

Druid (Feral)
Rogue

Aye, that's a tree-in-tab-in-tree(leaf), which is possible with current syntax. What's not (yet) allowed is tree-in-tree(leaf) without the intervening tab, which I think Phanx was aiming for, or anything-in-tree(nonleaf), which I would find very useful.

Is there no way to cast by spellid?

Quote from Phanx

You can test with the latest Grid alpha; just remove the childGroups = "tab" from GridCore.lua to get a tree with the same depth, and add sideGroup = true in GridStatus.lua on line 56.

It looks correct to me; I wonder if there was just a problem applying the diff to your copy of ACD.lua. Try replacing it entirely with this one:
http://paste.wowace.com/rbh4codm07tusew8/

This is what it looks like when I modify Grid as you describe (removing childGroups="tab" from GridCore, and adding sideGroup=true in GridStatus):

You have some regular options as children of the "Auras" group, so those options appear above the nested tree group, just like they would if you had nested a tab or select group. The empty "Delete (De)buff" inline group is there even without my patch, with a stock r991 ACD, so I assume that's defined in your options somewhere although I didn't go looking for it.

Quote from Nevcairiel

I didn't say ACD couldn't be modified to do this. Everything can be done. This is software development, we're only limited by our imagination.

It just can't be done with AceConfigDialog (right now, implied).

Indeed. :)

If you're so inclined, of course you're welcome to take a look at my patch and point out the mistakes; if not, I'll just keep toying with it myself and try to get Phanx's test case to work.

Quote from Nevcairiel

Its not not allowed, its just not possible due to how the tree group is constructed.
its not like we would block it from functioning, there is just no way to instruct a tree to create a new one instead of adding to the parent.

It's not currently possible; I'm trying to make it possible by adding some options table syntax. As Phanx noted there are still issues with my attempt, but since it works correctly for me, I'm not yet convinced that it can't be done.

And if it helps, a tree inside a tree is not the only use case; my original desire was to have tabs inside a tree, just like is currently possible for leaves of the tree, except I wanted them also on inner nodes of the tree. Since nested group controls are already supported in some contexts, I see no reason not to make that support more consistent.

@Phanx: could you send me your options table to see if I can replicate what you're seeing and fix my patch? Did you apply that diff to the latest version of ACD? I think it last changed in r986, but I just diff'd against the r991 package.

I hacked up a patch to implement this:
http://paste.wowace.com/2860/

Phanx, want to try it and see if it accomplishes what you want? Since "tree" is the default childGroups/sideGroups setting you don't even have to add sideGroups="tree" to your level 2 groups, you'd just need sideGroup=true on the level 3 groups underneath.

Quote from Phanx

Well, it's not quite the same, since I don't want my second tree group to actually be inline with other options above and below it. I just want the left pane to become another two-pane container. But, I think having a two-pane window, and letting tabs appear along the top of the second pane would also be reasonable. Neither case should break scrolling, since the left pane isn't inline and doesn't scroll (even if it has a subcontainer that does).

If it's not (and will never be) possible, though, I'm still open to suggestions on how I can make the menus for Grid's aura statuses less of a pain in the ass to navigate. Having the left tree panel scroll through 30+ entries at Level 3 pretty much sucks, especially since the tree panel has to be so wide to avoid truncating them.

It was not my goal to put other options both above and below an inline group control, I agree that would be ugly. I was just trying to use inline groups as a workaround to solve exactly the issue you describe -- wanting to nest a new, separate group control on the right side of an existing tree control (in my case I wanted tabs over there, in your case you want another tree control, but it is exactly the same need). It turns out inline groups are not the right tool for that job, which leaves us needing a proper tool.

That's what the new ticket describes, including a possible syntax for how it would be denoted in the options table. I think it's fairly straightforward and would solve both our problems, and I'm messing about with the ACD code myself to see if I can implement it, but I'm sure the actual ACD maintainers could probably do it much better and faster.

Quote from Nevcairiel

The ticket was closed because the question in the ticket was answered. Yes it is working as intended.

Ticket recycling sucks, you lose track of things.

Fair enough; I've filed a new ticket as a feature request, to address both Phanx's and my use-cases:
http://www.wowace.com/addons/ace3/tickets/198-nesting-a-new-group-control-inside-a-tree-group/

In theory, what you want should be doable by putting an inline group inside each level 2 subgroup, and then put your non-inline level 3 tree groups inside that inline group. That should "reset" the tree nesting and generate a brand new tree control in the right panel, like you described.

Unfortunately that doesn't work right now because inline=true is inherited by all child groups all the way down, and cannot be overridden by inline=false. I filed a ticket on this just the other day which was declined by nev, but you may want to comment on it to point out this use-case; maybe your request will have more weight than mine:
http://www.wowace.com/addons/ace3/tickets/196-inline-true-inherited-on-all-child-groups-and-cant/

And for the super ironic twist, I posted here looking for exactly this kind of feature almost two years ago (except I wanted tabs in the inline group, rather than a second tree control), and was immediately shouted down by none other than yourself, Phanx. :)
http://forums.wowace.com/showthread.php?t=15748
Doubly ironically, Xinhuan suggested a workaround which was actually exactly what I initially tried and didn't work, because of the forced inline=true inheritance.

Another method is to re-use the actual options subtable, and let AceOptions' "handler" inheritance do some work for you:

options.rule1 = {
  type = 'group',
  [b]handler = somethingSpecificToRule1,[/b]
  args = {
    stat = {
      type = 'select',
      name = 'Stat',
      values = {
        "ITEM_MOD_HIT_RATING_SHORT" = _G["ITEM_MOD_HIT_RATING_SHORT"],
        "ITEM_MOD_EXPERTISE_RATING_SHORT" = _G["ITEM_MOD_EXPERTISE_RATING_SHORT"],
        ...
      },
      get = function() ... end,
      set = function() ... end,
    },
    cap = {
      type = 'select',
      name = 'Cap',
      values = {
         "MeleeHitCap",
         "SoftExpertiseCap",
        ...
      },
    },
    userdata = {
      type = 'input',
      name = 'Values',
    },
  }
}

[b]
options.rule2 = {
  type = 'group',
  handler = somethingSpecificToRule2,
  args = options.rule1.args
}
options.rule3 = {
  type = 'group',
  handler = somethingSpecificToRule3,
  args = options.rule1.args
}
...
[/b]

Then, write your get/set/validate/etc functions to use "info.handler" to determine which frame/savedvars-subtable/etc to operate on.

Quote from Cyprias

OnUpdate vs OnFinished timer performance.
http://forums.worldofwarcraft.com/thread.html?topicId=26723614545&postId=267208819134&sid=1#15

                      CPU/Sec
Interval      OnUpdate    OnFinished   IncreaseInPerformance
  0.01          1.86         0.69            269%
  0.03          1.73         0.31            500%
  0.05          1.65         0.19            868%
  0.10          1.48         0.14           1057%
  0.20          1.43         0.10           1430%
  0.40          1.50         0.08           1875%
  0.60          1.50         0.07           2143%
  0.80          1.49         0.07           2128%
  1.00          1.48         0.07           2114%

Those findings are interesting, but possibly a little misleading.

If I understand the testing methodology correctly, this only tells us how much CPU time is spent in the (testing) addon's own Lua code. So of course offloading the timing mechanism to the game client's animation system will reduce the Lua code's apparent CPU usage, but it comes at the cost of increasing the animation system's CPU usage, even if we can't measure that directly.

It's probably safe to say that the animation system can do the work more efficiently than Lua, but this doesn't measure that at all, so calling it a straight-up "2000% performance increase" is a stretch, I think.

Presumably the reason we care about CPU usage is to reduce CPU load in order to improve framerate, so what we really need is a test that measures average framerate under a heavy load of timers using each of these mechanisms. But since framerate varies quite a lot second-to-second anyway, I'm not sure what kind of data we'd need to show a conclusive benefit, and measure the size of that benefit.

On the other hand if all you care about is making your addon look better in the Lua profiler by hiding the timing overhead in the animation system instead, then these results are useful. :)

Another possibility (drycoded, YMMV, etc):

local j = 1
for i = 1,#t do
  if t[i] ~= 2 then
    t[j] = t[i]
    j = j + 1
  end
end
for i = j,#t do
  t[i] = nil
end

The idea is to "compact" the table by looping over it once, skipping undesired elements and copying desired elements into earlier indecies that were skipped. Then nil out anything left at the end, since it was already copied into a lower index.

This *might* perform better for large tables; since I *think* multiple calls to table.remove() will be quadratic in performance, and this should be linear. If your tables are small it won't matter and your (more readable) solution is better; if your tables are big, something like this may be worth a try.

It's a hilarious coincidence that you necro'd this thread at just this moment, because just a few weeks ago I picked up my old code again and have been fleshing it out. I think mine is almost usable, but I'd be happy to collaborate. The lib you linked to looks interesting too, I'll have a look at how it does things.

1.2.2 is up, with (I hope) finalized presets for 4.0.1 and Cataclysm.