Nested Groups #64


  • Enhancement
Open
Assigned to infusonwow
  • cjm7TW created this issue May 8, 2014

    One of the very nice features of WA is the ability to group Auras together, but you can only group things which are not groups.

    Basically this would allow you to have a groups in groups where the sub groups are treated just like how current auras are in groups.

    Some of the advantages would be greater control on how all your icons are set dynamically.

    Now this cannot be done currently but you can get the same effect by just putting all the auars in one group, but you have to change more then one setting if you want to move more then one icon.

  • cjm7TW added the tags New Enhancment May 8, 2014
  • cjm7TW posted a comment May 8, 2014

    Also to add might have issues with ticket 7 even more ("Very large displays break imports") due to the larger strings.

  • _ForgeUser13850389 posted a comment May 21, 2014

    +1 for this, if it ever gets implemented. Been waiting years for this!

  • _ForgeUser2582346 posted a comment Oct 11, 2014

    Not only does this help in grouping common display/trigger/load conditions but, more than anything for me, it helps me organise my auras better e.g

    • 1 > Class Auras
    • 1.1 > Deathknight Auras
    • 1.1.1 > Blood Auras
    • 1.1.2 > Frost Auras
    • 1.2 > Druid Auras
    • 1.2.1 > Balance Auras
    • ...
    • 2 > Raid Auras
    • 2.1 > SoO Auras

    etc.


    Edited Nov 4, 2016
  • _ForgeUser3997528 posted a comment Oct 17, 2014

    This would indeed be a really nice addition for players using multiple classes and specs,

    As a workaround you could add prefixes to your displays like:

    • Paladin_Protection_[display name]
    • Warlock_Destruction_[display name]

    That would keep your list stored by char and spec.


    Edited Oct 17, 2014
  • _ForgeUser2861435 posted a comment Oct 25, 2014

    This is a great idea, it is sometimes frustrating that this is not a thing!

    The lack of response to this ticket is disheartening.


    Edited Oct 25, 2014
  • _ForgeUser128970 posted a comment Nov 12, 2014

    Would be a very helpful addition. Groups within a Dynamic Group in particular would solve the issue of positioning stacked auras.

    For example, tracking multiple spells in a dynamic group and creating multiple shared position auras displaying their available/active/cooldown states.


    Edited Jul 31, 2015
  • _ForgeUser10602895 posted a comment May 9, 2015

    +1 for this!

  • _ForgeUser826036 posted a comment Jun 18, 2015

    +1 please :D

  • Juggerone posted a comment Jul 31, 2015

    +1 That would be amazing, indeed.

    I have WA for 4-5 trinkets and each of them uses 2-3 auras, throwing them into a dynamic group just messes them up. In this case would be nice to be able to make 1 group for each trinket and then throw the groups into a dynamic one.

  • Managed posted a comment Aug 5, 2015

    Another option is a "Folder" weakaura. This would have no universal control over the settings of the weakauras inside of it, as its only purpose would be for organizing multiple dynamic/groups in it.

  • _ForgeUser1606128 posted a comment Sep 11, 2016

    So what's the interest level here?

    I'd be open to working on this enhancement as long as it's something the project owners actually want in the addon.

  • InfusOnWow posted a comment Sep 11, 2016

    There's interest. The reason it hasn't been implemented is that it is highly complex and lots of work. I would estimate that it would a serious effort by someone familar with the existing code to do. It's far from trivial.

  • cjm7TW posted a comment Sep 11, 2016

    Wish I knew more Lua but I hate scripting languages in general (strongly type language guy).

    I don't know what all is being worked on currently but a refactor of the current RegionTypes might be a good idea just in its own right. There is a lot of replication which could be replaced by turning the system into Lua's (fake) object structure. Once that is done it should not be hard to have groups of groups but I could see it causing a bit more performance overhead with how everything would have to resolve.

    That in itself would help with any kind of future expansion / modification, not to mention when Blizzard's API changes there are many fewer places to edit.

  • _ForgeUser1606128 posted a comment Sep 12, 2016

    @InfusOnWow I'm not opposed to really digging in and understanding what's going on (and of course a pull request is totally reviewable, so if it sucks I won't be offended by a rejection).

    As for the implementation, there are several paths that it could take that add/remove complexity.

    For instance, suppose that you elected to create groups just for organization, meaning that you can't setup triggers on them, they don't control positioning as a group, etc.

    A naive implementation of that takes every existing aura and gives them a new "organizationName" property. Imagine that the property value looks like:

    "Shaman > Restoration > Healing Stream Totem"

    "Shaman > Restoration > Gift of the Queen"

    Then the only thing that really has to change is the list of the auras to account for the grouping, which you could get by splitting on the > character and building the tree.

    So all the functional parts of the AddOn still work against the (mostly) flat list of auras and these groupings are for organizational display only.

    Beyond that, I don't see any unit tests in the code, in the interest of bringing us closer to this feature, I wouldn't mind putting together some unit tests/refactoring to make taking on an issue of this type with more safety and reliability.


    Edited Sep 12, 2016
  • _ForgeUser1606128 posted a comment Sep 12, 2016

    I should add that I'm not trying to trivialize the effort involved in this. While my suggestion below simplifies the object model, its still probably a substantial effort to make the UI support a reasonable display of the data.

  • InfusOnWow posted a comment Sep 12, 2016

    Well, dig into the code first. You'll learn of the atrocities it contains on the ui side.

  • cjm7TW posted a comment Sep 15, 2016

    @InfusOnWow: Go

    Which is why I mentioned a refactor of the entire ReionTypes might be in order first. It was rather interesting looking in there.

  • InfusOnWow posted a comment Sep 15, 2016

    Region Types has some duplicated code, but is otherwise perfectally maintainable code.

    The options code is rather hard to maintain and that's where the main complications with nested groups are. Anyway, good luck and if you have questions, feel free to ask.

    Any clean up is obviously welcome.

  • _ForgeUser3444038 posted a comment Nov 4, 2016

    +1 for this option -no...+5 for this option WA needs this sooooo badly.

    Currently going through pages and pages of auras from WoD deciding what needs to be kept, deleted, or archived at the very bottom of the list and set to never turn on.

    So many times I have been on alts and decided against making auras because I didn't want to over saturate and lengthen my already long list of auras with less important ones.

    For anyone that is even slightly bothered about organisation for clarity or efficiency (and let's face it, if someone uses WA extensively, then that probably means them), this should get the "most like to see implemented" vote. It certainly gets mine.

  • gnuheike1 posted a comment Nov 28, 2017

    +1

  • AeleasYT posted a comment Jan 31, 2018

    The fact that this is assigned to someone who hasn't been active since November of 2016 makes me think it's not happening, even though it would be tremendously useful.

  • oiFrango posted a comment Jan 31, 2018

    After all these years, this is still the only feature I'm really missing in WeakAuras. I don't even need multi-level nesting, just one additional level would go so far.


    Edited Jan 31, 2018
  • InfusOnWow posted a comment Feb 1, 2018

    If it makes someone happy, I'll reassign it. The reason this hasn't been worked on, is simply that it is very complex.

     

    I would estimate it's several months of work to do that. And that would mean other work would not get done.

  • InfusOnWow unassigned issue from mirrored_ Feb 1, 2018
  • InfusOnWow self-assigned this issue Feb 1, 2018
  • oiFrango posted a comment Mar 18, 2018

    I would estimate it's several months of work to do that. And that would mean other work would not get done.

    I think it would be worth it.

  • Prongu posted a comment May 14, 2018

    Nested group functionality is definitely a hot item!

    Check out Uberauras (its WA2 custom code, not it's own addon in case anyone's confused) if you're looking for similar functionality. It allows you to have one weakaura that correctly displays for the cooldown, buff time, and or active/usable ability all in one. Additionally, it can be set to function for two DIFFERENT abilities in one weakaura. On top of that, custom code can be used within these auras, allowing you for example, to see Void Eruption, void form's buffs, void bolt and its cooldown all in ONE weakaura which is *within* a dynamic group.

    Hopefully this explanation and/or the weakauras are helpful :)


    Edited May 14, 2018
  • SunshinyDave posted a comment Jun 14, 2018

    Would also love this to be implemented! Hope you can get this done (would be a great surprise for BFA!) :)

  • Stanzilla posted a comment Oct 5, 2018
  • Stanzilla added a tag Enhancement Oct 5, 2018
  • tinyrivers posted a comment Mar 3, 2019

    So, we do still get a lot of requests for this, so I thought it might be worth explaining what exactly it is we plan on doing (and why it doesn’t include nested groups). First, some of the problems with implementing nested groups directly:

     

    • Export size: World of Warcraft does not play very nicely with extremely large strings in their text boxes. Anything over 20 thousand characters or so in the same edit box will cause a noticeable hang when rendered. The worst case I ever saw was a very large group of auras, which when compressed clocked in at just under 450 thousand characters (which with the compression ratio back then, would be a bit over half a megabyte in size when uncompressed), and took at least 5 minutes to render on screen. We did improve this a great deal in 2.8.0, when we switched to a much more efficient compression library (eg that 450k char string I mentioned became a 50k char string). But implementing nested groups would likely reintroduce the problem, as authors would publish monolithic groups of groups of groups (and so on), which even with our compression improvements would likely grow to be as big as (or even bigger than) the largest group sizes we saw before 2.8.0. So, if we committed to nested groups, then we would be knowingly reintroducing this performance issue. This is not something I relish doing.

     

    • Maintainability: WeakAuras is a large and rather complex addon to maintain. Every feature we add does increase this complexity, but not all features are created equal. Nested Groups in particular would fall afoul of the unfortunate state of the code which renders the options panel. A big source of the complexity in WeakAuras Options is the multi-select feature, where you can select multiple auras and view/edit their settings as if they were one aura. To give you an idea of how much this complicates development, I can talk about the Custom Options feature I developed for the 2.10.0 release. The core logic of Custom Options was written without support for multi-select, took a week of dedicated development time to create, and was about 600 lines long. Adding in support for multi-select took 2 weeks, and inflated the feature to about 1000 lines of code, and to this day is a source of bugs in Custom Options. As for Nested Groups? Well, since selecting a group automatically selects all of its children, a nested group would have to somehow render the entire tree. It would be affected by the same problem as Custom Options, but much more intensely. And we can’t remove support for multi select, as much as it complicates development; it is a feature that has existed for about a decade, and frankly it would be a long and frustrating task to do, anyways. Speaking personally, I believe that attempting to implement Nested Groups directly would just cause me to burn out and stop working on WeakAuras in my free time, possibly leaving the other developers (both present and future) with a half finished mess. Nobody wants this.

     

    Those are the primary reasons why we haven’t already implemented Nested Groups. However, there is obviously a lot of demand for this. This ticket is several years old, yet still gets comments bumping it back up. We get tickets on GitHub which ask for it regularly. People ask on reddit, the WoW forums, and especially on our discord how to nest groups. So, what we can do instead (and what we plan on doing) is to tackle the use cases which we see most often. Here are the two most common use cases which we plan to solve:

     

    • Organization: Many users have a lot of auras, and would like better support for organization of their auras. Nested Groups would solve this by allowing you to build a tree structure (really, a forest). What we plan to implement (and you may have seen a few of the early experiments for this already) are tags. See the ticket that Stanzilla linked in the comment above for more details on this.

     

    • Groups as Components: The most common form of this use case I have seen is to have a “dynamic group of groups”, where a user would create a group of, say, textures which are arranged in a particular way, and then have several variants of that group, all placed in a super group which then moves the sub groups around as if they were a single aura. We do in fact intend to solve this use case pretty directly! However instead of adding an abstraction layer (ie, treating whole groups as a unit), we are going the opposite direction (ie, give users the power to add/remove elements to each aura, so that the “sub groups” really are just one aura). The infrastructure for this is in active development, and we will have more concrete details in the near term future, once the infrastructure is complete.

     

    I hope this sheds some light on why this ticket has remained open for so long, and what we intend to do to solve it (because we do intend to do so, I promise!)


To post a comment, please login or register a new account.