Authors CurseForge

Hi there,
I am trying to share my grid layout with a friend. I was able to locate my grid.lua file in my C:/Users/<myusername/AppData/Local/VirtualStore/Program Files (x86)/World of Warcraft/WTF/Account/<myaccount>/SavedVariables

However, this file path does not seem to exist for my friend. He got through the whole thing (viewing hidden files and all) up until he opened the Virtual Store and had no folders inside. We are both using Windows 7 x64 OS.

We attempted to drop the grid.lua into his normal World of Warcraft/WTF/Account/<his account>/SavedVariables but it had no effect on the appearance of his grid. A search for his old grid.lua with his old configuration turned up nothing.

My question: where should we place the grid.lua file so he is able to see my grid setup? Is there a way to force grid to look at a specific file path for its configuration/settings? Or is there a way to determine where grid is looking from the in game grid menu or some slash commands?

Thanks!

Quote from Mists

I've tried the alpha and works fine except one thing: when I'm crowd controlled (fear, sheep etc), everybody around shows out of range. This is very frustrating since I would normally use the time I cannot control my character to plan what I will do first when I'm back to normal again. Which, being as I play a healer, means most likely healing someone around, and not being able to tell at a glance who's in range is severely limiting the judgment of the situation.

Apologies if this is simply due to the range module overhaul, but I fear it's due to how the Blizzard API works, so I guess I just wanna highlight it early if that's the case and you have not noticed yet.

Seeing as the new Grid release exhibits the same behaviour as the alpha I highlighted before, I suppose it's intended?

That's the expected behavior of the UnitInAnge API, yes. The general purpose of a range check is to show who you can heal; if you're a sheep, you can't cast any heals, so it's reasonably accurate to show everyone as out of range of your heals.

But, as has already been mentioned, if you need multiple-range checking or you prefer the old spell-based API methods, you're free to use the GridStatusMultiRange plugin.

Quote from Phanx

The general purpose of a range check is to show who you can heal; if you're a sheep, you can't cast any heals, so it's reasonably accurate to show everyone as out of range of your heals.

I thought the general purpose of a range check is to show who's in range... :p

Anyway not gonna argue, I'll just use the plugin.

hi, my AV layout should look sth like this
12345
678
but

GridLayout:AddLayout("By Group 40", {
    [1] = {
        groupFilter = "1,6",
        sortMethod = "INDEX",
        groupBy = "GROUP",
        unitsPerColumn = 10,
        maxColumns = 1,
    },
    [2] = {
        groupFilter = "2,7",
        sortMethod = "INDEX",
        groupBy = "GROUP",
        unitsPerColumn = 10,
        maxColumns = 1,
    },
    [3] = {
        groupFilter = "3,8",
        sortMethod = "INDEX",
        groupBy = "GROUP",
        unitsPerColumn = 10,
        maxColumns = 1,
    },
    [4] = {
        groupFilter = "4",
        sortMethod = "INDEX",
    },
    [5] = {
        groupFilter = "5",
        sortMethod = "INDEX",
    },
})

won't work.
what have i done wrong?

You should really spell out in detail what you mean by "won't work". There are literally thousands of ways of stuff failing, and unless the gods of grid come by themselves (which probably really will happen here ^^), you'd need to supply details for the rest of us to help you.

sry, "wont work" was quite unspecific :/

first: if i choose this layout i'll get 6times

FrameXML\SecureGroupHeaders.lua:429: attempt to index local 'groupingOrder' (a nil value):

and group 67 which should be below 123 aren't appearing at all. sometimes grp 8 is there, sometimes not :/

The error message is telling you exactly what's wrong. When you specify a "groupBy" attribute, you must also specify a "groupingOrder" attribute. Your code specifies groupBy, but not groupingOrder.

i'm feeling quite stupid :(

but i thought, because of the error coming from another lua an "groupingOrder" not being mentioned in the gridlayoutlayouts.lua, that it was something else.

groups 6+7 and the last player of grp2 are still missing btw.

Heya,

I just posted a bug report for Grid: groups with multiple columns don't align correctly, ever (not groups that could have multiple columns, only groups that actually DO have multiple columns). Most people don't use groups with multiple columns, I know.

I realize the normal thing to do is to just post the ticked and not post here, sorry for that. The reason I'm posting is selfish, and, I realize, not your problem. It's that this particular bug has a big impact on my module, where groups with multiple columns / rows come up all the time and display completely wrong at the moment.

