This project is read-only.

[Tree] 2.3.0 Fight Options

Topics: Rawr.Tree
Dec 8, 2009 at 5:26 PM

I'm trying to get a handle on the new options in 2.3.0, in the Fight tab. 

Rejuvention: Does "Average number of Rejuvenations" refer to the number you cast per minute, or the number of HoTs that you keep rolling?  I assume the latter, since most people cast more than 6 per minute :).  However, I also often keep more than 6 rolling, so maybe it's something else that I'm not thinking of?  If my primary spell is Rejuvenation, how does that interact with this slider?

Regrowth: Like rejuvenation, I'm assuming "Average number of Regrowths" is an indication of the average number I have rolling.  This must assume I never clip them, though, since even if I turn it all the way to 6 it shows no benefit from Glyph of Regrowth.  Am I understanding that correctly?

Living Seed: Does "Living Seed average" mean the amount of a living seed heal that should be considered "effective"?  If so, is this an indication that our HoTs are going to receive similar options in the future?

BTW - much props for the "Idle percentage" slider - I think that's going to be very useful for me.

Dec 10, 2009 at 2:54 PM
Edited Dec 10, 2009 at 2:55 PM

I see this is a work in progress!  (2.3.1 has many revisions to this tab, just 2 days later.)  I'll post my new assumptions/questions here, either so you can set me straight if it's done, or so that you have another user's perspective if it's still in development.

The top 3 casting % sliders: Are these % of total casts, or % of time spend casting?  Does 100% mean that's the only spell I ever cast, so that the "primary spell" is used to fill in the difference should I choose less than 100%?  Should I make sure that the sum of those three plus the idle percentage slider at the bottom add up to no more than 100?  I know from the behavior I see when playing with these slider that many of my "assumptions" here are wrong, I just don't know what's correct.

Average number of Lifebloom Stacks: This slider goes up to 8.  Does that mean that I "stack" it 8 times before letting it bloom (5 of the "stacks" are actually just refreshing the 3-stack), or that I keep stacks rolling on 8 people?

Living Seed average: same question as first post: does this mean the amount of a living seed heal that should be considered "effective"?  If so, is this an indication that our HoTs are going to receive similar options in the future?

Wild Growth casts per minute: Do I need to make sure that my casting % sliders at the top leave enough casts/time under 100% to fit these casts in?

I'm excited that the tree model is getting some love!  Thank you for your development!

Dec 10, 2009 at 3:55 PM

Err, hi.


Time I got a look on the website again. Yes, I've resumed work on the model (I quit WoW for awhile in May), and am busy in the process of adding loads of new stuff. You're welcome to contact me (I think you can find my address somewhere here or PM me by ElitistJerks). It's a good thing to receive feedback from someone who uses the model a lot.

My small to do list:

- add talent trees to default

