Authors CurseForge

Quote from MSaint

... in the Ace2 version of Grid, GridCore.lua registered for the ADDON_LOADED event also, and if the addon that was loaded later was a Grid module, it registered it. This is missing from the Ace3 port.

Hmm. I didn't encounter this problem with any of the plugins I tested when I removed the ADDON_LOADED watching, but I do have a better idea on how to solve the issue, that will work better anyway.

Quote from Phanx

I've never worked with, or even used, a plugin that added indicators, so I have no idea. It should actually be simpler, though, since you don't need to poke around in AceOO-2.0 anymore.

Ok I think I'm a bit stupid here. With AceOO I could just "extend" GridFrame. How can I do that with Ace3.0 now? I already looked into Ace3.0's API but couldn't find an explanation what the modules really are and how exactly they work.

edit: Ok, the best solution I found is ignoring Ace3 and just manually securehooking every GridFrame method I need. Seems to work.

Okay, so I've got it all working, thanks for your earlier reply. I also encountered the error MSaint was talking about (about module.name), but just commented out the line and it went away. :P

However, I noticed a weird overlay backdrop lingering whenever the frame-layout was set to something with more groups than just By Group 5. Easiest way to see it is to set the alpha on border and background to 0% and set Solo Layout to By Group 5 w/Pets. I can grab a screenshot if you'd like*.

If I comment out this section of GridLayout:CreateFrames():

f.texture = f:CreateTexture(nil, "BORDER")
f.texture:SetTexture("Interface\\ChatFrame\\ChatFrameBackground")
f.texture:SetPoint("TOPLEFT", f, "TOPLEFT", 4, -4)
f.texture:SetPoint("BOTTOMRIGHT", f, "BOTTOMRIGHT", -4, 4)
f.texture:SetBlendMode("ADD")
f.texture:SetGradientAlpha("VERTICAL", .1, .1, .1, 0, .2, .2, .2, 0.5)

..it goes away. But not sure what, if any, that will break. I also had some issues with the range check and name updates, but I hadn't deleted my SavedVariables by then so gonna try it some more.

EDIT: * Look at Stanzillas screenshot below for an example of what I mean.

Quote from MSaint

Second, in the latest version, Grid errors out when loading, at least for me, apparently because after the self.name:match in the modulePrototype:onInitialize method, module.name is empty for the first round of modules (GridLayout, etc.). Actually, the fix for this that I used to get things going was simply to change references to module.name where I didn't want the long version to module.moduleName, to which AceAddon DOES NOT prepend the parent name and underscore. At least, this can be used for creating the namespaces so that they match the old system (for the debug options name and text I used module.moduleName or module.name).

The module name is now pulled from moduleName. Thanks for the tip.

Quote from MSaint

I hope I'm being more helpful than I am bothersome.

The more eyes on it, the better.

Quote from Stanzilla

I can't seem to get rid of this background here, background color is set to black with alpha 0.

Is this a regression from Ace2 Grid?

I don't think it's currently possible to remove that background through the UI.

From GridLayout.lua:

-- create bg texture
f.texture = f:CreateTexture(nil, "BORDER")
f.texture:SetTexture("Interface\\ChatFrame\\ChatFrameBackground")
f.texture:SetPoint("TOPLEFT", f, "TOPLEFT", 4, -4)
f.texture:SetPoint("BOTTOMRIGHT", f, "BOTTOMRIGHT", -4, 4)
f.texture:SetBlendMode("ADD")
f.texture:SetGradientAlpha("VERTICAL", .1, .1, .1, 0, .2, .2, .2, 0.5)

Quote from Greltok

Is this a regression from Ace2 Grid?

Sorry, it is a regression.

Quote from Stanzilla

I can't seem to get rid of this background here, background color is set to black with alpha 0.

Fixed in r1336.

Quote from Stanzilla

and rangecheck seems to have a problem with the player, I'm always out of range of myself!

I'm not seeing this. Can you send me your saved variables?

Sorry to bring up the module registration again, but here it is. My layout module is now working with the Ace3 port, but I have to do the following to make it work:

GridConfigurableLayouts = GridLayout:NewModule("GridConfigurableLayouts", "AceEvent-3.0", "AceTimer-3.0", "AceHook-3.0")
.
.
.
function GridConfigurableLayouts:OnInitialize()
   if not self.db then
      GridLayout:RegisterModule("GridConfigurableLayouts", GridConfigurableLayouts)
   end
end

When GridLayout does self.super.OnInitialize(), my module has not yet been loaded, and so does not get registered.

