Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
Should more layouts be provided, or ways to edit them in the config, etc?
If anything, I think fewer layouts should be provided. The default "By Class" layouts are all but useless for the reasons described in my last post. A full-fledged layout editor is also outside the scope of what I think the default configuration should offer; it would be a good candidate for a plugin, but is in no way necessary. A better solution may be to do away with the layout presets in the default distribution and implement a simple dynamic system, like:
Arrangement
By Class
By Group
Include Groups
1
2
3
4
5
6
7
8
Extra Units
Pets
Tanks
There's not really any reason someone should have to pick "By Group 10" for normal raids and "By Group 25" for heroic raids... if Grid is smart enough to know which layout to use, why not just let someone pick "By Group" and change the size for them?
Regardless of the selected method of arrangement in the above menu, units should form a 5 x N grid; "By Class" should run everyone together in one "group" the way my custom layout does to avoid gaps.
It also seems a little silly that you need duplicates of every layout to choose whether or not to show pets, and yet more layouts if you want to show tanks. These could easily be toggled on the fly.
Agreed. What you describe is more like what I had in mind for "editing". The pet thing has irked me for some time as well. I would add arranging the class sorting.
A setting for WG and other 40 creature raids is needed as well, it is irritating having to manually mess around in there. If anyone wants to add the code for that, feel free.
I don't think the order really needs to change for anyone.... everyone with AoE heals will want people organized by most likely proximity, and even if you don't have AoE heals it's still a fairly intuitive ordering. Something like changing the order would be better suited to an "advanced layout editor" plugin, rather than the core.
It looks like changing distance/yards for the range indicator is not possible...
Grid has separate settings for various ranges iirc. I will add those either as separate statuses or settings on range itself. Default will probably remain the 40 yard one. Is there a point to the 100 yard one? ie. does anyone use it?
I don't know anyone who uses more than one range status in Grid... not only is it only useful for a very few situations, but it's a huge increase in CPU usage.
Default range for healers should be 40 yards; DPS classes should probably default to 30 yards since no damage abilities have a 40 yard range by default and only a few can be talented to that kind of range.
I guess the only drawback with it is you do not know what groups people are in. Maybe there should be a keyboard shortcut to toggle between group based and class based for fights that need that. (I hate having to open config just for such tweaks).
I don't know anyone who uses more than one range status in Grid... not only is it only useful for a very few situations, but it's a huge increase in CPU usage...
It can certainly be implemented as a selection amongst the sizes so you force only computing one of them. Making them separate statuses is fine too I think. Each one would be slightly more efficient by lacking code to support multiple ranges.
On the other hand I am pondering a status that displays the # of people within 15 yards of someone. This would let you target aoe heals better. Probably need to lib the code for that etc.
Umm... it's not sorted by groups at all, so "By Group 25" doesn't make any sense. Also, due to its automagic nature, it works equally well for 10-man raids. "By Class 10-25" might be a better name. :p
I guess the only drawback with it is you do not know what groups people are in.
There are almost no abilities left that are group-dependent... for the few that are, you can just open the raid panel with whatever keybind you already have for that, and look at what group you're in and who's in it. Those who absolutely depend on knowing which group everyone is in can just stick with a "By Group" layout.
On the other hand I am pondering a status that displays the # of people within 15 yards of someone. This would let you target aoe heals better. Probably need to lib the code for that etc.
Eh, that's been discussed several times over the last few years, and it's just not practical... you'd need to scan ranges and broadcast them to the raid very frequently for it to be anywhere near accurate, and unless everyone was standing still (obviating the need for such a tool) it would never be accurate anyway due to varying degrees of latency and de-sync from the server. I play right next to my boyfriend, and it's rare that I look over at his screen and see myself in the same place that I am on my screen. It's sometimes a small difference, but other times a really huge difference, like I'll be 20 yards ahead of him on my screen, and 20 yards behind him on his screen... seeing things like that firsthand, I really can't believe there's any way you could accurately maintain a raid-wide view of who was within any distance of anyone else, even if you spammed the comm channel with 9/24 ranges as often as was possible without being disconnected. It would also be pointless if not everyone in the raid was running it, and it's about impossible to get everyone to install something that only sort of helps a few people...
I am less concerned with speculation and more concerned with if it actually would work / be helpful in practice on boss fights.
Right, but consider these two scenarios:
1) Everyone in the raid stands in a specific place and doesn't move for the majority of the fight. For example, Patchwerk.
2) Everyone in the raid is moving constantly or frequently for the entire fight. For example, Sapphiron.
In a fight like #1, keeping track of everyone's relative positioning in a reasonably accurate fashion is easy, because you need to sync and do calculations very infrequently. However, the need to keep track of everyone's relative position programmatically is very low, because if nobody is moving, you already know who's where and don't have to keep track of changes. You can always throw a Chain Heal at a rogue and have it jump to 2-3 other melee players, because all of the melee players are in the same place.
In a fight like #2, the opposites are true. Because everyone is moving all the time, it's much more difficult to keep track of where everyone is just by looking at the game world. However, because everyone is moving all the time, you would need to sync ranges and perform calculations very frequently to achieve any useful degree of accuracy. Previous discussions have generally concluded that it would be impossible to achieve such a degree of accuracy without incurring unacceptable costs in CPU time and sync bandwidth. Considering that most AoE healing abilities require someone to be within 10 yards of someone else, and considering how quickly you can move 10 yards, you would need to find the ranges of everyone else in your group, broadcast that data, receive data from the other 4-24 members of your group, and perform calculations to determine how many people were within 10 yards of each person, all many times every second. Also keep in mind that latency and the nature of the client-server relationship means that where X is on your screen isn't necessarily where X is on their own screen, and neither are necessarily where the server thinks X is (although the server's view and X's view will be more similar than either and your view).
Simply put, it would work, but not accurately enough to be dependable, and not without a significant impact on performance. If you search around, you'll find several old threads on the subject, one with Xinhuan giving a much more thorough explanation of why it wouldn't work as intended.
...Simply put, it would work, but not accurately enough to be dependable, and not without a significant impact on performance. If you search around, you'll find several old threads on the subject, one with Xinhuan giving a much more thorough explanation of why it wouldn't work as intended.
What I am thinking is that lets say 1/second you see who is within 15 yards. If this # changed or changed by a certain amount you broadcast it.
As noted this is not accurate and due to the broadcast lag from server actual->target->server->recipient will never be "accurate" (except for static fights like patchwork or kelthuzad etc.)
However the question is this: can a slowly updated value like this, possibly even averaged over time give valuable information. Even in a nutty fight, if a ranged/healer is standing somewhere on its own will its # change a lot or be mostly static. For the rat pack, they are running around attacking something being tanked. Even while running in a pack like that the number is likely to be high and remain so.
The valuable information is identifying the loners or people with a low #, or even those that tend to have low numbers. I think this scheme can work and do so without a severe performance impact. If it is done in a lib the only overhead could be broadcasting a change in # since for instance deadly boss mods does range checks already. As for it producing valuable results I think only actually trying it can answer that. I am not at all confident that thought experiments can tell us anything about this since it is really about individual player behavior: is the player a pack animal or a loner?
Druids and Priests can easily meter the results with / without such a status. (Is there a jump range on chain heal as well?)
Do you have links to the threads? I am not getting the magic query right for google so far.
What I am thinking is that lets say 1/second you see who is within 15 yards. If this # changed or changed by a certain amount you broadcast it.
You could do that, but in fights where people are moving much, by the time 1 second passes, the people who were within 10 yards of you are probably scattered all over the map. :p
Druids and Priests can easily meter the results with / without such a status. (Is there a jump range on chain heal as well?)
There is a range on Chain Heal jumps... it's not explicitly stated anywhere, but observed behavior puts it in the 10-15 yard range. However, that 10 yards is based on where the server thinks everyone is, which is not always where they appear to be on my screen. I've had Chain Heal jump what appeared to be 30-40 yards at times, while at others it doesn't jump between people who are practically standing on top of each other.
Do you have links to the threads? I am not getting the magic query right for google so far.
I'm raiding at the moment, but if you search for "GridStatusChainRule" on the forums here you might find it. Or try searching for posts by Xinhuan containing the word "triangulate" or "triangulation".
Hi there,
I recently took the opportunity to try out Grid 2 on my druid and thought I'd provide some insight into my impression.
Firstly, it should be said that I'm what I'd consider to be an advanced user of Grid, so a lot of how i except Grid 2 to be is based on my current Grid setup.
First impression: Too many numbers!
With textual counter for all three hots, it just becomes too much detailed information, and not very eye friendly. Especially once you shrink the frames down to reasonable size. (The current default size is too large considering the number of them that you need to fit in your screen in a raid.)
I do not think that it is necessary to show Rejuvenation or Regrowth as a textual timer. I currently use a square corner indicator each for these two, and have them switch color as they are about to expire (i.e. one tick left, 3 seconds).
Lifebloom as a textual timer i support fully, with one decimal point even :D
On the topic of decimal points. Even if you show Rejuvenation and regrowth as textual timers, please don't do this with any decimal points. This leads me to request that a textual indicator displaying numbers can use the string length slider to determine decimal points. Ultimately letting the user decide.
Of minor note, I would prefer that the default for Mark of the Wild would be 'show if missing'.
Well, that's all i can think of in my current state of being bored at work.
..."GridStatusChainRule" ... posts by Xinhuan containing the word "triangulate" or "triangulation".
Awesome, that did the trick. Weird, I missed a couple of mods during the guid branch conversions. I guess I never looked for Curse hosted but without projects.
I agree. I am not raiding with Grid2 yet but I have both open usually and all 3 as numbers seemed like a lot. I may replace rejuv with a square since it actually benefits from expiring (I use the regrowth glyph). There will be a settable threshold for the decimal part (per indicator). Possibly also a global setting for number of decimal places. (0.1 seconds is good for me because I have low and stable latency).
...The current default size is too large considering the number of them that you need to fit in your screen in a raid...
The current defaults are for everyone's convenience unless they are temporarily for me during testing / alpha. Even at the current size settings they are only 1/4 of what I need them for my screen resolution which is 2560x1600. They will remain this way for a while. If anyone has code for screen resolution detection I can make it switch between various screen sizes.
If anyone has code for screen resolution detection I can make it switch between various screen sizes.
Considering that a dynamic default size would only ever be selected once the first time a user logged in with the addon, it seems a bit silly to allocate resources to guessing what a good size for each resolution might be. I run at 1600x1050 resolution, and the default size of Grid2 is much smaller than I need, although it is an improvement over the microscopic default size of Grid. Just pick a reasonable default size, and make sure the configuration UI is intuitive enough that people can figure out how to adjust the size; it only needs to be done once, and the "right size" will be different for everyone based on screen resolution, UI scale, visual acuity, and aesthetic tastes. The current default size is probably fine.
As a tank, i guess 30 yards are fine and 40 for healers like already said.
It is like some sort of a ready check, where is everybody and can I pull some mobs. Maybe the instanze maps make this obsolete, but I always thought range alpha in Grid makes it a little easier.
i was thinking that nothing could be as confusing as setting up grid but then i downloaded this and i am like "wtf is blink? and why is there an option for it?" admittedly i did figure it out sooner or later but i just thought that the grid prior setup was more understandable.
will be watching this addon though, grid kept throwing errors (even if it was still usable) with 3.2 and i was getting major tired of them.
I'll try to remember when I'm at home. Most of my forum posting occurs at work. :p
If anything, I think fewer layouts should be provided. The default "By Class" layouts are all but useless for the reasons described in my last post. A full-fledged layout editor is also outside the scope of what I think the default configuration should offer; it would be a good candidate for a plugin, but is in no way necessary. A better solution may be to do away with the layout presets in the default distribution and implement a simple dynamic system, like:
There's not really any reason someone should have to pick "By Group 10" for normal raids and "By Group 25" for heroic raids... if Grid is smart enough to know which layout to use, why not just let someone pick "By Group" and change the size for them?
Regardless of the selected method of arrangement in the above menu, units should form a 5 x N grid; "By Class" should run everyone together in one "group" the way my custom layout does to avoid gaps.
It also seems a little silly that you need duplicates of every layout to choose whether or not to show pets, and yet more layouts if you want to show tanks. These could easily be toggled on the fly.
Agreed. What you describe is more like what I had in mind for "editing". The pet thing has irked me for some time as well. I would add arranging the class sorting.
A setting for WG and other 40 creature raids is needed as well, it is irritating having to manually mess around in there. If anyone wants to add the code for that, feel free.
GridLayout:AddLayout(L["25 by Class"], { [1] = { groupFilter = "1,2,3,4,5", groupBy = "CLASS", groupingOrder = "WARRIOR,DEATHKNIGHT,ROGUE,PALADIN,DRUID,SHAMAN,PRIEST,MAGE,WARLOCK,HUNTER", unitsPerColumn = 5, maxColumns = 5, }, [2] = { isPetGroup = true, groupFilter = "1,2,3,4,5", groupBy = "CLASS", groupingOrder = "HUNTER,DEATHKNIGHT,WARLOCK", unitsPerColumn = 5, maxColumns = 5, }, })I don't think the order really needs to change for anyone.... everyone with AoE heals will want people organized by most likely proximity, and even if you don't have AoE heals it's still a fairly intuitive ordering. Something like changing the order would be better suited to an "advanced layout editor" plugin, rather than the core.
Was quite handy as raid leader and tank.
Grid has separate settings for various ranges iirc. I will add those either as separate statuses or settings on range itself. Default will probably remain the 40 yard one. Is there a point to the 100 yard one? ie. does anyone use it?
Default range for healers should be 40 yards; DPS classes should probably default to 30 yards since no damage abilities have a 40 yard range by default and only a few can be talented to that kind of range.
I added your layout as "By Group 25".
I guess the only drawback with it is you do not know what groups people are in. Maybe there should be a keyboard shortcut to toggle between group based and class based for fights that need that. (I hate having to open config just for such tweaks).
It can certainly be implemented as a selection amongst the sizes so you force only computing one of them. Making them separate statuses is fine too I think. Each one would be slightly more efficient by lacking code to support multiple ranges.
On the other hand I am pondering a status that displays the # of people within 15 yards of someone. This would let you target aoe heals better. Probably need to lib the code for that etc.
So what exactly do you need to set it to?
Umm... it's not sorted by groups at all, so "By Group 25" doesn't make any sense. Also, due to its automagic nature, it works equally well for 10-man raids. "By Class 10-25" might be a better name. :p
There are almost no abilities left that are group-dependent... for the few that are, you can just open the raid panel with whatever keybind you already have for that, and look at what group you're in and who's in it. Those who absolutely depend on knowing which group everyone is in can just stick with a "By Group" layout.
Eh, that's been discussed several times over the last few years, and it's just not practical... you'd need to scan ranges and broadcast them to the raid very frequently for it to be anywhere near accurate, and unless everyone was standing still (obviating the need for such a tool) it would never be accurate anyway due to varying degrees of latency and de-sync from the server. I play right next to my boyfriend, and it's rare that I look over at his screen and see myself in the same place that I am on my screen. It's sometimes a small difference, but other times a really huge difference, like I'll be 20 yards ahead of him on my screen, and 20 yards behind him on his screen... seeing things like that firsthand, I really can't believe there's any way you could accurately maintain a raid-wide view of who was within any distance of anyone else, even if you spammed the comm channel with 9/24 ranges as often as was possible without being disconnected. It would also be pointless if not everyone in the raid was running it, and it's about impossible to get everyone to install something that only sort of helps a few people...
Its not so much about abilities as sometimes having tactical groups in a boss fight.
I am less concerned with speculation and more concerned with if it actually would work / be helpful in practice on boss fights.
Right, but consider these two scenarios:
1) Everyone in the raid stands in a specific place and doesn't move for the majority of the fight. For example, Patchwerk.
2) Everyone in the raid is moving constantly or frequently for the entire fight. For example, Sapphiron.
In a fight like #1, keeping track of everyone's relative positioning in a reasonably accurate fashion is easy, because you need to sync and do calculations very infrequently. However, the need to keep track of everyone's relative position programmatically is very low, because if nobody is moving, you already know who's where and don't have to keep track of changes. You can always throw a Chain Heal at a rogue and have it jump to 2-3 other melee players, because all of the melee players are in the same place.
In a fight like #2, the opposites are true. Because everyone is moving all the time, it's much more difficult to keep track of where everyone is just by looking at the game world. However, because everyone is moving all the time, you would need to sync ranges and perform calculations very frequently to achieve any useful degree of accuracy. Previous discussions have generally concluded that it would be impossible to achieve such a degree of accuracy without incurring unacceptable costs in CPU time and sync bandwidth. Considering that most AoE healing abilities require someone to be within 10 yards of someone else, and considering how quickly you can move 10 yards, you would need to find the ranges of everyone else in your group, broadcast that data, receive data from the other 4-24 members of your group, and perform calculations to determine how many people were within 10 yards of each person, all many times every second. Also keep in mind that latency and the nature of the client-server relationship means that where X is on your screen isn't necessarily where X is on their own screen, and neither are necessarily where the server thinks X is (although the server's view and X's view will be more similar than either and your view).
Simply put, it would work, but not accurately enough to be dependable, and not without a significant impact on performance. If you search around, you'll find several old threads on the subject, one with Xinhuan giving a much more thorough explanation of why it wouldn't work as intended.
What I am thinking is that lets say 1/second you see who is within 15 yards. If this # changed or changed by a certain amount you broadcast it.
As noted this is not accurate and due to the broadcast lag from server actual->target->server->recipient will never be "accurate" (except for static fights like patchwork or kelthuzad etc.)
However the question is this: can a slowly updated value like this, possibly even averaged over time give valuable information. Even in a nutty fight, if a ranged/healer is standing somewhere on its own will its # change a lot or be mostly static. For the rat pack, they are running around attacking something being tanked. Even while running in a pack like that the number is likely to be high and remain so.
The valuable information is identifying the loners or people with a low #, or even those that tend to have low numbers. I think this scheme can work and do so without a severe performance impact. If it is done in a lib the only overhead could be broadcasting a change in # since for instance deadly boss mods does range checks already. As for it producing valuable results I think only actually trying it can answer that. I am not at all confident that thought experiments can tell us anything about this since it is really about individual player behavior: is the player a pack animal or a loner?
Druids and Priests can easily meter the results with / without such a status. (Is there a jump range on chain heal as well?)
Do you have links to the threads? I am not getting the magic query right for google so far.
You could do that, but in fights where people are moving much, by the time 1 second passes, the people who were within 10 yards of you are probably scattered all over the map. :p
There is a range on Chain Heal jumps... it's not explicitly stated anywhere, but observed behavior puts it in the 10-15 yard range. However, that 10 yards is based on where the server thinks everyone is, which is not always where they appear to be on my screen. I've had Chain Heal jump what appeared to be 30-40 yards at times, while at others it doesn't jump between people who are practically standing on top of each other.
I'm raiding at the moment, but if you search for "GridStatusChainRule" on the forums here you might find it. Or try searching for posts by Xinhuan containing the word "triangulate" or "triangulation".
I recently took the opportunity to try out Grid 2 on my druid and thought I'd provide some insight into my impression.
Firstly, it should be said that I'm what I'd consider to be an advanced user of Grid, so a lot of how i except Grid 2 to be is based on my current Grid setup.
First impression: Too many numbers!
With textual counter for all three hots, it just becomes too much detailed information, and not very eye friendly. Especially once you shrink the frames down to reasonable size. (The current default size is too large considering the number of them that you need to fit in your screen in a raid.)
I do not think that it is necessary to show Rejuvenation or Regrowth as a textual timer. I currently use a square corner indicator each for these two, and have them switch color as they are about to expire (i.e. one tick left, 3 seconds).
Lifebloom as a textual timer i support fully, with one decimal point even :D
On the topic of decimal points. Even if you show Rejuvenation and regrowth as textual timers, please don't do this with any decimal points. This leads me to request that a textual indicator displaying numbers can use the string length slider to determine decimal points. Ultimately letting the user decide.
Of minor note, I would prefer that the default for Mark of the Wild would be 'show if missing'.
Well, that's all i can think of in my current state of being bored at work.
Awesome, that did the trick. Weird, I missed a couple of mods during the guid branch conversions. I guess I never looked for Curse hosted but without projects.
I agree. I am not raiding with Grid2 yet but I have both open usually and all 3 as numbers seemed like a lot. I may replace rejuv with a square since it actually benefits from expiring (I use the regrowth glyph). There will be a settable threshold for the decimal part (per indicator). Possibly also a global setting for number of decimal places. (0.1 seconds is good for me because I have low and stable latency).
The current defaults are for everyone's convenience unless they are temporarily for me during testing / alpha. Even at the current size settings they are only 1/4 of what I need them for my screen resolution which is 2560x1600. They will remain this way for a while. If anyone has code for screen resolution detection I can make it switch between various screen sizes.
Considering that a dynamic default size would only ever be selected once the first time a user logged in with the addon, it seems a bit silly to allocate resources to guessing what a good size for each resolution might be. I run at 1600x1050 resolution, and the default size of Grid2 is much smaller than I need, although it is an improvement over the microscopic default size of Grid. Just pick a reasonable default size, and make sure the configuration UI is intuitive enough that people can figure out how to adjust the size; it only needs to be done once, and the "right size" will be different for everyone based on screen resolution, UI scale, visual acuity, and aesthetic tastes. The current default size is probably fine.
As a tank, i guess 30 yards are fine and 40 for healers like already said.
It is like some sort of a ready check, where is everybody and can I pull some mobs. Maybe the instanze maps make this obsolete, but I always thought range alpha in Grid makes it a little easier.
will be watching this addon though, grid kept throwing errors (even if it was still usable) with 3.2 and i was getting major tired of them.
Somewhat off-topic, but did you make sure you had the latest version of Grid, or report the errors? I haven't seen any errors from Grid.
I added the config for this.