- more explanation of glyphs (what is modelled is "burst" (on single target, it will automatically figure out which combination of rejuv/regrowth/lifebloomstack/swiftmend/nourish is best) and "total healing in a fight", so it does not take into account how fast you can heal someone in the raid (reaction speed) and things like that .... basically there are all sorts of reasons not to depend on Rawr to select glyphs (e.g. I have Swiftmend glyph, because the target you heal is probably the one that needs attention so you want to keep rejuv on him, and this is something Rawr doesn't really take into account)

- custom charts (mana sources, mana spent per spell over total fight, healing done per spell over total fight, hps per spell, healing breakdown for single target, comparison of single target burst spell mixes)

- ability to select single target burst spell mix (currently: auto)

- perhaps add % for wild growth actual usage and similar for other hots

- add a 3rd variable "reaction healing" which gives the most healing you can cast within X seconds to have maximum effect in Y seconds (e.g. you have 3 seconds to cast and 8 seconds for total healing)

- make the variables Burst/Sustained/Overall relative instead of absolute (relating to a "target" amount of healing, so you can say "I'm ok with my 15000 hps burst, but I want 7000 overall hps in the 5 minutes" - currently you need to fiddle with the slider (burst vs sustained) for that

- much more explanation of how the model works


To your questions.

Rejuvenation - it first was "amount of rejuvenations active on average", but now it is "% of time spent casting rejuvenation"... If the total of your spells goes above 100%, it is automatically scaled down. The idle percentage is a way to control your primary spell only (so if you have 60% spent casting hots and you have 50% idle time, you will get 40% idle time and 0% primary, but if you want 10% idle time, you will get 10% idle time and 30% primary spell casting)

Regrowth - assumes you don't clip it, that's correct. Perhaps I could add a slider for that, too.

Living Seed - Yes. Hmm, good idea. If I keep adding sliders, it will get messy but perhaps there's a way around that. Maybe it's not needed for the normal hots and only for living seed (you can't control it so it often heals targets that are 100%)

The Idle Percentage slider was actually not my invention.

Average number of lifebloom stacks - this is currently bugged, but it will try to let you roll 8 stacks, using the lifebloom stack type below. Slow means you cast it say every (duration-1) seconds, until the 3rd , which you let bloom. Fast means you make a 3-stack quick, then let it bloom. Rolling means just that: no bloom.

Wild Growth casts per minute - This one is automatically scaled down if the total is larger than 100% - not really perfect, but it's ok for now. Also, it assumes full spell effect on your targets.

General remarks. Models like these are an approximation; the target is not perfect simulation, but to get a nice comparison of gear. With healing there are many profiles that are interesting for us, e.g. how fast can you heal 1 person in 8 seconds with a 3 second window to cast, or how much is your total healing output over 6 seconds using a certain spellcast profile, regardless of overhealing, how fast can you heal 1 person if you just go all out, how fast can you heal a group with WG+Rejuv and nourish? And obviously there could be more.


Dec 10, 2009 at 7:10 PM

Thank you for the response!  Over my lunch break I was able to really figure it out, thanks to these explanations, and now for the first time I feel comfortable plugging in my variables, clicking optimize, and trusting the results enough to spend my emblems!

Of your TODO list, I would most like "much more explanation of how the model works", then second "how fast can you heal 1 person if you just go all out."  For whatever my requests are worth :).  Personally, I gear for maximum sustained raid healing, and let things like burst healing fall where they may.  That's what the tank healers are for :).

Dec 10, 2009 at 7:43 PM

I can't really say I enjoy the new Tree model. Maybe I'm just getting used to it, but I use Rawr as a tool to help me gear not only my main, but my alts. My tree druid is an alt--a raid-ready alt, but an alt nonetheless--and this thing is simply too difficult to spend the time to figure out for an alt.

I'm sure it's an extremely powerful tool, but I'd really like some drop-down boxes like we used to have that will plug in some default numbers. For example, if I select "Rejuv spam on raid + Regrowth and fast build/bloom on tanks" it'll just... do that for me.

As it stands now, if I tell this thing that I spend 90% of my time casting Rejuv, 10% of my time casting Regrowth, and keep just one single solitary Lifebloom stack up with a fast build/bloom, it wants me to use the Lifebloom idol. That's just not right, so either I've got something very wrong or it does IMO. :s

Despite my comments, thank you very much for your work on this tool. :)

Dec 10, 2009 at 10:39 PM

You have a valid point, Shanyn. Perhaps I should wait sending in big changes when it's not completely polished yet. On the other hand, I do believe there are code errors and I know things are improving. My goal is to have a module  that will work out-of-the-box for most people, immediately. This is a goal I think is reachable before 2010.

It is also my opinion that the model as it was a week ago, maybe worked well enough for people to rely on it for some part, but I'm pretty sure the numbers were off, especially concerning the interesting bits (do I go for haste, spell power, crit or spirit/mp5/int). It did usually say that higher iLvl items are better for healing, which works in general.

Anyway, I can't reproduce the error you described on my system, yet. I'm trying, though ;)

Dec 10, 2009 at 10:42 PM

Ah.  Note that Torlando says "Average number of lifebloom stacks - this is currently bugged...".  I'm guessing that's the reason for the behavior you're seeing.  I suddenly am no longer confident to spend my emblems, but I'm very hopeful, since it's just a bug, and I see that when it works correctly I'll know how to set it up to model *my* rotation!  :)

This raises a question for me, though.  How do the two lifebloom sliders work together?  If I select to roll 2 stacks of lifebloom with "rolling no bloom", and set my "Lifebloom casting" to 0%, what happens?  What about if I set it to 100%?  How do they interact?

Dec 11, 2009 at 4:20 AM

Okay, let's see. It's 5:10 AM in the morning, I think I'm suffering from programmer addiction ;)

I updated the "Fight" tab to have a "streamlined" spell setup: first you set lifebloom stacks, then you set wild growth and swiftmend, then you set the three hots, then the idle time, then primary spell. This is also the "spell prioritization" in the model.

You will now have to set a target for your character. By default this is 9000 hps single target all out and 8500 hps sustained for 4 minutes in a certain configuration. The points (burst/sustained) will be calculated with the following formula: 10000 * (1 - target / pointdifference )

There are a few custom charts: mana sources (sustained), mana used per spell (sustained), healing breakdown (sustained), healing breakdown (single target burst), hpct and hpm per spell (general) and a comparison of different single target spell mixes

