None of these require cluttering up 25 frames with another bar, when the "low mana" indicator works perfectly for both.
I have to agree, the only good indicator someone came up with IMHO was Text2 - everything else (side indicators, extra bar,...) is against the concept of Grid. Well, maybe showing incoming heals as halth bar is nice too, but that's about it.
What are the current plans for tracking HoT's cast by anyone? Is inter-client communication necessary or does the WOW API provide the information needed? It's a candidate for addition to LibHealComm-3.0 but I haven't really looked thoroughly into the technical details of it, so not sure if this is something that might be better left handled elsewhere?
well, SpecialEvents-Aura provides the basic stuff. I don't think we need any comm-library, afaik the API allows to check the remaining time of all buffs you applied yourself (please correct me if I'm wrong), and I think Grid doesn't really need to care about the time left on hots you didn't cast yourself. xbeeps, if for some reason you want to write a hot library, I'd suggest to make it standalone and not part of LibHealComm-3. But maybe I'm missing a good reason why hots need an inter-client communication.
Quote from Phanx »
1. "Upper Text" and "Lower Text" -- hopefully it will still be possible to use just one text, in the center of the frame. To this effect I would suggest sticking with the current "Text 1" and "Text 2" names for these indicators.
Hmm. I assume most players use the second center text (or wish they'd realize there's a hidden setting to enable it), and in the default Grid setup (vertical health bar) I find it very appealing to have the unit name on the lower line and the missing hp (or whatever else) on the upper line (which is why I'd suggest to use that as default, opposed to the name on the upper line). Of course someone could add some code to vertically center either of the two indicators if the other indicator isn't bound to any status.
Quote from Phanx »
2. It appears that "Unit Name" is no longer considered a status. While for the most part this is fine, since the name can really only be displayed as text, this concerns me, as I use the "GridFriendlyNames" plugin that was posted by someone a while back to alter the displayed names for certain people, either because their names are identical when truncated to 4 characters, or because they go by something other than the first 4 characters of their name and it's easier to locate them when their name text is something I recognize. (Plus it's fun to change the names of people who irritate me. :P)
I didn't really think about the integration of external modules yet, but I could imagine having them as separate entries on the left pane (somehow marked so you know they are external modules), and probably they could even extend core options. Guess this is something that needs a good concept. And technically 'unit name' could still be a status, but some magic might display its options in the 'unit grouping' config screen. I dunno. I just wanted to keep the basic settings all together.
Quote from Phanx »
3. From what I've seen, the Ace3 GUI gives you three levels of options... logically, I think a sorting like this would be better:
I'd not want something selectable on the left pane if there's nothing to be displayed on the right pane (in your example that would be "Status Properties"). Besides that I think the indicator priorities should be at the end as you'd usually first set up the status, then move down in the left pane and define the priorities.
Quote from Phanx »
I'd take "PvP" out of there... I watched the discussion culminating in a PvP plugin for the current version of Grid, and I'm still not sure how PvP flag status is remotely relevant to any aspect of raiding. The argument I saw was that on a PvE server you'd want to avoid buffing people who were PvP flagged in order to avoid becoming PvP flagged yourself... the only time I can see this being an issue at all would be with world bosses like Kazzak and Doomwalker, and even then, are you really going to gimp your raid by not buffing or healing or otherwise touching people who are PvP flagged?
People playing on a PvE server do not want to accidentally spread a pvp plague near any 25man instance. My raid tells flagged people to zone out, try to escape alliance until the flag wears off, do whatever they want but stay away from the raid. Besides that, if you don't care about the pvp status, just don't enable the setting :)
Quote from Phanx »
As for "MT Status" I'd like to request giving users the choice of using Blizzard MTs or oRA2/CTRA MTs.
Whoever is going to write that code should probably look into supporting both options. The screenies I've scribbled aren't complete, they are just examples.
Quote from Phanx »
Oh... I brought this up before, but didn't see any response... I've seen quite a bit now about the simplified layout options, and would like to know if it will still be possible to create more complex layouts. I don't need in-game layout generation for this; the current hard-coding system is fine. But having "sort by class or by group" and "show raid pets?" and "display only max instance amount" will simply not be enough... in a 40-man raid group sorting that way was fine, but now sorting that way makes an ungainly sprawl all over my screen with two people in one class group, nobody in another, and five in another. And sorting by raid group doesn't help me effectively focus my yellow healing lasers. :)
I agree, and I think its technically possible to sort by class but still have 5ppl per column. As for 'special' layouts, someone might provide an optional module that allows you to define your personal group setup, and once you've 'saved' it, it could show up in the drop down selection. Same for the 'dynamic layout' module, that could have it's own config screen, but it's added as option to the general sorting drop down so you have all options available in one menu.
Won't quote the lengthy image maia, but that's about what I was talking about with more intuitive as well. You have my vote :P
I just have no clue how anyone could implement such a setup without planning to kill me: sometimes you have suboptions (like AFK, PVP,...) and then choose the indicator from the list of available indicators via a dropdown (and then define settings related to that kind of indicator), sometimes you have the option of using more than one indicator (e.g. in the inc heals pic), and then the settings below.
Maybe the more realistic version is to initially choose one indicator from a dropdown, then the related options appear, and below a button with "add another indicator", and once you click that button you have another dropdown to choose an indicator. So in theory you could assign each status to all indicators if you'd really want to. Oh, that idea is similar to the 'smart playlists' UI from iTunes.
Well, it's logically still a mess, it's a draft, but it's only here to gather input (UI-wise and technically).
I've decided to make some draft configuration screens I'd like to share with you. Please keep in mind that I have *no* idea about what's possible with AceConfig-3.0 (e.g. show and hide UI elements based on the current setting of a dropdown menu), and neither did I spend much time considering the limitations of the technical (modular) implementation. It's simply what I'd love to see as config screens in future versions of Grid, and in case someone with time, knowledge and interest likes them, feel free to implement them (or base your more realistic layout on them) in cooperation with Jerry and Pasta (unless they have good reasons for objections):
Just wanted to come back and comment on this again after using the GridStatusReadyCheck plugin... while the default colors are perfectly logical, I personally have a very hard time distinguishing the yellow "no response yet" indicator from the green "ready" indicator, but as there is no in-game facility for changing these colors, I've had to resort to editing the Lua.
Well, then the colors aren't optimal. We can have that discussion as long as we want, but I'll always be the 'Apple' guy, and I'll never want messy programs like MS Office. :)
I also don't like the concept of "information modules" that choose where to display themselves, as in maia's example of boss debuffs showing as a center icon and all other debuffs relegated to the border.
I'm not saying they choose where to display themselves, but that not every module needs to be displayable everywhere, and also it's an advantage to have everything related to heals in one package instead of having to go into seven different submenus and assign colors, priorities etc for each mini-status. Why do we have four modules for incoming heals if it can be one smart package? Why do we have a raid boss debuff module, a detox module, a core debuff module etc, if it should be one larger information module?
Quote from Jerry »
I would object to both these requests. The first because this is information clutter that I don't need/want to be able to heal effectively.
I agree, but I do think we could have stuff like that displayed only out of combat, or only when pressing a meta key. This is probably part of a 'raid unit status' module raid leaders will want to use (pvp, afk,ML,...).
I'd like to add some thoughts and some information:
the current status is that Jerry is working on an Ace3 version of Grid with a new roster unit code - this means, he has to rewrite lots of the core functions. Besides that, pastamancer has been messing with some ideas for new ways to setup Grid, which would also allow an easy import/export of any configuration. I don't have any details about the current progress or schedule, but I assume pasta and jerry will post in this thread sooner or later.
As for some optimizations: yes, I do believe most of the people that are using Grid are either healers or raid leaders. And yes, I do believe we have way too many small external modules, and we should merge some functionality. Three easy examples: a) everything related to healing, b) everything related to (de)buffs, c) raid status stuff (pvp flag, readycheck, offline, not in range,...), more see below.
Besides that, I'd love to see an optimization of displays - mainly for the simple reason that finding a good UI setup isn't an easy task, and ideally most people will use the (good) defaults.
While having complete control over a setup, I do think we could reduce the options. Obviously, a status doesn't have to be displayable at all indicators, but also it might be too much to define all the details of a combined status like the one mentioned above. We're currently at the UI problem most Microsoft Office products have: they can do a lot, but people just don't find anything anymore.
I therefor think that (appropriate) indicators should be a submenu of status modules, and that we should merge status functionality to have things like:
1) HEALS: available as text display only, maybe the option of a 'second' health bar displaying incoming heals (like VisualHeal). Text display: e.g. "-5 +2" (aka -5k health and +2k incoming). And yes, I think LibHealComm-3 should be part of the Grid core addon.
2) HOTS: only available as corner/border indicator, displaying the number of applied hots (Renew, Lifebloom,...) by a gradiently changing color, but it could also blink if a hot you casted yourself is going to wear off within 3 seconds. A tooltip could display the details for the hots.
3) THREAT: A single corner/border indicator could display lots of aggro/threat information: a bright red for bosses or aggro from multiple targets, a darker orange for 'normal' aggro, orange for a very high threat, blinking on gaining aggro, blue for threat reductions/resets (fade, feign death,...).
4) UNIT STATUS: either displayed as text or as corner indicator (oh, if we'd have tooltips they'd be useful here too), showing basics (pvp status, offline, >100 yrds away, ready,...) but maybe also the results of oRA queries (e.g. durability)
5) DEBUFFS: added support for raid boss debuffs to core, smart priority ordering: four groups for debuffs (with descending priority): raid boss debuffs, curable important debuffs, uncurable important debuffs, unimportant debuffs (the debuffs you usually don't care about, such as the mage frostbolt proc). Probably center icon / text / border / corner indicator options.
6) BUFFS: center icon / text only: display of missing buffs (only out of combat) you can buff yourself.
7) CLASS RELATED INFORMATION: e.g. for priests it would default to (in descending priority) Prayer of Mending / Shield / Shield debuff, other classes might need other information.
Each of these information modules would allow the binding to one or more indicators (e.g. the debuff indicator might use center icon for boss debuffs and border for all other debuffs), but besides some basic configuration I don't see the need to e.g. change each color for a gradient hot indicator, or the threat level in percent for the threat display. We only need good defaults.
As for the layout code, I think we can reduce the options too, we only need some basic settings like "sort by group or class", "display pets?", "display all raid units or limit to max number in instance?" and Grid will do the rest.
Finally, I'd just like to remind everyone that if you're willing to contribute to the development, please get in touch with Jerry and Pastamancer, as they are working on the code.