I have a heavily tested alpha that is really ready for beta, but I can't reasonably tag it beta and syndicate knowing that it is going to constantly display stuff wrong. So I have an especial interest in this bug being fixed.

I fully tracked down the bug and included that info and how to fix it in the bug report.

If my posting here about the bug is too annoying, well, I suppose I won't be offended if I get deleted or flamed.

IMPORTANT EDIT: I've been looking at this closely, and realized that what was done that creates this bug (hooking SetPoint and clearing all points each time a point is set) was done to work around another bug . . . so I suppose this should be ignored for now. I'm working hard to figure out the bug underneath this bug.

Ok, figure this out. Was a real pain. The code for the secure group headers has changed from what they are giving us (confirmed thru stack traces). Points are only being cleared on UNUSED unit frames on update, so if the settings for a header change such that points need to be updated on unit frames that are actually in use, well, the old points aren't cleared.

Fixing this eliminates the need for hooking SetPoint on the unit frames and eliminates the whole problem.

The best fix I have found is to set an OnAttributeChanged script on the headers, and if the attribute being changed is one that affects the points, I clear the points on the child unit frames:

local function GridLayout_OnAttributeChanged(self, name, value)
   if name == "point" or name == "unitspercolumn" or name == "columnanchorpoint" then
      self:ClearPoints()
      if self:IsVisible() then
         SecureGroupHeader_Update(self)
      end
   end
end

and of course:

function GridLayout.prototype:ClearPoints()
   local count = 1
   local uframe = self:GetAttribute("child" .. count) 
   while uframe do
      uframe:ClearAllPoints()
      count = count + 1
      uframe = self:GetAttribute("child" .. count)
   end
end

I set the script for each header in GridLayout:CreateHeader()

I have to run to catch a plane now, so I can't do a whole ton of testing or anything now. I'll a very thorough look at it when I get home tomorrow.

I do hope this is helpful.

Hmm, when I said it was different from "What they are giving us" that was based on downloading what is posted at:

http://us.media.blizzard.com/wow/interface/WoW_Interface_enUS.zip

But I looked in Tekkkub's GitHub repo of the blizzard UI and the SecureGroupHeaders.lua there shows exactly the change I mentioned above, i.e. the call to ClearAllPoints was moved into the section that processes only the unused unit frames.

I'm really not sure where I should be getting the correct source, but anyway what I posted above stands.

I'm going to log in now and test it as thoroughly as I can to make sure that adding the above and removing the existing hooks doesn't cause any problems / regressions.

I'm not part of the Grid team. But solving this benefits me for reasons I gave two posts up, so hopefully Phanx won't mind a little unsolicited debugging work and a little clutter in this thread.

I have a few days of semi-vacation, see.

After a fair amount of testing I made this work with one change. The call to SecureGroupHeader_Update() was causing tainting. After fixing that, I tested it in combat, inviting and removing players (in and out of combat), changing layouts. No problems with anything that I could find, and the old anchoring problems are completely gone.

Here are my exact changes:

-- GridFrame.lua : just commented out the hooks (lines 208-210).

-- GridLayout.lua :
-added the following function at line 38:

local function GridLayout_OnAttributeChanged(self, name, value)
   if (name == "point" or name == "unitspercolumn" or name == "columnanchorpoint") then
      GridLayout:Debug("GridLayout_OnAttributeChanged : Clearing All Points for " .. self:GetName())
      self:ClearPoints()
      if self:IsVisible() and self:CanChangeAttribute() then
         self:SetAttribute("dummy_attribute", "dummy_value") -- to force an update without tainting
         --  the above seems better than Hide/Show, but that would work as well
      end
   end
end

-Added the following at line 58 (was 47):

   header:HookScript("OnAttributeChanged", GridLayout_OnAttributeChanged)

-Added the following function at line 126 (was 113):

function GridLayout.prototype:ClearPoints()
   local count = 1
   local uframe = self:GetAttribute("child" .. count) 
   while uframe do
      -- GridLayout.Debug("GridLayout.prototype.ClearPoints :  Clearing points for " .. uframe:GetName())
      uframe:ClearAllPoints()
      count = count + 1
      uframe = self:GetAttribute("child" .. count)
   end