You can also select the spell mix to use for single target max hps calculation (e.g. RjRgLbN*) from a drop-down box

When you select values in the sustained spell setup that are out of bounds (e.g. you want to cast more than you can) the model will automatically downscale internally (this is explained on the "Fight" tab)

I implemented the Frost idol and the T10 set bonuses.

Well, that's basically it. I also fixed the lifebloom stack bug, of course.

The Lifebloom stack slider and the Lifebloom slider are completely seperate things. You can keep a lifebloom stack on a tank and still cast lifebloom on the raid sometimes. That's basically what is meant.

Dec 11, 2009 at 3:53 PM

Gimee gimee gimee!

Dec 13, 2009 at 11:13 PM

"Scores" are not HPS anymore (is that what they used to be?).  They are now a number that indicates your healing output relative to the goals you set in the Options->Stats tab.  Higher is still better, though (even if "higher" works out to be less negative).  That's the only "question" I could personally figure out how to help you with from the information you gave. 

Dec 14, 2009 at 2:35 AM

Certainly different fights may have different percentages for different spells, but Rawr has to use *something* for them.  Maybe the best way to calculate these things would be to run a full raid and look at the logs to get averages for time spent casting.  Or focus just on the crucial fights, since there's no reason to optimize for the easy ones.  My own personal method is to think of my most mana intense "rotation" and optimize my gear based on rough estimates of how much time I spend casting each spell in that case, because I *HATE* the thought of running OOM (and I haven't for a long time).

If you'd like help understanding the options, I'd suggest some specific questions about them.

Dec 14, 2009 at 4:56 AM
Edited Dec 14, 2009 at 5:27 AM

I set mine up for 8 wild growths, 10 rejuvenations, 2 regrowths, then enough lifeblooms to take up the leftover time.  The actual % casting I then figure out based on my haste (the more haste, the less % time I need to be casting regrowth to keep up 2 stacks, for example).


Dec 14, 2009 at 2:32 PM

Apparently Swiftmend falls off in some cases. I found two reasons. The first one is a rounding error, resulting in "-0.00000001 < 0 , so remove swiftmend". The other is : "rejuv+regrowth cast times are too low, so remove swiftmend"

