OPie

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.

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.

# OPie Lime #
* You can now snapshot your custom OPie rings to share them with other players.
* Changes made in OPie configuration panels are now applied immediately (outside of combat lockdown), and can always be undone entirely by clicking Cancel.
* New, configurable "Selected slice (keep ring open)" binding allows you to use the currently-selected slice without closing the ring (Bindings → Slice Bindings).
* Slices can now be hidden based on a macro conditional evaluated when the ring is opened.
* Improved support for spells with automatically recharging charges, e.g. Roll.
When some, but not all, charges have been expended, OPie displays a semi-transparent cooldown spiral and a spinning spark around the slice's border to indicate the time remaining until the next charge is available.
Added a separate "Show recharge numbers" option to display time until next charge is available as a number.
* You can now adjust the position at which OPie rings are displayed through the configuration UI.
* An Extra Action Button slice can now be added to custom rings.
* OPie can now automatically select matching slice colors based on slice icons.
* The Quest Items ring now includes the Cooking School Bell and Blingtron 4000 if you have not yet completed those daily quests today.
* Cooldowns are now displayed for battle pet slices.
* Slices that are unusable due to being out of range now have a red stripe in the upper left corner of the icon.
* Slices that are unusable due to a lack of resources now have a blue stripe in the upper left corner of the icon.

## Changes ##
* Custom rings limited to other classes or characters can now be modified through the Custom Rings options panel (Inactive rings sub-menu).
* Changing a ring's binding through the Custom Rings configuration panel now changes both the default and active profile's binding for the ring.
* Ability names in custom OPie macros are automatically converted into spell links when the macro is saved.
You can temporarily revert links to text representations by right-clicking or alt-right-clicking them.
* Many bundled rings have been updated.
* Improved custom macro parser to support {{spell:id}} tags in castsequence/castrandom macros, /cast !{{spell:id}} syntax, and preserve empty clauses.
* Improved default mount detection for {{mount:ground}} and {{mount:air}} tags in OPie macros.
* Deleting a ring now also deletes the related per-ring options.
* Removed the option to display an icon at the center of an OPie ring.
* Removed Challenger's Paths ring.
* Masque is no longer supported.
* The various overlay dialogs now shroud OPie configuration panels from mouse wheel events.
* This update changes slices using the pre-Lime default slice color (e5ff00) to use icon-dependent colors.
* Non-/cast-like custom macros are now always considered usable.
* Unusable slices are now dimmed rather than faded.

## Bug fixes ##
* Fixed an error that occurred when navigating away from slice detail view when the macro box is focused and modified.
* Fixed an error that occurred when the Unbind button was clicked.
* Fixed an error that occurred when resetting per-slice bindings for a specific ring to default values.
* Fixed an error that occurred during slice selection when ring scale was set to low values.
* Fixed an issue preventing unbinding a ring from releasing the binding to other rings.
* Fixed an issue preventing correct macro feedback for /castsequence macros with a single spell and a specified reset condition.
* Fixed an issue causing the ring contents column in the custom ring configuration panel to not be updated correctly when slices were deleted under some circumstances.
* Fixed an issue causing all battle pets to appear twice in the battle pet slice category in Patch 5.2.
* Fixed a graphical issue in the cooldown animation.
* Fixed an issue causing nested ring slices to overlap in some circumstances.
* Items on cooldown are no longer indicated as usable.
* Fixed an issue causing the "Show recharge numbers" option to be ignored (in favor of "Show cooldown numbers") when performing Spinning Crane Kick.
* Fixed an error that occurred when saving custom macros while playing a class that has a spell flyout ability.
* Fixed an issue preventing nested ring rotation from being saved.
* Corrected slice icon display for non-active /cast {{spell:id}}-like macros in the custom rings panel.
* Fixed an issue preventing OPie slash commands from opening correct configuration panels on first use in Patch 5.3.
* The "Make rings top-most" option is no longer disabled when "Activate on left click" option is unchecked.
* Fixed an issue preventing the overlay dialog used in the option panels from being cleared correctly in some circumstances.
* Fixed an issue causing option panel descriptions to be truncated incorrectly.
* Fixed incorrect ability out-of-range feedback for self-cast abilities and actions.

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?

