...As this information has absolutely no bearing on actual gameplay, I don't think it belongs on unitframes at all. If you can't remember who is the master looter, it's fairly straightforward to open the raid panel and check. Grid frames should contain only the information you need to make gameplay decisions, such as who to heal, or who to dispel poison from, or who needs a Blessing of Protection.
...
Personally I use grid as my only unit frame with PitBull adding self, target focus & their targets + pet & its target for hunter. I never ever show party frames.
So yes, grid does need to be able to display a lot more stuff than it does out of the box. I am however happy with the "frilly" stuff being plug ins.
I _can_ open the raid frames to look up some stuff, I can NOT open them up for a party though. So your example is wrong for 5 man.
Toadkiller, the core will be very flexible. A module that e.g. adds 0..n additional icons will probably be written in only a few lines of code. But nevertheless the core will have a predefined set of options. Grid1 became unconfigurable because about 100 people asked for one highly important function each. Which is why we have tons of options. You'll have to look for such functionality in optional modules in the future.
Please keep in mind that an addon is what the authors want it to be. It doesn't matter if ten, hundred or thousand raiders don't like the inverse health bar. If the authors think that an inverse health bar is a feature and not a bug, this is how it's going to be in the core. And if the addon authors think that one icon is sufficient, you'll only find one icon in the core too. It's basically a 80/20 rule (look up pareto law of power distribution if you're interested).
PS: your buff-icon example doesn't convince me: I don't care about missing buffs when I'm in combat, I have the center icon for raid debuffs, and the border for non-raidboss-debuffs that I can cure. Plus, you could put everything into the center icon with different priorities: boss debuff > trivial debuff > missing buff.
With regards to the number of indicator's, I'd like to point out that there's a difference between the capability of the base addon showing 0..n indicators and the default configuration showing 4.
The base addon can support 9 indicators but the default configuration can only show 4 like the authors want, thus allowing users to use the default and then choose to increase as their needs change.
And it would remove the need for Yet Another Grid Plugin.
...If the authors think that an inverse health bar is a feature...
PS: your buff-icon example doesn't convince me: I don't care about missing buffs when I'm in combat, I have the center icon for raid debuffs, and the border for non-raidboss-debuffs that I can cure. Plus, you could put everything into the center icon with different priorities: boss debuff > trivial debuff > missing buff.
All right, I will volunteer to add easy non inverse health bar conversion to the config.
As for the icon example, yes you are right you can do as you say and avoid using an icon to begin with by putting your curables on the border and with some kind of priority for curse vs poison or whatever it is. But then what about unstable affliction? What about debuffs that reduce your armor but increase your AP? Not all debuffs want removal. What about simultaneous debuffs? All I know is I can cure something, I can make no intelligent choice about it. In fact, at that point Grid dictates the cure order by which one it displays on top.
I do not think I mentioned missing buffs. By the way, you most certainly will care about missing buffs in Mount Hyjal. Trash waves do not care if you prefer to rebuff resurrected people only out of combat. I also like to see if a resurrected tank needs buffing. I most certainly do take the mana penalty to rebuff them in combat. This means I do not shove missing buffs in with debuffs. My missing buffs have their own indicator and it has priority mark/gift > Omen > Thorns.
So for me I prefer accuracy in my work. This conflicts with your example which has reduced the information provided to the point where there is some loss of information. What you want is not wrong, but neither is what I want. No, I cannot go over to Jerry's house and make him do things this way. I can just plead for a slight reduction in the plugins necessary. Or at least enough options in the core so that a non-shaman could load it up and say "yeah! this does the trick" instead of "oh, well lemme get at least 2 more plugins". If it happens it happens, if it doesn't I have to download them. It's not a big deal either way except that a lot of people will need to load plugins yet again.
I also hereby volunteer to convert GridStatusMissingBuffs -> Grid2CombinedBuffs or whatever the naming convention will be. Hopefully the "missing" part is already in the core (invert the display condition).
I absolutely have no idea how you can judge my gameplay or which damm reasons give you the right to tell me what i need or what i don't for my gameplay. I am fine if you say 'i don't need that' - But your conclusion 'i don't need that therefore you don't need that' just fails out of logical reasons as we do have different assumptions to start with.
I absolutely have no idea why you think I am judging your gameplay or have any damn reasons giving me the right to tell you what you need or don't need for your gameplay. My conclusion absolutely was not "I don't need X, so you don't need X either". If you'd pull your head out of your ass, drop the self-righteous attitude, and read my post without getting emotional, maybe you'd notice the parts where I said that I have absolutely no objection to the plugin architecture, and think it's great that anything can be added for anyone via plugins. If you want to get all up in arms because someone on an Internet forum doesn't think that knowing who's the Master Looter in an online game is critical to success in and enjoyment of the game, I suggest you take your hands off the mouse and keyboard, push your chair back, stand up, and go outside.
To make it easier to start out with grid i think a click2cast engine should be shipped with the package also with usable defaults (e.g. healing / decurse spells setup). This does extend beyond the scope of Grid, but for me Grid's power lies in the combination of the Unitframe in conjunction with a click2cast Addon. Since both of them are seperate packages, the advanced user can later decide if he wants to switch Grid for AG_Unitframes / Pitbull / ... or the Click2cast engine for another. But he does not need to search and install 2-3 packages (or 10) and configure the thing for 1 hr before he can start.
And how would this be anything but incredibly wasteful bloat for those who prefer to use a standalone click-casting addon that works with Grid and other unit frames? The view that using one addon that does 50 things is better than using 50 addons that each do one thing is flawed, and leads to conglomerations of horrors like CT_RaidAssist or RDX. There is nothing wrong with using one addon for unit frames, and another addon for click casting. It doesn't take any more time to set up two addons that each do one thing than it does to set up one addon that does two things. Your main complaint seems to be about the lack of class- and role-specific defaults in click-casting addons; I submit that that is not a Grid-related issue, but something you should suggest to the authors of click-casting addons.
Quote from Toadkiller »
Every single one has asked for it to be fixed to be like a regular unit frame. About a third refuse to even use Grid unless it can be made to have standard colored & behaving bars. These are not rank noobs. These are people that use sRaidFrames, X-Perl, etc.
If a person feels that Grid needs to be "fixed" to be like a "regular" unit frame, and are already using a "regular" unit frame, and are just going to spend time trying to make Grid look and act just like that "regular" unit frame, I really have to ask -- why are they switching to Grid?
Quote from Toadkiller »
I _can_ open the raid frames to look up some stuff, I can NOT open them up for a party though. So your example is wrong for 5 man.
See, that's the kind of reasoned argument I wish people used more often. As I don't use Grid for my 5-man parties, I didn't consider that aspect of leader/looter statuses. Now that you mention it, that makes sense, and I can see where awareness of such statuses do indeed belong in the core.
Quote from Toadkiller »
But then what about unstable affliction? What about debuffs that reduce your armor but increase your AP? Not all debuffs want removal.
Perhaps a "blacklist" feature is in order...
By the way, you most certainly will care about missing buffs in Mount Hyjal. Trash waves do not care if you prefer to rebuff resurrected people only out of combat.
While I can see your point for Mount Hyjal, there isn't really any other situation in the game where the entire raid can be stuck in combat for so long that people need to be resurrected and rebuffed during battle. Additionally, under Maia's system of a prioritized center icon, the majority of the time people don't have raid debuffs on them, so nothing would be overriding the missing buff display. Specifically, I'm fairly certain that there aren't any "raid debuffs" in Mount Hyjal trash waves.
I can just plead for a slight reduction in the plugins necessary. Or at least enough options in the core so that a non-shaman could load it up and say "yeah! this does the trick" instead of "oh, well lemme get at least 2 more plugins".
You know, the snide remarks about my class really aren't necessary. Believe it or not, there is more to playing a shaman well than endlessly spamming Chain Heal. Furthermore, I use exactly the same Grid configuration on my shaman, druid (75% feral, 25% tree), mage, shadow priest, and protection paladin. The only thing that differs between characters is which (curable) debuffs are shown on the center icon, and which (non-curable) debuffs are relegated to a corner indicator. As I mentioned in my wiki comments, I totally understand where a full-time healing druid would need more granular HoT management, and if I raided as a healing druid, I would definitely want an HoT plugin, but we'll just have to agree to disagree on the actual quantity and form of indicators that are necessary.
Anyway, I still don't see what's wrong with "needing" a few extra plugins. Unless it's is poorly coded, or deliberately interferes with a Grid core function, there's practically no overhead to running a plugin as compared to having the same feature included in the core.
Wow, a lot of discussion and different opinions expressed over the weekend !
I'll start this answer by talking about the way I use Grid right now. My main character is a resto druid. I am also raid leader. I use Grid, GridAlert and GridStatusRaidDebuff. Grid is configured mostly like the default, expect I use smaller square (26 pixels, I think), and I have activated the second text indicator so that I have the unit name visible most of the time. And yes, I use the normal Grid bar colors, vertical and inverted. Not only do I use them like that, but I think it's one of the most interesting feature that Grid has over other unit frames.
I do not think I need anything more than the default. I certainly don't think I need a way to show missing buffs, as there are much better alternatives (I use XRS, but there are others).
Grid is not, in my opinion, supposed to be a "standard" unit frame addon. It is expected that Grid do not show everything there is to know about a unit. I expect to see in Grid everything I need to see to be able to heal this unit effectively. Who is raid leader, who is master looter, it's not an information that will help me in my healing duty. Who gets Felrage'd certainly is.
This being said, I also agree that different people have different needs. I have just committed a patch so that corner and text indicators are created using a generator function, and that this generator function is publicly available. My issue with this is not the functionality itself, but how to make a configuration window that is easy to use and not overwhelming. For instance, I am still thinking about ways to show different status depending on different states (in combat / out of combat, or when a specific key is pressed). This also adds complexity to the configuration window. I would like the configuration window to be unable to allow an inexperienced user to completely break Grid.
Finally, I want to integrate a layout editor in the configuration. Once there is a layout editor, sharing layouts between user will be easy.
Ooh, good stuff Jerry. Does this mean an icon generator as well?!
You already mentioned restricting the statuses you can hook up to an indicator to the right types. I think it would be nice if a suggested indicator can be specified. Although that means there is config stuff associated with a plugin. Should plugins come in pairs? The plugin + pluginConfig?
A mechanism to list unassigned statuses would be very nice as well. Perhaps even broken down by plugin showing assigned stuff from the plugin and unassigned stuff? That way you can see the deadwood and dump it.
Ok, the modifier key / in out of combat stuff sounds interresting. I think what you mean by breaking is making choices that usually show nothing when they in fact should. I think having a simulator as part of the LayOut editor would help. Then you can click an incombat checkbox / hold down the modifier key(s) etc. and see what is going on. Maybe it is even smart enough to list its triggering effects (buffs debuffs etc) so the entire set of conditions can be simulated. This definitely implies paired plugins / pluginConfigs.
Another or additional approach is to spell out what a particular group of settings / hooked up statuses will accomplish for an indicator. Although 2^n or whatnot can be quite a long list.
Phanx, Maia:
Please do not misunderstand why I don't like the inverse color scheme. Different people have different brains. I could train mine to like it. I choose not to. I like the regular color scheme because my brain has learned to interpret it since I was 4 or 7 or whatever years old and saw my first bar graph. Maia's goal with the inverse scheme is laudable. I get what it is about. It is just not right for me and some other users. For me I like to fade out people that are out of range instead. This lets me heal all the bright people near me, or move so I am in range of assigned people. Like I said, I am happy to write config code to make it painless and thus a non-issue.
PS: Love Thy Shaman. Just don't mention Brain Heal after midnight or you will surely see some Shamanistic Rage.
Grid2-$Rev: 74477 $\modules\IndicatorText.lua:28: <unnamed>:SetPoint(): Unknown region point
Grid2-$Rev: 74477 $\modules\IndicatorText.lua:28: in function `Layout'
Grid2-$Rev: 74477 $\GridFrame.lua:116: in function `LayoutIndicators'
Grid2-$Rev: 74477 $\GridFrame.lua:44: in function <Interface\AddOns\Grid2\GridFrame.lua:42>
<in C code>: in function `Show'
Interface\FrameXML\SecureTemplates.lua:801: in function <Interface\FrameXML\SecureTemplates.lua:715>:
Interface\FrameXML\SecureTemplates.lua:1008: in function <Interface\FrameXML\SecureTemplates.lua:889>:
<in C code>: in function `SecureGroupHeader_Update'
<string>:"*:OnShow":1: in function <[string "*:OnShow"]:1>
<in C code>: in function `Show'
Grid2-$Rev: 74477 $\GridLayout.lua:420: in function `LoadLayout'
Grid2-$Rev: 74477 $\GridLayout.lua:347: in function `ReloadLayout'
Grid2-$Rev: 74477 $\GridLayout.lua:218: in function `?'
...:
<string>:"safecall Dispatcher[2]":13: in function `?'
CallbackHandler-1.0\CallbackHandler-1.0.lua:91: in function `SendMessage'
Grid2-$Rev: 74477 $\GridCore.lua:323: in function <Interface\AddOns\Grid2\GridCore.lua:306>
(tail call): ?:
CallbackHandler-1.0\CallbackHandler-1.0.lua:146: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:146>
<string>:"safecall Dispatcher[1]":4: in function <[string "safecall Dispatcher[1]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[1]":13: in function `?'
CallbackHandler-1.0\CallbackHandler-1.0.lua:91: in function `Fire'
AceEvent-3.0\AceEvent-3.0.lua:70: in function <Interface\AddOns\Ace3\AceEvent-3.0\AceEvent-3.0.lua:69>
---
Grid is just a square with no name/txt in it, and if i pick a texture (which seems to be working \o/) i just get a bar in class color across the square
As Jerry stated, the biggest problem Grid has is to find a decent way of configuring it. And while many, many people have feature suggestions, hardly anyone has come up with suggestions on how a configuration UI could be structured. A simple example: it's easy to name 4 corner icons. But what if you'd have a slider that lets you enable 0..12 corner icons, how would you name them, and how would a user know where corner icon #7 will appear?
Quote from Phanx »
Perhaps a "blacklist" feature is in order...
Actually Grid has a feature that's not obvious, which is why I think it's necessary to think about a way to improve it in Grid2: you can disable certain debuffs by adding them to the debuff list, and then simply not assigning them to any indicator. I e.g. do that for Frostbolt and other trivial pvp related debuffs, as when PvPing I only want to dispel those nasty warlock debuffs :)
Quote from Toadkiller »
For me I like to fade out people that are out of range instead. This lets me heal all the bright people near me, or move so I am in range of assigned people.
Toadkiller, I do fade out players out of range too. And the main reason why I came up with the inverted health bar colored by class is that this allows you to always know which unit class someone belongs to. If I see a bright light blue area, I know I need to shield/PoM/flash heal, and if it's brown/orange/pink, I'll Greater Heal instead. Plus, when units don't need any (healing) attention, they don't scream at me - they only do if they are taking damage.
PS: I could imagine having an optional module named Grid2AdditionalCoreOptions which adds some config options (well, it rather keeps them in a seperate pane). Examples are: disabling the inverting of the health bar, making unit frames non-squared but changing width and height separately,... basically like TweakUI or whatever the program was called for Windows 98/2000/XP (unsure about Vista, I've converted to OSX many years ago). This way we can keep the core options clean and close to the intentions of the authors, and people who have the urgent need to change a specific setting can still do so.
With regards to the corner indicators, I was thinking that 8 corners should be sufficient: top-left/center/right, middle-left/right, bottom-left/center/right. Although I could see a case for having a middle-center indicator as well. These would appear as a list of checkboxes to allow the user to enable/disable specific corners. This could also be extended to include a count next to each corner which sets the number of indicators to be created for that corner. Corner indicators should always be referred to by their location, e.g. top-left. In the case of multiple indicators in a corner, they would be named numerically in order from the one closest to the corner, e.g. top-left-2.
Now that I think about it, one could apply this to the icons too.
As Jerry stated, the biggest problem Grid has is to find a decent way of configuring it. ...suggestions on how a configuration UI could be structured. A simple example: it's easy to name 4 corner icons. But what if you'd have a slider that lets you enable 0..12 corner icons, how would you name them, and how would a user know where corner icon #7 will appear?
Yes that is why I am all over this thread. I want Grid2 to do a much better job. With the config lod, we can have a gui editor which makes a lot of things easier.
Square indicators:
We can enable the most extreme scenario which is 3 squares per corner plus the side ones or even 3 instead of just one for the sides. You get a list of the indicators and their names. These can just be what they are now, so the 4 corner ones, the 4 side ones, and then the extra 2 ones per corner with -2 and -3 tacked on as doxxx suggests. You click on the ones you want to enable from the list and they show up in a nice gui representation of a Grid square.
Text, icons:
Same deal for text & icons. You present a list of "sensible" locations they can be at and the user picks what they want.
Scale is a slider. Height & width can be adjusted by directly dragging the sides of the square etc.
I like the simulator idea so you can just test your settings right there. A lot of the time spent in Grid is cycling through combat to see if your stuff worked. For instance it took me 3 weeks to get Raid Debuff going for Archimonde because a) I forgot to hook it up at first, b) It turns out the fire debuff was too spammy and obscured Grip of the legion leading to a wipe because it wasnt cured fast enough. Finally the 3rd time it was usable.
Quote from maia »
I could imagine having an optional module named Grid2AdditionalCoreOptions which adds some config options ...
That works for me. I was also thinking maybe stuff like Grid2OptionsDruidToad, or Grid2OptionsDruidPhanx. These could automagically adjust your settings (and require the additional plugins needed) or provide some kind of one button click for a fast setup. Perhaps there is a base Grid2OptionsDruid that does basic setup for Druids using only the core as is. This allows Grid2 to provide best-practice without requiring new users to first get a phd in Grid.
I was actually thinking about that earlier, after reading the post where someone suggested a package distribution with bundled plugins. While I still feel quite strongly that there should never be any package, due to...
- the enormous variety of available plugins and personal preferences,
- the fact that the SVN does not support "packaging", and even the core and the options are separate addons that must be downloaded separately,
- the fact that compliations quickly become outdated as their creators fail to update included addons,
- the fact that even if a compliation is updated, it's a huge waste of bandwidth to download 20 addons every time 1 changes, and
- the fact that not all addon/plugin authors want their works included in compliations
... I do like your suggestion about plugins that do nothing but modify the configuration of Grid and other plugins. However, I think that a better solution (for new users, at least) would be class-aware defaults. In Grid(1) all four debuff types are shown on the same indicator by default; this is totally useless for all classes, as no matter what you can or can't dispel, undispellable garbage is frequently going to show up and hide things you could dispel and/or waste your time deciphering the debuff type. Grid2 could avoid this and similar problems by defaulting to the Class profile instead of the Default profile, and having specific default settings for each class.
What I'd really like to see, though, would be a departure from the current Ace profile system. Rather than A, B, and C being complete, self-contained setups with no relation to each other, it would be wonderful to have a master/diff system where A contained the bulk of my settings, and B and C contained only small changes, such as which debuff types to show on the center icon, and which to show on the bottom left corner.
Ok I must say that my favourite hot indicators are the candybar style ones that shrink down to nothing. Since we have mana bars already, could that become a general indicator type bindable to countdown statuses? There are some layout and sizing issues I suppose unless they are added to an edge as well.
Quote from Phanx »
What I'd really like to see, though, would be ... a master/diff system where A contained the bulk of my settings, and B and C contained only small changes...
Oh sweet music to my ears. I am doing a version of this in AutoBar already. Various chunks of settings can generally belong to Account (global), Class or User (not shared at all). Simple dropdowns allow selection for each separate chunk. Modifying that chunk applies to changes to its current setting.
A diffing system sounds interresting but I am not sure how it would work UI wise? But at any rate: Down with the evils of the Ace profile system!
Quote from Phanx »
...I think that a better solution (for new users, at least) would be class-aware defaults.
Makes sense. So basically what I called Grid2OptionsDruid etc is just plain a part of Grid2Options. And really there is no point for it being separate. Combined with the above the class stuff would just end up in one of your minor diffing profiles. For a raid leader that does want to see everything, they can then have multiple icons and enable and link all dispell types.
A small feature request: could you separate spacing into vertical and horizontal? The reason for this being that it's possible to place icons outside the unit frame with a plugin. For example if I place 1 icon on the right side, I would need horizontal spacing > 0 and vertical spacing == 0, or similar.
While I like the indicators and the whole Grid functionality as it is, I sometimes want a little bit more, for example more that 1 icon for each unit. Only way I found to do this without cluttering the frame itself is to place those on the outside, between units. Right now I hardcoded into Grid 0 vertical spacing, but would be nice to have it as an option in the core addon.
Grid2Options\core.lua:34: attempt to index local 'element' (a nil value)
Grid2Options\GridIndicators.lua:103: in function `AddIconIndicatorOptions'
Grid2Options\GridIndicators.lua:163: in main chunk
<in C code>: in function `LoadAddOn'
Grid2-$Rev: 74477 $\GridCore.lua:132: in function `?'
AceConsole-3.0\AceConsole-3.0.lua:59: in function `value'
Interface\FrameXML\ChatFrame.lua:3040: in function `ChatEdit_ParseText':
Interface\FrameXML\ChatFrame.lua:2732: in function `ChatEdit_SendText':
Interface\FrameXML\ChatFrame.lua:2753: in function `ChatEdit_OnEnterPressed':
<string>:"*:OnEnterPressed":1: in function <[string "*:OnEnterPressed"]:1>
---
Getting that doing /Grid2.
And in Options under indicator there's only options for (Bar, text-up, text-down)
One point to be mentioned in regard to debuffs such as Unstable Affliction and why a blacklist mechanism would not necessarily work. The Priest's Dispel Magic will dispel *two* effects on a single cast. If, for example, someone gets both SW:P and UA and only SW:P was showing, it would be a *bad* thing.
Making it so that I'm not aware of UA in order to prevent me dispelling it makes it dangerous to dispel any time that UA might be floating about on someone. It also prevents me from throwing a HoT on the individual to at least counter the effects of UA's DoT mechanic. Likewise, giving UA high visible priority could prevent me from seeing other debuffs such as a disease, and could be equally disastrous (not for me, but for the affected person).
That said, I'll concede that UA awareness is somewhat a unique scenario (at least in my admittedly limited raid experience) and would perhaps be a good candidate for a plugin to handle special logic/indicators for it. Nevertheless, I do see a legitimate reason why someone might want to be able to see more than one icon out of the core settings.
While I'm on the subject of potential configuration enhancements, I'll mention just two other things.
Concerning indicator placements, make the number of placements configurable as a square of a given configuration number. The default would be 3, which would produce 9 placements. A value of 4 would produce 16 placements, and so on. Indicators could then be assigned to a placement index. I would leave the rest of the implementation details to the developers as a thought exercise.
Concerning the blinking state, it would be my humble opinion that the state be removed and that a blinking interval be used in stead as an attribute to the active state. A value of 0 would mean no blinking (and the default if not specified). Otherwise, the interval would specify how slow/fast an indicator could blink. Ideally, this would be modifiable programmatically as well (i.e. blink faster as a cooldown/duration nears its end) Again, the specific implementation details would be left to the developers as a thought exercise.
Debuff blacklisting on Unstable Affliction is fine as long as you can assign the debuff UA to another indicator. That way you'll be able to tell when someone has that on them and don't risk dispelling it.
Also the worst thing about setting up the layout on the first grid was that the options ui was not intuitive at all. Things were labeled and grouped poorly. Just cleaning up the organization of that mess would help walking new users through setup. Being able to export a layout though may be the best idea ever.
A "config" mode would also be extremely useful for new users as they can play around with settings and see how they work on the fly, instead of having to setup some specific status for an indicator and wait until it occurs "live".
Looking forward to this I must say.
For the record, it is extremely unlikely (read: It will not happen) that I write a "config" mode for Unit Frame setup and Grid Layout. Others may try, though. I suspect it's gonna be painful.
I will try, if nobody beats me to it, to write a new configuration UI for Grid, based on ideas that has been expressed here and others, but it will most certainly not end up as a 'config' mode.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Personally I use grid as my only unit frame with PitBull adding self, target focus & their targets + pet & its target for hunter. I never ever show party frames.
So yes, grid does need to be able to display a lot more stuff than it does out of the box. I am however happy with the "frilly" stuff being plug ins.
I _can_ open the raid frames to look up some stuff, I can NOT open them up for a party though. So your example is wrong for 5 man.
Please keep in mind that an addon is what the authors want it to be. It doesn't matter if ten, hundred or thousand raiders don't like the inverse health bar. If the authors think that an inverse health bar is a feature and not a bug, this is how it's going to be in the core. And if the addon authors think that one icon is sufficient, you'll only find one icon in the core too. It's basically a 80/20 rule (look up pareto law of power distribution if you're interested).
PS: your buff-icon example doesn't convince me: I don't care about missing buffs when I'm in combat, I have the center icon for raid debuffs, and the border for non-raidboss-debuffs that I can cure. Plus, you could put everything into the center icon with different priorities: boss debuff > trivial debuff > missing buff.
The base addon can support 9 indicators but the default configuration can only show 4 like the authors want, thus allowing users to use the default and then choose to increase as their needs change.
And it would remove the need for Yet Another Grid Plugin.
Did look in SV grid2.lua but not quite sure which one to change.
Any help appreciated :)
I for one is quite happy with the way Grid2 is coming along, doing a great job.
All right, I will volunteer to add easy non inverse health bar conversion to the config.
As for the icon example, yes you are right you can do as you say and avoid using an icon to begin with by putting your curables on the border and with some kind of priority for curse vs poison or whatever it is. But then what about unstable affliction? What about debuffs that reduce your armor but increase your AP? Not all debuffs want removal. What about simultaneous debuffs? All I know is I can cure something, I can make no intelligent choice about it. In fact, at that point Grid dictates the cure order by which one it displays on top.
I do not think I mentioned missing buffs. By the way, you most certainly will care about missing buffs in Mount Hyjal. Trash waves do not care if you prefer to rebuff resurrected people only out of combat. I also like to see if a resurrected tank needs buffing. I most certainly do take the mana penalty to rebuff them in combat. This means I do not shove missing buffs in with debuffs. My missing buffs have their own indicator and it has priority mark/gift > Omen > Thorns.
So for me I prefer accuracy in my work. This conflicts with your example which has reduced the information provided to the point where there is some loss of information. What you want is not wrong, but neither is what I want. No, I cannot go over to Jerry's house and make him do things this way. I can just plead for a slight reduction in the plugins necessary. Or at least enough options in the core so that a non-shaman could load it up and say "yeah! this does the trick" instead of "oh, well lemme get at least 2 more plugins". If it happens it happens, if it doesn't I have to download them. It's not a big deal either way except that a lot of people will need to load plugins yet again.
I also hereby volunteer to convert GridStatusMissingBuffs -> Grid2CombinedBuffs or whatever the naming convention will be. Hopefully the "missing" part is already in the core (invert the display condition).
I absolutely have no idea why you think I am judging your gameplay or have any damn reasons giving me the right to tell you what you need or don't need for your gameplay. My conclusion absolutely was not "I don't need X, so you don't need X either". If you'd pull your head out of your ass, drop the self-righteous attitude, and read my post without getting emotional, maybe you'd notice the parts where I said that I have absolutely no objection to the plugin architecture, and think it's great that anything can be added for anyone via plugins. If you want to get all up in arms because someone on an Internet forum doesn't think that knowing who's the Master Looter in an online game is critical to success in and enjoyment of the game, I suggest you take your hands off the mouse and keyboard, push your chair back, stand up, and go outside.
And how would this be anything but incredibly wasteful bloat for those who prefer to use a standalone click-casting addon that works with Grid and other unit frames? The view that using one addon that does 50 things is better than using 50 addons that each do one thing is flawed, and leads to conglomerations of horrors like CT_RaidAssist or RDX. There is nothing wrong with using one addon for unit frames, and another addon for click casting. It doesn't take any more time to set up two addons that each do one thing than it does to set up one addon that does two things. Your main complaint seems to be about the lack of class- and role-specific defaults in click-casting addons; I submit that that is not a Grid-related issue, but something you should suggest to the authors of click-casting addons.
If a person feels that Grid needs to be "fixed" to be like a "regular" unit frame, and are already using a "regular" unit frame, and are just going to spend time trying to make Grid look and act just like that "regular" unit frame, I really have to ask -- why are they switching to Grid?
See, that's the kind of reasoned argument I wish people used more often. As I don't use Grid for my 5-man parties, I didn't consider that aspect of leader/looter statuses. Now that you mention it, that makes sense, and I can see where awareness of such statuses do indeed belong in the core.
Perhaps a "blacklist" feature is in order...
While I can see your point for Mount Hyjal, there isn't really any other situation in the game where the entire raid can be stuck in combat for so long that people need to be resurrected and rebuffed during battle. Additionally, under Maia's system of a prioritized center icon, the majority of the time people don't have raid debuffs on them, so nothing would be overriding the missing buff display. Specifically, I'm fairly certain that there aren't any "raid debuffs" in Mount Hyjal trash waves.
You know, the snide remarks about my class really aren't necessary. Believe it or not, there is more to playing a shaman well than endlessly spamming Chain Heal. Furthermore, I use exactly the same Grid configuration on my shaman, druid (75% feral, 25% tree), mage, shadow priest, and protection paladin. The only thing that differs between characters is which (curable) debuffs are shown on the center icon, and which (non-curable) debuffs are relegated to a corner indicator. As I mentioned in my wiki comments, I totally understand where a full-time healing druid would need more granular HoT management, and if I raided as a healing druid, I would definitely want an HoT plugin, but we'll just have to agree to disagree on the actual quantity and form of indicators that are necessary.
Anyway, I still don't see what's wrong with "needing" a few extra plugins. Unless it's is poorly coded, or deliberately interferes with a Grid core function, there's practically no overhead to running a plugin as compared to having the same feature included in the core.
I'll start this answer by talking about the way I use Grid right now. My main character is a resto druid. I am also raid leader. I use Grid, GridAlert and GridStatusRaidDebuff. Grid is configured mostly like the default, expect I use smaller square (26 pixels, I think), and I have activated the second text indicator so that I have the unit name visible most of the time. And yes, I use the normal Grid bar colors, vertical and inverted. Not only do I use them like that, but I think it's one of the most interesting feature that Grid has over other unit frames.
I do not think I need anything more than the default. I certainly don't think I need a way to show missing buffs, as there are much better alternatives (I use XRS, but there are others).
Grid is not, in my opinion, supposed to be a "standard" unit frame addon. It is expected that Grid do not show everything there is to know about a unit. I expect to see in Grid everything I need to see to be able to heal this unit effectively. Who is raid leader, who is master looter, it's not an information that will help me in my healing duty. Who gets Felrage'd certainly is.
This being said, I also agree that different people have different needs. I have just committed a patch so that corner and text indicators are created using a generator function, and that this generator function is publicly available. My issue with this is not the functionality itself, but how to make a configuration window that is easy to use and not overwhelming. For instance, I am still thinking about ways to show different status depending on different states (in combat / out of combat, or when a specific key is pressed). This also adds complexity to the configuration window. I would like the configuration window to be unable to allow an inexperienced user to completely break Grid.
Finally, I want to integrate a layout editor in the configuration. Once there is a layout editor, sharing layouts between user will be easy.
You already mentioned restricting the statuses you can hook up to an indicator to the right types. I think it would be nice if a suggested indicator can be specified. Although that means there is config stuff associated with a plugin. Should plugins come in pairs? The plugin + pluginConfig?
A mechanism to list unassigned statuses would be very nice as well. Perhaps even broken down by plugin showing assigned stuff from the plugin and unassigned stuff? That way you can see the deadwood and dump it.
Ok, the modifier key / in out of combat stuff sounds interresting. I think what you mean by breaking is making choices that usually show nothing when they in fact should. I think having a simulator as part of the LayOut editor would help. Then you can click an incombat checkbox / hold down the modifier key(s) etc. and see what is going on. Maybe it is even smart enough to list its triggering effects (buffs debuffs etc) so the entire set of conditions can be simulated. This definitely implies paired plugins / pluginConfigs.
Another or additional approach is to spell out what a particular group of settings / hooked up statuses will accomplish for an indicator. Although 2^n or whatnot can be quite a long list.
Phanx, Maia:
Please do not misunderstand why I don't like the inverse color scheme. Different people have different brains. I could train mine to like it. I choose not to. I like the regular color scheme because my brain has learned to interpret it since I was 4 or 7 or whatever years old and saw my first bar graph. Maia's goal with the inverse scheme is laudable. I get what it is about. It is just not right for me and some other users. For me I like to fade out people that are out of range instead. This lets me heal all the bright people near me, or move so I am in range of assigned people. Like I said, I am happy to write config code to make it painless and thus a non-issue.
PS: Love Thy Shaman. Just don't mention Brain Heal after midnight or you will surely see some Shamanistic Rage.
on startup when entering the game i get:
Grid is just a square with no name/txt in it, and if i pick a texture (which seems to be working \o/) i just get a bar in class color across the square
Actually Grid has a feature that's not obvious, which is why I think it's necessary to think about a way to improve it in Grid2: you can disable certain debuffs by adding them to the debuff list, and then simply not assigning them to any indicator. I e.g. do that for Frostbolt and other trivial pvp related debuffs, as when PvPing I only want to dispel those nasty warlock debuffs :)
Toadkiller, I do fade out players out of range too. And the main reason why I came up with the inverted health bar colored by class is that this allows you to always know which unit class someone belongs to. If I see a bright light blue area, I know I need to shield/PoM/flash heal, and if it's brown/orange/pink, I'll Greater Heal instead. Plus, when units don't need any (healing) attention, they don't scream at me - they only do if they are taking damage.
PS: I could imagine having an optional module named Grid2AdditionalCoreOptions which adds some config options (well, it rather keeps them in a seperate pane). Examples are: disabling the inverting of the health bar, making unit frames non-squared but changing width and height separately,... basically like TweakUI or whatever the program was called for Windows 98/2000/XP (unsure about Vista, I've converted to OSX many years ago). This way we can keep the core options clean and close to the intentions of the authors, and people who have the urgent need to change a specific setting can still do so.
Now that I think about it, one could apply this to the icons too.
Yes that is why I am all over this thread. I want Grid2 to do a much better job. With the config lod, we can have a gui editor which makes a lot of things easier.
Square indicators:
We can enable the most extreme scenario which is 3 squares per corner plus the side ones or even 3 instead of just one for the sides. You get a list of the indicators and their names. These can just be what they are now, so the 4 corner ones, the 4 side ones, and then the extra 2 ones per corner with -2 and -3 tacked on as doxxx suggests. You click on the ones you want to enable from the list and they show up in a nice gui representation of a Grid square.
Text, icons:
Same deal for text & icons. You present a list of "sensible" locations they can be at and the user picks what they want.
Scale is a slider. Height & width can be adjusted by directly dragging the sides of the square etc.
I like the simulator idea so you can just test your settings right there. A lot of the time spent in Grid is cycling through combat to see if your stuff worked. For instance it took me 3 weeks to get Raid Debuff going for Archimonde because a) I forgot to hook it up at first, b) It turns out the fire debuff was too spammy and obscured Grip of the legion leading to a wipe because it wasnt cured fast enough. Finally the 3rd time it was usable.
That works for me. I was also thinking maybe stuff like Grid2OptionsDruidToad, or Grid2OptionsDruidPhanx. These could automagically adjust your settings (and require the additional plugins needed) or provide some kind of one button click for a fast setup. Perhaps there is a base Grid2OptionsDruid that does basic setup for Druids using only the core as is. This allows Grid2 to provide best-practice without requiring new users to first get a phd in Grid.
- the enormous variety of available plugins and personal preferences,
- the fact that the SVN does not support "packaging", and even the core and the options are separate addons that must be downloaded separately,
- the fact that compliations quickly become outdated as their creators fail to update included addons,
- the fact that even if a compliation is updated, it's a huge waste of bandwidth to download 20 addons every time 1 changes, and
- the fact that not all addon/plugin authors want their works included in compliations
... I do like your suggestion about plugins that do nothing but modify the configuration of Grid and other plugins. However, I think that a better solution (for new users, at least) would be class-aware defaults. In Grid(1) all four debuff types are shown on the same indicator by default; this is totally useless for all classes, as no matter what you can or can't dispel, undispellable garbage is frequently going to show up and hide things you could dispel and/or waste your time deciphering the debuff type. Grid2 could avoid this and similar problems by defaulting to the Class profile instead of the Default profile, and having specific default settings for each class.
What I'd really like to see, though, would be a departure from the current Ace profile system. Rather than A, B, and C being complete, self-contained setups with no relation to each other, it would be wonderful to have a master/diff system where A contained the bulk of my settings, and B and C contained only small changes, such as which debuff types to show on the center icon, and which to show on the bottom left corner.
Ok I must say that my favourite hot indicators are the candybar style ones that shrink down to nothing. Since we have mana bars already, could that become a general indicator type bindable to countdown statuses? There are some layout and sizing issues I suppose unless they are added to an edge as well.
Oh sweet music to my ears. I am doing a version of this in AutoBar already. Various chunks of settings can generally belong to Account (global), Class or User (not shared at all). Simple dropdowns allow selection for each separate chunk. Modifying that chunk applies to changes to its current setting.
A diffing system sounds interresting but I am not sure how it would work UI wise? But at any rate: Down with the evils of the Ace profile system!
Makes sense. So basically what I called Grid2OptionsDruid etc is just plain a part of Grid2Options. And really there is no point for it being separate. Combined with the above the class stuff would just end up in one of your minor diffing profiles. For a raid leader that does want to see everything, they can then have multiple icons and enable and link all dispell types.
Grid2OptionsDruidToad will be written tho!
A small feature request: could you separate spacing into vertical and horizontal? The reason for this being that it's possible to place icons outside the unit frame with a plugin. For example if I place 1 icon on the right side, I would need horizontal spacing > 0 and vertical spacing == 0, or similar.
While I like the indicators and the whole Grid functionality as it is, I sometimes want a little bit more, for example more that 1 icon for each unit. Only way I found to do this without cluttering the frame itself is to place those on the outside, between units. Right now I hardcoded into Grid 0 vertical spacing, but would be nice to have it as an option in the core addon.
Thanks in advance!
Getting that doing /Grid2.
And in Options under indicator there's only options for (Bar, text-up, text-down)
Making it so that I'm not aware of UA in order to prevent me dispelling it makes it dangerous to dispel any time that UA might be floating about on someone. It also prevents me from throwing a HoT on the individual to at least counter the effects of UA's DoT mechanic. Likewise, giving UA high visible priority could prevent me from seeing other debuffs such as a disease, and could be equally disastrous (not for me, but for the affected person).
That said, I'll concede that UA awareness is somewhat a unique scenario (at least in my admittedly limited raid experience) and would perhaps be a good candidate for a plugin to handle special logic/indicators for it. Nevertheless, I do see a legitimate reason why someone might want to be able to see more than one icon out of the core settings.
While I'm on the subject of potential configuration enhancements, I'll mention just two other things.
Concerning indicator placements, make the number of placements configurable as a square of a given configuration number. The default would be 3, which would produce 9 placements. A value of 4 would produce 16 placements, and so on. Indicators could then be assigned to a placement index. I would leave the rest of the implementation details to the developers as a thought exercise.
Concerning the blinking state, it would be my humble opinion that the state be removed and that a blinking interval be used in stead as an attribute to the active state. A value of 0 would mean no blinking (and the default if not specified). Otherwise, the interval would specify how slow/fast an indicator could blink. Ideally, this would be modifiable programmatically as well (i.e. blink faster as a cooldown/duration nears its end) Again, the specific implementation details would be left to the developers as a thought exercise.
Also the worst thing about setting up the layout on the first grid was that the options ui was not intuitive at all. Things were labeled and grouped poorly. Just cleaning up the organization of that mess would help walking new users through setup. Being able to export a layout though may be the best idea ever.
Looking forward to this I must say.
I will try, if nobody beats me to it, to write a new configuration UI for Grid, based on ideas that has been expressed here and others, but it will most certainly not end up as a 'config' mode.