I have fixed the rounding error (well technically I can't actually fix it, but I inserted a Round() statement) and I've removed the Swiftmend autoremove.

I'm also introducing the option to let Idle time apply to hots too. The idea is that you can then select say 50% rejuv casting, 20% lifebloom casting, and 20% idle time and the system will automatically calculate remaining time to be spend casting your filler spell.

An alternative way to do it would be to just give sliders with percentages of casting rejuv, regrowth, lifebloom, nourish, healing touch and nothing. I would then introduce small check boxes with each slider, indicating which spells can be scaled down to guarantee idle time. There will always be some scaling to guarantee you don't case more than 100%

The Fight tab really is just a tool to specify what your usual casting profile is (or, the one you want the model to use). I made a design choice to use "percentage of time spent casting a spell" instead of "amount of casting per minute" or "average amount of active hots" because I think the percentage of time spent casting a spell will give better results. Average amount of active hots changes with time and in challenging situations, this really is "as high as possible", same goes for "amount of casting per minute". These values do not scale with haste. If you get haste, your amount of casting per minute does not change, if you get more haste you would probably cast more so you would have more active hots.... but with a casting percentage, you will see more rejuvenation casts per minute and more average rejuvenations on the target (lower gcd) as well as less averager rejuvenations on the target (glyph). That's in a nutshell why I chose this method.


After some discussion with Astrylian, I modified the rating system. Now, the rating will be the estimated theoretical HPS until the cap, from which point there will be diminishing returns. The old system was giving inverse diminishing returns when you were under the cap and was based around 0. The new system will still allow improvements to be less and less important when over the cap, but will no longer promote certain improvements under the cap. It will also no longer give negative results and remove misunderstandings of users.


Regarding haste caps, I'm not sure if the module is wrong or not. Nature's Grace gives some haste when you crit and you get 10% spell haste from GotEM.

I'm also planning to add a slider for Latency.

Dec 14, 2009 at 4:19 PM

It'll be in the next release, yes.

Don't believe the current values of GCD there. It didn't have priority (actually, I'm still not completely finished with rebuilding Tree) because I focused on getting the calculation right first.

The next release will have two lists, one with the base values, out of combat. One with the values as they are expected to be in combat, when special effects will go proc.

There is one issue which is pretty nasty to solve and is not model specific. Special effects are averaged out over the entire fight. That means that haste trinkets and Nature's Grace effects are averaged out to every spell. It is not something I have a quick and simple solution for at the moment. With trinkets one could imagine just calculating the uptime, calculating the rotation inside uptime, calculating the rotation outside uptime and taking the weighted average of these two. Nature's Grace is rather more difficult: which spells will benefit from the 3 seconds 20% haste? It completely depends on your casting habits. I sometimes spend some time casting rejuv all around, then at some point I decide that a few people are really low and I start throwing nourishes around, until at some point I realize all rejuvs are falling off and I cast rejuv again. Now Nourish will crit while rejuvenate will not, so chaincasting nourish will give a nice uptime on Nature's Grace. But if you would cast Nourish, Rejuv, Nourish, and so on, the uptime might be different. I'm not sure.

Dec 14, 2009 at 5:01 PM

I am considering an option to ignore haste effects from special effects in the calculations. This would make certain trinkets with haste procs less good and it will remove the Nature's Grace effect. It will also reduce the value of crit (because what Nature's Grace does is convert crit to haste in a way). You will, however, see Haste being a valued stat until the cap. Right now, Nature's Grace and trinkets will artificially lower the cap ("soft cap")

Dec 14, 2009 at 5:19 PM

I'm not sure if removing haste effects altogether is a good idea.  Since I believe spell haste scales non-linearly (once you hit the 1sec GCD it's worthless, right?), your best bet is to just not use GetAverageStats/AccumulateAverageStats, and instead compute the actual average haste provided (ie, if you're only 50 from the cap, the trinket gives 100, and its uptime is 20%, you get 0.2*50 = 10haste from it, rather than 0.2*100 = 20haste).  This doesn't solve every problem (ie if you want to compute burst healing with a haste trinket procced), but it's a start to not over-estimating the value of haste.  Most melee DPS models do something similar for Armor Pen procs.

Dec 14, 2009 at 6:02 PM

Actually, gcd caps are already in place and Rawr will simply tell you that you have more haste than you need. Besides, the global cooldown is capped at 1.0 seconds, but the haste effect on rejuvenation with the new glyph is as far as I know not capped.


I do agree that decreasing trinket value using that method once you get near the cap is an appealing idea, but the effect on rejuvenation would be lost.


I think a real solution would involve calculating actual uptimes per trinket, calculating overlaps of special effects (this is harder than just multiplication, because stuff could proc at the same time), then put it in a neat table and calculate a weighted average.

However, with 10 special effects, you can make loads of combinations, 1023 to be precise. (2^n_effects - 1) The effort into calculating will be comparable to having 1000 as many items.

Dec 15, 2009 at 9:40 AM

Next release will have the option to ignore Nature's Grace and Haste from special effects.


Dec 15, 2009 at 3:07 PM

"However, with 10 special effects, you can make loads of combinations, 1023 to be precise. (2^n_effects - 1) The effort into calculating will be comparable to having 1000 as many items."

Can a tree really have 10 haste special effects at a time?  Or do you just mean there are 10 total options?  If it's the latter, you can do it dynamically, since at most there would be, what, 3?

Dec 15, 2009 at 5:36 PM

I hope the new version will be clearer :)

It also has the option to calculate revitalize on yourself and calculate the average amount of revitalize procs per minute.

Dec 15, 2009 at 11:42 PM
Edited Dec 15, 2009 at 11:42 PM

