[Tree] Question on Haste

Topics: Rawr.Tree
Mar 23, 2009 at 5:49 PM
Is there some way I can get Rawr to include the 1sec soft cap on haste is reached while optimizing gear?
Coordinator
Mar 23, 2009 at 5:52 PM
Not currently... Trolando, looks like there's no optimizable stats for Tree; wanna add some?
Mar 23, 2009 at 8:04 PM
Okies, thanks for the quick response... thought I might be missing something :)
Mar 29, 2009 at 8:13 AM
Edited Mar 29, 2009 at 8:14 AM
Actually... is 'Trol' is doing this?.... wow this would be hugely beneficial!  I love RAWR, but I have to hit the sof-cap on the gcd, so wind up using spreadsheets until I've geared up way past it.
Developer
Mar 29, 2009 at 2:03 PM
I have to ask why you want to force this constraint? If your real goal is to maximise burst healing output, just optimise for that value, it includes haste and nature's grace effects in the model, along with crit and spell power effects.
If you are going to optimise for sustained healing output, haste will only fully come to its own, if you don't run OOM during the fight and have mana remaining, else the model will reduce your casting fraction in order to conserve mana.

If I understand better your reasoning, maybe we can ensure that the model inherently considers it (or allows it to be considered easily).

Patch 32639 now exposes some values, but I'm not sure if they are what you need and are the easiest format to use.
Mar 31, 2009 at 12:35 PM
Edited Mar 31, 2009 at 4:12 PM
To clarify (I hope)... when optimizing, for say my mage... the hit-cap can be included as a requirement, and the optimization is being done on the best gear I can have after that cap is reached to keep up an optimal rotation.

For healing, I need to not only ensure I'm getting the best throughput or not going OOM, but also that when I'm hitting a heal for an emergency situation, outside 'perfect' rotation, that I've reached the soft-cap GCD so I can fire off that big heal to save someone as quickly as possible. 

Currently when I optimize my gear, I come up short almost an entire second from reaching my 1 sec haste soft-cap, meaning I'm at a disadvantage for a 'save that person who is almost dead' knee-jerk reaction. 

Basically, I want to be able to treat that haste soft cap as a necessity, because it's not all about a rotation for healing. 

So I look at it a bit like the hit cap... I want to 'force' that soft-cap of haste (1 sec GCD) to make sure my 'oh shit' heals are fast enough, and then optimize on top of that.  If more haste gets added after that (as you mentioned, particularly in the sustained model), that's great, but I still need to ensure that when things get hairy, I've cut the time off the GCD to save someone as fast as possible.

Does that make more sense?

And thank you for looking at this!

Edit: Also, the OP of this EJ thread has the Haste rating break-down druids are using to ensure that soft-cap is reached.  Most restos consider that 1 sec GCD a requirement much like the hit-cap for other classes/specs, so of course talents and raid composition come into play as well as listed there (and sorry if I'm giving you tmi, just not sure if you're a resto druid or not =P).
Developer
Mar 31, 2009 at 7:50 PM
I play a druid in a 10-man guild. It tends to change from week to week :-)
So I know the basics, but definately not an expert.

Plus I typically play with 600ms of lag, so to me, cutting of a few miliseconds of the cast, doesn't feel like it will make a difference. If you get yourself in that much trouble, hope your important enough that my fellow healer will save your ass, or that I am willing to use my battle res on you.

Furthermore doesn't your instants hit at the beginning of the cast, so for swiftmend and nature-swiftness as oh-crap buttons, haste shouldn't matter (unless you need 2 gcd's to use).

I cannot think how to easily incorporate that into the model. I don't want to artificially penalise your throughput, if your not haste capped. The extra constraint should probably be able to help you achieve what you want though.

Please just help check the haste numbers. I did a quick compare against the post you mentioned, and the model seems to be aiming for 504 haste rating for the soft-cap, and 1640 for the hard cap (with no buffs or talents) while they quote very different numbers there. (These values are calculated, not coded as constants. Maybe a formula issue?) The conversion ratio of 32.79 does seem to be correctly used. I'm guessing something else isn't being modelled. Under the talents tab, it looks like Celestial Focus isn't getting a value, so that might be part of the problem. I'll look into that, but if you can find anything else, please let me know.






Developer
Mar 31, 2009 at 8:21 PM
Edited Mar 31, 2009 at 8:22 PM
Ok, added haste buff from Celestial Focus and fixed formula for soft-cap calculation (patch 32712). Now haste numbers are looking much closer to numbers in the EJ Post.

But yell, if you still find any further differences.
Mar 31, 2009 at 10:51 PM
I don't know how to load up the source :(
Coordinator
Apr 1, 2009 at 12:44 AM
Wait for b6.
Apr 1, 2009 at 3:47 PM
Ah okies cool... thanks again for this!!
Apr 7, 2009 at 10:17 AM
I posted elsewhere, but as this is the thread we'd chatted on, thought I'd repost here:

The new tree additions are confusing to me.  I LOVE that restrictions are being added... but as the person who brought them up, found myself confused as to how to use them.

There are people WAY better at math than I am who can help I'm sure... but I wanted to bring up the stuff I was confused about.

I mentioned the 1sec GCD soft-cap as a semi-requirement for restos, there seems to be several different haste choices, when only the one is the typical.  From those choices, I've been unable to optimize my gear.  One I realize is a bug that is unrelated with items not being slotted, but the others I think come from too many choices... I just want to hit the one soft-cap, and there's a bunch of haste choices, and I'm not sure what they all mean.

I 'think' (correct me if I'm wrong), I should have 3 optimization choices:

   1. Overall Rating
   2. Heal-burst
   3. Heal Sustained

And what I expected in the Optimizer (again, sorry if I'm fumbling this).
I could add a requirement of 'haste soft-cap' and it would optimize my gear based on one of the 3 above optimizations while meeting (or coming close to) that soft-cap... INCLUDING buffs I'd manually added as well as my talents.

Perhaps I'm doing it all wrong and don't understand how to set it up, but I *think* I do... but by manually switching out my gear, I got myself to 4pts below the haste soft-cap, and had a higher score for all 3 of the above optimization choices.

I TOTALLY understand that Rawr isn't perfect and thrilled about the work that has been done on the tree module... I'm just confused why the haste soft-cap isn't a static requirement option and why there are so many haste options.  Perhaps when messing with it, a bunch got uploaded?

Again, thanks for doing this... just after asking for it, I'm still confused how to use it.... requiring +hit on my mage optimizes, +haste on my druid does not.


Coordinator
Apr 7, 2009 at 4:54 PM
Can you explain what actually doesn't work? We don't understand what you're asking.

Having almost never used Tree before, just looking at what requirements are available, it makes sense to me that you'd optimize for Overall Rating, with an additional requirement of 'Haste until Soft Cap <= 0'. Or if I wanted a specific percentage of haste, 'Haste Percentage > 30' or whatever.

Is this a usability issue? What are you expecting that you're not seeing?
Apr 7, 2009 at 6:04 PM
Think of the haste like +hit for mages... it's a static number, which of course is effected by talents/buffs.

On my mage, if I put in 237 MUST be attained (this means I get every buff possible from boomkins, dranei, etc). i.e. Hit rating >= 237

Optimizing puts me within 2 of the hit cap


On my druid, if I put in the number that must be attained with all buffs: i.e. Haste rating >= 253

Optimized for Overall Rating using 253 haste as an additional req I get:

   1. Overall Rating: 14122
   2. Heal-burst: 5100
   3. Heal Sustained: 9022
   4. Haste Rating: 188
   5. GCD: 353 short

Running the optimizer without the haste req I get the EXACT same numbers as above.

Manually adding my gear, I get:

   1. Overall Rating: 13850
   2. Heal-burst: 5183
   3. Heal Sustained: 8567
   4. Haste Rating: 320
   5. GCD: 221 short

Now granted, my Over-all Rating & Heal Sustained is lower in my manual gear... BUT I really care about that haste rating getting damn close (like a mage gives up dps for +hit), so as far as I can tell, the gear isn't getting optimized to meet that requirement.

Does that make sense, or am *I* doing something wrong?












Coordinator
Apr 7, 2009 at 6:29 PM
Edited Apr 7, 2009 at 6:30 PM
Uhmmm... I'm confused. In the model I'm looking at (latest dev version), there's no additional requirement for a specific number of haste rating. So I don't know what you're optimizing 'using 253 haste as an additional req'. I don't think there should be an optimizable value like that, either. We don't want users to have to look up specific breakpoints of numbers of haste ratings on other websites or calculate it or whatever. We want users to care about what actually matters. The haste % actually matters. Whether you're past the soft or hard haste cap actually matters. And those things adjust based on everything that affect them, including buffs, talents, whatever, not just haste rating. Are you not able to optimize for what actually matters?

Again, I have very little experience with the tree model, so please correct me if I'm wrong. It's very possible that this is broken somehow, and I look forward to wildebees responding soon. I'm looking at the latest development build too, so it may be that the optimizable value you're using was removed since b6 came out or something? I'm not sure.
Apr 7, 2009 at 6:45 PM
I guess we're coming at it from two different mindsets... so bear with me =)

The haste was JUST added in b6, wildebees was a rockstar for putting it in =)) so this is all new... but a resto druid drives to hit a haste soft-cap of 1 sec GCD.

In a raid with every single talent and buff possible (perfect world) that takes a haste rating of 253.

AFTER that cap is reached, we'd want our gear optimized.

And I guess I'm confused about what you mean by "actually matters".... for tree, getting that GCD down does matter, and having gear optimized ignoring that as a requirement doesn't work.  You can look at a mage rotation and balance out +hit against dps, and come to a happy medium... but for a healer, that GCD is about firing off a quick heal, not a rotation, so the haste has to be met, regardless of how it 'optimizes'.

Does that make sense?


Coordinator
Apr 7, 2009 at 6:55 PM
Edited Apr 7, 2009 at 6:56 PM
Right, but the haste rating doesn't matter on its own, does it? It's just part of the equation.

haste rating + talents + buffs (+ some other stuff?) = Total Haste

Total Haste is what matters. That's what brings your GCD down, right? Rawr users should not have to know that 'In a ... perfect world ... [it] takes a haste rating of 253'. And they should be able to use the exact same optimization requirements for whatever buff/talent situation they're in. Rawr should just 'automagically' get you to the soft haste cap (if that's what you set for requirement), for whatever situation you're in.

Standard Disclaimer: I've spec'd tree once in my life, am terrible at healing, totally unfamiliar with the Tree model, so again, take everything I say with a huge grain of salt. Wildebees, help! :)
Apr 7, 2009 at 7:01 PM
Edited Apr 7, 2009 at 7:14 PM
It's a language/thinking issue (and somewhat a display one too I suppose) but NOT a code issue (btw, I'm Rusty's hubby, so I'm not just randomly jumping in =P ).

