Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
Very nice draft for the UI (draft is an understatement!).
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?
Just a couple things that jumped out at me while going over your mockups:
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.
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)
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:
Layout
- General
- Anchoring
- Sorting
Indicators
- Text 1
- Text 2
- Health Bar
- Border
- Top Left Corner
...
Status Properties
- Buffs and Debuffs
--- Missing Buffs
--- Curable Debuffs
--- Raid Debuffs
--- Healing Reduction Debuffs
- Heals
--- Incoming Heals
--- Heals Over Time
--- Overhealing
- Threat
--- Aggro
--- Threat
- Raid Status
--- Offline
--- AFK
--- Ready
--- Raid Icons
--- MT/MA
Generally once I pick a color for something, I don't need to do it again, and am more likely to be switching around indicator locations... hence my placement of Indicators above Status Properties.
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?
As for "MT Status" I'd like to request giving users the choice of using Blizzard MTs or oRA2/CTRA MTs. My guild uses the Blizzard MT markers, but also requires that oRA2/CTRA be installed so that the raid leaders can track raid cooldowns etc. I don't know if there are currently and MT indicator plugins for Grid, but I know that PitBull won't display Blizzard MTs if oRA2/CTRA are installed, and I'd prefer Grid didn't also make that assumption.
With the indicator priority screen I'd like to see that dynamically update... for example, if I have "AFK" set as the third priority, and I then select "AFK" as the first priority, my previous first priority shifts down to second, and previous second shifts down to third. As this is possible with the current AceOptions system (see Numen for a great example) I'm assuming it will be possible in Ace3.
Finally, I hope there will be something like "/grid lock" to quickly toggle the locked status of the frame.
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. :)
[Edit] In response to the post about a "simulation mode", I'd like to see this as well. In general I like PitBull's "configuration mode"... but I'd suggest that changes made while in this mode should not be applied without confirmation.
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.
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.
Oh yes, sorry i forgot only the caster is interested in the HoT's. Still the outgoing ticks should be sent to libhealcom (e.g. 3Stack lifeboom in 2 secs - lifebloom full heal in 4 secs (and this one should update / be delayed if lifebloom is renewed).
I guess it really depends what incoming heal info people care about.. for example I only care about whether the unit in grid already has a heal being cast on them, so I can start a new cast on someone else if I am raid healing. Basically the current Grid functionally with HealComm-3.0 support I guess.
We try not to play whack-a-mole on bosses, assign paladins and druids as tank healers, assign shaman/coh priests to raid healing = Profit. Trash is usually whack-a-mole.
So on my grid frames a value for incoming heal amount is fairly useless. Yet other people like to see a value for incoming heals al la visual heal.
Hmm. I assume most players use the second center text (or wish they'd realize there's a hidden setting to enable it)
Oh I know there's a setting to enable it, I just don't use it. Too much clutter.
Quote from maia »
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.
During inital setup, maybe; I was thinking more of things I'd want to configure more often over my total time using the addon. Although I'd still argue that if you had good defaults, most people would be more interested in configuring where a status was shown on the frame than in configuring what colors to use for the status. Going back to my ready check example, I'm sure the "yellow = no response, green = ready" colors work wonderfully for the majority of users, so the most common way people would want to modify this status would be to configure which indicator to use (top left corner, border, etc) rather than changing the colors.
Quote from maia »
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 :)
Hmm. I still don't see why it matters if you're PvP flagged while you're inside a 25-man instance, or why you'd need to buff or heal or do other flag-spreading activities outside the instance, or why if you get flagged you can't just zone in. I don't play on a PvE server, though, so I guess I just don't see the problem. :P
Quote from maia »
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.
It's more than techincally possible to sort by class within a single (wrapping 5-column) group; I use just such a layout now. My concern with a built-in class sort is that the default alphabetical class sort isn't very useful. I have mine set to sort like this: warrior, rogue, druid, paladin, shaman, priest, mage, warlock, hunter. This way classes that are always in melee range are shown first, followed by hybrids that can be melee or ranged, followed by classes that are always ranged; there's also a bit of healing priority in there, as you can see with warlocks and hunters (who shouldn't really ever need heals) at the bottom.
Hmm. I still don't see why it matters if you're PvP flagged while you're inside a 25-man instance, or why you'd need to buff or heal or do other flag-spreading activities outside the instance, or why if you get flagged you can't just zone in. I don't play on a PvE server, though, so I guess I just don't see the problem. :P
On a PvE realm, if one person is PvP flagged at the beginning of a raid, this happens :
- Any raidmember that buffs / heals him gets PvP flagged, pretty soon you end up with half your raid PvP flagged
- If a groupbuff is applied with someone non PvP flagged targeted, PvP flagged groupmembers don't get the buff
- Later on during the fights, unless specifically targeted, group heals or multiple heals (think shaman) won't heal PvP flagged people, there may be issues with things like shadowpriest mana regeneration too
PvP flags (or rather raids half PvP flagged) are eeeeevil on PvE realms trust us
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.
Sorry about that. Making them configurable would have required making Waiting/Ready/Not Ready separate statuses, which seemed less desirable.
May I suggest configuring it to show as Center Icon instead? You might find it easier to distinguish.
On a PvE realm, if one person is PvP flagged at the beginning of a raid, this happens :
- Any raidmember that buffs / heals him gets PvP flagged, pretty soon you end up with half your raid PvP flagged
- If a groupbuff is applied with someone non PvP flagged targeted, PvP flagged groupmembers don't get the buff
- Later on during the fights, unless specifically targeted, group heals or multiple heals (think shaman) won't heal PvP flagged people, there may be issues with things like shadowpriest mana regeneration too
PvP flags (or rather raids half PvP flagged) are eeeeevil on PvE realms trust us
Yeah, the key is not what happens when they're pvp flagged, it's what doesn't happen when half the raid is pvp flagged. If a few are flagged, then the whole raid has to flag. Chain heal won't touch them. They won't get group buffs. etc.
- If a groupbuff is applied with someone non PvP flagged targeted, PvP flagged groupmembers don't get the buff
- Later on during the fights, unless specifically targeted, group heals or multiple heals (think shaman) won't heal PvP flagged people, there may be issues with things like shadowpriest mana regeneration too
I didn't know these kind of spells distinguished between flagged and non-flagged players. o_O
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.
One reason to make it part of LHC-3.0 is that it already listens to UNIT_AURA, and runs through the buffs (to determine heal modifier), so i guess this could be extended to also keep track of own HoT's and broadcost the neccessary info to other clients, without adding too much additional processing. But again, I haven't looked very thorougly at this, so maybe this is not needed at all.
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?
[Edit] In response to the post about a "simulation mode", I'd like to see this as well. In general I like PitBull's "configuration mode"... but I'd suggest that changes made while in this mode should not be applied without confirmation.
The pvp .. when I am healing (or tanking depending on what I am doing - running SM as 55 is tanking usually lol) I couldn't care less about PvP, even if I would be killing Kazzak, I'd still buff and heal. It's what pallys do, if I happen to get killed in the process by a horde then I hope I get that last buff/heal off before having to run back. But when you're on a worldboss like that and flagged, your raid most likely is doomed for failure when horde are around. It's the one thing you really don't need when trying to down world bosses.
The simulation mode, I totally second/third/fourth that. It would make it a lot easier, and would also help getting new comers to see what setting exactly does what :) Kill 2 birds in one stone.
Quote from Mokhtar »
On a PvE realm, if one person is PvP flagged at the beginning of a raid, this happens :
- Any raidmember that buffs / heals him gets PvP flagged, pretty soon you end up with half your raid PvP flagged
- If a groupbuff is applied with someone non PvP flagged targeted, PvP flagged groupmembers don't get the buff
- Later on during the fights, unless specifically targeted, group heals or multiple heals (think shaman) won't heal PvP flagged people, there may be issues with things like shadowpriest mana regeneration too
PvP flags (or rather raids half PvP flagged) are eeeeevil on PvE realms trust us
I didn't know this, but then again, I've just obtained my first Greater Blessings, so I've not toyed with them much.
One of the trickiest aspect of "Simulation mode" is that Grid heavily rely on SecureHeaderGroup code in the Blizzard UI, which has no support for simulation.
I just wanted to clarify about the Incomming Health/Heals stuff:
I am currently using the ExtraBar feature which adds a shaded bar behind the Healthbar with the expected incoming Health. This makes it easier for me to distinguish if a HoT, Lower Heal or Greater Heal is needed (if there is time for the later).
I think the different features people use are:
Incomming Heal Indicator (someone else is Healing the Target)
Incomming Heal Text '+X'(Someone is Healing the Target for amount X)
Incomming Heal Text '+X/+Y'(Someone is Healing the Target for amount X, Your for amount Y)
Incomming Heal Bar %X (The incomming Heal would Heal the target to %X health)
Incomming Heal Bar %X/%Y (The incomming Heal would Heal the target to %X health and your heal up to %Y)
Part of all indicators are the time they require to Cast (e.g. Flash Heal vs Greater Heal) - where the tank might be healed for enough, but the Greater Heal does not complete before the tanks death.
For Hots:
Show the Total amount healed, or just the ticks in the next 2/4/6 seconds ?
The Healthbar is useful as a greater Heal for 5K heals the poor mage with 8k usually to full health, where a well beaten Druid with 25K can take a few.
Oh yes, sorry i forgot only the caster is interested in the HoT's. Still the outgoing ticks should be sent to libhealcom (e.g. 3Stack lifeboom in 2 secs - lifebloom full heal in 4 secs (and this one should update / be delayed if lifebloom is renewed).
I doubt if any healer is interested how many time left before hots went off. Do you really check Hots time like dpser in raid? Healer only have time to care about if this person have Hots on or not. Even though lifebloom will full heal in 4 secs. As healer can you guarantee your target won't go down before lifebloom's full heal? Healer like pally won't stop heal even if they know lifebloom will heal that target to full after 4 sec.
Organized raid heal assignment is always better than healer working on their own. Those information might be useful but not as much as people think in theory.
Also too much information display on a small area is way too mess. I'm pretty happy about the information that original grid give to us. For those mod, how many of them are really useful. (eg: show mana bar on grid. Who is going to check everyone's mana when you heal. Raid leader won't use that as well. There is other addon that show whose mana is on low. Much better than you check 25 people's mana bar and find by yourselves.)
By the way. Do you think those player that come to find mod for grid is new user? I think all those people that try to find mod for grid is advance user. Normal player won't know there have so many function for them to use.
Also if you combine all mod to standard version. When a new user pick up this addon and see so many function. What will happen? They might throw away after 1 min. Same as difference between pitbull and ag_uf.
I just want point out. Too much function will only lead to failure. Make grid as standard addon. As long as it is easy to make mod and easy to share config is ok.
I doubt if any healer is interested how many time left before hots went off. Do you really check Hots time like dpser in raid? Healer only have time to care about if this person have Hots on or not. Even though lifebloom will full heal in 4 secs. As healer can you guarantee your target won't go down before lifebloom's full heal? Healer like pally won't stop heal even if they know lifebloom will heal that target to full after 4 sec.
The real problem arises when several healers diverge their heals from a target who takes a lot of damage (i.e. a main tank), to heal someone who are not directly taking damage but may take damage later. Only one healer is needed to throw that single heal, but too often several healers do it, and often they discover this, and all of them stop or else they all continue wasting time and mana while the main tank might die. VisualHeal was invented to prevent this, because when you heal, only the incoming heals that will land *before* your heal is shown on the bar. Both (or all) healers will instantly know who has to continue and who has to stop, and the others can quickly go back to healing the tank before he dies. Now, with integration into unit frames (like Grid) you don't have to start a heal of your own on a target before you can see other heals to that target, so it is even faster to determine whether you should diverge your healing from your main target.
Quote from Yasuna »
Organized raid heal assignment is always better than healer working on their own. Those information might be useful but not as much as people think in theory.
And you can't have both, or what are you implying? By having both, you gain the edge when improvisation beyond the assignments are needed.
Quote from Yasuna »
Also too much information display on a small area is way too mess. I'm pretty happy about the information that original grid give to us. For those mod, how many of them are really useful. (eg: show mana bar on grid. Who is going to check everyone's mana when you heal. Raid leader won't use that as well. There is other addon that show whose mana is on low. Much better than you check 25 people's mana bar and find by yourselves.)
Innervate? Mana Tide Totem?
Quote from Yasuna »
By the way. Do you think those player that come to find mod for grid is new user? I think all those people that try to find mod for grid is advance user. Normal player won't know there have so many function for them to use.
You don't have to be a new user to desire simplicity and good defaults. I hate addons that don't work out of the box. Many and advanced options does not rule out the possibility of an addon that is functional and well configured out of the box.
Quote from Yasuna »
Also if you combine all mod to standard version. When a new user pick up this addon and see so many function. What will happen? They might throw away after 1 min. Same as difference between pitbull and ag_uf.
I just want point out. Too much function will only lead to failure. Make grid as standard addon. As long as it is easy to make mod and easy to share config is ok.
Again, good defaults for the win...
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
E.g.
Making basic testing possible for setups (e.g. layout space).
If there is a separate Window for Priorities the Indicator menu becomes obsolete.
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?
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.
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)
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:
Generally once I pick a color for something, I don't need to do it again, and am more likely to be switching around indicator locations... hence my placement of Indicators above Status Properties.
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?
As for "MT Status" I'd like to request giving users the choice of using Blizzard MTs or oRA2/CTRA MTs. My guild uses the Blizzard MT markers, but also requires that oRA2/CTRA be installed so that the raid leaders can track raid cooldowns etc. I don't know if there are currently and MT indicator plugins for Grid, but I know that PitBull won't display Blizzard MTs if oRA2/CTRA are installed, and I'd prefer Grid didn't also make that assumption.
With the indicator priority screen I'd like to see that dynamically update... for example, if I have "AFK" set as the third priority, and I then select "AFK" as the first priority, my previous first priority shifts down to second, and previous second shifts down to third. As this is possible with the current AceOptions system (see Numen for a great example) I'm assuming it will be possible in Ace3.
Finally, I hope there will be something like "/grid lock" to quickly toggle the locked status of the frame.
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. :)
[Edit] In response to the post about a "simulation mode", I'd like to see this as well. In general I like PitBull's "configuration mode"... but I'd suggest that changes made while in this mode should not be applied without confirmation.
Sure, but what kind of functionality is needed exactly? Library function calls? events? And what information should these calls/events convey?
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.
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.
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.
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.
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 :)
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.
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.
Oh yes, sorry i forgot only the caster is interested in the HoT's. Still the outgoing ticks should be sent to libhealcom (e.g. 3Stack lifeboom in 2 secs - lifebloom full heal in 4 secs (and this one should update / be delayed if lifebloom is renewed).
We try not to play whack-a-mole on bosses, assign paladins and druids as tank healers, assign shaman/coh priests to raid healing = Profit. Trash is usually whack-a-mole.
So on my grid frames a value for incoming heal amount is fairly useless. Yet other people like to see a value for incoming heals al la visual heal.
Oh I know there's a setting to enable it, I just don't use it. Too much clutter.
During inital setup, maybe; I was thinking more of things I'd want to configure more often over my total time using the addon. Although I'd still argue that if you had good defaults, most people would be more interested in configuring where a status was shown on the frame than in configuring what colors to use for the status. Going back to my ready check example, I'm sure the "yellow = no response, green = ready" colors work wonderfully for the majority of users, so the most common way people would want to modify this status would be to configure which indicator to use (top left corner, border, etc) rather than changing the colors.
Hmm. I still don't see why it matters if you're PvP flagged while you're inside a 25-man instance, or why you'd need to buff or heal or do other flag-spreading activities outside the instance, or why if you get flagged you can't just zone in. I don't play on a PvE server, though, so I guess I just don't see the problem. :P
It's more than techincally possible to sort by class within a single (wrapping 5-column) group; I use just such a layout now. My concern with a built-in class sort is that the default alphabetical class sort isn't very useful. I have mine set to sort like this: warrior, rogue, druid, paladin, shaman, priest, mage, warlock, hunter. This way classes that are always in melee range are shown first, followed by hybrids that can be melee or ranged, followed by classes that are always ranged; there's also a bit of healing priority in there, as you can see with warlocks and hunters (who shouldn't really ever need heals) at the bottom.
On a PvE realm, if one person is PvP flagged at the beginning of a raid, this happens :
- Any raidmember that buffs / heals him gets PvP flagged, pretty soon you end up with half your raid PvP flagged
- If a groupbuff is applied with someone non PvP flagged targeted, PvP flagged groupmembers don't get the buff
- Later on during the fights, unless specifically targeted, group heals or multiple heals (think shaman) won't heal PvP flagged people, there may be issues with things like shadowpriest mana regeneration too
PvP flags (or rather raids half PvP flagged) are eeeeevil on PvE realms trust us
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSorry about that. Making them configurable would have required making Waiting/Ready/Not Ready separate statuses, which seemed less desirable.
May I suggest configuring it to show as Center Icon instead? You might find it easier to distinguish.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYeah, the key is not what happens when they're pvp flagged, it's what doesn't happen when half the raid is pvp flagged. If a few are flagged, then the whole raid has to flag. Chain heal won't touch them. They won't get group buffs. etc.
I didn't know these kind of spells distinguished between flagged and non-flagged players. o_O
One reason to make it part of LHC-3.0 is that it already listens to UNIT_AURA, and runs through the buffs (to determine heal modifier), so i guess this could be extended to also keep track of own HoT's and broadcost the neccessary info to other clients, without adding too much additional processing. But again, I haven't looked very thorougly at this, so maybe this is not needed at all.
The pvp .. when I am healing (or tanking depending on what I am doing - running SM as 55 is tanking usually lol) I couldn't care less about PvP, even if I would be killing Kazzak, I'd still buff and heal. It's what pallys do, if I happen to get killed in the process by a horde then I hope I get that last buff/heal off before having to run back. But when you're on a worldboss like that and flagged, your raid most likely is doomed for failure when horde are around. It's the one thing you really don't need when trying to down world bosses.
The simulation mode, I totally second/third/fourth that. It would make it a lot easier, and would also help getting new comers to see what setting exactly does what :) Kill 2 birds in one stone.
I didn't know this, but then again, I've just obtained my first Greater Blessings, so I've not toyed with them much.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI am currently using the ExtraBar feature which adds a shaded bar behind the Healthbar with the expected incoming Health. This makes it easier for me to distinguish if a HoT, Lower Heal or Greater Heal is needed (if there is time for the later).
I think the different features people use are:
Part of all indicators are the time they require to Cast (e.g. Flash Heal vs Greater Heal) - where the tank might be healed for enough, but the Greater Heal does not complete before the tanks death.
For Hots:
Show the Total amount healed, or just the ticks in the next 2/4/6 seconds ?
The Healthbar is useful as a greater Heal for 5K heals the poor mage with 8k usually to full health, where a well beaten Druid with 25K can take a few.
I doubt if any healer is interested how many time left before hots went off. Do you really check Hots time like dpser in raid? Healer only have time to care about if this person have Hots on or not. Even though lifebloom will full heal in 4 secs. As healer can you guarantee your target won't go down before lifebloom's full heal? Healer like pally won't stop heal even if they know lifebloom will heal that target to full after 4 sec.
Organized raid heal assignment is always better than healer working on their own. Those information might be useful but not as much as people think in theory.
Also too much information display on a small area is way too mess. I'm pretty happy about the information that original grid give to us. For those mod, how many of them are really useful. (eg: show mana bar on grid. Who is going to check everyone's mana when you heal. Raid leader won't use that as well. There is other addon that show whose mana is on low. Much better than you check 25 people's mana bar and find by yourselves.)
By the way. Do you think those player that come to find mod for grid is new user? I think all those people that try to find mod for grid is advance user. Normal player won't know there have so many function for them to use.
Also if you combine all mod to standard version. When a new user pick up this addon and see so many function. What will happen? They might throw away after 1 min. Same as difference between pitbull and ag_uf.
I just want point out. Too much function will only lead to failure. Make grid as standard addon. As long as it is easy to make mod and easy to share config is ok.
The real problem arises when several healers diverge their heals from a target who takes a lot of damage (i.e. a main tank), to heal someone who are not directly taking damage but may take damage later. Only one healer is needed to throw that single heal, but too often several healers do it, and often they discover this, and all of them stop or else they all continue wasting time and mana while the main tank might die. VisualHeal was invented to prevent this, because when you heal, only the incoming heals that will land *before* your heal is shown on the bar. Both (or all) healers will instantly know who has to continue and who has to stop, and the others can quickly go back to healing the tank before he dies. Now, with integration into unit frames (like Grid) you don't have to start a heal of your own on a target before you can see other heals to that target, so it is even faster to determine whether you should diverge your healing from your main target.
And you can't have both, or what are you implying? By having both, you gain the edge when improvisation beyond the assignments are needed.
Innervate? Mana Tide Totem?
You don't have to be a new user to desire simplicity and good defaults. I hate addons that don't work out of the box. Many and advanced options does not rule out the possibility of an addon that is functional and well configured out of the box.
Again, good defaults for the win...