Not sure if this is an appropriate solution in this case (most likely it's overkill), but SpecialEffect already supports calculation of combinations of effects in case you weren't aware. Take a look at SpecialEffect.GetAverageCombinedUptimeCombinations. The bulk of calculations is linear in number of effects, but it's still quite expensive.

Dec 16, 2009 at 1:55 PM

Take a break for a week and Blizzard goes and launches a patch and someone takes over the Rawr model...

On the one hand thanks for that, since I probably won't have much time for Wow and Rawr maintenance in the year ahead.

Although I like some things of the new model interface, there are many issues with this approach.

The posters in this thread make it sound like Rawr.Tree wasn't working, but before the 3.3 patch, no issues were reported on Rawr.Tree. The only real outstanding issue was slightly better spell mixes for cases where there is some hybrid tank/raid healing required. (Granted it also wasn't perfect, but no1 seemed to be complaining. Combined haste effects and nested special-effect handling were limitations that needed to be addressed, but in practice I don't think it was significant). Trolando, why do you claim "It is also my opinion that the model as it was a week ago, maybe worked well enough for people to rely on it for some part, but I'm pretty sure the numbers were off" ?

The idle slider was an experiment that failed and should have been removed from the model, since it didn't have the type of effects users would have expected and would just have caused confusion in the long run. Its usefulness in the current model I'm not sure about yet (will require more understanding of the model and some experimentation).


Things I like of the new model:

- The extra graphs are a nice addition.

- Ability to have more flexibility to setup spell usage was needed.

- The extra descriptions on the options menus help a lot.


Things I don't like/possible bugs:

- Removing all the detailed breakdowns of spells and the simulation result from the main stats menu. (Maybe it should be relocated, but that section contains valuable info to check against ingame numbers/do quick calculations for model sanity. For example I wanted to quickly check the calculations on Revitalise, but finding out how much mana Rejuv costs, is extremely difficult with the current interface).

- The way Revitalise is represented atm, makes it look way better than it really is: Rolling rejuv on yourself for about 390 mana per cast, in return for 180 mana regained over the cast period, is like I remembered from original calculations months ago, not worthwhile. Sure, that is a nice bonus, but you shouldn't maintain rejuv on yourself for that reason. Thus it should rather be proccing off the "raid healing" portion, instead of the maintained HoTs. Thus either you will waste mana trying to keep it up, or its mana returned will be much less than currently predicted.

- The options menus are too complicated for average users. (What I had on my todo list, was to expand the previous list of spell casts to add a manual option, that would allow some of this configurability). Maybe if we add a drop-down list that then can configure the rest of the settings for default values, based on certain profiles it might help. Here I'm think of single/double tank healing profile (especially in 10-mans this might occur, where you don't have the luxury of concentrating on raid healing), one or two hybrid type profiles and then full raid healing profiles, possibly split between bursty setups where regrowth/nourish are needed or sustained damage where rejuv shines.

- The healing spell usage percentages is difficult to interpret. For example lets say I use 30% each for lifebloom, rejuv and regrowth, as a gutfeel what does that mean? If I did my calculations correctly, for my gear, it should mean I have on average 2.7 lifeblooms, 4.9 rejuvs and 5.4 regrowths active at any 1 time. (I would have expected only half as my active regrowths, since its cast time so much longer than an instant). Although the equal percentages felt close to what I assumed my casting split it, thinking about my healbot display, there typically are fewer regrowths than lifeblooms or rejuvs showing, so the ratios are probably way different. We need to think if there is a more intuitive way to configure this.

- I believe the latency calculations is totally wrong and should be removed. I play with 700 - 800 latency and according to your latency formulas my instants would almost be double cast time. To not derail the discussion too much, the short summary of how I believe latency works is that latency less than the gcd/cast time doesn't affect throughput at all, it only affects reaction times, since you can precast.

- It looks like minimising and maximising rawr causes the custom charts to default back to the standard rating colors and legend.

-The bottom summary status bar, mostly shows the ratings, but now and again it switches to a rating and mana value, doesn't look like it is intended to do that.

-I noticed that on the buffs graphs mana and rejuvenation potions give the same results, which cannot be correct. (This might be an older issue, that I just never noticed before).

-It looks like Healing Touch has been completely dropped from spell choices. I remember that when WotLK's details were announced, you could hardly find a druid that wanted to use Nourish instead of a Glyphed HT. Many have been converted, but I'm not sure if we can really drop HT completely. Atleast showing its HPCT and HPM on the graphs should be maintained to show its relative effectiveness, instead of raising the question if glyphed HT is a viable alternative.

-The cast time percentage per spell and in particular the auto reduction part of that graph makes no sense to me. For example why does it want to dump my lifebloom stack? And what does the results mean, did it actually utilise the lifebloom stack in the calculations or not? (This links to the detailed breakdown that was removed, where it should have been possible to see what was happening).

-I'm slightly uneasy about the cap/diminishing returns concept of switching between burst and sustained. Maybe it is because I'm used to working with linearised engineering models, but this extra non-linearity you introduce, which dynamically causes the weighting between burst and sustained to shift feels like it could cause issues if it isn't setup properly by the user. (On the other hand, if it is setup nicely it might work great. Maybe for practical scenarios you cannot go so far wrong as to cause a bit issue, I haven't experimented yet.).

-The way solver was restructured highlights a lot of code duplication. Some of it probably was there previously and is now only more obvious, but some of the calculations seem to duplicate code in spell.cs. I assume your still in the process of restructuring.

-I see in terms of sustained mana management you went back to the idea of casting until your OOM and then waiting until you regen fully. I still maintain that approach is great for dps, but totally inaccurate for healing modeling. If you stop casting completely, people die, wipe results! The answers obtained will not be the same as throttling back to make your mana last for the complete fight. If you do have to throttle back, you should start with reducing the least mana efficient spells, typically nourish and regrowth and maintain your HoTs for the efficiency (Unless the damage is spiky and your HoTs will result in overhealing). Using that form of throttling, has interesting side-effects, like scaling back on Nourish, also results in degradation of the T7 4-piece set bonus (nourish bonus/hot). That type of effect was mostly modeled in my code, but the current method lacks that type of subtlety. Worse than that is the fact that the current model doesn't indicate in any way I could determine whether mana is an issue at all or not.


