Scaling doesn't really apply here, because if you scaled mine down to the size of Luzienne's, they'd be useless because you wouldn't be able to read them.
I disagree. Scaling applies perfectly well here, healers that need to be able to click stuff can scale it up to your size if they want and be fine, while the rest of us can keep it nice and small. The only reason yours wouldn't fit smaller is because you used the full number of deficit; going with something like 2.3 for a 2300 deficit means you can easily make it readable at Luzienne's size.
Perhaps there whould be a separate thread (or perhaps a wiki page) for this, but I'd like to start talking about how Grid would be modularized and what the API will look like.
I see a few different classes/modules:
GridCore
-- (main addon): manages unit list and basic events (hp, mana, auras)
-- also watches for PLAYER_REGEN_ENABLED/PLAYER_REGEN_DISABLED to queue sorting/positioning if in-combat
--
-- roster events :UpdateRoster()
-- relay status message from GridStatus instance to appropriate GridFrame instance(s) :StatusGained(string unitid, string category, string status, number priority, string color, string text or "") :StatusLost(string unitid, string status)
-- unit attributes for use by GridStatus/GridSort plugins
string name = :GetUnitName(string unitid)
string class = :GetUnitClass(string unitid)
number subGroup = :GetUnitSubgroup(string unitid)
number hp, number hpMax = :GetUnitHealth(string unitid)
number mana, number manaMax = :GetUnitMana(string unitid)
table auras = :GetUnitAuras(string unitid)
boolean hasAura = :UnitHasAura(string unitid, string texture)
GridFrame
-- (class): defines an individual unit frame, tied to a unitid
-- is also responsible for determining how to display a status event
-- :SetUnit(string unitid)
string unitid = :GetUnit()
-- unit status events :StatusGained(string status, number priority, string color, string text or "") :StatusLost(string status)
-- frame size
number x = :GetHeight()
number y = :GetWidth()
GridLayout
-- (class): places GridFrames relative to the main anchor
-- :PlaceFrame(GridFrame frame, number group, number member)
-- spacing and scaling :SetFrameSpacing(number x, number y)
number x, number y = :GetFrameSpacing() :SetGroupSpacing(number spacing)
number spacing = :GetGroupSpacing() :SetScale(number scale)
number scale = :GetScale()
GridSort
-- (class): sorts available units and provides a tuple (group, member) for the active GridLayout.
-- it should be possible to cache the sort results and provide instant lookup of unitid to (group, member) tuple.
-- :SortedUnitIterator() -- each call of the function returned by the iterator returns: string unitid, number group, number member
number group, number member = :GetUnitPosition(string unitid) :UpdateSort()
GridStatus
-- (class): plugins that watch for special events (low health, debuffs, aggro)
--
Categories for status events DEBUFF (POISON, MAGIC, DISEASE, CURSE, PW:SHIELD, BANDAGED, etc.) HOT (RENEW, REGROWTH, etc.) BUFF_MISSING ( PW:FORT, AI, MOTW, etc.) BUFF_GAINED ( POWER_INFUSION, INNERVATE, SOULSTONE, etc.) ALERT ( AGGRO, LOW_HEALTH, LOW_MANA, etc.) OTHER ( ??? )
Alternatively, I could see adding a GridLayoutGroup class with its own GridFilter and GridSort classes/functions so that you could have a group containing just the tanks in addition to your regular raid view by group. I don't know if you'd want to go through the trouble to allow multiple frames for the same unitid though.
That might work something like this:
function classes.prototype.GridLayoutGroup:RosterUpdate()
local _,unitid
if Compost then
self.units = Compost:Erase(self.units)
else
self.units = {}
end
for unitid in self:GridSortIterator(self:GridFilter(GridCore.units)) do
tinsert(self.units, unitid)
end
self:UpdateFrames()
end
Scaling doesn't really apply here, because if you scaled mine down to the size of Luzienne's, they'd be useless because you wouldn't be able to read them.
I disagree. Scaling applies perfectly well here, healers that need to be able to click stuff can scale it up to your size if they want and be fine, while the rest of us can keep it nice and small. The only reason yours wouldn't fit smaller is because you used the full number of deficit; going with something like 2.3 for a 2300 deficit means you can easily make it readable at Luzienne's size.
It's more than the deficit. The H/C/D indicators would become unusable and, if you reduced the distance between frames, the glow would become useless as well. What I meant was that some type of theme or layout module might be best because you could use one that had the colored corner indicators and the two digit health indicator if you wanted or you could use one that had the letters for status and the full health indicator if you found that suited you better. Then you could scale them to whatever size you wanted.
Does the player button have to be a square? I see a square being used as part of the reason why scaling is an issue. To me - health information does not communicate more readily after you exceed a certain width. Take the area as is shown in the grid mockups was and redistribute it into rectangular or cylinder shapes for each player. Attach caps onto the ends '(' or '[' and bars on the sides for communicating additional information. It comes out as being similar to perfect raid, but on a more compact scale. Also has the same flavor on a small scale that huds put up (IceHud for example).
What I am asking is why limit the representation to squares? Different Models could be made for the player representation with different fills. Chevrons 'V' with the letter area being a health indicator and the area above in the valley, the two caps, and below the point and on the sides being used for additional information. '~' shapes.
If I am going to be whacking the moles, they might as well be pretty moles.
It doesn't have to be but if you want the buttons to be efficiently targeted, they need to be squares. The narrower or shorter they get, the slower you will become at mousing over them to get the right one. maia struck the nail squarely (pun!) on the head with the initial design. For this particular grid layout, I would hypothesize that squares will perform best at small (32x32) sizes.
The corner boxes seem a bit too small currently, though I'll have to wait until I have a chance to use it to decide for sure. This addon looks very promising Maia. :)
The corner boxes seem a bit too small currently, though I'll have to wait until I have a chance to use it to decide for sure.
read post #1:
The size and spacing of the boxes will be scalable, and obviously you can drag the entire frame to wherever you want. Also you can filter out specific subgroups/, and optionally also display the first letters of each unit name (due to the limited size a max of one or two). Possible future features: unit subgroups sorted horizontally instead of vertically, pet support,...
Is this planned to be a raid only addon or will it also work in say a much smaller window for a normal party?
It's currently using RosterLib and therefor working for soloing, partying and raids.
Is it planned the overall window size will be fixed or will it auto adjust to the number of raid memeber/groups etc
I disagree. Scaling applies perfectly well here, healers that need to be able to click stuff can scale it up to your size if they want and be fine, while the rest of us can keep it nice and small. The only reason yours wouldn't fit smaller is because you used the full number of deficit; going with something like 2.3 for a 2300 deficit means you can easily make it readable at Luzienne's size.
Perhaps there is hope afterall, although I don't know how you would use modifiers off the top of my head.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI see a few different classes/modules:
GridCore
-- (main addon): manages unit list and basic events (hp, mana, auras)
-- also watches for PLAYER_REGEN_ENABLED/PLAYER_REGEN_DISABLED to queue sorting/positioning if in-combat
--
-- roster events
:UpdateRoster()
-- relay status message from GridStatus instance to appropriate GridFrame instance(s)
:StatusGained(string unitid, string category, string status, number priority, string color, string text or "")
:StatusLost(string unitid, string status)
-- unit attributes for use by GridStatus/GridSort plugins
string name = :GetUnitName(string unitid)
string class = :GetUnitClass(string unitid)
number subGroup = :GetUnitSubgroup(string unitid)
number hp, number hpMax = :GetUnitHealth(string unitid)
number mana, number manaMax = :GetUnitMana(string unitid)
table auras = :GetUnitAuras(string unitid)
boolean hasAura = :UnitHasAura(string unitid, string texture)
GridFrame
-- (class): defines an individual unit frame, tied to a unitid
-- is also responsible for determining how to display a status event
--
:SetUnit(string unitid)
string unitid = :GetUnit()
-- unit status events
:StatusGained(string status, number priority, string color, string text or "")
:StatusLost(string status)
-- frame size
number x = :GetHeight()
number y = :GetWidth()
GridLayout
-- (class): places GridFrames relative to the main anchor
--
:PlaceFrame(GridFrame frame, number group, number member)
-- spacing and scaling
:SetFrameSpacing(number x, number y)
number x, number y = :GetFrameSpacing()
:SetGroupSpacing(number spacing)
number spacing = :GetGroupSpacing()
:SetScale(number scale)
number scale = :GetScale()
GridSort
-- (class): sorts available units and provides a tuple (group, member) for the active GridLayout.
-- it should be possible to cache the sort results and provide instant lookup of unitid to (group, member) tuple.
--
:SortedUnitIterator() -- each call of the function returned by the iterator returns: string unitid, number group, number member
number group, number member = :GetUnitPosition(string unitid)
:UpdateSort()
GridStatus
-- (class): plugins that watch for special events (low health, debuffs, aggro)
--
Categories for status events
DEBUFF (POISON, MAGIC, DISEASE, CURSE, PW:SHIELD, BANDAGED, etc.)
HOT (RENEW, REGROWTH, etc.)
BUFF_MISSING ( PW:FORT, AI, MOTW, etc.)
BUFF_GAINED ( POWER_INFUSION, INNERVATE, SOULSTONE, etc.)
ALERT ( AGGRO, LOW_HEALTH, LOW_MANA, etc.)
OTHER ( ??? )
Alternatively, I could see adding a GridLayoutGroup class with its own GridFilter and GridSort classes/functions so that you could have a group containing just the tanks in addition to your regular raid view by group. I don't know if you'd want to go through the trouble to allow multiple frames for the same unitid though.
That might work something like this:
function classes.prototype.GridLayoutGroup:RosterUpdate() local _,unitid if Compost then self.units = Compost:Erase(self.units) else self.units = {} end for unitid in self:GridSortIterator(self:GridFilter(GridCore.units)) do tinsert(self.units, unitid) end self:UpdateFrames() endIt's more than the deficit. The H/C/D indicators would become unusable and, if you reduced the distance between frames, the glow would become useless as well. What I meant was that some type of theme or layout module might be best because you could use one that had the colored corner indicators and the two digit health indicator if you wanted or you could use one that had the letters for status and the full health indicator if you found that suited you better. Then you could scale them to whatever size you wanted.
What I am asking is why limit the representation to squares? Different Models could be made for the player representation with different fills. Chevrons 'V' with the letter area being a health indicator and the area above in the valley, the two caps, and below the point and on the sides being used for additional information. '~' shapes.
If I am going to be whacking the moles, they might as well be pretty moles.
It doesn't have to be but if you want the buttons to be efficiently targeted, they need to be squares. The narrower or shorter they get, the slower you will become at mousing over them to get the right one. maia struck the nail squarely (pun!) on the head with the initial design. For this particular grid layout, I would hypothesize that squares will perform best at small (32x32) sizes.
and a demo of the borders and corners, obviously not really doing anything so far:
hawt
just a little note: might want to lower the opacity of the framebgd so the squares are easier to see.
(and yes, the background will be alphaable)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSomething you can use for textures =)
Looks good! What about showing the letters in Red when someone gains aggro?
That's what the red dots are for, it seems :]
So, maia, no deficit shown at the moment ?
Is there some highlighting yet (when hovering a square) ?
British: no highlighting yet, but i'm planning to add visual feedback. Need to do the basics first though.
Couple of questions for ya.
1. Is this planned to be a raid only addon or will it also work in say a much smaller window for a normal party?
2. Is it planned the overall window size will be fixed or will it auto adjust to the number of raid memeber/groups etc.
Over all I'm loving it especialy the size when placed next to squishy.
read post #1:
The size and spacing of the boxes will be scalable, and obviously you can drag the entire frame to wherever you want. Also you can filter out specific subgroups/, and optionally also display the first letters of each unit name (due to the limited size a max of one or two). Possible future features: unit subgroups sorted horizontally instead of vertically, pet support,...
It's currently using RosterLib and therefor working for soloing, partying and raids.
It auto-adjusts.
no more need of a gigantic ui to get only what you need
XRS, Squichy & Detox will complete the need of informations ;)