Phanx is in-charge, and usually quite reasonable in my experience.
Please play nicely, everyone.
P.S. Don't forget about branches in svn.
- Curse Premium
Member for 13 years, 7 months, and 6 days
Last active Thu, Apr, 19 2018 19:38:07
- 0 Followers
- 957 Total Posts
- 0 Thanks
May 12, 2009CC licenses really aren't meant for code.Posted in: General Chat
Apr 26, 2009Posted in: Grid & Grid2Quote from RenewIs there an option to hide players who are in a vehicle instead of treating them like pets and showing on the pet section of Grid?
No. In fact I don't think that it's actually possible with the secure raid pet headers. Let me know if you find a combination of header attributes that works.
Apr 15, 2009It's not possible due to how the frame is made.Posted in: AddOn HELP!
In order to have the missing health show up colored, the background has the color and an 80% transparent statusbar covers up the remaining health. The incoming heals bar is implmented as another semi-transparent statusbar and when it is active, the transparency of the health bar is changed so you don't notice that there's two semi-transparent statusbars ontop of each other.
Mar 14, 2009Oooh, I wish I had more time to write up a proper response but I'm heading out of town for the weekend.Posted in: Grid & Grid2
Azethoth, let me know if I'm understanding you correctly. Doing that 'homework' helped me figure out where you're coming from.
Phanx, I think I already understand your point of view so you get a short summary.
Azethoth wants the default indicators to have task-oriented names so that status modules can provide task-oriented default settings. This would also allow users to change the location and type of a default indicator while still picking up defaults from other modules. Renaming or deleting a default indicator would prevent those defaults from affecting it.
Phanx is concerned that task-oriented names for the default indicators will be non-intuitive and actually conflict with how she has Grid currently setup.
I'm intrigued by the task-oriented defaults but also concerned that having a one-to-one mapping between tasks and indicators (by default) is going to be awkward.
Consider the case of the 'center icon' in Grid. By default it has generic debuff types and ready check statuses assigned to it. If you call it 'debuff types' then ready check doesn't really fit. What about having status categories for each task 'generic debuff', 'specific debuff', 'my hots', 'other hots', 'aggro', 'health' (including dead/ghost), etc. and only let users assign those categories to indicators in the simple config mode. The advanced config would let people assign individual statuses.
Mar 13, 2009This argument needs more user stories.Posted in: Grid & Grid2
Walk us through things a user might want to do with the indicator configuration. Try to be as specific as possible. Abstract user stories aren't very useful.
Then think about the one most important thing that defines an indicator. What makes the square in the top-left corner different from the icon in the bottom-right corner?
Then go back and re-visit the user stories and make sure that what you picked works well with the users expectations.
Also, Phanx is usually right.
Don't read what's between the parenthesis until after you've thought about it. (Personally, I think indicators should be named by type and location/anchor because that's what people see. There is a square in the top left corner, an icon in the center, another square in the top right corner, etc.)
Mar 13, 2009Here's a suggestion from the peanut gallery.Posted in: Grid & Grid2
When proposing default settings, rank them in order of importance. Once everyone agrees that there's nothing missing from the list and mostly agree on the order, then you can argue where to draw the line (or multiple lines).
I personally feel that Grid shouldn't be showing your self buffs, or any buff that lasts for more than 10 minutes. There's plenty of addons that are very good at tracking buffs, let them be good at that. Let Grid be good at letting you know who needs your attention in-combat first.
Feb 24, 2009Posted in: Grid & Grid2Quote from tsadokThis checks whether the color table is the same table reference as the cached one and not whether the actual colors are the same.
Would this be considered an issue at your end, or is dynamic color changing not common enough to be worth worrying about? I'm formulating a solution at my end which involves my first use of weak tables, which is sort of exciting :)
It's intended. You should have one table per color rather than one table per unit. If you're changing color based on range you have what... 4-5 different colors?
Feb 17, 2009I'd love to see more work done on Grid2. I started working on Grid again because the UnitGUID changes needed to be done and Grid2 wasn't ready for prime-time yet.Posted in: Grid & Grid2
I'm in the same situation as Jerry though. I haven't been playing much lately.
- To post a comment, please login or register a new account.