In summary: I like the new options available in the GUI, but it needs some more work to create a less complex starting point (i.e. non-advanced mode). I like some of the code refactoring, but it should be completed to remove a lot of the duplication that is now evident. I'm very concerned about the way mana limited fights are now handled.




Dec 16, 2009 at 3:54 PM

I guess some team effort is in order, or something, because I like the new setup.  Btw, there are nice improvements in SVN over what's released currently.

Dec 16, 2009 at 6:08 PM

I haven't had a chance to read through all of this yet, but wanted to point out two things first.

  • Rawr is developed as a team. We have 'owners' of each model, but that only lasts as long as you are around. Now that you're back, we welcome your help again, Wildebees.
  • The past couple versions have seemed to 'ruin' the Tree model, from a user perspective. Luckily, that's 90% because of Tro's silly rating scheme, which I helped him get straightened out lately, and we'll be posting a new version tonight; please try that.
Dec 16, 2009 at 11:22 PM

Thanks for the great list of things to do, Wildebees. I've made a todo list which now consists of many items. (Some not relevant to the end users, such as further refactoring). I have also sent you an email via the system, please read it.


SebzCP, I'm very sorry that you're the victim of all this. I am trying to improve the model, not make it useless. I believe I underestimated the complexity of the changes especially to the rating system.


The new release will see the following items that I worked on today:

- reduced spell casting when going OOM. Please, please look at this, especially developers. It was the best I could come up with in the very limited time I had today. It takes the total MPS needed to drop to prevent going OOM, then calculates based on the values in sliders how much MPS will be reduced from each spell, then it removes this amount from the spell. Obviously, sometimes not the full mana reduction effect can be reached, when spell casting time percentages cannot be reduced further (below 0%). I'm sure there are better ways to do this, please engage in a discussion about it. Yes I know it's complicated with 5 sliders and gives the user many many options to configure it. I want to work on a "Simple interface" next but I simply lack the hours right now to do that. It's 0:20 AM here.

- I have added all statistics in the main stats frame. Actually I commented them out during the revamp to fix them back in later, and simply hadn't come to it yet. I made it my number 1 priority so I did this first today.

- Revitalize will now be calculated differently. You just enter the amount of procs you expect and that's basically it. If you expect none, so be it.


The default values are way off what you might want them to be right now. Please advice me with better values.

I have added a small list of things that will be done after the release of tonight in the "Module Notes".

Dec 22, 2009 at 12:52 AM

The Check-in of today will add an option to Rawr:


// [Drop down control with spell profiles] [Delete button]
// [Text edit control                    ] [Add button]

Currently you can simply use this option to create spell profiles and save them. Also, at this moment nearly every option is stored in that way, including things like fight length.

The ultimate goal is that when starting fresh, there will be some prepared spell profiles, e.g. "Tank healing", "Tank healing plus raid", "Raid healing plus tank", "Raid healing", "Intensive raid healing". This will conceptually make Rawr.Tree easy to use for someone who's not familiar with Rawr.

I would like feedback.

Dec 27, 2009 at 12:41 PM

There's always something on the todo list, but what's most important right now is to fix the haste trinkets. There are a few other things that show up in the "Module Notes" (I'm not at home so I don't know exactly what my todo list looks like).

When would you say a module is sound enough? Probably when the results it gives are pretty similar to what's said on ElitistJerks, or on similar sites/blogs. When the value of trinkets agrees with your own opinion. When if it disagrees, there's a good reason for it that you can discover. When the various predictions for spell healing per tick etc agree with what you see in game. When all such things hold, a module is sound enough.

Lately, I've been thinking a lot about whether HPS is really the measure for expected gear value. If you read forums like ElitistJerks, people use different reasoning all the time: for example, when choosing trinkets or glyphs, it's often about personal preference instead of HPS ("I don't want to remove other people's Rejuvenation/Regrowth", "I want my reaction speed as high as possible"), so it seems HPS is not everything. Then there's the problem with haste: some people just can't heal well with lots of haste, because their internal timing screws up: those people would benefit more from crit and spell power. Others want to make best use of Nature's Grace, etc. Then there are people who don't want a faster Rejuvenation or a proc of Nature's Grace, because it screws their timers or it causes a HoT to fall off faster, despite that the target is healed earlier/faster. There's the question "am I healing something we have on farm status or something we're still trying to get our first kill on?". When things are on farm status, it doesn't really matter that you do a lot of healing, it matters that you do a lot of healing faster than other healers. I've been considering a third Value next to "Maximum Single Target Healing" and "Sustained Healing", which would measure "Maximum Healing for X seconds using Y seconds casting time" or something along those lines.

