Download
(102 Kb)
Download
Updated: 08-05-13 08:50 AM
Pictures
File Info
Compatibility:
Escalation (5.3)
Updated:08-05-13 08:50 AM
Created:unknown
Downloads:204,195
Favorites:1,291
MD5:
OPie  Popular! (More than 5000 hits)
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 (4)
File Name
Version
Size
Author
Date
Type
5.4.7.12
4kB
04-05-14 07:12 PM
Addon
1.3
6kB
09-21-12 06:37 AM
Addon
1.0
1kB
02-14-11 01:19 PM
Addon
0.2
2kB
10-21-10 07:30 AM
Addon


Archived Files (1)
File Name
Version
Size
Author
Date
Lime 4
101kB
Foxlit
05-02-13 02:45 PM


Post A Reply Comment Options
Old 01-06-14, 09:53 PM  
Brusalk
A Fallenroot Satyr
 
Brusalk's Avatar
AddOn Author - Click to view AddOns

Forum posts: 28
File comments: 156
Uploads: 5
Originally Posted by Foxlit
To revisit that last answer,

Originally Posted by Brusalk
Is there a way to choose a "default" button for when you have sub-rings that's remembered between openings?
OPie Lime 9 has a "Forget sub-ring rotation" option for sub-ring slices, which ensures that whenever you open a ring, the first slice in the sub-ring starts out selected.


Originally Posted by Brusalk
Also, there wouldn't happen to be a way to toggle autorun inside a ring would there? Middle mouse button is a convinent bind for OPie, but traditionally I've used it for autorunning. It'd be nice to get that back if possible :P
Try Forward, which should let you toggle almost-but-not-quite-autorun from within an OPie ring.
Thanks for the help! I'll check out that forward addon. I'm guessing he basically just creates a secure action button that is bound to forward autorun.
Brusalk is offline Report comment to moderator  
Reply With Quote
Old 11-11-13, 03:30 PM  
Foxlit
A Warpwood Thunder Caller
 
Foxlit's Avatar
AddOn Author - Click to view AddOns

Forum posts: 91
File comments: 271
Uploads: 13
To revisit that last answer,

Originally Posted by Brusalk
Is there a way to choose a "default" button for when you have sub-rings that's remembered between openings?
OPie Lime 9 has a "Forget sub-ring rotation" option for sub-ring slices, which ensures that whenever you open a ring, the first slice in the sub-ring starts out selected.


Originally Posted by Brusalk
Also, there wouldn't happen to be a way to toggle autorun inside a ring would there? Middle mouse button is a convinent bind for OPie, but traditionally I've used it for autorunning. It'd be nice to get that back if possible :P
Try Forward, which should let you toggle almost-but-not-quite-autorun from within an OPie ring.
__________________
... and you do get used to it, after a while.
Foxlit is offline Report comment to moderator  
Reply With Quote
Old 11-09-13, 09:30 AM  
Foxlit
A Warpwood Thunder Caller
 
Foxlit's Avatar
AddOn Author - Click to view AddOns

Forum posts: 91
File comments: 271
Uploads: 13
Originally Posted by Brusalk
Is there a way to choose a "default" button for when you have sub-rings that's remembered between openings?

