I'm currently experiencing an issue as of SVN rev 27848 where the AddOn is not binding my chosen activator upon login. I'm using this as a (most excellent) replacement for the venerable BeneCast. So I have the "Heal" action set to show when I use the MiddleButton on a unit frame. The problem is, I have to go into the AddOn's configuration and middle click on the "Set Activator" button every time I log in. Mind you, the interface shows that "MiddleButton" is the activator even though it doesn't work after logging. I even checked the saved variables, and it is indeed correctly saving my choice of activator.
Wonderful AddOn, I might add!
I encountered this issue tonight while trying to enable support for oRA2. I checked in another update that fixed the issue for me in this scenario. If you were still having the problem after the last update I did, try the latest version.
I encountered this issue tonight while trying to enable support for oRA2. I checked in another update that fixed the issue for me in this scenario. If you were still having the problem after the last update I did, try the latest version.
This has been fixed for me -- I believe by one of yesterday's commits.
Some additional changes that are coming in the next couple days. I just need a bit more testing to make sure they are working well enough :)
Support additional layout styles as plug-ins. This is mostly incorporated already with the latest SVN code. Finishing up the pyramid style. Will be fully completed with the next SVN update. Another style in the works is a rectangle. With this one, you define the bounds of the rectangle, and the buttons show up on the outside edges of that rectangle. When combined with anchoring to the unit frame, instead of the cursor, shows the buttons around the edges of a frame without disturbing the look of the frame.
Support the ability to have a distinct set of actions for hostile vs. friendly units. This is implemented as a single set of hostile actions that show up when the unit is a hostile unit, regardless of the unit group (party, pet, target, etc.). Action buttons switch from normal set of actions to hostile set while open as well.
Support the ability to define a layout for each unit group, as well as for each frame group. Allows fully configurable layout appearance, scaling, and positioning based on which set of frames the action buttons show up for. Frame group settings are checked first, then unit group settings, then global default settings. For example:
Grid frames: buttons show up using the square layout style, relative to the center of the clicked grid unit, and closing after each click.
oRA2 MainTank frames: buttons show up using the bar style flowing down, and stay open after each click.
Some additional changes that are coming in the next couple days. I just need a bit more testing to make sure they are working well enough :)
Support additional layout styles as plug-ins. This is mostly incorporated already with the latest SVN code. Finishing up the pyramid style. Will be fully completed with the next SVN update. Another style in the works is a rectangle. With this one, you define the bounds of the rectangle, and the buttons show up on the outside edges of that rectangle. When combined with anchoring to the unit frame, instead of the cursor, shows the buttons around the edges of a frame without disturbing the look of the frame.
Support the ability to have a distinct set of actions for hostile vs. friendly units. This is implemented as a single set of hostile actions that show up when the unit is a hostile unit, regardless of the unit group (party, pet, target, etc.). Action buttons switch from normal set of actions to hostile set while open as well.
Support the ability to define a layout for each unit group, as well as for each frame group. Allows fully configurable layout appearance, scaling, and positioning based on which set of frames the action buttons show up for. Frame group settings are checked first, then unit group settings, then global default settings. For example:
Grid frames: buttons show up using the square layout style, relative to the center of the clicked grid unit, and closing after each click.
oRA2 MainTank frames: buttons show up using the bar style flowing down, and stay open after each click.
Uploaded these changes, and the uabLayout_Pyramid plug-in
I'm having another, more serious, issue now with r28857. When creating a new action set I receive a spamming of lines similar to the following in my chatbox:
Unable to register frame : aUFgroupgroup5UnitButton1 (no unit) in group : partyraid
Unable to register frame : ArcHUDFramePlayerNamePlate (player) in group : player
All the lines dealing with aUF have "partyraid" at the end. The group numbers vary 1 through 8. I am using ArcHUD, but disabling it doesn't help (although the error lines about ArcHUD disappear). An action set will work fine until I log out or reload the ui. After that, all I get is the red close button, without any action buttons, in the middle of the screen (instead of centered on my cursor, as it should be) when I try to activate the set. New sets created after logging in/reloading ui work as expected until I log out/reload ui again. I have cleared the savedvars twice, but the issue still crops up immediately.
I have attached my UnitActionBars.lua savedvars file. This was copied while the game was still running. Action sets "Heal" and "Test" do not work. Action set "Test2" worked at the time that I copied the file.
I ran into a problem with the cancel button showing up in the middle of the screen with no other buttons last night when working on a different issue, but it was on initial login/UI reload.
Buttons are associated with unit frames through something I'll call a "control button". When a frame registers with ClickCastFrames, UAB attempts to identify the frame group for that frame. If it can't find the matching frame group, it doesn't register the frame.
Assuming it finds a matching frame group, it tries to use an available "control button". If there are no available control buttons, then you get the error you mentioned. You shouldn't get the error unless the number of control buttons is too low for the frames that register and match the expression for some frame group.
The fact that you are getting the error means that UAB is matching up the frames with some frame group, but does not have a control button for that frame. Looks like the first player in group 5 of the raid group for aUF, and the player frame (or one of the player frames) for ArcHUD.
I've run UAB in a raid, and not encountered these errors, so it's likely that more frames are matching some frame group expression than should match, causing valid frames to NOT match.
I'll be posting an update this afternoon to address a few issues, including the "X" in the middle of the screen problem based on how I saw it last night.
I'll take a look at the agUF frame matching expression, and take a look at ArcHUD to see what frames register with ClickCastFrames.
Finally, are there any other unit frame add-ons that you are using? oRA2? Grid? other raid frames or MT/PT frames?
One other thing to check after talking with a friend about past issues they have had.
Make sure you don't have another click-casting add-on loaded (Click2Cast, Clique, etc.). Even if you don't bind anything using the other add-on, it can interfere with uab behavior (and vice-versa).
Unable to register frame : aUFgroupgroup5UnitButton1 (no unit) in group : partyraid
Unable to register frame : ArcHUDFramePlayerNamePlate (player) in group : player
I found a place where these errors would be generated when you create a new action set through the UI (fubar or GUI dialog). I'll address this issue before I post the update.
These errors, however, are not really related to the cancel button in the middle of the screen problem. If that problem persists after the next update, let me know and I'll try again to reproduce it with your configuration.
One thing to take note of. If a set of unit frames are not in the list of frame groups that shows, then uab will not work for those frames. Right now, there is no message being displayed when uab encounters a frame it does not support.
I plan to change this so that it will only silently ignore frames that it knows about, but you have selected to disable uab for (the frame group is there, but disabled). The behavior for unknown frames will be based on a setting: silently ignore, report a warning to the chat frame, or dynamically support with the settings for the unit group associated with the frame. The original behavior of uab was to support a fixed number of frames for each unit group. This caused some significant limitations, so frame groups were introduced. Unfortunately, this had the side effect that uab (currently) has to know about every type of unit frame that you want to support.
This is part of the cause of the errors you saw - some legacy code was not taking into account to validate that the unit frames that had previously registered with ClickCastFrames were, in fact, part of some frame group. The latest update validates the frames in this case as well.
The reason I mention all this is that a possible reason for uab not working is that with the prior version, the ag_UnitFrames support forgot to include support for the aguf raid frames (fixed in the latest update), and there currently is no plug-in for AceHUD (though it would be easy to add it). This is why the errors were showing up.
The other issue with the cancel button only showing up in the middle of the screen is one that I have heard before, but have not been able to reproduce yet in the same scenarios as people report it. I hope this update fixes it by accident ;)
Couple other notes on this update: Now using standard cooldown timers and item counters. Trying to get cyCircled support, but having a couple skinning issues as yet. I'll post a cyCircled plug-in (or an extra file inside uab) so that you can see how it looks now (some look fine, others don't).
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.
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
Ok, I won't build that one yet... easy enough to support it, if you do eventually want it, but I won't mess with it yet.
Quote from kccricket »
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.
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?
I had nearly this exact problem night before last, and fixed it for me, but it appears it's not fixed for you (which means it's likely to come back soon for me too - pesky things). I'll run with your saved-vars file again to see if I can reproduce it.
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).
Problem appears to be related to support for the Blizzard frame group. I initially had Blizzard support disabled, and was using ag Unit Frames, but could not see the problem happen. I enabled support for Blizzard frames, logged out, disabled aguf, logged back in, and the problem showed up.
Fixed. Problem was due to having no frames (from an enabled frame group) registering for a specific unit group. For example, the Blizzard frames don't have a focus frame or ToT Target frame, so those cancel buttons were never properly initialized, causing them to show by default.
This update also includes support for layouts to hide the cancel button.
Also adds support for class filters on all standard unit status values.
cyCircled support (first cut at it) is there as well (checked in last night).
this is a really great mod, as a disabled wow player, this mod helps bring back functionality I lost in wow 2.0 THANK YOU!
I hate to add to the pile of requests, but is there anyway you could add support for perl classic unitframes? I know there is a lot of different raid frames out there so adding support to all of this is daunting/not possible. I have no problem using clique with perl unitframes, perhaps whatever hook clique uses UnitActionBars could also? Thank you again for a awesome addon.
this is a really great mod, as a disabled wow player, this mod helps bring back functionality I lost in wow 2.0 THANK YOU!
I hate to add to the pile of requests, but is there anyway you could add support for perl classic unitframes? I know there is a lot of different raid frames out there so adding support to all of this is daunting/not possible. I have no problem using clique with perl unitframes, perhaps whatever hook clique uses UnitActionBars could also? Thank you again for a awesome addon.
Yep, I'll post a Perl Classic plug-in later today. Thanks for the support :)
Do you have any plans to add the functionality to this mod where the bars are always up like how group buttons or party bars currently is? Thats how my friends wife is used to playing as our healer. If not no big deal, I'll just have her stick with partybars.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I encountered this issue tonight while trying to enable support for oRA2. I checked in another update that fixed the issue for me in this scenario. If you were still having the problem after the last update I did, try the latest version.
Support for status checks for missing buffs (AB/AI, Fort, Shadow, MOW/GOW, Spirit) is available through the uabStatus_MissingBuffs add-on.
This has been fixed for me -- I believe by one of yesterday's commits.
Uploaded these changes, and the uabLayout_Pyramid plug-in
All the lines dealing with aUF have "partyraid" at the end. The group numbers vary 1 through 8. I am using ArcHUD, but disabling it doesn't help (although the error lines about ArcHUD disappear). An action set will work fine until I log out or reload the ui. After that, all I get is the red close button, without any action buttons, in the middle of the screen (instead of centered on my cursor, as it should be) when I try to activate the set. New sets created after logging in/reloading ui work as expected until I log out/reload ui again. I have cleared the savedvars twice, but the issue still crops up immediately.
I have attached my UnitActionBars.lua savedvars file. This was copied while the game was still running. Action sets "Heal" and "Test" do not work. Action set "Test2" worked at the time that I copied the file.
Any ideas?
Buttons are associated with unit frames through something I'll call a "control button". When a frame registers with ClickCastFrames, UAB attempts to identify the frame group for that frame. If it can't find the matching frame group, it doesn't register the frame.
Assuming it finds a matching frame group, it tries to use an available "control button". If there are no available control buttons, then you get the error you mentioned. You shouldn't get the error unless the number of control buttons is too low for the frames that register and match the expression for some frame group.
The fact that you are getting the error means that UAB is matching up the frames with some frame group, but does not have a control button for that frame. Looks like the first player in group 5 of the raid group for aUF, and the player frame (or one of the player frames) for ArcHUD.
I've run UAB in a raid, and not encountered these errors, so it's likely that more frames are matching some frame group expression than should match, causing valid frames to NOT match.
I'll be posting an update this afternoon to address a few issues, including the "X" in the middle of the screen problem based on how I saw it last night.
I'll take a look at the agUF frame matching expression, and take a look at ArcHUD to see what frames register with ClickCastFrames.
Finally, are there any other unit frame add-ons that you are using? oRA2? Grid? other raid frames or MT/PT frames?
Make sure you don't have another click-casting add-on loaded (Click2Cast, Clique, etc.). Even if you don't bind anything using the other add-on, it can interfere with uab behavior (and vice-versa).
I found a place where these errors would be generated when you create a new action set through the UI (fubar or GUI dialog). I'll address this issue before I post the update.
These errors, however, are not really related to the cancel button in the middle of the screen problem. If that problem persists after the next update, let me know and I'll try again to reproduce it with your configuration.
One thing to take note of. If a set of unit frames are not in the list of frame groups that shows, then uab will not work for those frames. Right now, there is no message being displayed when uab encounters a frame it does not support.
I plan to change this so that it will only silently ignore frames that it knows about, but you have selected to disable uab for (the frame group is there, but disabled). The behavior for unknown frames will be based on a setting: silently ignore, report a warning to the chat frame, or dynamically support with the settings for the unit group associated with the frame. The original behavior of uab was to support a fixed number of frames for each unit group. This caused some significant limitations, so frame groups were introduced. Unfortunately, this had the side effect that uab (currently) has to know about every type of unit frame that you want to support.
This is part of the cause of the errors you saw - some legacy code was not taking into account to validate that the unit frames that had previously registered with ClickCastFrames were, in fact, part of some frame group. The latest update validates the frames in this case as well.
The reason I mention all this is that a possible reason for uab not working is that with the prior version, the ag_UnitFrames support forgot to include support for the aguf raid frames (fixed in the latest update), and there currently is no plug-in for AceHUD (though it would be easy to add it). This is why the errors were showing up.
The other issue with the cancel button only showing up in the middle of the screen is one that I have heard before, but have not been able to reproduce yet in the same scenarios as people report it. I hope this update fixes it by accident ;)
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.
Ok, I won't build that one yet... easy enough to support it, if you do eventually want it, but I won't mess with it yet.
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?
I had nearly this exact problem night before last, and fixed it for me, but it appears it's not fixed for you (which means it's likely to come back soon for me too - pesky things). I'll run with your saved-vars file again to see if I can reproduce it.
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.
I don't have a fix yet, but at least I can reliably reproduce the situation.
This update also includes support for layouts to hide the cancel button.
Also adds support for class filters on all standard unit status values.
cyCircled support (first cut at it) is there as well (checked in last night).
I hate to add to the pile of requests, but is there anyway you could add support for perl classic unitframes? I know there is a lot of different raid frames out there so adding support to all of this is daunting/not possible. I have no problem using clique with perl unitframes, perhaps whatever hook clique uses UnitActionBars could also? Thank you again for a awesome addon.
Yep, I'll post a Perl Classic plug-in later today. Thanks for the support :)