Have you ever considered supporting mouseover for the raid target ring?

Because you have to move the mouse cursor to select an action to perform (ignoring per-slice bindings and center actions), and doing so somewhat limits your ability to place the mouse over what you actually want to target with the slice action, OPie generally avoids using your mouseover target.

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.]

Can you help me understand the stuff I'm missing?

ActionBook is the part of OPie that handles actually performing the various actions (casting spells/using items/running macros/summoning battle pets/equipping equipment sets/etc) securely. Among other things, it maps descriptions of actions (like "cast spell with id=126201" or "run macro text: /cast [@pet] Frostbolt") to a single numeric actionId; returns information about an action given its actionId (including the action's icon, cooldown, charges, whether it can be cast right now, the appropriate tooltip to show, etc); and finally performs an action given its actionId.

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.

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?

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 guyshttp://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!

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.

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.

You can skin non-Button objects with Masque, and you don't have to let it handle all of your textures. You can feed it only the border texture, for example; see the SkinSupport.lua file in my addon PhanxBuffs.

I don't think that partial skinning would lead to a good experience in OPie's case: even just changing the border texture probably requires changes to how the button's icon is positioned, sized, and transformed; to the outer and inner glow effects indicating used to indicate active/overlaid actions; to cooldown mask rendering; to the position of the various overlays like item/charge count and keybinding text; etc etc.

On OPie's side, the code implementing those buttons is very different from what Masque expects. Past versions supported Masque by removing some of the functionality and feeding Masque a rather limited view of what should be displayed on those buttons; I no longer view this approach as providing a good enough user experience. I don't currently want to implement or maintain duplicate button-creating code to support Masque, so Lime contains no Masque support at all.

Originally Posted by Phanx

Alternatively, if you're not interested in supporting Masque yourself, can't you at least give something a global name so a third-party addon can hook in and skin the "buttons" with Masque? It's probably possible to do right now using EnumerateFrames or something, but that seems pretty horrible.

Yes; third-party skinning is already supported in Lime. The existing buttons are anonymous because I don't want to invite code that attempts to skin them directly, because it might fail to do so correctly if the internal implementation changes, and would probably be incapable of reverting its changes without an interface reload.

Instead, third-party implementations can replace the function responsible for creating the indicator frames, and create whatever widgets are required for their skins. Use something like the following:

You can use SetPortraitToTexture() to create round textures. Even on actionbuttons. Maybe that is interesting for your mod.

Hey zork. I'm not particularly interested in changing how the default skin looks at the moment (and think that circles have disturbingly few corners to put things in), but if you'd like to try your hand at it, you could probably use the API mentioned above.

You can skin non-Button objects with Masque, and you don't have to let it handle all of your textures. You can feed it only the border texture, for example; see the SkinSupport.lua file in my addon PhanxBuffs.

Alternatively, if you're not interested in supporting Masque yourself, can't you at least give something a global name so a third-party addon can hook in and skin the "buttons" with Masque? It's probably possible to do right now using EnumerateFrames or something, but that seems pretty horrible.

While out in Pandaria, how do I get Opie to select a specific ground mount in the default druid shapeshifting ring. It is picking the armoured blue windrider by default. When I looked at the macro it does not specify any land mount but it also does not pick travel form either.

Help?

To customize which ground mount is used, edit the macro. By default, OPie simply selects the first ground mount it finds.

You can force it to cast travel form by holding down ALT.

how can i edit it?
ive tried dragging the mount as a couple codes
[nocombat,outdoors,nomod:alt] {[Headless Horseman's Mount]} with [[]] {{}} {[]}.. but it doesnt work.
any tips?

EDIT: solved by foxlit before. gonna leave this here as finding resolved posts is a pain.

Originally Posted by Foxlit

If you're typing out your mount's name, avoid including square brackets. Alternatively, you can open the spellbook and shift-click on the mount while the keyboard focus is on the macro input box; that'll add a link.