end

And here I am yet again. Driving home a little while ago it occurred to me that I was going about this the wrong way. So I fixed it. Then I grouped up, fought, played with layouts, etc., . . . to make sure it works.

What I realized is that it's ridiculous to hook OnAttributeChanged for this problem. It slows things down whenever an attribute is set and it runs the complete updating of the frame TWICE every time a point needs to change.

Instead what I did is to create GridLayout.prototype:SetLayoutAttribute() and every time an attribute is set that affects or could affect anchoring, I call that instead of calling SetAttribute directly.

The change to GridFrame is the same, i.e. comment/remove the hooks.

The change to GridLayout is now to add the following function:

function GridLayout.prototype:SetLayoutAttribute(name, value)
   if (name == "point" or name == "unitspercolumn" or name == "columnanchorpoint") then
      GridLayout:Debug("GridLayout.prototype:SetLayoutAttribute : Clearing All Points for " .. self:GetName())
      local count = 1
      local uframe = self:GetAttribute("child" .. count) 
      while uframe do
         -- GridLayout.Debug("   Clearing points for " .. uframe:GetName())
         uframe:ClearAllPoints()
         count = count + 1
         uframe = self:GetAttribute("child" .. count)
      end
   end
   self:SetAttribute(name, value)
end

I use that function instead of SetAttribute on lines 108, 114, 119, 174, 909-911, 918, 926-928, and 935. That is, anywhere we might be affecting anchor points of frames.

Much cleaner, much more efficient.

Hopefully this concludes my spamming of this thread.

Attribute names are generally camelcase ("unitsPerColumn" instead of "unitspercolumn") in both Grid and Blizzard's own UI code, so unless you're lowercasing them somewhere else, the code you posted will only catch the "point" attribute. If you're using lowercase attribute names in your layout/plugin, you should change them to camelcase for consistency.

I went ahead and committed your changes, with camelcase attribute names. Thanks very much for all your time and hard work on this issue!

Also, the repo is open, so feel free to commit any fixes if need be.

Yeah, actually, the names of attributes are case insensitive and all get lc'd by SetAttribute(), so the line before should be name = string.lower(name), rather than putting the strings in with the camelcasing.

Sorry, I grabbed the code from when it was in the OnAtributeChanged hook, saw the problem later and never corrected it here. In OnAttributeChanged all attribute names come through in lc for the reason given above.

Btw, it actually took me a while to even notice the mistake because, as it happens, even without the change it fixed the problem. As things stand, if you look at where point, unitsPerColumn, and columnAnchorPoint are set in GridLayout, the only time you really ever need the points cleared is when a layout is loaded. Since "point" always gets set, that was happening correctly. If you had no concern at all about saving problems later, you could even just clear the anchorpoints once after loading a layout before showing the group, and everything would be good . . . for now.

r1435, USEnglish client/server, WoW 4.0.6 live.

Clicking anywhere along the border of the party/raid frames of Grid strangely brings up the options window. It happens consistently within combat or not.

Is this as designed (I really hope not)? Or is there some option I'm missing? If its as designed, what code can be modified to stop this behavior? Using Clique for heal-spell casting, this happening in the middle of a raid is very problematic.

Update: this problem occurs when the tab on the top left of the frame showing "Grid" is disabled.

Further update: the frame-positioning-bug change submitted by the previous poster that's in r1435 is itself buggy.

Have a 10-man raid with the the default layout. Have 9 people in the raid with the 10th slot in the lower right side of the frame open. Then later invite a 10th person to fill out the raid...when in combat.

The person invited "takes over" the slot the previous person in slot 9 was in. That original slot-9 person partially overlaps the new invite and has 1/2 of its frame in slot 10 (not completely filling it up). That original slot-9 person's frame is completely inaccessible from then on in combat or out of it, until you relog. The name is not shown, no indicators appear and Clique cannot access it. No errors are thrown.

Is it technically possible (through a plug-in) to add focus or boss frame to Grid layout?
(or target's target frame maybe..)
I had this question back in the ages when I was healing the Dreamwalker encounter. I realized I can't heal properly with my druid when the target isn't on my Grid. lol

Though there isn't such an encounter in current raid content, it can still be a convenient feature for smiting priest, tank healing using boss' target macro, or monitoring certain buffs/debuffs.

Thanks in advance.