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.
On my resto shaman main, I have the low mana threshold set to 35%. Maybe my guild does it differently than yours, but we expect our raiders to be able to manage their own mana, just as we expect them to move out of void zones, attack the right target, keep the zombies away from Gluth, heal the tank, and not pull aggro.
If I know a fight will last long enough for a second Mana Tide, I'll drop it early when I'm around 75% mana myself, regardless of how much mana anyone else has. If the fight isn't that long, then I just wait until I see blue borders on everyone in the party. If PriestX is running OOM and needs the Mana Tide early, well, he's a big boy and he can communicate. If he's consistently running OOM before anyone else, it's probably time to sit down with him and figure out why he's having such a problem managing his mana.
Also, if I really have some burning need to know the exact amount of mana someone has, I have tons of time while the lasers are charging to just target them. :p
We expect the restos to be aware of their group and use it as soon as everyone is below 75% with the assumption a 2nd Tide will become available as they are the only ones in control of said Mana Tide.
Using it yourself at 75% when everybody else is at 90% would get you sat and a good talking to form my GL probably...they are fairly big on raid/party buffs being used properly (ie maximizing their results).
Grid mana bars pretty much are required for this then, or I have to have Pitbull group frames up (which I do not care to fill the screen up with in a 25)
I suspect you will find a larger group of people using Grid Mana bars than the few who write on this forum as the comparison to grid vs gridmanabars downloads on Curse is 30k vs 100k...30% of us. Once/if Grid2 takes over for Grid they will be just like the Auctioneer folks were when they scrapped big pieces of their app...coming out of the woodwork
Using it yourself at 75% when everybody else is at 90% would get you sat and a good talking to form my GL probably...they are fairly big on raid/party buffs being used properly (ie maximizing their results).
Considering that I've successfully led my guild through completing all of the 10-man achievements pre-Ulduar, have solo healed 3-drake Sartharion and most of Naxxramas, and am currently leading our 10-man Ulduar achievement group, I'd have to disagree with your implication that I'm playing my class wrong.
Let's say you have a fight that lasts 7 minutes. I can either (a) wait until everyone is below 76% mana, and then not have time to use a second Mana Tide, or (b) use one Mana Tide at 1 minute in, regardless of whether everyone will gain the full amount, and then be able to drop a second one at 6 minutes in, when everyone will certainly gain the full amount. Even if everyone in the party is only at 90% when I drop the first one, if the timing means I'll be able to drop a second one, how is everyone getting 42% of one Mana Tide and 100% of a second Mana Tide not better than the party only getting 100% of one Mana Tide?
Mana bars give a quick view at the exact information. % indicators downsample the information. It's in the eye of the beholder what information they want and how much effort/information overload they want.
Neither is better or worse (performance wise) as long as we don't have a scientific experiments that shows that one is without a doubt faster than the other.
For Grid's geometric arrangement vs stuff like a vertical row of frames: We do have a scientific theory that show that the first is much faster than the second: Fitts's law. M_t=a+b log(1+D/W) where M_t is mean time, a, b are constants depending on the person, D is distance and W is width of the target in a motor motion task in the plane. This theory is broadly verified and at the core of much of the input interaction side of HCI today.
So if someone tells me I should want if I want a fast solution grid I agree to that because the rectangular arrangement means smaller average distance between two raid members.
For mana bars being distracting, I know of no tangible scientific theory showing that this is true. I know quite a few phenomena and experiment that relate but none to the best of my knowledge clearly confirms or denies the stated hypothesis that they are bad. Phenomena and experiments that are possibly relevant relate to: the pop-out effect [1,2,3], selective inattentional blindness [4] ,studies of forced attention switching and performance interference [5,6]
It is my understanding that we are (a) pretty good at keeping attention (b) in fact often tangibly don't even cognitively "see" distractors (c) are hard to distract even by significantly odd distractors (d) visual and other cross-sensory effect can degrade relative performance in some cases.
But I'm just a casual reader of that kind of stuff, so someone who had full working knowledge of the field could likely say much more than this.
That said for me the whole discussion comes down to taste until someone actually sits down a large pool of people and tests and shows a broad significant effect for or against mana bars.
Even if there was a study that resolved this one way or the other, I don't actually think that people who do not want a grid-layout are "wrong". People have to pick solutions to their preference and comfort level. Ultimately what matters is not what is fastest, but if anybody died in raid. If people achieve that with their respective solution and are happy with their solution, I consider it a good solution.
References:
[1] Ware, C. (2004) Information Visualization: Perception for Design. (2nd Edition) Morgan Kaufman. (Great reference with focus on applicability to interface design)
[2] Wolfe, J M (1998 ). Visual Search. In H. Pashler (Ed.), Attention, East Sussex, UK: Psychology Press.
[3] Theeuwes, J. (1992). Perceptual selectivity for color and form. Perception & Psychophysics, 51, 599-606.
[4] Simons & Chabris (1999). Gorillas in our midst: sustained inattentional blindness for dynamic events. Perception, 28, 1059-1074.
[5] Styles, E. A. (1997) The Psychology of Attention, Psychology Press.
[6] Stuart, G. W. , McAnally, K. I. Meehan, J. W. (2003) The overlay interference task and object-selective visual attention. Vision Research, 43:13, 1443-1453.
researched debate in wow? what is the world coming to.
how about this? %text indicator below a threshold. ie: at 30% it appears and reads "30%" (or whatever actual percentage) and then disappears once over 30%. Configurable threshold of course.
Best of both worlds, info only when required and fully granular when it is required.
Your grid starts to light up with text you know the raid is very low mana, obviously you would select a relatively tiny font size, 6 or 7 or something.
Currently using stufraid whilst I await the second coming of Grid :P.
alternatively have a full width mana bar which at full represents a configurable percentage. (Likely not blue to avoid the unconscious indication of full=100%) Above the setpoint the manabar would hide of course.
ie: you could show the bar as full width at 30% (yes you would need to do math on the fly) or others may set it up to be full width at 100% (ie: what is normal currently).
...the bar code is hacky. I didn't find a clean way to hook the current bar indicator layout function, so I had to duplicate a lot of the code to allow for an alternative layout function to be fed. There are various ways to make this cleaner/easier. Either the bar indicator gets made more flexible to allow width hence removing the need to override, or a second indicator type such as sidebar for that purpose might be helpful...
The current health bar code needs some messing with as the heals bar is not always functional. Due to the color inversion etc. and its implications it is also not the correct basis for a Bar Status imo. I am rather tempted to just directly implement it instead of hacking around with 1-3 of the Blizzard status bars.
If that is done it may be possible to extract some common code for both the health / healing displays and the bar displays discussed here.
Mana Bars are unlikely to ever be included in the core due to the severe performance penalties. They are quite fine as a separate plugin for whoever wants to use them.
As for a Bar status, I have a vague idea that it may be a good alternative way to show lifebloom / rejuv / regrowth timers, especially if they are based on the max time of regrowth so they can be directly compared. There could possibly even be notches for their particular GCD.
Which reminds me. Is the gcd based timing in Grid popular? Does it need porting to Grid2? Is it even useful in the face of different cooldown times for different spells? (well for druids at any rate).
One more thing, the current mana status has a single threshold. I think there was discussion somewhere to allow multiple versions / multiple thresholds for it which would be a nice way to get somewhat more detail without getting the full mana bars penalty. Overhead vs the current one is 1 extra if / threshold in the detection / color / text code.
When updating to the latest Grid2 revision the Healthframe stays black for all mana-classes. When disabling Grid2ManaBar everything works fine, so do you guys know any new version of this or a quick fix for the problem? It seems to have to do with the StatusAura changes in the latest revisions. I also would be fine with the possibility to set up ~3 Manaindicators for different tresholds, but I think this doesn't work without a plugin either yet.
All right, I finally read this entire post after noticing the reference to Grid2ManaBar which I had not seen before. I think the approach needs to be to have a bar indicator to build this on. I do not think the current bar indicator is that thing as they have unresolved dependencies on the health and incoming heals that makes them less than reusable.
I can see the need for two types of bar indicators, or an indicator with two behaviors:
1) Countdown bar. This could be used for instance to show druid hot timers. Ideally for me it would be real time and not %. So you could set max to the 27 seconds of a regrowth and then everything else is relative to that: rejuv at 18 and 9 for lifebloom. Relative length would give you relative time.
2) Percent Bar. This is just like the current bar and would handle any % status.
Both cases there needs to be an orientation, location and width + length for the bar(s).
In the case of the Countdown bar there is also a value which is its "100%", so 27 in the druid case.
...Main thing about the code. ManaColor would very likely be better placed in StatusMana.lua. For now it duplicates virtually all of the code of LowMana/Mana to offer the appropriate power-based color status...
I think the change needed is to rename lowmana to mana-low. It has its color built in which is fine as its simply a low mana indicator. You would not want a low focus or low rage indicator. Also, low mana is low mana. It is better to hook up this single status than to split out its color.
Your ManaColor needs to be power and power-color if it is going to handle non-mana types.
At that point it can maybe replace some of the low mana stuff.
If it is not burdensome the power code can replace some of what is in the core ... ?
First off I know Grid2ManaBars is broken. It was a proof of concept back when and I am waiting to get a sense that Grid2 won't be changing anymore before making it permanent.
Having inherent bar-like indicator types would rock, basically what I was hoping for when we first had this discussion.
The status side is easier. Really I didn't do other power types because it was proof of concept not because it's hard to do. My remarks mostly have to do with code footprint and efficiency. I had to duplicate code to get the mana bars working, and some of that duplication is in fact also inefficient (i.e. power color or power value are read out more than once) only because the core support of mana wasn't set up for continuous readout yet. If the core mana (and other power types) expose continuous values of power types, all this goes away.
If there are indeed core-supported indicators and a more suitable mana/power status, it will be easy to write a clean Grid2ManaBars, so I would just rewrite the whole thing from scratch. The current (old) code is kind of messy, given that Grid2 wasn't really supporting this kind of stuff.
I'm kind of busy right now, but maybe I can find time to write a pseudo-new-Grid2ManaBars on the assumption that indicators and status are as they should be. The whole thing would reduce to very simple code in that case.
A few things this doesn't do at all right now:
*) Handle non-horizontal orientation
*) Only works with side-bottom
*) Does not offer any power type except for mana
Design issue:
*) Overlays rather than rearrange the health bar.
Likely good steps to take:
*) Make a real percentage-bar indicator rather than hijacking the standard bar indicator one. Alternative solution is to give the bar indicator some basic layouting feature.
*) Move ManaColor into StatusMana, or have a PowerColor instead.
*) Options: Adjust height of bar.
I couldn't get this working. I checked out Grid2ManaBar.lua and Grid2ManaBar.toc from the SVN, and put them a directory named Grid2ManaBar in the interface/addons folder. It appears in the wow addon selection screen, so it looks like it is loading. But in the grid2 configuration screen the "bar-mana" status indicator doesn't appear. (Assuming this is the name based on what I am reading in the lua script itself.)
EDIT: Made the rest of this into a separate post since it's unrelated to getting it working.
By the way, I'm not sure I understand why this kind of addon would cause performance issues. In looking at what Elsia posted, it doesn't appear to be doing anything fundamentally different from what the health and heals bars already do (other than perhaps in a future version it will ask the other bars to scale differently in order to give itself some frame real estate, but I still don't understand why that would cause a performance issue.)
In fact if anything I agree with what Elsia is thinking here. Why not allow more options as far as a bar type indicator? Say for example, somebody wants a bar to show up in grid for perhaps a short duration buff. Something along the lines of having a bar appear when I cast lifebloom, the bar starts at 100% going down to 0% indicating the time remaining on the buff. You could then allow these bars to change colors or even blink based on other factors (e.g. how many stacks of lifebloom changes the color of the bar.) Other options could include inverting that (e.g. buff starts with bar at 0%, moving up to 100% when the effect ends) changing where the bar starts from (e.g. 0% starts at the top, 100% ends at the bottom, or vice versa) as well as the location (along the top, along the side, etc.)
This probably isn't something I would do in my own setup, but it might be something that somebody would find useful somewhere. If you could just add it in there without the need to go learn how to code lua (or find somebody who can) it would be pretty neat.
This could also have the result of streamlining how the default frame is configured. For example now you'd have a framework setup where the person could configure their health bars to e.g. blink when they are low, change color when they are low, etc, all without needing one indicator for bar-health and another indicator for bar-health-color for example.
It requires updating up to 40 mana bars. That's the performance difference really. In my experience that isn't really a performance drain at all (on my crummy old machine), but people's mileage may vary. Having this as a module is a good solution tbh.
On it not working: You want bar-mana-color to manacolor. For now it only works if set to bottom side but it should work for that case. It does not work for anything but mana yet. It really is pre-alpha.
It requires updating up to 40 mana bars. That's the performance difference really. In my experience that isn't really a performance drain at all (on my crummy old machine), but people's mileage may vary. Having this as a module is a good solution tbh.
In that case I think what would be ideal is if grid core could include an ability to configure bar indicators for whatever status you want, much as I described above.
Then separately from core, as a module we could have Grid2StatusMana which we could set our bar indicator to follow. Also if somebody desires it, we could also have modules for (though to be honest I think their use would be limited to arena) Grid2StatusEnergy, Grid2StatusRage, and Grid2StatusRunicPower. And you could, at your option configure all of these to show up on the same bar indicator, and this would result in the same functionality as the existing GridManaBars.
This would allow us to have an elegant system for easy to configure (by the user, within the UI) bars in the grid2 core, but while at the same time keeping the performance issues addressed in that, nobody would have any potential for such performance issues unless they installed Grid2StatusMana.
Is there an update on the progress of this? I use Grid2 as my party frames as well, and when tanking I need to know when to stop and let the healer mana up.
There is a ton of other stuff to do so this has not been converted yet. If you need to see mana just set up a regular mana warning for say 75% or something.
There is a ton of other stuff to do so this has not been converted yet. If you need to see mana just set up a regular mana warning for say 75% or something.
Forgive my noobness, but I wasn't even away GRID2 could do something like that! That actually suits my needs perfectly.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
We expect the restos to be aware of their group and use it as soon as everyone is below 75% with the assumption a 2nd Tide will become available as they are the only ones in control of said Mana Tide.
Using it yourself at 75% when everybody else is at 90% would get you sat and a good talking to form my GL probably...they are fairly big on raid/party buffs being used properly (ie maximizing their results).
Grid mana bars pretty much are required for this then, or I have to have Pitbull group frames up (which I do not care to fill the screen up with in a 25)
I suspect you will find a larger group of people using Grid Mana bars than the few who write on this forum as the comparison to grid vs gridmanabars downloads on Curse is 30k vs 100k...30% of us. Once/if Grid2 takes over for Grid they will be just like the Auctioneer folks were when they scrapped big pieces of their app...coming out of the woodwork
Considering that I've successfully led my guild through completing all of the 10-man achievements pre-Ulduar, have solo healed 3-drake Sartharion and most of Naxxramas, and am currently leading our 10-man Ulduar achievement group, I'd have to disagree with your implication that I'm playing my class wrong.
Let's say you have a fight that lasts 7 minutes. I can either (a) wait until everyone is below 76% mana, and then not have time to use a second Mana Tide, or (b) use one Mana Tide at 1 minute in, regardless of whether everyone will gain the full amount, and then be able to drop a second one at 6 minutes in, when everyone will certainly gain the full amount. Even if everyone in the party is only at 90% when I drop the first one, if the timing means I'll be able to drop a second one, how is everyone getting 42% of one Mana Tide and 100% of a second Mana Tide not better than the party only getting 100% of one Mana Tide?
-
View User Profile
-
View Posts
-
Send Message
Project AuthorNeither is better or worse (performance wise) as long as we don't have a scientific experiments that shows that one is without a doubt faster than the other.
For Grid's geometric arrangement vs stuff like a vertical row of frames: We do have a scientific theory that show that the first is much faster than the second: Fitts's law. M_t=a+b log(1+D/W) where M_t is mean time, a, b are constants depending on the person, D is distance and W is width of the target in a motor motion task in the plane. This theory is broadly verified and at the core of much of the input interaction side of HCI today.
So if someone tells me I should want if I want a fast solution grid I agree to that because the rectangular arrangement means smaller average distance between two raid members.
For mana bars being distracting, I know of no tangible scientific theory showing that this is true. I know quite a few phenomena and experiment that relate but none to the best of my knowledge clearly confirms or denies the stated hypothesis that they are bad. Phenomena and experiments that are possibly relevant relate to: the pop-out effect [1,2,3], selective inattentional blindness [4] ,studies of forced attention switching and performance interference [5,6]
It is my understanding that we are (a) pretty good at keeping attention (b) in fact often tangibly don't even cognitively "see" distractors (c) are hard to distract even by significantly odd distractors (d) visual and other cross-sensory effect can degrade relative performance in some cases.
But I'm just a casual reader of that kind of stuff, so someone who had full working knowledge of the field could likely say much more than this.
That said for me the whole discussion comes down to taste until someone actually sits down a large pool of people and tests and shows a broad significant effect for or against mana bars.
Even if there was a study that resolved this one way or the other, I don't actually think that people who do not want a grid-layout are "wrong". People have to pick solutions to their preference and comfort level. Ultimately what matters is not what is fastest, but if anybody died in raid. If people achieve that with their respective solution and are happy with their solution, I consider it a good solution.
References:
[1] Ware, C. (2004) Information Visualization: Perception for Design. (2nd Edition) Morgan Kaufman. (Great reference with focus on applicability to interface design)
[2] Wolfe, J M (1998 ). Visual Search. In H. Pashler (Ed.), Attention, East Sussex, UK: Psychology Press.
[3] Theeuwes, J. (1992). Perceptual selectivity for color and form. Perception & Psychophysics, 51, 599-606.
[4] Simons & Chabris (1999). Gorillas in our midst: sustained inattentional blindness for dynamic events. Perception, 28, 1059-1074.
[5] Styles, E. A. (1997) The Psychology of Attention, Psychology Press.
[6] Stuart, G. W. , McAnally, K. I. Meehan, J. W. (2003) The overlay interference task and object-selective visual attention. Vision Research, 43:13, 1443-1453.
how about this? %text indicator below a threshold. ie: at 30% it appears and reads "30%" (or whatever actual percentage) and then disappears once over 30%. Configurable threshold of course.
Best of both worlds, info only when required and fully granular when it is required.
Your grid starts to light up with text you know the raid is very low mana, obviously you would select a relatively tiny font size, 6 or 7 or something.
Currently using stufraid whilst I await the second coming of Grid :P.
ie: you could show the bar as full width at 30% (yes you would need to do math on the fly) or others may set it up to be full width at 100% (ie: what is normal currently).
The current health bar code needs some messing with as the heals bar is not always functional. Due to the color inversion etc. and its implications it is also not the correct basis for a Bar Status imo. I am rather tempted to just directly implement it instead of hacking around with 1-3 of the Blizzard status bars.
If that is done it may be possible to extract some common code for both the health / healing displays and the bar displays discussed here.
Mana Bars are unlikely to ever be included in the core due to the severe performance penalties. They are quite fine as a separate plugin for whoever wants to use them.
As for a Bar status, I have a vague idea that it may be a good alternative way to show lifebloom / rejuv / regrowth timers, especially if they are based on the max time of regrowth so they can be directly compared. There could possibly even be notches for their particular GCD.
Which reminds me. Is the gcd based timing in Grid popular? Does it need porting to Grid2? Is it even useful in the face of different cooldown times for different spells? (well for druids at any rate).
One more thing, the current mana status has a single threshold. I think there was discussion somewhere to allow multiple versions / multiple thresholds for it which would be a nice way to get somewhat more detail without getting the full mana bars penalty. Overhead vs the current one is 1 extra if / threshold in the detection / color / text code.
I can see the need for two types of bar indicators, or an indicator with two behaviors:
1) Countdown bar. This could be used for instance to show druid hot timers. Ideally for me it would be real time and not %. So you could set max to the 27 seconds of a regrowth and then everything else is relative to that: rejuv at 18 and 9 for lifebloom. Relative length would give you relative time.
2) Percent Bar. This is just like the current bar and would handle any % status.
Both cases there needs to be an orientation, location and width + length for the bar(s).
In the case of the Countdown bar there is also a value which is its "100%", so 27 in the druid case.
I think the change needed is to rename lowmana to mana-low. It has its color built in which is fine as its simply a low mana indicator. You would not want a low focus or low rage indicator. Also, low mana is low mana. It is better to hook up this single status than to split out its color.
Your ManaColor needs to be power and power-color if it is going to handle non-mana types.
At that point it can maybe replace some of the low mana stuff.
If it is not burdensome the power code can replace some of what is in the core ... ?
Having inherent bar-like indicator types would rock, basically what I was hoping for when we first had this discussion.
The status side is easier. Really I didn't do other power types because it was proof of concept not because it's hard to do. My remarks mostly have to do with code footprint and efficiency. I had to duplicate code to get the mana bars working, and some of that duplication is in fact also inefficient (i.e. power color or power value are read out more than once) only because the core support of mana wasn't set up for continuous readout yet. If the core mana (and other power types) expose continuous values of power types, all this goes away.
If there are indeed core-supported indicators and a more suitable mana/power status, it will be easy to write a clean Grid2ManaBars, so I would just rewrite the whole thing from scratch. The current (old) code is kind of messy, given that Grid2 wasn't really supporting this kind of stuff.
I'm kind of busy right now, but maybe I can find time to write a pseudo-new-Grid2ManaBars on the assumption that indicators and status are as they should be. The whole thing would reduce to very simple code in that case.
In order to help discussion I started an experimental project for it here:
http://www.wowace.com/addons/grid2manabars/repositories/mainline/
A few things this doesn't do at all right now:
*) Handle non-horizontal orientation
*) Only works with side-bottom
*) Does not offer any power type except for mana
Design issue:
*) Overlays rather than rearrange the health bar.
Likely good steps to take:
*) Make a real percentage-bar indicator rather than hijacking the standard bar indicator one. Alternative solution is to give the bar indicator some basic layouting feature.
*) Move ManaColor into StatusMana, or have a PowerColor instead.
*) Options: Adjust height of bar.
EDIT: Made the rest of this into a separate post since it's unrelated to getting it working.
In fact if anything I agree with what Elsia is thinking here. Why not allow more options as far as a bar type indicator? Say for example, somebody wants a bar to show up in grid for perhaps a short duration buff. Something along the lines of having a bar appear when I cast lifebloom, the bar starts at 100% going down to 0% indicating the time remaining on the buff. You could then allow these bars to change colors or even blink based on other factors (e.g. how many stacks of lifebloom changes the color of the bar.) Other options could include inverting that (e.g. buff starts with bar at 0%, moving up to 100% when the effect ends) changing where the bar starts from (e.g. 0% starts at the top, 100% ends at the bottom, or vice versa) as well as the location (along the top, along the side, etc.)
This probably isn't something I would do in my own setup, but it might be something that somebody would find useful somewhere. If you could just add it in there without the need to go learn how to code lua (or find somebody who can) it would be pretty neat.
This could also have the result of streamlining how the default frame is configured. For example now you'd have a framework setup where the person could configure their health bars to e.g. blink when they are low, change color when they are low, etc, all without needing one indicator for bar-health and another indicator for bar-health-color for example.
On it not working: You want bar-mana-color to manacolor. For now it only works if set to bottom side but it should work for that case. It does not work for anything but mana yet. It really is pre-alpha.
In that case I think what would be ideal is if grid core could include an ability to configure bar indicators for whatever status you want, much as I described above.
Then separately from core, as a module we could have Grid2StatusMana which we could set our bar indicator to follow. Also if somebody desires it, we could also have modules for (though to be honest I think their use would be limited to arena) Grid2StatusEnergy, Grid2StatusRage, and Grid2StatusRunicPower. And you could, at your option configure all of these to show up on the same bar indicator, and this would result in the same functionality as the existing GridManaBars.
This would allow us to have an elegant system for easy to configure (by the user, within the UI) bars in the grid2 core, but while at the same time keeping the performance issues addressed in that, nobody would have any potential for such performance issues unless they installed Grid2StatusMana.
Forgive my noobness, but I wasn't even away GRID2 could do something like that! That actually suits my needs perfectly.