My understanding is that this is not affecting Status modules because they are built with a prototype that makes sure it has a db namespace in it's OnInitialize and which adds its options using its RegisterStatus method. Thus registration is taken care of when the module loads, rather than when the parent initializes.

I can CERTAINLY live with having to register my own module. Possibly that is the best solution. I just want you to know that that is how it is working at the moment.

Respecting my above post, I'm thinking this ONLY affects my module for the moment, since there are no other modules out there that will be GridLayout modules (GridDynamicLayouts registers itself as a Grid module directly at the moment). The builtin modules are loading correctly, and GridStatus and GridFrame modules are in a different situation.

So I guess this is the last thing you need to worry about. I assume you will have a lot on your plate for a while.

Some day it would be nice to clean up that detail, maybe, but for now it works.

The Ace3 port seems to be working well now, at least for me. Thank you.

I'm testing r1340 on the 4.0.1 PTR (just the base addon, no additional plugins)

GridStatusAuras is failing to scan any buffs or debuffs due to the auto-detection of the abolish spells (Disease and Curse). Both of these are gone in 4.0 + (and from what I've read unlikely to return).

Because the GetSpellInfo calls to those two spells fails, the BS table isn't set up properly, which cascades into abolish_types and setting up the options. The net effect is that no auras are detected, so you end up with a Grid that knows about things like health, mana and death status but nothing else.

I commented out all references to the abolish detection and buffs and debuffs are now showing correctly.

Given the estimates of the 4.0.1 patch hitting in 2-9 days, I'm not sure it is worth scanning for Abolish based on the version of the game. Personally I'd just ditch them and tell anyone who chooses to run this on 3.3.5 that they're testing a pre-4.0 version.

A patch to remove the offending bits is at

http://nadt.net/patches/GridStatusAuras-removeabolish.patch

If you wish to save a few minutes.

Cheers

Quote from Fonex

GridStatusAuras is failing to scan any buffs or debuffs due to the auto-detection of the abolish spells (Disease and Curse). Both of these are gone in 4.0 + (and from what I've read unlikely to return).

I installed the PTR last night, and noticed this as well. I will compare our changes, and check in a fix later.

Checked in a fix for GridStatusAuras.

I have GridStatusHeals ready to go using the new Blizzard healing API. I just have to decide when to commit it, as it doesn't work on live.

GridRange has some issues with tooltip scanning using LibGratuity-3.0 on the PTR.

Most importantly, unit buttons aren't being created on PTR. I haven't had chance to figure out why yet.

Quote from Greltok

GridRange has some issues with tooltip scanning using LibGratuity-3.0 on the PTR.

The issue is that SetSpell() was renamed to SetSpellBookItem(). This will require a fix to LibGratuity-3.0.

Quote from Greltok

Most importantly, unit buttons aren't being created on PTR. I haven't had chance to figure out why yet.

This is because SecureGroupHeaderTemplate's initialConfigFunction behavior changed. I'm still trying to grok the changes.

Quote from Greltok

I have GridStatusHeals ready to go using the new Blizzard healing API. I just have to decide when to commit it, as it doesn't work on live.

I'll probably commit this in a day or two. Grid (Ace3) will still load on live once it's in, but heals won't be shown.

Quote from Greltok

GridRange has some issues with tooltip scanning using LibGratuity-3.0 on the PTR.

This has been resolved in LibGratuity-3.0 r42.

Quote from Greltok

Most importantly, unit buttons aren't being created on PTR. I haven't had chance to figure out why yet.

Unit buttons are now created on PTR, but not in combat. This obviously still needs work.

I've had a few problems come up when testing the latest version on Beta. Here are a couple:

1) The timing of module registration rears its head again. When GridRoster gets enabled (for me), it does not yet have it's db set up. This results in some errors. Quick fix is adding in self.super.OnInitialize(self) to GridRoster's OnInitialize() method. Since the current module registration system is broken, I wonder if it wouldn't just be easiest to go over to having the modules ALWAYS just call the registration function themselves and do away with the code that is not working properly?
2) LibHealComm is broken because there is no update to cataclysm spells and talents. Every time it initializes for a class that no longer has some spell that formerly existed, it errors out. I assume this problem will be taken care of in Greltok's updated GridStatusHeals.

I have some time, so I will keep playing with this and post any potentially useful info I come up with.

Quote from MSaint

2) LibHealComm is broken because there is no update to cataclysm spells and talents. Every time it initializes for a class that no longer has some spell that formerly existed, it errors out. I assume this problem will be taken care of in Greltok's updated GridStatusHeals.

The new GridStatusHeals will address this. I will commit it tonight.

As far as I know, LibHealComm has been EOLd for 4.0.