|
I had in the trigger nothing, I don't know what it's exactly in english, cause it's translatet into german ;) but I changed it and the aura didn't work.
I'll try it tomorrow again. Hopefully I'll find the mistake ;) |
I'll try and take a look tonight, if my connection works then (but it hasn't connected at all for about ~14 hours so far).
When you say it doesn't work, is it always showing or never showing? If it's always showing (even when you don't have a target) then it's a known bug that'll be fixed in the next release. If you want, you can do a /powa export ingame and it'll export your entire profile. Paste it here and it might help a bit :) |
With the 5.0 version, I'm not sure the Power Auras "Classic" name is justifiable.
I'll see myself out... |
Right, going to make this clear again because I'm sick of people ignoring it:
This is an alpha-quality release. The UI is in an alpha-quality state. Feedback is incredibly useful, so long as it's constructive and helpful. In the vast majority of cases, it has been incredibly useful. However there's still the lingering issue of people complaining about <x> and throwing their toys out of the pram because they expected a release-quality system. I'll just quickly explain how our development process has worked in regards to the UI:
You might be wondering what the point of using the development UI is. In a nutshell, the alpha was put out for two reasons:
Now I've gotten that off my chest, here's the tentative plans for the next couple of releases (hopefully one on Saturday, but no promises):
TL;DR Feedback is useful, whining is not. Pretending this is final is a bad idea. |
I didn't mean it in a negative way... but failed to really have a constructive point, I admit. It was in regard to the *nice* overhaul being done and the word classic being used. What's classic about it? Power Auras Awesome 5.0 seems more relevent. I don't care what the name is nor was I intending to provide feedback of the addon's progress.
|
It wasn't aimed at you, it was just something I wanted to address in general. Apologies if it came across that way :)
|
Right, basically nailed the Sources system now.
Here's how it works, with pretty pictures: 1) Create the display (we'll do a Timer).  2) Configure it to track what you want. I'll make it track the Legacy of the White Tiger buff.  3) No messing around with sources, because it defaults to automatic configuration mode.  4) It works.  For something a bit more advanced (using a buff icon for the texture): 1) Create the texture display.  2) Again, configure it. This time I'll make it show my whirly kick of wet paper bags.  3) It's in automatic mode, so I just need to check "Use Buff/Debuff for Icon".  4) Close editor, spin around, done.  The configuration modes are:
Hopefully that'll resolve any concerns about how painful it'd be to set things up. Next on the list is either going to be more triggers/source types, or adding timers/whatever to existing displays. |
Putting up an alpha now, one thing to note is that any existing UnitAura triggers will need reconfiguring (you'll need to delete their entire displays to do so). I made changes to how UnitAura works to add in all the missing options, including tooltip matching and multiple unit scanning. Plan is to extend this to all the other triggers too, over the next couple of days.
Sources might be a little buggy, in particular auto-configuring might be off. Report any issues with those please. But hey, alpha is alpha. dealwithit.jpg |
Quote:
|
Can you try deleting the entire aura? If not, can you do a "/powa debug" and check the log for anything that looks like an error (missing localisation strings/load time messages don't count - everything else does). There's a "copy" button on each row which you can click for a full output string to paste into a post here.
I might just put out another release tonight which will forcibly nuke existing saved variables. I can just hide under the word 'alpha' and get away with it, right? :) |
Hey just trying out last build (Alpha 6) and cant realy make it to work.
Here is my story :D Wanted to cofigure 'Shadow Word: Pain' to activate texture when its on target. Current Trigger : unit Buff/Debuff Type : Debuff Unit : target Matches Match : Shadow Word: Pain checked only 'Ignore Case' and 'Is Mine'. Stacks on default (operator >=, Count 0, Source 'Stack Count') Above didnt work. When in Matches, checked the Match Tooltip, cleared 'Match' field and write "shadow" in 'Match Tooltip' it kinda started to react.. It activated any time the hostile mob buffed himself (as I was playing around on Pandaria continent not on dummies) In no point there was word 'shadow' in tooltip of it, still texture showed up on buff and deactivated when buff did fade. After using /powa debug there was error listed like 3 times: [GetScreenEdgeDistance] Invalid edges, defaulting to 0. Pressing Copy button next to it is causing WoW to crash x___X Quote:
Power Aura Classic: No iterator found: GetAllAnimations Power Aura Classic: No iterator found: GetAllTriggers and some others in chat. [Edit] Out of curiosity I asked Aura to pick texture from source debuff. Its still activated by target buff, but the icon is taken from its first debuff =) |
I'll take a look when I get home tonight, when you get in next can you click the Matches editbox on the display you created, copy the text and paste it here? Want to make sure that the encoding isn't screwy.
As for the WoW crash, that's an interesting one. I'll take a look. The 'No Iterator Found' messages are fine, as is the 'GetScreenEdgeDistance' one. |
Match for 'Shadow Word: Pain' :
e3tbIkVmZmVjdCJdPSJTaGFkb3cgV29yZDogUGFpbiJ9LFswXT17WyJVc2VUb29sdGlwIl09ZmFsc2UsWyJQYXR0ZXJuIl09ZmFsc2UsWyJFZmZlY3QiXT0iPEJ1ZmYvRGVidWZmIE5hbWU-IixbIlN0ZWFsYWJsZSJdPWZhbHNlLFsiVG9vbHRpcCJdPSIiLFsiQ2FzdEJ5Il09InBsYXllciIsWyJFeGFjdCJdPWZhbHNlLFsiQ291bnQiXT0wLFsiSWdub3JlQ2FzZSJdPXRydWUsWyJDb3VudFNvdXJjZSJdPTAsWyJPcGVyYXRvciJdPSI-PSJ9fQ== Match Tooltip for 'shadow' (with empty 'Match' field): e3tbIlVzZVRvb2x0aXAiXT10cnVlLFsiRWZmZWN0Il09IiIsWyJUb29sdGlwIl09InNoYWRvdyJ9LFswXT17WyJVc2VUb29sdGlwIl09ZmFsc2UsWyJQYXR0ZXJuIl09ZmFsc2UsWyJFZmZlY3QiXT0iPEJ1ZmYvRGVidWZmIE5hbWU-IixbIlN0ZWFsYWJsZSJdPWZhbHNlLFsiVG9vbHRpcCJdPSIiLFsiQ2FzdEJ5Il09InBsYXllciIsWyJFeGFjdCJdPWZhbHNlLFsiQ291bnQiXT0wLFsiSWdub3JlQ2FzZSJdPXRydWUsWyJDb3VudFNvdXJjZSJdPTAsWyJPcGVyYXRvciJdPSI-PSJ9fQ== |
The first string in your post seems to be that of the default UnitAura trigger (it doesn't match Shadow Word: Pain). Either way, I figured out the problem, was a stupid error on my part. I'll put out another release in a couple of hours, sorry for the inconvenience :)
Edit: Uploading now. Also fixes upgrade issues from pre-alpha 6 versions, so deleting UnitAura stuff won't be needed. |
Works well now ^_^ Thanks!
Another little glitch. I set Aura to show when Mind Blast is off cooldown (using 'Spell Off Cooldown' trigger). Works well enough, but if I set in 'Texture Option/Sources': Service : Texture Type : [UL] Name I get either : - Shadow Form icon (this black head) IF i have Shadow Form on me, or - WoW logo IF im out of Shadow Form |
Sources for anything that isn't UnitAura are still very broken/not implemented. I'll probably pull those off for the next release.
|
Is it possible to show 'stacks' of rechargable cooldowns in diffrent aura's? just like it's possible with buffs and debuffs.
i know Roll (monk) and Hand of Gul'dan (warlock) use this system and i would love to be able to show how much charges i have left. |
I may be wrong, but last time I checked (for Warrior's double-charge talent at least) these effects put a buff on the player. You could set up some trigger combination for it - if you have the buff, you've got one charge left. If the spell is on cooldown and you have no buff, you've got no charges left, and if the spell is off cooldown and you don't have the buff then you've got two charges.
I'll play around tonight and see what I can do, maybe implement it as a Charges source/trigger combo. Thanks for the idea :) |
I don't know about warrior's but i don't get a buff from Hand of Gul'dan, nor roll.
I would love you (no homo) if you can add it :D |
Worst case scenario, I'll just scan the combat log for usages of these abilities and then check if a cooldown is present. Might be easier to just do that initially.
If there's any abilities that behave like this that I'm missing, please correct me:
Edit: I'll work on it when the servers come up tonight, assuming maintenance isn't extended. In addition, the next release will have 'linked' displays (got them working before shutdown), so duplicating the configurations if you want a texture/timer tracking the same thing won't be necessary. In other news: Next alpha release will hopefully be tomorrow, mostly as a bugfix one but with some new features (reworked animation editor, linked displays). Layouts have been pushed to 5.1, since I don't have time to work on them just yet. |
There's new API GetSpellCharges, which should return the desired value, at least for player unit. (haven't tested it myself...)
Also, paladins have clemency talent which give an additional charge to all "Hand of ..." spells. EDIT: Just tested it... it takes spellname or spellid as argument and returns 4 values: currentCharges, maxCharges, rechargeStartTime(same format as GetTime()), rechargeTime(in seconds) It returns nil if the spell have only one charge. Also found a bug... calling it with "Chi Torpedo" when having bothcelerity and of course Chi Torpedo talents returns incorect results, checking for "Roll" works fine even if its replaced with torpedo. |
Yeah, the API is really messy with spells that replace other spells. Thanks for the tip though :)
Edit: Uploading alpha 8 now, lots of bugfixes/changes. Doesn't include this trigger yet though, haven't had time to work on it I'm afraid. |
I got some internal changes done last night which will make adding sources a lot easier going ahead. Next release will hopefully have sources for everything as a result. As servers have come down, don't expect it until tomorrow/the day after.
Also, I got that SpellCharges trigger working perfectly fine (sources included) just before the servers went down. Parameters are:
I might consider adding another option (MaxCharges) which would override the maximum number of charges, effectively allowing you to make it so that StacksInvert tells you the number of charges missing from the custom maximum, or TimePerCharge telling you the time until you have <x> amount of charges. |
1 Attachment(s)
For me, PA is the most valuable addon available and I think it's great that you are putting in such effort to work out the issues you have identified. Thank you for creating this awesome tool! :banana:
I am going to try to offer some constructive feedback based on my use of the live version and my testing of the alpha for the new one. If my feedback can be of use to you I’m glad, and if it cannot then I understand, it is probably because I have not fully understood what you are trying to achieve. About the UI... What I find most problematic about the alpha UI at the moment is that the distinction between the Aura Browser and the Aura Editor is a bit confusing. In short, I think you are trying to do too much in the Aura Editor while not letting the Aura Browser manage some of the things that it ought to. I will go into more detail about what I mean. In version 4, we used to have separate pages that contained auras (arranged in matrices), and as I understand it, what you now create and call “Auras” in the Aura Browser correspond to what those pages used to be. They are “containers” in which you can keep your different sets of auras. In turn, what used to be called Auras are now called Displays and these now exist only in the Aura Editor—you both select which one to edit and edit it within the Aura Editor. So effectively, it’s like the Aura Editor isn't just the editor but also behaving as the browser for the different Displays within an "Aura", thus housing some of the utility that the Aura Browser used to. This leads to the structural depth of the Aura Editor becoming very large while the Aura Browser isn’t as useful anymore because it’s not very often that I switch which group of auras that I am working with (not as often as I toggle between individual Auras/Displays, at least). I used to be able to create/delete/select my Aura/Display in one window (Browser) and then immediately be presented with editing options in the other (Editor). Now I basically have to do all of this in the Aura Editor window which leads to a lot of clicking back and forth in the structure. Is there a reason that I don’t understand for why some of the tasks of the Browser have been shifted over to the Editor? At the moment it just feels like the Editor has become confusing, click-intensive and cumbersome to work with. I think it’s a great step to stop having a set number of pages that can contain a set number of auras and instead work with more abstract “containers” of auras. But why are these containers currently called “Auras” and why are the auras themselves called “Displays”? Why not just say that an Aura can now be a texture, a text, a counter/timer, a time bar, etc and these can be organized in something called Groups? On some of my characters I use between 50 and 100 auras. In those cases it’d be great to have elaborate ways of organizing them but I also realize that many people probably settle for making 5 to 10 auras and are happy to just have them stored in one simple group. Thinking about the alpha of the new PA gave me the following idea, which is really just an idea and I have no clue how well it fits with either your design intent or the coding behind PA—but for a moment, suppose the following: Within the Browser you can create Auras and Groups. An Aura can be a texture/text/timer/etc. A Group has no visual representation on the screen but can contain other Groups and/or Auras. (So it’s basically like a hierarchical folder/file system.) Now, while the Group doesn’t have any visual representation on the screen, it still has its own positioning parameters (just a non-visual anchor point), and can have its own activation triggers (which are then inherited by any Groups/Auras within the group). So, for example, if you have a number of Auras that you want visible only when you are in combat, you can make that a trigger for the Group and then you don’t have to set each Aura within the Group to only display when in combat. I also see a potential here that it might make for performance increases since it might then be possible to program the addon so that it will know that it can ignore trying to evaluate any triggering parameters of the individual Auras within a Group if the Group itself isn’t triggered. A system like this could accommodate very complex collections of Auras, while at the same time, for the user that is satisfied making just 5 to 10 Auras, he/she doesn’t need to worry about creating any Groups or the complexity that can be achieved thereby. So it is up to the individual user’s needs how advanced and deep the structure of this part of the addon becomes. So basically, the Aura Browser would handle Auras and Groups in terms of create/delete, cut/copy/paste, import/export and selection. Whenever an Aura or Group is selected, its properties are opened for editing in the Aura Editor window. (The Aura Editor would now be a relatively shallow structure, not needing the breadcrumbs anymore, but instead the Aura Browser might require some sort of breadcrumbs structure to handle going back up in the Group hierarchy.) And, as already said, triggers and positioning (maybe even a scale multiplier) would be inherited through the Group hierarchy. I realize that this design might be far from feasible when compared to current design intents and I’m sure you can see many problems with it, but I wanted to share it none the less as an idea that I think would make the UI work better at least for someone using PA the way I do. I also realize I haven’t mentioned anything about how custom made triggers or sources would work in this design but that is because I don’t feel like I yet understand how you mean for them to work on the whole. I would imagine though that the Browser would also handle the creation/deletion/selection of these and that the Editor would then be where their properties were handled. I made a visual example of how I imagined the Browser possibly working in case my explanation in text managed to be unclear. I hope you don’t take offense to me playing around with your design so directly. I in no way mean that my suggestion is flawless and I fully understand if it is of no use to you in any way. :) |
The reasoning behind the naming 'change' for auras/displays was mostly for some similarity in what the code calls <x>. I could have kept the names, but it's one of those things that'd require a lot of changes to the localisation strings. That said, the Sources system isn't called Sources in the code, so I guess this is kind of a moot point now :)
I do agree that the browser seems somewhat redundant, I've been toying around with the idea of just exposing displays on the browser directly with the auras acting as the groups (similar to your suggestion - except without any logic/positioning for groups). I wouldn't mind giving it a try, certainly. I'd probably not allow groups to have any impact on the logic, the reason being that not even the current containers (auras) affect the logic in any way - they exist purely for grouping purposes at this point. In fact, auras themselves didn't exist until after 100 changesets into initial development - a point where everything else was already in a working state. I certainly wouldn't be averse to making it clearer about what display is linked to what internally. Maybe (borrowing your mockup) something like this would be in order, whereby displays that are linked to each other by their activation criteria (as added in the latest release) would appear in subgroups under the selected aura together. You could then rename the subgroup if the name is too vague (it'd be based off of the first 'Main' trigger, so Unit Aura in the example), and change the colouring of the group while you're at it. To edit a display you'd simply click on it. Groups containing groups would probably be a no, since the aura/group hierarchy shown should suffice, for instance you could name an aura "Buffs" and name each individual group after the buffs those displays are responsible for tracking. As for things like exporting/deleting an aura only being available in the editor right now, that's just a temporary thing. Right clicking an aura in a future release will have a context menu for this stuff, with the current tasks remaining as another way of pulling it off. Thanks for the feedback at any rate :) |
Alpha 9 is out, has that SpellCharges trigger in it and basic sources support for ComboPoints/SpellCooldown (the latter also has new options, including ignoring the end of a cooldown if the GCD is currently active).
As for the previous post with the UI ideas for the browser, I'm going to try them out tonight and see what it ends up looking like. |
Maybe you are aware of it, but I notice on my prot warrior the Spell Off Cooldown trigger doesn't seem to be working as intended. The Ignore GCD and Ignore GCD End checkboxes seem to have no effect. (Maybe it's only the Ignore GCD that isn't working though, making it seem as if the Ignore GCD End has no effect.) On my enh shammy they appear to be working perfectly (and I have to say that the Ignore GCD End is going to be VERY useful!)
|
The GCD detection probably needs fixing for certain classes, since it uses baseline spells (Warrior is set to use Strike). I'll play around with it real quick and see what's up :)
And yes, if Ignore GCD isn't working properly then the end will also not work as intended. Edit: They removed Strike (seem to start with Heroic Strike directly now). Setting it to use Execute instead. Should be working, but I'm testing with about ~800ms so any real GCD testing is kind of hard to pull off :) |
I have three small requests, in case you'd be interested in taking them into consideration.
1) Exact colors I have so many times been wanting to have several auras match each other in color. It's seemed to me that the only way to make sure you have a perfect color match is to work with duplicate auras (to preserve the color from one to the other). I would love it if the color picker had some option to enter a color numerically, in RGB or Hexadecimal or whatever, just some way of ensuring that you are using the exact same color on two auras. 2) Animation speed in seconds I often use auras that spin like an egg-timer to visualize the duration of a short buff or sometimes a cooldown. Like for instance if I suddenly get a Sword and Board proc I have a little spinning aura show up that tells me "you have to consume this proc before this egg-timer is pointing straight upwards" (typically I would do this with an arrow type of texture that has a clear direction in which it's pointing). It works very intuitively for me in feeling how long I have before the buff or whatever expires and I prefer it to timebars. What I'm wondering is: wouldn't it be pretty easy to just have the animation speed slider be marked in seconds instead of just as a multiplier? As far as I have noticed, having the animation speed at 1 currently means that the animation will take 1 second per repeat (per rotation in the case of a Revolve-Clockwise animation). Wouldn't it be more useful to have the slider go from say 0.25 sec to 60 sec in intervals of 0.25? It seems to me that it would just be a matter of writing a little function that converts seconds into a multiplier of 1. I also can't really see that it would mean a downside when it comes to any other uses of animation speed. Naturally its possible for me to do this conversion manually (as I have been trying to do in version 4) but the problem is that some durations aren't currently possible to achieve exactly. 3) Time Frame trigger I think it would be useful to have a trigger that simply restricts the display of an aura to a customizable time frame. What I mean by this is simply a trigger that has two parameters: Onset and Duration. If I set Onset to 5 seconds and Duration to 20 the aura will not appear immediately when all other trigger conditions are met but instead it will wait 5 seconds and if the trigger conditions are still being met it will then first actually display the aura. After that it will display the aura for a maximum of 20 seconds as long as the rest of the trigger conditions are met. I see a trigger like this as being very useful for tracking internal cooldowns of trinkets etc when the ICD is known by you personally but PA doesn't have any other way of tracking it. There are other situations as well in which I think this kind of trigger could be useful but I won't go through all of that. In version 4, there was a duration slider on the animation tab which only went as far as 30 seconds (not making it useful for tracking most ICDs). This slider seems to only hide the display of the aura though while still considering the aura logically turned on. I think it would be beneficial to have a time frame type of trigger that actually in terms of logic considers the aura itself turned off if the conditions of the time frame aren't met. Maybe the trigger explained above could simply be a development of the current Time Remaining trigger. The difference, of course, being that the suggestion I made has its chronological anchor point at the start of the trigger whereas "Time Remaining" has its base in the end point of the aura's duration. This could just be a matter of adding a checkbox that distinguishes between the Onset being in relation to the start or the end of the auras expected "life time". In other words, example: begin showing the aura 10 seconds from the start OR end of the aura's duration and show it for a maximum of 5 seconds thereafter. (I think the current restriction of 10 seconds in the Time Remaining trigger seems unnecessarily low though.) Anyway, I realize that even if you would be interested in incorporating these requests they won't be (and shouldn't be) very high on your priority list but they are things I have been thinking about that I feel could improve the usability of the addon. Keep up the great work! :) |
Quote:
Quote:
Quote:
Time remaining having such a low limit is unintended, I'm still doing a polish pass on them + the animations (hence why SpellOffCooldown just got significantly improved). Edit: I came up with a possible really easy way of implementing a time frame system. It won't be as a trigger, but rather I could expose some settings on the Activation action. They'd be available in the advanced editor, I'll give it a shot when the servers come up tonight. In short, if I'm right, I could just stick some parameters onto the DisplayActivate action which control an onset delay and a time window to show for. They'd also be at a per-sequence level, so you could have multiple sequences with different durations if desired. |
Regarding (1) you can use ColorPicker Plus that modifies/enhances the default colorpicker.
|
Quote:
|
I'll probably do a new release tomorrow. Server shutdown = 10 hour maintenance = not much I can really do.
I did put in a Talents trigger though, so you can limit activation based upon your chosen talents. |
I got a basic implementation of a time frame for displays done. At the moment you can set an onset (a delay before it shows) and a duration (the time period for which it shows).
If the onset is 0, there's no delay, and if the duration is 0 then the display will hide when the criteria are no longer met - so you can use either of the features without needing both of them. If both values are zero, you get the current behaviour with no code changes (the implementation is really messy). A small implementation detail, the rate at which these are processed is limited by your Update Speed setting. If it's too low, you'll notice minor delays in when the displays should show/hide. In addition I've currently got advanced features which change how these behave. No guarantees these will all survive, but in basic testing they're all working perfectly:
Due to how this is implemented, it's highly unlikely that there'll be a way to use the duration information for timers/bars/triggers and whatnot however. This might change at a later date. |
Wow this sounds amazing! I think a trigger like this can add a lot of creative usability, especially with the added features you describe. I'm excited to get to test it. :)
|
Yeah, it's hell to test all these combinations though.
I'm extending the Rolling Onset setting to be the same as the Rolling Duration one too, and adding an additional setting for handling the current progress during sequence changes. Edit: Enjoy testing it, you'll find the settings in the advanced activation editor by the trigger operators/sequences stuff. I'll expose the onset/duration settings in the basic one too at some point. On a side note, I'm feature freezing on either Tuesday, Wednesday or Thursday at the latest. I'll have all the necessary triggers/sources done by then hopefully (aiming for the next release, in fact). After then any new features/triggers/whatever will be postponed until 5.1, the time between the freeze and the 28th will be the official beta-quality period, with a release planned on the 28th. Might be postponed to the 29th if needed. |
When I create a Display in advanced mode (with multiple triggers: !1&2&!3) I get the following error showing up (count continues indefinitely). The Display also won't appear when it should. (In this particular example, triggers 1 and 3 are Spell Off Cooldown and 2 is just the normal Player Status.) If you want more details just let me know.
Message: :14: attempt to call upvalue 'T3' (a nil value) Time: 08/19/12 05:30:37 Count: 1504 Stack: :14: in function `action' Interface\AddOns\PowerAuras\Dispatcher.lua:108: in function <Interface\AddOns\PowerAuras\Dispatcher.lua:93> |
This is why I shouldn't alpha release at 2am :p
I'll see what's up with it. Edit: Found the problem. Fixed the problem. Uploaded the non-problem. |
New error, same situation. :)
Trigger operators are as follows: !1&2&!3. Triggers 1 and 3 are Spell Off Cooldown, trigger 2 is Player Status. When spell 1 is On Cooldown (!1 == TRUE) there is no error, but as soon as spell 3 is On Cooldown (!3 == TRUE) then a repeated error starts counting and the Display does not appear. So in other words, !1 seems to be handled perfectly but !3 seems to create an error as soon as it holds true. Triggers 1 and 3 are identical except for spell name. Code:
Message: ...Ons\PowerAuras\Classes\Triggers\SpellOffCooldown.lua:85: attempt to index local 'store' (a nil value)If I then reintroduce the Player Status trigger as trigger 3 with then the trigger operators as: !1&!2&3, the error does not occur. Let me know if you want more details. Also... I have noticed a small issue with the Ignore GCD End option. If I have this checked and the associated spell is on cooldown, and I then trigger a GCD when the associated spell's cooldown has between 2 and 3 seconds left, then the Display associated with the Spell Off Cooldown trigger will flash for a moment when the GCD is over (but the associated spell itself actually has between 1 and 0.5 seconds left of its cooldown). Here is a manual time log to be extra clear: 0 seconds: Spell A has 3 seconds left on its cd (Display for Spell A is not showing) 0.5 seconds: Spell A has 2.5 seconds left on its cd and a GCD is initiated (Display for Spell A is not showing) 2 seconds: Spell A has 1 second left on its cd and the GCD is just finished (Display for Spell A incorrectly flashes for a brief moment) 3 seconds: Spell A's cd is finished (Display for Spell A is correctly showing) |
Fixed the first bug. If you want to fix it locally, change line 26 in PowerAuras\Types\Triggers\Loader.lua from:
Code:
tinsert(actionData["Stores"], class:InitialiseDataStore(params));Code:
tinsert(actionData["Stores"], class:InitialiseDataStore(params) or false); |
Quote:
|
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 :p |
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.
|
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 :) |
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.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! |
Aiming for another release tonight, I'll quickly summarise each point you've raised though (thanks again for all the feedback by the way):
As for the features going ahead:
As you can see, a lot of things to do :) |
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.
|
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 :) |
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:
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:
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.
|
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 :o (Other error I fixed by removing files with Auras I did set in older build) |
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. |
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. |
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 :)
|
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 |
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 :p
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. |
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:
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. |
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. |
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. |
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).
|
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. |
| All times are GMT -6. The time now is 04:57 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI