Go to Page... |
Updated: | 08-05-13 08:50 AM |
Created: | unknown |
Downloads: | 227,481 |
Favorites: | 1,246 |
MD5: |
OPie is a radial action-binding addon: it lets you group actions into rings which appear when you hold down a keyboard or mouse binding. When you release the binding, OPie will perform an action based on where your mouse cursor is.
Use OPie to reduce the amount of clutter on your action bars: rings can contain your abilities, items, professions, battle pets, equipment sets, macros, and raid or world markers. Some rings for common class abilities and professions are included, as is a special quest items ring which automatically makes all of your quest and quest-starting items easily accessible. Other addons may add additional rings; for example, Spade uses OPie rings to let you chose the seeds you want to plant on your farm.
Download OPie today; configure to your liking (/opie), and customize your rings (/opie rings). For more details, see the OPie Guide, the screenshots here, or a YouTube video of OPie in action.
Ring snapshots and tutorial/gameplay videos
You can create snapshots of your custom rings to share with other players; if you like, you can post them in the comments section on this page. Likewise, if you've created a video showing how you use OPie, I would very much like to hear about it.
Bug reports and feature requests
If you encounter any problems while using OPie, or think of useful functionality to add to OPie, use the OPie ticket tracker if possible, or leave a comment here.
File Name |
Version |
Size |
Author |
Date |
Type |
7.3.5.0 |
4kB |
03-04-18 06:32 AM |
Addon |
||
1.3 |
6kB |
09-21-12 06:37 AM |
Addon |
||
1.0 |
1kB |
02-14-11 02:19 PM |
Addon |
Comment Options |
Foxlit |
View Public Profile |
Send a private message to Foxlit |
Find More Posts by Foxlit |
Add Foxlit to Your Buddy List |
04-03-13, 12:02 AM | |
|
Just released OPie Masque if you want to link to it for others wondering where skinning went.
__________________
Retired author of too many addons. Message me if you're interested in taking over one of my addons. Don’t message me about addon bugs or programming questions. |
|
Phanx |
View Public Profile |
Send a private message to Phanx |
Find More Posts by Phanx |
Add Phanx to Your Buddy List |
04-06-13, 01:19 PM | |
A Murloc Raider
Forum posts: 5
File comments: 45
Uploads: 0
|
Subring Problem
So since the latest update, my subring is not remembering what I last had chosen. It always reverts back to whatever is listed 1st in the ring when I log out and back on. Before the last update, when I had chosen some selection that was not the 1st choice in my subring, it would remember it, now it does not.
|
|
daggerz |
View Public Profile |
Send a private message to daggerz |
Find More Posts by daggerz |
Add daggerz to Your Buddy List |
04-06-13, 08:13 PM | ||
|
Re: Subring Problem
__________________
... and you do get used to it, after a while. |
|
|
Foxlit |
View Public Profile |
Send a private message to Foxlit |
Find More Posts by Foxlit |
Add Foxlit to Your Buddy List |
04-17-13, 05:43 PM | |
A Kobold Labourer
Forum posts: 0
File comments: 24
Uploads: 0
|
problem
ive a problem trying to update a custom macro. it doesnt save the updates.
if i try to make a new custom macro i get this error Message: Interface\AddOns\OPie\Meta\RingKeeper.lua:149: Error: No flyout found for ID=%i Time: 04/18/13 01:37:46 Count: 1 Stack: [C]: in function `GetFlyoutInfo' Interface\AddOns\OPie\Meta\RingKeeper.lua:149: in function <Interface\AddOns\OPie\Meta\RingKeeper.lua:123> Interface\AddOns\OPie\Meta\RingKeeper.lua:168: in function <Interface\AddOns\OPie\Meta\RingKeeper.lua:167> (tail call): ? Interface\AddOns\OPie\Meta\RingKeeperConfig.lua:1084: in function `setSliceProperty' Interface\AddOns\OPie\Meta\RingKeeperConfig.lua:558: in function <Interface\AddOns\OPie\Meta\RingKeeperConfig.lua:558> [C]: in function `Hide' Interface\AddOns\OPie\Meta\RingKeeperConfig.lua:944: in function `func' Interface\FrameXML\UIDropDownMenu.lua:710: in function `UIDropDownMenuButton_OnClick' [string "*:OnClick"]:1: in function <[string "*:OnClick"]:1> Locals: (*temporary) = 0 i recognized this error in the last version, but downgrading to lime1 dont resolve it tnx for help! |
|
Zelnia |
View Public Profile |
Send a private message to Zelnia |
Find More Posts by Zelnia |
Add Zelnia to Your Buddy List |
04-18-13, 05:32 PM | ||
|
Re: problem
__________________
... and you do get used to it, after a while. |
|
|
Foxlit |
View Public Profile |
Send a private message to Foxlit |
Find More Posts by Foxlit |
Add Foxlit to Your Buddy List |
04-20-13, 05:17 PM | |
A Kobold Labourer
Forum posts: 0
File comments: 24
Uploads: 0
|
Re: Re: problem
tnx you. i love modding my interface and using addons.
i tried a lot of them almost every addon XD But Opie its my favourite addon. Please keep it up until wow exists =) and maybe u can give some hint to those guys http://www.autohotkey.com/board/topi...-menu-scripts/ they are building a radial menu for windows with a open source scripting language but they are rly far away from opie's "user-friendly" and reliability. Tnx for your work! |
|
Zelnia |
View Public Profile |
Send a private message to Zelnia |
Find More Posts by Zelnia |
Add Zelnia to Your Buddy List |
06-09-13, 08:12 AM | |
|
I just spent a few hours trying to grok how OPie works so that I could try to make the raid targets work for mouseover, falling back to target. From what I can see, the reason why it is more difficult than it would seem to be is because when the ring opens under the mouse, the unit situation changes. When the unit situation changes, the hint function is called again (probably something triggered by the secure button) and then there's no valid mouseover. Does that sound right?
From what I can see in Spade, it gets around all of this by just running /target mouseover every time the ring is triggered, before it opens. Sneaky. That said, I'm not sure how I could integrate that workaround into the raid targets' create. I have this feeling it's something like just adding a set of parameters like "macro","/target mouseover", but I have no idea. Looking at how spell and item work, it looks like they're using the actionMap to make sure hint isn't spammed, but it ends up calling create again and then my eyes glaze over. Have you ever considered supporting mouseover for the raid target ring? Can you help me understand the stuff I'm missing? Thanks. |
|
pelf |
View Public Profile |
Send a private message to pelf |
Find More Posts by pelf |
Add pelf to Your Buddy List |
06-11-13, 05:14 PM | |||
|
As you've noticed, Spade is a bit of an exception: it brings up OPie rings when you click on things in the game world, and changes your target to what you clicked on to open the ring opens. Hijacking the player's target in this way is probably acceptable when they're out of combat and on Sunsong Ranch, but might not be acceptable when the player is in combat with something more dangerous than a kobold. The functionality that Spade uses to run the /target mouseover macro upon opening its OPie ring is not currently supported by the code that handles user-customizable rings, so while Spade's behavior could be replicated in a target marker ring (that would change your target to mouseover when you activate the ring), you'd have to write an addon to do so. This is in part a UI limitation (I'm not sure how to reasonably indicate that an action will be performed when you open the ring, and allow you to customize that action within OPie's Custom Rings panel), and in part a precaution to make importing a ring snapshot a little safer (the on-open action could be a macro that does... well, anything, really). One change that I could contemplate making is to add a whitelist of actions that might be useful when you open the ring, and include that in the custom rings UI; something along the lines of a "When you open this ring:" dropdown, with "Do nothing" and "Target mouseover" as some of the options. I'm not sure how useful that would be, and I don't particularly like the idea of changing a player's target while they're in combat (trying to, say, mark up the next pull). What do you think would be useful/reasonable? [There's a slight chance I'm misinterpreting things, and what you would actually like to do is to create a slice that'd set a target icon on your mouseover unit if it exists; in which case, use a custom macro: raid targets are not protected, so a simple /run with any logic you desire would do. OPie would not be able to tell what your macro actually does (so no marker-specific indication feedback), but that's probably not a big deal.]
The hint functions are for the second purpose: they return information about just what will happen if you ask ActionBook to actually perform that actionId, but are not actually called when it's time to perform the action. The ActionBook:create calls ask ActionBook to allocate a new actionId, and provide both the information necessary to perform the action, and the hint function used to tell the player what the action will do. There are several internal action types: ActionBook can (insecurely) call a custom Lua function (used in e.g. DataBroker integration), or perform an action using the SecureActionButtonTemplate (spells, items, etc). Another action type is "collection": a list of other actionIds with some additional metadata, and is somewhat similar to how spell flyouts are an actions that contain a number of other actions. OPie displays ActionBook's collection actions as rings, and can perform an actionId specified in that collection's metadata when you open those rings. If you wanted to customize the on-open action, you'd need to find the location where OPie creates/updates the collection used by the ring, and add the __openAction=actionId key/value pair to its description.
__________________
... and you do get used to it, after a while. |
||
|
Foxlit |
View Public Profile |
Send a private message to Foxlit |
Find More Posts by Foxlit |
Add Foxlit to Your Buddy List |
06-12-13, 05:58 PM | |
|
Whew. Thanks for the response. There are a lot of moving parts, aren't there.
The issue I found with trying to do as you suggested in brackets was, without a way to "cache" what the mouseover unit was before it was obscured by the ring, even writing a custom macro isn't going to be able to actually act on the unit I intended. What I had been sort of trying to figure out how to do was add unit caching to the hint function for the target markers (and successive call prevention, sort of like the spell action has). Where it broke down was my understanding of what exactly is expected as inputs and outputs to each of those things. Your asserts document the names of them rather well, but I definitely got to the point where every time I followed a code path trying to understand how a thing was used, I ran into some of those big blocks of code that you pass to execute and some stuff that was tied up in the secure template frames you have instantiated. And ultimately... this would run afoul of: Do you think that, for the target marker category, specifically, it would be possible at all to cleanly modify it to allow this sort of thing? I suppose the issue is, as you said, the limitations of what you can do. Once the mouseover unit is obscured, the only way to cast on it is to change target or focus to the thing that used to be and I guess that's just not something that an addon could do in combat; so, then we're left with two different behaviors. I wonder, is there a way to use something analogous to "click through" frames to allow the center part of the ring ... or even the whole ring ... to stop obscuring the "mousing over" situation that's happening? |
|
pelf |
View Public Profile |
Send a private message to pelf |
Find More Posts by pelf |
Add pelf to Your Buddy List |
06-14-13, 04:45 PM | |||
|
The behavior is caused by the "Make rings top-most" option, which overlays a button over the entire screen to capture mouse events occurring over other buttons. The option was originally intended to be used in conjunction with "Activate on left click", but also fixes an issue where if a ring binding involving a mouse button was released over a Button widget, the release event would not be delivered to OPie, leaving the ring open. Currently, the option applies regardless of whether "Activate..." is enabled or not, while the configuration UI lies about its state if "Activate..." is disabled. I intend to fix the configuration UI in a future release. Turning the "Make rings top-most" option off should resolve the "obscuring" behavior you describe (making /target mouseover and probably also your marking macros work properly). In the current version, you'd need to open /opie options, check "Activate on left click", uncheck "Make rings top-most", uncheck "Activate on left click", and click Okay. You can change the state of the option on a per-ring basis using the dropdown at the top right of the options configuration panel.
__________________
... and you do get used to it, after a while.
Last edited by Foxlit : 06-14-13 at 08:12 PM.
|
||
|
Foxlit |
View Public Profile |
Send a private message to Foxlit |
Find More Posts by Foxlit |
Add Foxlit to Your Buddy List |
06-14-13, 10:54 PM | |
|
Interesting. I can fiddle with that setting idea.
Right, as you say, about the normal mousing away behavior. I guess one solution would be to dramatically reduce the size of the ring for the target markers so it's likely that even after moving to the selected mark, the cursor would still be over the target. After all this, I'll probably end up just using the default behavior with target... but, I have enjoyed/appreciated your time and explanations and definitely enjoyed looking through your code. I can honestly say it looks like you're doing more with what is available than most I've seen. Speaking of that... You definitely use the pattern wherein scope is temporarily restricted via an arbitrary do...end block extensively. Where did you pick that up? What's your motivation for being so careful with variable scope? EDIT: That is, if you don't mind more questions and a continued discussion . EDIT2: Make rings top-most is not checked for any of my rings.
Last edited by pelf : 06-15-13 at 12:04 PM.
|
|
pelf |
View Public Profile |
Send a private message to pelf |
Find More Posts by pelf |
Add pelf to Your Buddy List |
06-16-13, 05:37 PM | |||
|
__________________
... and you do get used to it, after a while. |
||
|
Foxlit |
View Public Profile |
Send a private message to Foxlit |
Find More Posts by Foxlit |
Add Foxlit to Your Buddy List |
06-29-13, 08:59 PM | |
A Kobold Labourer
Forum posts: 0
File comments: 1
Uploads: 0
|
Wow, I came here to talk about mouseover units, and that's exactly the last conversation. I use them extensively, and would like to figure out how to make them work with Opie.
One easy option would be to use focus, with the understanding that, should have have a focus already set, you will lose it. But you mouseovers will work. It would just focus your mouseover when you open a ring, then use it on the mouseover when you release, and then clear your focus. But something is actually being overlooked here -- you CAN cache a unit into thin air with /targetlasttarget. So you can do something like this when you hit the ring binding: /target mouseover /targetlasttarget That will "cache" the mouseover target as your last target, but appear to the user as though nothing had happened. Then when you release the binding, you would do something like the following: /targetlasttarget /cast Spell_picked_from_ring /targetlasttarget And viola, you have just cast a spell at the mouseover while you didn't actually have your mouse over it. This will fail if you change targets while holding the binding, but I don't think that's an unreasonable limitation. The other caveat is that if you are using macros that rely on targetlasttarget, then they might break. I use it in a focus-to-target swapping macro, but this wouldn't break it. I think most uses of targetlasttarget work exactly as I described: a momentary cache of a target you don't really have. Given that there are certain edge cases where it might fail, you should probably use guid checking to make sure something hasn't gone amiss. (That is, use the mouseover unitid to get the guid of your mouse, and then check it again right before you cast the spell.) So it should be possible to somehow add this mouseover caching in, so you can use @mouseover in your opie macros, and it have it automagically translate it into the behavior above. Then again, I know those work when ran as macros, I'm not sure if you do that many target swaps from an addon, but I've understood that anything one button press can do with a macro, one button press can do with an addon. |
|
Arterion |
View Public Profile |
Send a private message to Arterion |
Find More Posts by Arterion |
Add Arterion to Your Buddy List |
07-04-13, 05:02 PM | |
|
That's a really smart idea. There is that hidden "cache"; I guess I've just never thought of using it like that. I wonder if that could be used in the base code at all...
|
|
pelf |
View Public Profile |
Send a private message to pelf |
Find More Posts by pelf |
Add pelf to Your Buddy List |