After reading through this I was able to get optimizer to do what she wanted using the current Beta version.  It is not completely intuitive (at least to me) but it works...I got a set of gear that gave her 259 haste from gear (and it recognized that was -6 haste from the Soft Cap).  The Global CD shows at 1.25 seconds, which, while that is probably right for spells not effected by GotEM, is NOT the number that resto druids generally care about, as the GCD really only matters for their instant cast spells, which ARE effected by GotEM, and would therefore have a GCD of 1 second (not 1.25).

But it looks to have done everything asked of it properly...just doesn't actually show the 1 sec GCD that she expected.

For the record, method of use was as Ast suggested above:

Haste until soft cap <= 0
Coordinator
Apr 7, 2009 at 7:07 PM
Ah hah. So would everything be solved if we made the following changes? (bear with me, bear at work, not a tree)

A) Show both "Standard GCD" (1.25 in that case), and "Instant GCD" (1.0 in that case) on the main screen.
B) Provide both of those as optimizable values, so that you could do the following Optimization:
Calculation to Optimize: Overall Rating
Additional Requirement: Instant GCD <= 1.0

Would that be more easily understood? I agree that that 'haste until soft capped' value seems kinda odd.
Apr 7, 2009 at 7:16 PM
Edited Apr 7, 2009 at 7:20 PM
That would make a lot more sense to me, that's for sure.

While we're on the subject of trees, I just noticed that running the Optimizer on her gear caused Rawr to buff her OH with Exceptional Spellpower, which is obviously wrong, since ES is a weapon buff.  Seems like it's probably a bug, although I've not ruled out user error on my part. =P

Edit:  Should I move this last piece to some other part of your web site?  I see an "Issue Tracker" section...
Coordinator
Apr 7, 2009 at 7:25 PM
That's a known display bug. I think it doesn't actually count those stats, it just shows the enchant, but doesn't actually count it. Wildebees, let me know if you need help fixing that; it's pretty simple.
Developer
Apr 7, 2009 at 7:31 PM
Edited Apr 7, 2009 at 7:34 PM
Sorry for not responding earlier, I just got online.

