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.
- Registered User
Member for 13 years, 8 months, and 6 days
Last active Wed, Nov, 20 2013 10:35:23
- 0 Followers
- 55 Total Posts
- 0 Thanks
Sep 27, 2010Respecting 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.Posted in: Grid & Grid2
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.
Sep 27, 2010Sorry 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:Posted in: Grid & Grid2
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.
Sep 25, 2010Heya.Posted in: Grid & Grid2
I hope I'm not being intrusive here; I have a couple of concerns / comments about the Ace3 port.
First off, I've been studying the AceAddon code, and it looks as though addons are initialized as soon as the ADDON_LOADED event is fired. GridCore registers addons in it's OnInitialize method, but I see no guarantee that all the modules have loaded at that point. Because of this, 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. I'm sure there are things I don't know about how addons are loaded, so maybe I am worrying about something absurd here. But I thought I'd mention it just in case. Rather than registering for the ADDON_LOADED event, perhaps another option might be to register modules when OnModuleCreated is called?
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).
I hope I'm being more helpful than I am bothersome.
Sep 23, 2010Heya. I tried to run the current Grid Ace3 branch and ran into a couple of snags. First off, when I try to load the options pages it fails with an error. I was able to fix this by changing GridCore.lua:169 toPosted in: Grid & Grid2
which puts the dual spec profile options in the profile options group, where they find the handlers they need. Not the only solution, but I wanted to get this running so that I can start updating my own module.
I also found that GridStatusHealth.lua still has a couple of calls to TriggerEvent that need to be changed to SendMessage on lines 298 and 341.
Now it works.
Probably you were aware of all of this, sorry if that is the case.
Thanks for sharing the branch with us so that the rest of us can get started updating our modules.
Sep 20, 2010Posted in: Grid & Grid2Quote from AlakabasterWorks well enought :) The button to add a name to group3 added the same name to group2 as well, you might want to check that. Everything else worked as expected, very nice.
Well, actually, the buttons are all working correctly. What most likely happened is that you had added your target to group 2, erased it, forgot to hit <enter>, and added your target to group 3. Then the name would pop up in both, but only because the deleting in group 2 was never registered and the page was refreshed when you added your target to group 3. Very annoying, but I see no way around having to hit <enter> every time you edit in a text box in Waterfall. I'll look more closely. Maybe there is some way around this.
Quote from AlakabasterCan you influence the order of the people in a group? I did put myself into group1, which worked, but I'd like to be shown as the first person (i.e. on top in grid, since my groups are vertical). Is that possible?
Unfortunately, the secure group frames will not respect the order of a name list. They can be set to sort on raid position or on name, nothing else. One thing that I do for myself is to set the unit frame border color for "Self:Me" to be a distinct color, so that I stand out in the grid.
Sep 19, 2010Thanks very much, Alakabaster. The bug that caused your error has been fixed.Posted in: Grid & Grid2
I have also added one of your suggestions: there are now buttons to add your current target to a name list (assuming they are in your raid or party). I think you are right that there are too many un-typable names out there.
If you are willing to give the current version a try, it would be much appreciated.
Sep 13, 2010I just realized that, because my project is categorized as experimental, it does not show up in a simple search on this site. Here is the URL:Posted in: Grid & Grid2
Sep 13, 2010Hello folks,Posted in: Grid & Grid2
This is a highly configurable in-game layout creation tool for Grid.
It includes filters to create layouts organized by role (tank, melee, healer, ranged), raid group, name lists, out of zone, offline status, guild, etc., . . . Filters can be mixed in any combination. The module also offers class filters for pet groups. Gives the option to turn off repetitions (for example, tanks will not appear in raid groups if you have a tank group first). It also offers optional configurable colored borders around groups.
This project is now in beta and is no longer experimental.
Apr 23, 2009OOOOOHHHHH!!! This would be SUCH a fantastic change! One of the major complaints from our officers is that security settings get lost and lists have to be resync'd etc., . . .Posted in: Raid AddOns
We would be very much in favor of this change. Having the security info in the guild info would be perfect for us.
- To post a comment, please login or register a new account.