(102Kb)

Updated: 08-05-13 08:50 AM

Add Favorite

Install Help

Pictures

File Info

Updated:	08-05-13 08:50 AM
Created:	unknown
Downloads:	227,431
Favorites:	1,246
MD5:

OPie

Version: Lime 6

by: Foxlit [More]

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.

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

Optional Files (3)

File Name	Version	Size	Author	Date	Type
OPie Masque	7.3.5.0	4kB	Phanx	03-04-18 06:32 AM	Addon
OPie Share	1.3	6kB	Foxlit	09-21-12 06:37 AM	Addon
OPie EquipmentManager	1.0	1kB	Timewasted	02-14-11 02:19 PM	Addon

Comment Options

Page 66 of 67

« First

03-31-13, 07:35 AM

Foxlit

A Warpwood Thunder Caller

Forum posts: 91

File comments: 271

Uploads: 11

Originally Posted by Phanx

Does the frame need to have a texture object at frame.hiEdge, for example, or is it sufficient that the frame has a frame:SetHighlighted method?

The returned table need not be a frame, nor does it need to contain any texture objects; just having the methods is sufficient.

__________________
... and you do get used to it, after a while.

Last edited by Foxlit : 03-31-13 at 10:24 AM.

04-03-13, 12:02 AM
Phanx Cat. Forum posts: 5617 File comments: 2321 Uploads: 54	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.

04-06-13, 01:19 PM
daggerz 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.

04-06-13, 08:13 PM

Foxlit

A Warpwood Thunder Caller

Forum posts: 91

File comments: 271

Uploads: 11

Re: Subring Problem

Originally Posted by daggerz

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.

Thank you; I'll fix it in the next update.

__________________
... and you do get used to it, after a while.

04-17-13, 05:43 PM
Zelnia 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!

04-18-13, 05:32 PM

Foxlit

A Warpwood Thunder Caller

Forum posts: 91

File comments: 271

Uploads: 11

Re: problem

Originally Posted by Zelnia

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

Thank you for the report; this should be fixed in Lime 3.

__________________
... and you do get used to it, after a while.

04-20-13, 05:17 PM
Zelnia 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!

06-09-13, 08:12 AM
pelf Sentient Plasmoid Forum posts: 133 File comments: 75 Uploads: 0	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.

06-11-13, 05:14 PM

Foxlit

A Warpwood Thunder Caller

Forum posts: 91

File comments: 271

Uploads: 11

Originally Posted by pelf

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.

__________________
... and you do get used to it, after a while.

06-12-13, 05:58 PM
pelf Sentient Plasmoid Forum posts: 133 File comments: 75 Uploads: 0	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?

06-14-13, 04:45 PM

Foxlit

A Warpwood Thunder Caller

Forum posts: 91

File comments: 271

Uploads: 11

Originally Posted by pelf

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.

So this "obscuring" behavior is a different issue from the one I had in mind (which was slice selection forcing the user to move the mouse, causing the "intended" mob is no longer accessible via the mouseover unit); the problem you're running into here is more similar to a /target mouseover macro failing to target what you're pointing at when triggered from an OPie slice.

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.

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'm going to rephrase it like this: once the user moves the cursor away from the mouseover unit the ring was activated over, there is no reliable way to set a target marker on that entity. Addons can ask OPie to change the player's target or focus whenever a particular ring is activated (even in combat, though this might not always be tolerable to the player), which would allow the marker to be set on the original entity regardless of where the mouse cursor is moved.

__________________
... and you do get used to it, after a while.

Last edited by Foxlit : 06-14-13 at 08:12 PM.

06-14-13, 10:54 PM
pelf Sentient Plasmoid Forum posts: 133 File comments: 75 Uploads: 0	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.

06-16-13, 05:37 PM

Foxlit

A Warpwood Thunder Caller

Forum posts: 91

File comments: 271

Uploads: 11

Originally Posted by pelf

EDIT2: Make rings top-most is not checked for any of my rings.

In the current version, that checkbox will always appear unchecked unless "Activate on left click" is also checked.

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?

It probably has less to do with scope management (though that aspect is useful on occasion, for instance to establish a sort of static scope for a function's helper resources, or to illustrate that some variables are intended to be more local than others), and more with text editor features: I can fold the do/end block, which allows me to hide the implementation details and get a high-level summary of what's in a particular unit of code.

__________________
... and you do get used to it, after a while.

06-29-13, 08:59 PM
Arterion 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.

07-04-13, 05:02 PM
pelf Sentient Plasmoid Forum posts: 133 File comments: 75 Uploads: 0	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...

Page 66 of 67

« First

Report this File

Category Jump: