Grid is an original idea from Maia, that came into being with the work of both Maia and Pastamancer. I came very late in the development of Grid. Lots of design decisions is still present in Grid2, although most of the code has been rewritten.
You can make Grid show only the number of column you want by editing the attributes of a particular layout. This has to be done in the lua source code (either with Grid or Grid2), at least until someone writes a layout editor (which would be a fun project).
I'd pay for Grid to allow me to manually move people around and LOCK it so it doesn't change regardless of group makeup or raid leaders swapping people around etc.
I'd pay for Grid to allow me to manually move people around and LOCK it so it doesn't change regardless of group makeup or raid leaders swapping people around etc.
And that would totally break in battlegrounds where people frequently join/leave the raid while you're in-combat.
Grid2Options seems to have some problems - Does it have anything to do with me removing the Loadondemand line in the toc?
[2008/10/31 23:29:47-179-x1]: Grid2Options\GridIndicators.lua:84: attempt to index field 'option' (a nil value)
Grid2Options\GridMedia.lua:12: in function <Interface\AddOns\Grid2Options\GridMedia.lua:7>
<string>:"safecall Dispatcher[3]":4: in function <[string "safecall Dispatcher[3]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[3]":13: in function `?'
CallbackHandler-1.0-3 (Ampere):91: in function `Fire'
LibSharedMedia-3.0-90053:173: in function `Register'
oRA2-2.0.$Revision: 628 $\Core.lua:431: in function <Interface\AddOns\oRA2\Core.lua:430>
<in C code>: in function `pcall'
AceAddon-2.0-91091 (Buffalo):24: in function <...ce\AddOns\Buffalo\Libs\AceAddon-2.0\AceAddon-2.0.lua:23>
AceAddon-2.0-91091 (Buffalo):669: in function `InitializeAddon'
AceAddon-2.0-91091 (Buffalo):541: in function <...ce\AddOns\Buffalo\Libs\AceAddon-2.0\AceAddon-2.0.lua:518>
<in C code>: ?
AceEvent-2.0-91091 (Buffalo):298: in function `TriggerEvent'
AceEvent-2.0-91091 (Buffalo):910: in function <...ce\AddOns\Buffalo\Libs\AceEvent-2.0\AceEvent-2.0.lua:903>
---
This error happens when I log in and I am also unable to enter the options in the interface --> Addons menu :)
Grid2Options seems to have some problems - Does it have anything to do with me removing the Loadondemand line in the toc?
LoadOnDemand is only bugged for things like libraries that are not explicitly loaded by the addon using them. Grid2Options is explicitly loaded by Grid2 when you try to access the configuration, so there is no reason to remove the LoadOnDemand flag. Also, it's like that Grid2Options is expecting Grid2 to be fully loaded when it loads, which is probably not the case if it's loaded at "load time".
As Phanx said, LoD is expected for Grid2Options and there is no reason to remove it.
I'm going to make another beta release of Grid2 as it is right now. The initial implementation of Grid2Alert and Grid2StatusRaidDebuffs seem to work, mostly. There is absolutely no configuration for them, though. Dispell and Aggro alerts are back. You can't disable them for now.
I have simplified StatusRaidDebuff. I does not check the combat log anymore, and only reacts on debuffs. I hope it is sufficient. With all the changes done in wow 3.0 concerning the combat log and auras, I'm confident that most of the tricks that GridStatusRaidDebuff had to use to provide a good feedback is not needed anymore. In that sense, Grid2StatusRaidDebuffs is nothing more than an ordered list of debuffs names linked to a specific zone and attached to the central icon.
I have generalised the "icon" indicator and statuses to provide a lot more information, if available. Stuff like Duration, number of applications and aura type (magic, poison, curse, ...) should be available for specific aura statuses and raid debuffs status. There is still a bug with the icon border color in the current implementation that I need to fix.
Ah, thanks for telling me that. I thought basically all loadondemand addons were broken.
Grid2Options worked fine after that, I did however have some nasty black areas around the frame covering parts of it, but I haven't tried the latest build.
And that would totally break in battlegrounds where people frequently join/leave the raid while you're in-combat.
Not if you code it so that new people coming in fill in empty spots.
And you assume I'd want it to stay locked forever. I'd want it to be configurable at the start of a raid and lock like that until raid is dropped. I'd never be changing who is where in a battleground ...
I'm a druid and have just got Wild Growth. I'd like a status in grid to tell me who's the optimum WG target in AoE heal situations. Something like:
Is active when there are people within 15 yards of the unit that do not already have WG on them and who are not at full health.
Changes colour based on how many of those people are in range getting more obvious for those with more people in range.
I don't know much about addons yet but I'm guessing the best solution would be one where a library kept track of what units are within specific ranges and queried with something like LibWithinRange_checkUnitsWithinRange("raid5", 15) however inter-addon communication works, my Grid2 status then checks the rest - for the buff and for the health. Does an library that does this already exist or would creating one sound plausible and not be a huge resource hog? I'll have a look at the DBM addon to see how it keeps track of individuals within certain ranges of a unit.
I too am a resto druid, and I don't feel the need. In fact, I don't want an addon to tell me who I should heal.
@jaredheath: although something like this could possibly be done, it would be quite difficult to do it right. With the concept of "group" becoming less important now, I suggest using a layout that take all groups and sort player by class and names. This is possible and quite easy to do.
Not if you code it so that new people coming in fill in empty spots.
And you assume I'd want it to stay locked forever. I'd want it to be configurable at the start of a raid and lock like that until raid is dropped. I'd never be changing who is where in a battleground ...
You can't tell the Blizzard secure raid header to show everyone except a named list. If someone joined the raid you wouldn't see them until you left combat.
Additionally, within a secure raid header, you can only sort by name (alphabetically) or by index (unit id: raid1..raid40).
Assuming you can live with those limitations, it would be possible to make an addon create a name-list-based layout for grid which would let you say "these people go in column 1, these in column 2, etc.".
I was hoping to do it myself as a library with a seperate Grid2 implementation.
Quote from jerry »
I don't want an addon to tell me who I should heal.
Nor do I, which is my favourite quality in Grid. It's just the same as any other status really; your rejuvenation status tells you that a rejuvenation is ticking on the unit (and you infer that casting rejuvenation on this target isn't necessary or that you might consider swiftmending, it can even change colour based on duration left to prepare you for the next task). The problem with WG though is that a simple aura-based status wouldn't tell you 4/5ths of the story about what effect your cast will have. But I agree, it's several degrees of magnitude different.
I have generalised the "icon" indicator and statuses to provide a lot more information, if available. Stuff like Duration, number of applications and aura type (magic, poison, curse, ...) should be available for specific aura statuses and raid debuffs status. There is still a bug with the icon border color in the current implementation that I need to fix.
All of this extra stuff is optional, I hope? For the vast majority of debuffs, I don't care at all about the duration or the number of applications; I just need to know that it's affecting that person at this moment. Same with aura type... currently I disable everything in GridStatusRaidDebuffs that I can cure, because I already show curable debuffs on another indicator (frame border), so I don't really care what kind of debuff whatever's left is. If it's showing through GSRD, I can't remove it.
Ah, thanks for telling me that. I thought basically all loadondemand addons were broken.
No. LoD is only "broken" in the sense that if an addon is LoD, it will only load if an addon explicitly loads it. However, up until this patch, LoD addons would also load if they were listed as dependencies in the TOC of another addon when that addon loaded.
Is active when there are people within 15 yards of the unit that do not already have WG on them and who are not at full health.
This would require everyone in your raid to be running code that continually checked how close they were to others and broadcast that information to the raid; there is no API function to check the distance between units unless one of the units is yourself (or possibly your pet, if you're using a pet's spell as the range check). While Grid already does the range checking parts, it would be quite a bit of data to broadcast, as in order for it to be accurate enough to be useful, you'd need to get 24 unit identifiers and 24 numbers from each of 24 people at least once a second. That's a lot of spam to be sending around for a very dubious benefit.
This would require everyone in your raid to be running code that continually checked how close they were to others and broadcast that information to the raid
That's a lot of spam to be sending around for a very dubious benefit.
I can see one or two opportunities for tightening up on the broadcasting. Also, by making it a library others may find new uses for it - the benefits may multiple.
Status that register themselves as "icon" must provide a Texture. They may also provide a Cooldown information, a text (number of applications) and a color (for the border but NYI). The central Icon indicator will use whatever information is available to update its display.
Right now, there are 3 statuses that register as "icon". The Raid Debuff Status, which provide all this information, the named buff/debuff status, which also provide all this information, and the debuff-type status, which do not provide this information (but that could change).
Also, by making it a library others may find new uses for it - the benefits may multiple.
Code should only be turned into a library if it has obvious potential for multiple applications. How many uses for knowing how far away from each other two arbitrary members of your raid are there? Not many. Other than Wild Growth, I can only think of two other spells that have effects dependent on the proximity of others to the target - Chain Heal and Circle of Healing - but as someone who is intimately familiar with the mechanics of both spells, I can tell you that having an addon to tell me when to cast one or the other is pretty much useless.
I know Wild Growth is a little different, and my druid is feral, so I haven't really had much experience with it, but honestly, the range is 15 yards. Set up your raid frames by class (so melee are shown together, and ranged together, etc) and I just don't see how the very marginal help this feature would be justifies 25 people running constant mass range scanning code and filling the addon comm channel with 625 names and 625 ranges every second or less.
Also, good luck getting all of your fellow raiders to install something to help you. It was hard enough getting everyone to install a threat meter, and those were of obvious benefit to everyone. :p
Status that register themselves as "icon" must provide a Texture. They may also provide a Cooldown information, a text (number of applications) and a color (for the border but NYI). The central Icon indicator will use whatever information is available to update its display.
I mean, I don't want this information on my icons, and I hope there will be a way to disable showing it without hacking the Lua every update.
Latest beta already works pretty good, only thing so far is that I don't understand the config quite well, at least I am not able to link a status to another frame object just yet. Also the health bar only colors when you hover over it with the mouse...other than that the default is pretty much the same as my Grid1 which I spent a lot of time on with additional modules. Thanks for the good work!
and I just don't see how the very marginal help this feature would be justifies 25 people running constant mass range scanning code and filling the addon comm channel with 625 names and 625 ranges every second or less.
Erm, in fact I don't see any point where the teensy inexistant gain of that "feature" warrants the massive communication spam and processing it'd need.
There's no use case for it. Yes, it can, 1 in 100 times, be a 1-target improvement to Wild Growth. And in 1 of 1000 such cases that might make the difference between wipe and success, and then I think there's also so many problems the mod-world already has...
Erm, in fact I don't see any point where the teensy inexistant gain of that "feature" warrants the massive communication spam and processing it'd need.
That's pretty much what I said. The functionality it would add would provide only a very marginal benefit, as you describe, and would not justify the overhead it would incur. :p
Is there a way to swap the indicators? I'd prefer the unit name and incoming heal to be on "text up", and health deficit as "text down".
The ability to assign statuses to indicators other than the defaults is yet to come, I think. That said, I strongly prefer to have only one text indicator at all, in the middle of the frame.
The ability to assign statuses to indicators other than the defaults is yet to come, I think. That said, I strongly prefer to have only one text indicator at all, in the middle of the frame.
Yeah, when a member has health deficit, I can no longer see who it is.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I'd pay for Grid to allow me to manually move people around and LOCK it so it doesn't change regardless of group makeup or raid leaders swapping people around etc.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAnd that would totally break in battlegrounds where people frequently join/leave the raid while you're in-combat.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis error happens when I log in and I am also unable to enter the options in the interface --> Addons menu :)
LoadOnDemand is only bugged for things like libraries that are not explicitly loaded by the addon using them. Grid2Options is explicitly loaded by Grid2 when you try to access the configuration, so there is no reason to remove the LoadOnDemand flag. Also, it's like that Grid2Options is expecting Grid2 to be fully loaded when it loads, which is probably not the case if it's loaded at "load time".
I'm going to make another beta release of Grid2 as it is right now. The initial implementation of Grid2Alert and Grid2StatusRaidDebuffs seem to work, mostly. There is absolutely no configuration for them, though. Dispell and Aggro alerts are back. You can't disable them for now.
I have simplified StatusRaidDebuff. I does not check the combat log anymore, and only reacts on debuffs. I hope it is sufficient. With all the changes done in wow 3.0 concerning the combat log and auras, I'm confident that most of the tricks that GridStatusRaidDebuff had to use to provide a good feedback is not needed anymore. In that sense, Grid2StatusRaidDebuffs is nothing more than an ordered list of debuffs names linked to a specific zone and attached to the central icon.
I have generalised the "icon" indicator and statuses to provide a lot more information, if available. Stuff like Duration, number of applications and aura type (magic, poison, curse, ...) should be available for specific aura statuses and raid debuffs status. There is still a bug with the icon border color in the current implementation that I need to fix.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumGrid2Options worked fine after that, I did however have some nasty black areas around the frame covering parts of it, but I haven't tried the latest build.
Not if you code it so that new people coming in fill in empty spots.
And you assume I'd want it to stay locked forever. I'd want it to be configurable at the start of a raid and lock like that until raid is dropped. I'd never be changing who is where in a battleground ...
Is active when there are people within 15 yards of the unit that do not already have WG on them and who are not at full health.
Changes colour based on how many of those people are in range getting more obvious for those with more people in range.
I don't know much about addons yet but I'm guessing the best solution would be one where a library kept track of what units are within specific ranges and queried with something like LibWithinRange_checkUnitsWithinRange("raid5", 15) however inter-addon communication works, my Grid2 status then checks the rest - for the buff and for the health. Does an library that does this already exist or would creating one sound plausible and not be a huge resource hog? I'll have a look at the DBM addon to see how it keeps track of individuals within certain ranges of a unit.
Any thoughts?
I ain't implementing this :-)
I too am a resto druid, and I don't feel the need. In fact, I don't want an addon to tell me who I should heal.
@jaredheath: although something like this could possibly be done, it would be quite difficult to do it right. With the concept of "group" becoming less important now, I suggest using a layout that take all groups and sort player by class and names. This is possible and quite easy to do.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou can't tell the Blizzard secure raid header to show everyone except a named list. If someone joined the raid you wouldn't see them until you left combat.
Additionally, within a secure raid header, you can only sort by name (alphabetically) or by index (unit id: raid1..raid40).
Assuming you can live with those limitations, it would be possible to make an addon create a name-list-based layout for grid which would let you say "these people go in column 1, these in column 2, etc.".
I was hoping to do it myself as a library with a seperate Grid2 implementation.
Nor do I, which is my favourite quality in Grid. It's just the same as any other status really; your rejuvenation status tells you that a rejuvenation is ticking on the unit (and you infer that casting rejuvenation on this target isn't necessary or that you might consider swiftmending, it can even change colour based on duration left to prepare you for the next task). The problem with WG though is that a simple aura-based status wouldn't tell you 4/5ths of the story about what effect your cast will have. But I agree, it's several degrees of magnitude different.
All of this extra stuff is optional, I hope? For the vast majority of debuffs, I don't care at all about the duration or the number of applications; I just need to know that it's affecting that person at this moment. Same with aura type... currently I disable everything in GridStatusRaidDebuffs that I can cure, because I already show curable debuffs on another indicator (frame border), so I don't really care what kind of debuff whatever's left is. If it's showing through GSRD, I can't remove it.
No. LoD is only "broken" in the sense that if an addon is LoD, it will only load if an addon explicitly loads it. However, up until this patch, LoD addons would also load if they were listed as dependencies in the TOC of another addon when that addon loaded.
This would require everyone in your raid to be running code that continually checked how close they were to others and broadcast that information to the raid; there is no API function to check the distance between units unless one of the units is yourself (or possibly your pet, if you're using a pet's spell as the range check). While Grid already does the range checking parts, it would be quite a bit of data to broadcast, as in order for it to be accurate enough to be useful, you'd need to get 24 unit identifiers and 24 numbers from each of 24 people at least once a second. That's a lot of spam to be sending around for a very dubious benefit.
Yes, I realise this.
I can see one or two opportunities for tightening up on the broadcasting. Also, by making it a library others may find new uses for it - the benefits may multiple.
What do you mean exactly ?
Status that register themselves as "icon" must provide a Texture. They may also provide a Cooldown information, a text (number of applications) and a color (for the border but NYI). The central Icon indicator will use whatever information is available to update its display.
Right now, there are 3 statuses that register as "icon". The Raid Debuff Status, which provide all this information, the named buff/debuff status, which also provide all this information, and the debuff-type status, which do not provide this information (but that could change).
How would you like this to change ?
Code should only be turned into a library if it has obvious potential for multiple applications. How many uses for knowing how far away from each other two arbitrary members of your raid are there? Not many. Other than Wild Growth, I can only think of two other spells that have effects dependent on the proximity of others to the target - Chain Heal and Circle of Healing - but as someone who is intimately familiar with the mechanics of both spells, I can tell you that having an addon to tell me when to cast one or the other is pretty much useless.
I know Wild Growth is a little different, and my druid is feral, so I haven't really had much experience with it, but honestly, the range is 15 yards. Set up your raid frames by class (so melee are shown together, and ranged together, etc) and I just don't see how the very marginal help this feature would be justifies 25 people running constant mass range scanning code and filling the addon comm channel with 625 names and 625 ranges every second or less.
Also, good luck getting all of your fellow raiders to install something to help you. It was hard enough getting everyone to install a threat meter, and those were of obvious benefit to everyone. :p
I mean, I don't want this information on my icons, and I hope there will be a way to disable showing it without hacking the Lua every update.
Erm, in fact I don't see any point where the teensy inexistant gain of that "feature" warrants the massive communication spam and processing it'd need.
There's no use case for it. Yes, it can, 1 in 100 times, be a 1-target improvement to Wild Growth. And in 1 of 1000 such cases that might make the difference between wipe and success, and then I think there's also so many problems the mod-world already has...
That's pretty much what I said. The functionality it would add would provide only a very marginal benefit, as you describe, and would not justify the overhead it would incur. :p
The ability to assign statuses to indicators other than the defaults is yet to come, I think. That said, I strongly prefer to have only one text indicator at all, in the middle of the frame.
Yeah, when a member has health deficit, I can no longer see who it is.