It's simple when calculating for max-dps or max-tank-healing: just a simple priority list based. It's harder here.

Dec 27, 2009 at 2:35 PM

Just something I thought of while doing some other things. Just a rewording of things earlier said, I think.


Basically the way the Tree module works right now is like this: it figures out what % of time you are casting a certain spells and then just does a few multiplications and sums and we arrive at our expected HPS. The fact that it's pretty hard to weave a quarter of a Nourish between refreshing HoTs is ignored, it will just assume you are very capable of casting a quarter of a Nourish. You could increase "Idle time" slider to compensate for this, or I could change the solver to be simulation-based instead of statistics-based, but this will soon get very messy. (Apart from "expectations", we'd have to deal with "haste effects" that modify rotations). In practice, I think this is not a real problem and if really necessary, could be compensated by reducing casting time percentages, instead of going for a simulation model.


By going for a statistical model based on casting time percentage, we reduces our whole Tree solving problem to calculating the casting time percentages. Now, assuming we're not suddenly going to change our casting behavior in the game, there are two things that influence the casting time percentages: we may be able to cast more or less because of the amount of haste we have; we may be able to cast more or less because of the amount of mana we have. The Spell Profile model must such that these two influences are modeled. Now the approach is as follows: we enter a Spell Profile that we would like to cast and we enter parameters that determine how the model will compensate for lack of time and lack of mana. This will cause the model automatically modify the casting time percentages when acquiring gear that increases our haste or our mana regen.


This is the basic idea. Now, assuming the spell/talent/glyph calculations are 100% correct, the question "Is the Tree model sound enough?" can be rephrased into a few subquestions:
1. Are [all special effects from] gear correctly modeled?
2. Is the Spell Profile model correct?
3. Is the Spell Profile model UI sufficiently understandable and flexible? (Actually, this is not relevant "to plan an optimized gear set", but it's relevant if you don't understand the model)
4. Is calculating expected theoretical healing per second over a long fight the correct approach to evaluating gear? (Are our assumptions correct?)

Q1: Most if not all gear and new trinkets are correctly modeled. I'm missing maybe one ICC trinket at the moment. I've made various assumptions regarding internal cooldowns and proc chances that are hard to verify and based on information. Especially Ephemeral Snowflake is a tricky one, I believe the iCD is 0.33 seconds, but other sources say 0.25 seconds or 0.4 seconds. It is also assumed that heals/casts/crits are nicely spread out in time, which isn't necessarily the case. Especially for effects from critical hits, this may be important, since these are only caused by casts of Regrowth and Nourish and from the Bloom effect of Lifebloom. It may well be all these effects will happen in a short time, instead of spread out over the entire fight.

Q2: I think it's mostly correct. There could be even finer parameters: the adjust-for-time algorithm could be remodeled to be like adjust-for-mana (a reversed priority list) and adjust-for-mana could be a bit more advanced, allowing spells to be on the same level (right now, it's a strict order). However, if the current implementation fits how you would adjust for time and mana, this means it's correct.

Q3: I am not sure here. We're not talking about the flexibility of the model (that's covered by question 2) but of the UI and I believe the ability to save and load spell profiles makes this a lot easier to use. Regarding understandability, I have my doubts. Perhaps even more text is required, or different descriptions.

Q4: One could argue that overhealing might be interesting, but I don't think overhealing is influenced much by gear and therefor not relevant for the model. Overhealing by Living Seed is in my opinion relevant because it has a strong influence on the value of Crit, but this is only a way to compensate for overvaluation of healing from Living Seed, not healing in general.

Dec 27, 2009 at 4:58 PM

To be honest I haven't figured out yet how to model latency, that's why it's grayed out. My original implementation quickly invited comments and I've disabled the option until I figure out what exactly is happening. Apparently, Blizzard is doing something that twists latency times quite a bit.


Dec 28, 2009 at 11:50 AM
Edited Dec 28, 2009 at 11:59 AM

I like the new spell profile loading and saving.

Some things I did pick up though (tying back to my concerns that the interface is maybe slightly too complex and now allows inconsistencies): I loaded the "Tank Healing (no Lifebloom)" profile. It has 100% of the Nourish spells at 3 HoTs, but the pofile only casts 2 HoTs.