Also, there wouldn't happen to be a way to toggle autorun inside a ring would there? Middle mouse button is a convinent bind for OPie, but traditionally I've used it for autorunning. It'd be nice to get that back if possible :P
"Not at the moment" on both fronts. The real autorun can only be toggled using that one binding (which you could bind it to something else, but that's neither here nor there); OPie has no way to redirect your interaction to that binding.

Having subrings revert back to specific slice actions after closing the ring is at least theoretically possible, but is still technically challenging there's currently no way to tell you what's inside an arbitrary ring without opening it, and as some slices might always be available, handling this properly would require setting up some sort of priority list to figure out what you want to revert to.

A simpler solution might be to give you a checkbox that'd block a sub-ring slice from saving its rotation at all, and rely on you to put the slice you want to be "locked" as the default selection first in the ring.
__________________
... and you do get used to it, after a while.
Foxlit is offline Report comment to moderator  
Reply With Quote
Old 10-30-13, 05:35 PM  
Brusalk
A Fallenroot Satyr
 
Brusalk's Avatar
AddOn Author - Click to view AddOns

Forum posts: 28
File comments: 156
Uploads: 5
Hey! I recently found OPie and I've fallen in love with it. It's so smooth and awesome!


Is there a way to choose a "default" button for when you have sub-rings that's remembered between openings?

I'll give an example: I have a ring that is set up to have multiple rings, and one of those sub-rings is one for choosing between Doomguard/Infernal summons. Is there a way to set up the ring such that it remembers that Doomguard is the one I want pre-selected when I open the main ring? Currently if I scroll to the Infernal, that's what is remembered and the Infernal is selected the next time I open the ring.


Thanks!

Also, there wouldn't happen to be a way to toggle autorun inside a ring would there? Middle mouse button is a convinent bind for OPie, but traditionally I've used it for autorunning. It'd be nice to get that back if possible :P
Last edited by Brusalk : 10-30-13 at 05:38 PM.
Brusalk is offline Report comment to moderator  
Reply With Quote
Old 10-04-13, 02:14 PM  
kuracisto
A Kobold Labourer

Forum posts: 1
File comments: 2
Uploads: 0
binding mouse button #4 and another key to activate

howdy all, forgive me if I've overlooked something obvious, but i just can't seem to get this to work. I want my 4th mouse button and a keyboard button to cause opie to open a ring. I'll use btn4 & 1 as an example.

I've tried BUTTON4+1, BUTTON4-1, BUTTON4 1, [btn:4]1, [btn:4]-1, [button:4]1, [button:4]-1, and a few other varieties.

Opie is currently version Lime 7, Wow is patched current, and I know the btn:4 is there because i can write a quick macro that understands "/use [btn:4] SPELL" and it'll activate when i click the action with the 4th mouse button.

I'm sorry if this is posted somewhere and i havn't seen it, but i've spent a couple of days trying to figure this out and feel it is passing the effort-reward line.

thanks,
Kuracisto@Arathor
kuracisto is offline Report comment to moderator  
Reply With Quote
Old 08-05-13, 08:47 AM  
Foxlit
A Warpwood Thunder Caller
 
Foxlit's Avatar
AddOn Author - Click to view AddOns

Forum posts: 91
File comments: 271
Uploads: 13
Originally Posted by Arterion
But something is actually being overlooked here -- you CAN cache a unit into thin air with /targetlasttarget.
It's not actually being overlooked -- I just don't consider it reliable enough to build functionality around. You pointed out some of the cases where it wouldn't work quite right; there are also a few other problematic ones, but they mostly come down to the same thing: the addon would sometimes fail to do what the user wanted.

It's probably worth noting that you can only check the target's GUID for non-protected actions, like setting target markers, but not casting spells in combat.

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.
There should be no technical limitations preventing you from implementing the scheme you describe: an addon could create a custom OPie ring that'd run /target mouseover /targetlasttarget on open, and have all of its slices be macros of the /targetlasttarget /do_things /targetlasttarget form.
__________________
... and you do get used to it, after a while.
Foxlit is offline Report comment to moderator  
Reply With Quote
Old 07-04-13, 05:02 PM  
pelf
Sentient Plasmoid
 
pelf's Avatar
Premium Member

Forum posts: 128
File comments: 74
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...
pelf is offline Report comment to moderator  
Reply With Quote
Old 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.
Arterion is offline Report comment to moderator  
Reply With Quote
Old 06-16-13, 05:37 PM  
Foxlit
A Warpwood Thunder Caller
 
Foxlit's Avatar
AddOn Author - Click to view AddOns

Forum posts: 91
File comments: 271
Uploads: 13
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.
Foxlit is offline Report comment to moderator  
Reply With Quote
Old 06-14-13, 10:54 PM  
pelf
Sentient Plasmoid
 
pelf's Avatar
Premium Member

Forum posts: 128
File comments: 74
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.
pelf is offline Report comment to moderator  
Reply With Quote
Old 06-14-13, 04:45 PM  
Foxlit
A Warpwood Thunder Caller
 
Foxlit's Avatar
AddOn Author - Click to view AddOns

Forum posts: 91
File comments: 271
Uploads: 13
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.
Foxlit is offline Report comment to moderator  
Reply With Quote
Old 06-12-13, 05:58 PM  
pelf
Sentient Plasmoid
 
pelf's Avatar
Premium Member

Forum posts: 128
File comments: 74
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?
pelf is offline Report comment to moderator  
Reply With Quote
Old 06-11-13, 05:14 PM  
Foxlit
A Warpwood Thunder Caller
 
Foxlit's Avatar
AddOn Author - Click to view AddOns

Forum posts: 91
File comments: 271
Uploads: 13
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.
Foxlit is offline Report comment to moderator  
Reply With Quote
Old 06-09-13, 08:12 AM  
pelf
Sentient Plasmoid
 
pelf's Avatar
Premium Member

Forum posts: 128
File comments: 74
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.
pelf is offline Report comment to moderator  
Reply With Quote
Old 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!
Zelnia is offline Report comment to moderator  
Reply With Quote
Post A Reply



Category Jump: