|Go to Page...|
|Thread Tools||Display Modes|
|08-14-12, 06:34 PM||#81|
A Murloc Raider
Join Date: May 2011
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.
Last edited by Gragagrogog : 08-14-12 at 09:11 PM.
|08-15-12, 07:19 AM||#82|
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.
Last edited by Meorawr : 08-15-12 at 02:50 PM.
|08-16-12, 01:04 PM||#83|
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.
|08-16-12, 02:29 PM||#84|
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!
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.
|08-16-12, 02:59 PM||#85|
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
Last edited by Meorawr : 08-17-12 at 02:02 PM.
|08-17-12, 02:03 PM||#86|
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.
|08-18-12, 09:04 AM||#87|
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!)
|08-18-12, 09:08 AM||#88|
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
Last edited by Meorawr : 08-18-12 at 09:20 AM.
|08-18-12, 10:07 AM||#89|
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!
|08-18-12, 10:16 AM||#90|
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.
Last edited by Meorawr : 08-18-12 at 03:05 PM.
|08-18-12, 11:11 AM||#91|
A Pyroguard Emberseer
Regarding (1) you can use ColorPicker Plus that modifies/enhances the default colorpicker.
|08-18-12, 11:14 AM||#92|
|08-18-12, 12:04 PM||#93|
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.
|08-18-12, 06:10 PM||#94|
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.
Last edited by Meorawr : 08-18-12 at 06:17 PM.
|08-18-12, 06:28 PM||#95|
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.
|08-18-12, 06:32 PM||#96|
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.
Last edited by Meorawr : 08-18-12 at 07:39 PM.
|08-18-12, 09:39 PM||#97|
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
Stack: :14: in function `action'
Interface\AddOns\PowerAuras\Dispatcher.lua:108: in function <Interface\AddOns\PowerAuras\Dispatcher.lua:93>
|08-19-12, 04:08 AM||#98|
This is why I shouldn't alpha release at 2am
I'll see what's up with it.
Edit: Found the problem. Fixed the problem. Uploaded the non-problem.
Last edited by Meorawr : 08-19-12 at 04:41 AM.
|08-19-12, 10:05 AM||#99|
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.
Message: ...Ons\PowerAuras\Classes\Triggers\SpellOffCooldown.lua:85: attempt to index local 'store' (a nil value) Time: 08/19/12 17:40:53 Count: 494 Stack: ...Ons\PowerAuras\Classes\Triggers\SpellOffCooldown.lua:85: in function <...Ons\PowerAuras\Classes\Triggers\SpellOffCooldown.lua:48> :9: in function `action' Interface\AddOns\PowerAuras\Dispatcher.lua:108: in function <Interface\AddOns\PowerAuras\Dispatcher.lua:93>
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.
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)
|08-19-12, 10:25 AM||#100|
Fixed the first bug. If you want to fix it locally, change line 26 in PowerAuras\Types\Triggers\Loader.lua from:
tinsert(actionData["Stores"], class:InitialiseDataStore(params) or false);
Last edited by Meorawr : 08-19-12 at 10:28 AM.
|WoWInterface » Site Forums » Archived Beta Forums » MoP Beta archived threads » Power Auras Classic 5.0|