Power Auras Classic 5.0

[Razee]

Originally Posted by Meorawr Having trouble reproducing the second, what abilities are you testing it with? (The one you're tracking via Spell Cooldown, and the ones you're using to invoke the GCD).

I'm on a prot warrior, my two spell off cooldown triggers are for Revenge and Shield Slam and I have seen the issue show up on both. The GCD is invoked by Devastate.

[Meorawr]

I've reproduced it a couple of times, but only with the Ignore GCD setting off (Ignore GCD End is on however).

And I swear, I used to love Sword and Board procs up until now

[Razee]

I have both boxes checked (Ignore GCD and Ignore GCD End). I don't, however, have Usable checked. Maybe that's what causes the problem to show up more clearly for me.

[Meorawr]

I think I've nailed it, basically it doesn't check how long is left on the GCD before deciding that it's fine to show it. So with a cooldown of 1 second remaining, if the GCD only has 0.2 seconds it'll show for 0.2 seconds (as the 1 second remaining is less than the class GCD).

Fix for it is to just make sure the remaining duration on the GCD is >= the remaining duration of the cooldown I think.

Edit: Seem to have fixed it now, thanks

[Razee]

I know that you are feature freezing soon, so I don't know if you are interested in more ideas about new things, but here are a couple more thoughts in case you fancy them.

1) Animation reset on Display reset
Let's say I have a Display triggered by a buff. This buff always lasts 8 seconds. 4 seconds into the buff, the buff refreshes giving it a new 8 seconds of duration. Would it be possible to have some way of the animation process also resetting at this point? Meaning that the start animation is replayed and the following repeated animation restarts its cycling (but the end animation doesn't play just because of the refresh). Basically, I would like the visual impression of that the Display was refreshed which a starting animation can provide. I used to solve this by making the aura hidden until 7.75 seconds remaining which resulted in the aura disappearing for 0.25 seconds every time the buff refreshed and then restarting. It would be more convenient though if there was some option to simply have the animation reset whenever the Display refreshes its duration. (It's really only with buff/debuff tracking Displays that I can see such an option having any practical use.)

2) Keypress trigger
Something that I have been thinking about for a while is that it would be cool if there was a way to manually use keyboard combinations to work as triggers. I am thinking it would probably be pretty easy to implement. It might sound useless and abstract though, so let me give a couple of examples where I have felt a need for this.

a) Taking a prot warrior as example right now: When single-target tanking I will want to use Thunder Clap to make sure that the Weakened Blows debuff is kept on the target and thus I would make a Display that brings my attention to that it's about to wear off (~ every 30 seconds). However, if I am multi-target tanking I would want to use Thunder Clap on cooldown (every 6 seconds) and I would want a Display that brings my attention to Thunder Clap every time it's off cooldown. Now, I don't think there's any way we can get PA to somehow sense if I am in a single-target situation or a multi-target situation, so it would be awesome if I, on the fly, through a customizable keypress could alter how my PA functions. In this situation: hitting, say, Ctrl-D toggles a trigger from FALSE to TRUE that causes my PA to now bring attention to Thunder Clap and Shockwave as soon as they are available, and hitting Ctrl-D again reverts to PA only letting me know when I need to use Thunder Clap to reapply Weakened Blows. I think most classes have similar situations where the way they use their skills is altered by dealing with a multi-mob situation. But in general as well, I think it would be really cool to be able to have manual triggers at your command that on the fly alters the functionality of your PA.

b) Suppose I have several long cooldowns that I want to track using PA. I find though that they clutter the screen a bit and detract from the rest of the information my other Displays are providing me with. So it would be nice to have some way of making these time counter Displays only show when I actually have an interest in the exact duration left on the cooldown. In this situation it would be cool if, for instance, while holding down Ctrl a trigger changes from FALSE to TRUE causing these Displays to show up and releasing Ctrl causes them to hide again. So a slightly different functionality than example a.

It's a pretty simply type of trigger. Most users probably wouldn't have much need for it but for heavy PA users I can see it providing a new kind of flexibility.

3) Fading out the Editor window
I recall you yourself having asked for feedback about having some way of fading out the Aura Editor window, like holding the mouse over it and pressing Ctrl. I do think it might be an issue for people that the Aura Editor covers the auras on the actual playing screen. I don't know if the size of the Editor window itself is finalized but it would be awesome if it wasn't quite as wide. In version 4 I used to keep the Browser window on the left side of the screen and the Editor window on the right side which left me with the center free. The new Editor window is quite a bit wider though so I'm finding it trickier.

In essence I think some way of making the Editor window fade to higher transparency would be a good idea (regardless of if the Editor can be made smaller or not). But would enough users do the necessary reading or testing to learn that holding down Ctrl while hovering over the Editor makes it fade away? Another way of achieving the same thing that I thought about was this: Suppose that simply hovering the mouse over the Browser window causes the Editor window to fade out. However, as soon as something in the Browser window is selected, the Editor window will of course reappear showing the selected item (until the mouse is brought off of the Browser and back onto it again). The reason I think this would work is because if a user moves the mouse away from the Editor and onto the Browser it will most likely mean they aren't interested in the current information in the Editor anymore but are instead wanting to load the Editor with new information via the Browser, so I don't think the risk of the Editor window fading out annoyingly when you are still trying to look at it is very large. At the same time, this solution would inevitable illustrate this fading out functionality for every user simply through their natural interaction with the UI; it doesn't require any reading up of hotkeys or unintuitive trial-and-error. It's a bit unconventional though so I definitely do feel that it's hard to know if it would really work as hoped without simply trying it and seeing if it feels "smart" or just awkward.

I promise these will be my final thoughts of "added functionality" since I know you'll be moving into beta soon. Meanwhile, I am finding the alpha to really be starting to function well and I love how solid the trigger operators are feeling compared to version 4. You're doing an awesome job!

[Meorawr]

Aiming for another release tonight, I'll quickly summarise each point you've raised though (thanks again for all the feedback by the way):

• Animation resetting: That sounds like a feature for a future release, but yeah it should be kind of possible at some point.
• Keypress trigger: Doable, but it would only work when the key is pressed. Releasing the key can't be detected (I'm not sure if it's an API bug at this point). It'd work for the example you gave, whereby a boolean state is toggled each time the combination is pressed, but I wouldn't be able to expand it further than that.
• Editor fading: Ctrl+Alt+Shift while mousing over the editor does that for now. I agree it needs to be more exposed, I'm thinking of sticking a button next to the Close button on the editor window that would act as a toggle for this - and maybe an option for automated alpha fading based upon where the mouse is/isn't.

As for the features going ahead:

• Triggers
• Tracking and UnitMatch triggers have been removed. I might reimplement them at a later date, but I'm questioning their worth considerably right now.
• I've just implemented Totems, ZoneType (instance/bg/arena) and WeaponEnchant.
• UnitData (class checks, etc) might be delayed until 5.1.
• UnitAuraType won't be in today's release, but will be in for 5.0.
• Actions
• Working on DisplayAlpha and DisplayColor actions now.
• Standalone actions will probably be cut until 5.1. There's not enough of them to justify keeping them in at the moment, so I'd rather hold them back until they can get some attention. The only one this really affects is triggering sounds in events that aren't related to displays.
• Custom Triggers
• Custom triggers are next on the list of things to do. Just working on the UI for them. They'll be expanded further in a future release, but they'll be in for 5.0.
• Tutorials
• These will be worked on last, hopefully I'll have time to flesh these out again.
• Exporting/Importing
• Will be done, but they might be limited a bit (namely, exporting/importing lone displays will probably be postponed). Exporting/importing will work for profiles and auras.
• Moving/Copying
• Will be done soon.
• UI stuff
• Advanced animations editor will be put back in soon, hopefully.
• Source editing for triggers should be accessible again, soon.

As you can see, a lot of things to do

[Vampyrate]

Hi Meo, while not a user of your addon (yet, I may soon), i saw this thread. You mentioned about a trigger on keypress vs keyrelease. As far as I know, WOW operates on key release by a default. There was an addon awhile back that changed WOW to operate on keyPRESS which was aimed at increasing DPS.

[Meorawr]

The method used for detecting keypresses without actually stealing focus of them only works on key down, basically it involves creating a frame which accepts keyboard input, showing it and setting SetPropagateKeyboardInput to true and handling the keypresses in an OnKeyDown script handler. There's an accompanying OnKeyUp script too, but that never gets fired with SPKI set to true (it does, however, if SPKI is false).

If that was a bit complicated, then in a simple explanation: The method used for keybinding abilties and triggering a keypress trigger (if I do add it) are two entirely different things

[Meorawr]

Alpha 12 is going up, next release should hopefully be the last alpha - the focus of it will be a 4.x to 5.0 upgrade. I don't promise that it'll be flawless, but if you want to help then you can provide me with existing saved variables for testing purposes:

• Go to your WTF folder in your WoW installation folder.
• Find "PowerAuras.lua" files in the folders: "WTF\Account\<Account Name>\SavedVariables" and "WTF\Account\<Account Name>\<Realm Name>\<Character Name>\SavedVariables".
• Open the files in any text editor (notepad will do), and copy the contents.
• Paste the contents into a Pastebin paste. I don't mind if you paste all the files into a single paste, or if you do a single paste per file, but please make it clear if there's more than one file in a single paste.
• Post the link to the paste here, or in a PM to me.
• If you want to be really helpful, a short summary on what each aura is supposed to do will help me pinpoint any subtle conversion bugs. Without it I can only really guess if it's working as intended.

As the system will be quite buggy, the plan is to keep a copy of the upgraded profile stored somewhere and expose a slash command (/powa migrate) which will replace your current profile with your old settings - so if the conversion is horribly inaccurate at first, and improvements are made to the process, you can just have it redo the upgrade without needing to keep the old settings around yourself.

When in the beta phase, the plans are:

• Fix critical bugs (as in, ones that cause horrible errors). There's a few bugs lying around right now that don't really affect anything, so I'm not in a complete rush to fix them as of yet.
• Tune the upgrade process.
• Add missing UI sections and give touch ups to the places that need them.

If any features need to be cut, they'll be the following (in order of precedence). I don't like cutting things, but it's a case of having to work to Blizzard's patch release schedule.

• Advanced animation editing.
• Tutorials
• Time Remaining/Stacks triggers
• Custom Triggers

[Silvertaurus]

Heya.
Just general feedback.

I dont know if I did miss it before, or its something new (since Alpha7).
In single 'Aura' you may have multiple displays..
But then you might add displays which inherits from other (if you trigger adding display from inside other).. at start I found it bit confusing at start since all displays are still shown in single Aura summary..

Changing Auras names and adding descriptions is not implemented. I might not be big priority to the main functionality of Addon, but would help in managing Auras. It was there in early Alpha versions

When you want to anchor position of one display to another, you have list of all displays avaible in all auras. There is no description, just generic icon of it - in my case its just WoW Logo or Timer Bar Icon.. and got 4 of each. Easy to get lost in them ^_^

Only real error I encountered is still WoW crashing when I press [Copy] button in debug windo
(Other error I fixed by removing files with Auras I did set in older build)

[Meorawr]

Inherited displays showing in the display grid was one of those things I couldn't really decide on - the advantage of showing them there is that it's one less click if you want to edit the inherited displays, but it does complicate things a bit. I might remove them from the grid again.

Changing aura names/descriptions is missing, you're right. I'll add it again soon

The dialogs themselves need some polish in general, what I'd likely do is separate each display by the aura that they're in. It'll also not show displays that it can't parent to (for instance, it won't show the display that you're anchoring, because anchoring to yourself makes no sense).

The WoW error on the copy button is known, I'll fix it later.

[Silvertaurus]

Seems the other error i though I fixed did came back =(

Recreating Step by step:
- Making an Aura with 2 displays:
--- texture showing up when my Shadow Word: Pain is on target
--- timer bar, inheriting from display 1 (showing its duration) and setting Parent display to the texture
- Making 2nd similar Aura for Vampiric Touch
- Both are working fine at this moment
- removing TimerBar for Aura1 - all is working fine (for future reference)
- bringing back this TimerBar
- removing TimerBar from Aura2

At this moment UI is breaking
- 'Aura Browser' window is fully functional no problem here
- 'Aura Editor' for any Aura is kina blank.
--- no buttons of any sort (just the X to close window)
--- just 3 segments of menu, displays and top 'location' bar.
- Icons of displays in choosen Aura are
--- displayed in 'default' position,
--- not anhored to the window of 'Aura Editor'
--- not clickable

[EDIT] Just tried the above steps where 2nd display is not inheriting from 1st ... the same problem.

[Meorawr]

I'll take a look later on today. I did try to basically reproduce it last night, but it worked fine for me. I probably missed something though

[Silvertaurus]

This is how my setup works in beta :
http://www.youtube.com/watch?v=5tyIzjhyySg

This is the issue :
http://www.youtube.com/watch?v=bxrLdsbnt6g

The error in chat is :

Power Auras Classic: Error:
...rface\AddOns\PowerAuras\Types\Displays\Variables.lua:158: Display ID 256 does not resolve to a valid display

[Meorawr]

Ah, I was only testing it with a single aura. Got the error now I think. Fun fact, most bugs are actually due to me not properly testing something with an aura that isn't #1 in the list

Edit: Mostly fixed it - it doesn't completely fail now, but there still is an error somewhere (which has no effect).

Edit #2: Nailed the other bug. Should also fix error messages when deleting a parent display - issue was just it not validating the displays still existed when it tried to reconfigure them, which was harmless anyway.

[Meorawr]

Alpha-whatever-it-is is going out now.

Got the basic 4.x to 5.0 upgrade code done. It's going to have a ton of issues, but here's the rundown at the moment:

• Currently, timers/stacks aren't migrated. Neither are animations/sounds, this'll be fixed soon.
• Text displays don't have their fonts properly migrated.
• Texture displays might have the wrong texture (custom textures work, as do numbered textures and the use icon setting should also work. The WoW textures option doesn't migrate yet, and if you had a custom texture which used a spell name/ID, it'll only work if you migrate the settings with the appropriate class that has the spell.
• The tank/healer/DPS role settings don't migrate. Partially because they don't have exactly-matching triggers, but also because the specialisation trigger can be configured to cover that (it includes options for actual talent specs now).
• The invert aura below setting won't migrate.
• While triggers are successfully generated for support types, main types don't migrate at all right now.
• Global auras are stuck in their own profile, and their upgrading hasn't yet been tested.
• The 4.x settings are serialized into a string and stored, so when future refinements are made to the process you won't be out of luck as far as requesting a re-upgrade goes. There's a /powa migrate slash command being added for this, however I've not added it to this release.

Basically, early WiP and so on so forth, but the code is there and it (for the most part) works - it's just missing some functionality right now and has glaring omissions.

First beta release will be tomorrow or Friday, depending upon patch schedules and so on. Also, this release has custom triggers implemented at a reasonably basic level.

[Melvex]

Meorawr, how can I create aura that would display current value of eclipse energy?
I can't find in MoP Powa chechbox with "Aura's text" Like >--this--< on 4.23 version powa.

And where is the button for shut off of auras? It's uncomfortable when you see on screen raw aura and you have to remove it because of you don't have enough time for tune it.

[judge40]

Does POWA 5.0 currently support the new Blizzard raid buff tracker?
i.e. the collapsing buff icon which will show how many of the 8 buffs you have and categorise them into types (Stats, Stamina, Mastery etc.)
See http://wow.joystiq.com/2012/03/29/ad...pgrades-thurs/

For example so I could set up an aura which showed if I had the Stamina buff or not, without having to specify each particular source of the buff.


At the moment I have a rather fiddly set up on my paladin which checks if I have cast BoM/BoK, if I have an equivalent buff from another class and then mashes it all up together to show me whether I need to re-cast my buffs and which one is preferable.

If POWA can be used to track the new system it would make my life somewhat easier, since I could just track for the buff type rather than have to specify each and every source myself.

[Meorawr]

It's being rolled into the UnitAuraType trigger (it'll be a fixed list of types, ranging from dispel types like Magic to group buff types like Stats).

[judge40]

Excellent, thanks for the response.

While I've not had as much time as I'd have liked to play around on the beta/PTR with POWA I've been keeping an eye on the changes through this thread and I'm really impressed with the changes, I think you've done a great job.