• 0

    posted a message on Grid2 vs Grid - a status update?
    (sorry for the minor thread necromancy)

    Continuing with this thread's original idea of Grid2 vs Grid, why is so much development focusing on classic Grid instead of the new(er) Grid2? There aren't many Ace addons where the original version thrives while the sequel stagnates (Cartographer 3 is was a notable exception).
    Posted in: Grid & Grid2
  • 0

    posted a message on VendorSearch - Adriweb
    Sounds very useful! Thanks!
    Posted in: General AddOns
  • 0

    posted a message on Click2Cast
    Thank you. The project search doesn't parse abandoned addons?
    Posted in: General AddOns
  • 0

    posted a message on Click2Cast
    I love that this addon just disappeared. What gives?
    Posted in: General AddOns
  • 0

    posted a message on WTF just happened?
    These aren't the droids you're looking for. Move along!

    (removed because I can read)
    Posted in: Updaters
  • 0

    posted a message on Baggins Priorities
    What is the point of the bag priority sliders if the section priority sliders don't affect only the bag they're in?

    Take the Fell Blossom for example. Given the following layout:
    • Bag: Trade Goods (priority 10)
      • Section: Herbs (priority 10)
        • Rule: PTSet->Tradeskill.Gather.Herbalism
        • Bag: Consumables (priority 15)
          • Section: Buffs (priority 5)
            • Rule: PTSet->Consumable.Buff

            • Technically, the Fel Blossom could go in either category. It is gathered using Herbalism, but it is also a consumable that gives you a buff. Logically, it should be placed in the Consumables category since it's not used in any tradeskill recipes. I would assume that since the Consumables bag has a higher priority than the Trade Goods bag, it would be placed in Consumables. Unfortunately, this is not true. Baggins seems to ignore the bag's priority and looks only at the section priorities, placing the Fel Blossom in the Herbs section of the Trade Goods bag. If I raise the Consumables->Buffs section priority to 11, the Fel Blossom moves to that section.

              This seems like a problem to me. Or perhaps I just don't quite understand how the priorities are intended to work.
            Posted in: AddOn HELP!
          • 0

            posted a message on wowace.py - lightweight, cross-platform addon updater
            Incoming bug report!

            Running gui.py results in an error:
            Exception in thread Thread-1:
            Traceback (most recent call last):
             File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
              self.run()
             File "/usr/lib/python2.4/threading.py", line 422, in run
              self.__target(*self.__args, **self.__kwargs)
             File "gui.py", line 185, in reload_data
              except wowace.urllib.URLError, e:
            AttributeError: 'module' object has no attribute 'urllib'


            changing urllib to urllib2 on that line results in an error further down the code:
            Exception in thread Thread-1:
            Traceback (most recent call last):
             File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
              self.run()
             File "/usr/lib/python2.4/threading.py", line 422, in run
              self.__target(*self.__args, **self.__kwargs)
             File "gui.py", line 190, in reload_data
              except IOError, (errno, strerror):
            ValueError: need more than 1 value to unpack


            Despite the errors, the gui appears and is responsive. Clicking on the "World of Warcraft Addons directory" browse button throws:
            Traceback (most recent call last):
             File "gui.py", line 290, in browse_wowdir
              dlg = wx.DirDialog(self, "Choose your WoW Addons directory:", style=wx.DD_DEFAULT_STYLE | wx.DD_DIR_MUST_EXIST)
            AttributeError: 'module' object has no attribute 'DD_DIR_MUST_EXIST'


            After entering my AddOns directory manually, the addons show in the Install tab, but there is no scroll bar on the list. Paging up and down using the keyboard works fine. To top it all off, the window has no decorations (title bar, close/minimize/maximize buttons, etc). Other than that, excellent utility! I've been using the command line up to this point since I just now realized it had a gui.

            I'm using Python 2.4.4 (#1, May 26 2007, 08:28:55) with wxPython/wxGTK 2.6.3.3.
            Posted in: Updaters
          • 0

            posted a message on UnitActionBars
            That sounds wonderful. It's always nice to theoretically work out all the usability issues before implementing a feature (something I wish I did more often) :D
            Posted in: General AddOns
          • 0

            posted a message on UnitActionBars
            Quote from Zuno »

            Possible? yeah, I'm sure it would be. Desirable? maybe, maybe not. A message in the chat window might be less intrusive, yet still get the point across. In many cases, it doesn't work with UAB because UAB doesn't have a plug-in for that add-on, not because that add-on is doing something wrong. If the add-on didn't register with ClickCastFrames, UAB would not even know about it, and then it would be an issue for the add-on, since very few click-casting mods would work with it. UAB, however, currently limits support to add-ons that it knows about (i.e., there is a UAB FrameGroup that matches the frames created by that add-on). What I'm suggesting is that this restriction be relaxed so that if there is a frame that registers with ClickCastFrames, but UAB has no FrameGroup for it, UAB will support it with the default settings, but also give a message in the chat window about UAB not providing full configuration support for that frame.


            Oh, I see. I had made the assumption that UAB would be unable to support any Unit Frames that didn't have proper names, having no way to reference them. If this is an incorrect assumption, then I feel silent failure is a better option without any default fallbacks. If a user wants to use UAB with a particular unit frame, they should get the support addon for it. Then again, this could create a burden on you, having to update each support addon with each new unit frame addon or addon update.

            The kind of issue that I forsee happening with "default support.":
            Lets say that I'm using ArcHUD, and I don't have a UAB addon to support it since I don't feel I have a use for it. I have a UAB action set up to use the MiddleButton on agUF. I also have the MiddleButton set up to do something like "assist," assuming I'm not on an agUF frame. I'm in the middle of combat and I see a party member needs help. I select him and click the middle button somewhere near the middle of the screen. Whoops, it just so happens that I was hovering over the ArcHUD frame when I clicked. Now, instead of assisting, the UAB action frame has popped up and is in the way.

            Is that a reasonable scenario?
            Posted in: General AddOns
          • 0

            posted a message on UnitActionBars
            Quote from Zuno »

            It would be pretty easy to skip un-named frames, but the end-result would be a silent failure. UAB doesn't work for those frames, but you get no indicator that it could not match the frame to any frame group.


            So it wouldn't be possible to present the user with a dialog explaining that they have a unit frame addon installed that isn't compatible with UAB, and that the user should ask the author of the offending addon to fix the code?

            Oh, and before I forget, the TOC file tries to load libs\AceModuleCore-2.0\AceModuleCore-2.0.lua, but that file isn't included in the ZIP (i.e. not listed as an external). It's not an issue for me since I manage dependencies manually, but one of my guild-mates ran into this.
            Posted in: General AddOns
          • 0

            posted a message on UnitActionBars
            In this case, I think the best option would be to skip parsing any frames without a proper name.
            Posted in: General AddOns
          • 0

            posted a message on UnitActionBars
            For me, the problem appears to be ArcHUD. Disabling ArcHUD resolves the issue.

            It appears that ArcHUD does, indeed, create frames with nil names. For example, line 194 of ArcHUD2/Frames.lua:
            local targethud = AH_CreateFrame("Frame", nil, main, {300, 100}, {"TOP", main, "BOTTOM", 0, -50}, nil)


            That first nil is where the name would go. I'll do some tests to see if I can add frame names myself, then perhaps submit a patch.
            Posted in: General AddOns
          • 0

            posted a message on UnitActionBars
            Quote from Archangel »

            Thanks for making the perl compliant addon, however I'm getting this error when trying to use it.

            Error: bad argument #1 to 'find' (string expected, got nil)
            AddOn: UnitActionBars
            File: FrameGroup.lua
            Line: 295
            Count: 1


            I am receiving the same error without using any extra UnitActionBars AddOns. Just agUF.
            Posted in: General AddOns
          • 0

            posted a message on UnitActionBars
            Quote from Zuno »
            If you run any of the other uab action sets, or bring up the buttons on any visible frame, does the close button in the middle of the screen go away?


            Nope. I had started over again and only had the "Heal" set available. I added a new set, "Test". Running the "Test" or "Heal" sets doesn't get rid of the close button, even if I run in on the ToTT frame. After a UI reload the rogue close button is identified as "TesttargettargettargetActionBtnNone". I can only assume that the "HealtargettargettargetActionBtnNone" frame is underneath it (perhaps there's a whole stack that I just can't see).

            I've attached an updated savedvars file.
            Posted in: General AddOns
          • 0

            posted a message on UnitActionBars
            I's all fixed now. I must say, you rock. UAB support for ArcHUD is certainly not something I'd considered before, and is personally not something I'd use, just so you know. :-D

            Edit: Whoops, spoke too soon. After relogging, the UABs work correctly (instead of not showing up), but there is now a persistent close button in the middle of the screen that won't go away when I click on it.

            Edit Again: A /dump GetMouseFocus() reveals the name of the frame as HealtargettargettargetActionBtnNone. I happen to have agUF's ToTT frame hidden, but enabling it (and reloading) doesn't do anything.
            Posted in: General AddOns
          • To post a comment, please or register a new account.