Yes, trees are now in a bit of a weird situation, where there are 2 GCDs being used, one for "normal" spells and one for certain spells, which benefit from the GotEM talent. I didn't invent the naming, it was in the model like that, and just exposed it in the most unambiguous way (in terms of the code). The question is what terminology does the normal tree community use? (I'm only a part time healer myself).

I had problems trying to have constraints based on floating point numbers. I'm not sure if they are supported, that is why I exposed the fields in the way I did as percentages or rating values.

Firstly the actual requirement for a haste rating value of 253, is some calculation some1 did determining conversion factors, assuming certain talents, group buffs etc. (Even the elitistjerk link that was posted earlier in this thread, provides a table of values instead of just a single 253 constant. So I agree with Astrylian, that the user should never have to specify that value, since it depends on too many things to remember. If you want to specify something, you want to say you want haste to get you within X (percent/rating/time ratio) of the cap, whatever is more intuitive to you. And again, remembr, you are adding it to fullfill some sense of better that you have, that doesn't neccesarily exist in the true model/game. (In your case, you want to be able to land an instant (rejuv, wild growth or lifebloom) in 1 second. Why? Since a single tick of any of those are not likely to save the target. In my opinion atleast).


Ideally you should probably be aiming to reach the hard cap, if you really want to aim for something, but practical?

I can add the time value in there, just not sure if I add the time in tenth of seconds, or what units to cause the least additional confusion.

*Edit: Moved to end of post* Advice on fixing the off-hand enchant bug would be appreciated. Thanks in advance. (I also don't think it is being used in the calculation though)


Apr 7, 2009 at 7:33 PM
Edited Apr 7, 2009 at 8:04 PM
Thanks for straightening me out! 

It's working great now that I understand what the hell I'm doing.  I was using >= on the cap, rather than <=

... sorry for the confusion!

And big hugs and kisses to everyone involved in adding this!!!

[quote]Ideally you should probably be aiming to reach the hard cap, if you really want to aim for something, but practical?[/quote]

I'd 'guess' the hard-cap gets thrown under the bridge over loss of other stats... but I've not delved to far into 3.1 gear, so who knows :D
Apr 7, 2009 at 7:43 PM
And yes, I checked...the bug is cosmetic only...no impact to the numbers.

Thanks for everyone's help! =)
Coordinator
Apr 7, 2009 at 7:50 PM
Thanks for all the help, everyone. So much of making Rawr work for people is just usability issues, not technical issues, and we need help understanding how best to word it for users, so thanks for that. :)

Wildebees, you're looking to override CalculationsBase.EnchantFitsInSlot(), and return false if it's a weapon enchant and it's in the offhand.
Developer
Apr 7, 2009 at 8:06 PM
Thanks Astrylian, I will have a look at that.

RustyDogma, you might be right that the hard cap is achievable and might not sacrifice too many other stats. I haven't looked at 3.1 gear at all, so cannot comment on that. But I just tried to make the point that I cannot just add a single constraint haste capped, since different people might want different values. You were implicitly asking for the haste cap on rejuv and lifeblooms, while now you are hinting at changing that constraint to be the haste cap for other spells (nourish, swiftmend, etc.) in 3.1 gear.

I'm actually also not very happy with the way haste percentage constraint is used currently, since you still need to lookup/calculate that the cap would require about 20% for GotEM spells. Would percentage from cap make more sense, or is the haste percentage an ok value to have available?

Developer
Apr 7, 2009 at 8:27 PM
Astrylian, shouldn't that check be part of CalculationsBase so it can be used by all models, instead of being applied in each model seperately?
I realise you need to be careful with dual-wielding, but it should be possible to distinguish between an offhand item and a second weapon or are their types not distinguishable?
Developer
Apr 7, 2009 at 10:05 PM
Patch 32903 checked in (should be included in the next beta/release, whenever that is released):
Disabled all Offhand enchants for Trees.
Added GCD and Lifebloom GCD values on main display and Optimisable Value list (as millisecond values).

I now use Lifebloom GCD instead of talking about the soft cap.

I think the time value will probably be the easiest for users to use in the long run, but for now I leave the other variations (haste percentage, rating until GCD or Lifebloom GCD caps) in there as well.

I trust you guys will manage with the current version, until the next release, when this naming takes effect. But let me know if there are additional changes that you expect will make life easier.