I also see the Regrowth Glyph is having no effect. Previously I had it that when your using regrowth for tank healing (maintained regrowths now I guess), I assumed you clipped the regrowth and managed to get the benefit from the Glyph (if used). (I'm now not 100% sure if I actually remembered to clip the last HoT tick of regrowth though). Maybe something to consider using again.



I'm one of the people that complained about the latency calculations. So I decided to go do a quick test:

I logged in in Org, my initial latency was reported as 650ms (yellow), but at some point it turned red (as usual, going to 750-800ms). I'm from South Africa and am being screwed by a telecoms monopoly etc.

I had 340 haste static, have nature's grace and egg of mortal essence (both procced during this test). (Edit: Oh and have 3/3 Celestial focus, that is probably on top of the rating shown by the ingame UI). (I have the full combatlog if any1 is interested, just didn't see an easy way to attach it here)

Here is an extract of the combat log (filtered on Wildebees and the on SPELL_CAST_%) and I added the Delta time column:

<!-- BODY,DIV,TABLE,THEAD,TBODY,TFOOT,TR,TH,TD,P { font-family:"Albany AMT"; font-size:x-small } -->

            Delta time

09/12/28 13:01:07.34

SPELL_CAST_SUCCESS Wildebees Rejuvenation
09/12/28 13:01:08.69 00:01.34
SPELL_CAST_SUCCESS Wildebees Lifebloom
09/12/28 13:01:09.75 00:01.06
SPELL_CAST_SUCCESS Wildebees Lifebloom
09/12/28 13:01:10.94 00:01.19
SPELL_CAST_SUCCESS Wildebees Lifebloom
09/12/28 13:01:12.77 00:01.83
SPELL_CAST_START Wildebees Nourish
09/12/28 13:01:14.41 00:01.64
SPELL_CAST_START Wildebees Nourish
09/12/28 13:01:15.56 00:01.16
SPELL_CAST_START Wildebees Nourish
09/12/28 13:01:16.70 00:01.14
SPELL_CAST_START Wildebees Nourish
09/12/28 13:01:18.41 00:01.70
SPELL_CAST_START Wildebees Nourish
09/12/28 13:01:19.50 00:01.09
SPELL_CAST_START Wildebees Nourish
09/12/28 13:01:21.16 00:01.66
SPELL_CAST_START Wildebees Nourish
09/12/28 13:01:22.73 00:01.58
SPELL_CAST_START Wildebees Regrowth
09/12/28 13:01:23.95 00:01.22
SPELL_CAST_SUCCESS Wildebees Lifebloom
09/12/28 13:01:25.44 00:01.48
SPELL_CAST_SUCCESS Wildebees Lifebloom
09/12/28 13:01:27.16 00:01.72
SPELL_CAST_SUCCESS Wildebees Rejuvenation
09/12/28 13:01:28.64 00:01.48
SPELL_CAST_START Wildebees Regrowth
09/12/28 13:01:30.17 00:01.53
SPELL_CAST_SUCCESS Wildebees Lifebloom
09/12/28 13:01:30.64 00:00.47
SPELL_CAST_FAILED Wildebees Nourish Not yet recovered
09/12/28 13:01:31.78 00:01.14
SPELL_CAST_START Wildebees Nourish


As you can see, latency cannot just be modelled as GCD+latency or cast time+latency.

Expanding on what I said in previous posts on latency: I believe that the GCD is enforced on the client side, so latency has no effect on the casting of instants.

I used Quartz until 3.3 and now I see my castbar in IceHUD also has the feature (not sure if it is standard UI or enabled by another addon), that shows the last part of my cast bar in red. This is the estimated latency part. If I want to stop cast, I need to do it before reaching this point. Or after going past that point, I can start casting/queing the next spell. Thus for casted spells, assuming latency doesn't vary I can get close to the same casting throughput compared to guys with very small latency.

In summary: Ignore latency for throughput calculations, it only adds to reaction time in cases where you need to respond quickly (i.e. heal the target within 3 seconds).

Once latency goes past cast time or GCD time though, I believe this mechanism breaks down and you do get close to the full effect of the latency. I have played like that a few times (ADSL link broke down, so used 3G link's extra latency), it isn't fun at all.

@SebzCP: I tried the TCP acknowledgement frequency thing once and although it seemed to reduce my latency by 100-200ms, I couldn't do the Heigan dance afterwards. Not sure if something weird was happening that day but I decided it only makes the reported latency less, it doesn't reduce your real latency and ends up making the connection less reliable (i.e. lag spikes instead of a constant latency). So I'm back to the default settings.



Dec 28, 2009 at 1:52 PM

I suppose I'll just remove latency completely.

I can modify the constructor of Regrowth to also add a boolean parameter "clip". It already has a "regrowthAgain" functionality but that one's only used for Rg* rotations.