This project is read-only.

[Tree] To bloom or not to bloom?

Topics: Rawr.Tree
May 17, 2009 at 2:27 PM

Hi All Rawr.Tree users


I played around with the model and tried various lifebloom usage situations. Some conclusions (used my low geared character, so might differ slightly based on your build):

Running a continuous lifebloom stack is relatively inefficent in terms of HPM, but gives good HPS.

Using 1x lifeblooms is quite efficient in terms of HPM, but gives low HPS.

A slow stacked 3x lifebloom (refresh 1s before bloom, up to 3), gives the highest HPM and HPS very close to the continuous stack situation, but is extremely bursty (lots of 1 or 2 stack ticks, where tanks health would fall, normal 3 stack ticks and finally a big burst making up for those low stack ticks in terms of total healing).

A fast stacked 3x lifebloom (stack to full in 3 seconds, then wait until bloom), gives the highest HPS, decent HPM, but is expensive in terms of cast time (3 gcd every 12 seconds or so).


I assume somewhere inbetween slow and fast stacking would give the best combination ( probably something like: LB, LB, wait till 1sec before bloom, LB, wait till bloom and repeat).


Now I'm wondering what should be included in the model:

Should the model try to optimise or should the user choose their method?

If we allow it to optimise, I'm guessing slow 3 stack will probably come out tops in many cases (based on the measurements of HPS, HPM and cast time), but its limitations (periods of low healing and finally a burst which potentially overheals), isn't being fairly considered.

If your tank healing, you can probably plan around this burst, but if your raid healing, the tank healers will probably appreciate constant healing more than extra bursts every 30 seconds.


I am wondering whether for raid healing scenarios specifying a target HoT HPS on the tank would make sense. Allowing the model to determine the combination of rejuv, regrowth and lifebloom mechanisms to achieve that and then switch to raid healing with the available mana/cast time. But it will likely result in a model that runs 3 or more times slower as it tries various combinations of spells. (Running an optimiser with high levels of thoroughness like that might become painful).


Suggestions/Thoughts from the users?


May 19, 2009 at 2:53 AM

I think the fast-stack giving highest HPS is a bit misleading.  Over twenty four seconds, you spend 6s casting LB.  With the continuous stack, you'd spend only 3s casting Lb, meaning you'd also be able to cast an extra 2+ Nourishes in the available time.  Continous HoT will out-HoT the fast-stack, and two Nourishes will out-heal the bloom.

I suspect that if you let users choose their method (similar to the current, user picks HoT rotation for tank(s), leftover time/mana goes to raid wide Rj or WG) people will understand that, with minimal explanation.  There is a lot of value in that.

It would be cool if I could tell the optimizer that I have a 6-minute fight, and I'm assigned to heal eight people.  It would give me an optimum (total healing done) spell count, constrained by cast-times, coldowns, HoT durations, and mana.  For mana-constrained fights, it would tend to recommend lifebloom slow stacks.  For cast-time constrained fights it would lean towards Rejuv and perhaps Regrowth.  For a short fight with limited targets (1 or 2), a continous lifebloom stack (+ Rg, +Rj, +Nourishes) would win.  Even though this would be cool, I'm not sure how many users would use it.

I'm not sure how to put a reasonable "bonus" value on either guaranteed minimum heals (penalty on slow-stack  ups and downs) or emergency burst capabilities (glyphed HT, on a target with no HoTs).

May 19, 2009 at 9:34 PM

I agree that highest HPS doesn't tell the whole story. Based on that and various possible combinations of glyphs, talents etc. which affect lifebloom duration, I also wouldn't like to just code a rule use continuous stack for cast time limited and some bloom method for mana limited. My approach would probably be to evaluate both (or all 3 combinations) fully and then choose the one with the highest result. That is why I raised the potential concern that optmisation runs might start to take longer.

If most users have faster computers than I have and don't feel concerned about that, then it might not be a problem.

To put some more users in the picture and give an update on the current model status: My first attempt at modelling swiftmend, took about 5 minutes just to update the trinket graph display. Try running the optimiser on that and you will end up waiting for days. This was due to attempting to estimate the effect of haste on when you can actually use swiftmend as well as various HoT durations based on talents. I ended up making very rough approximations on that, which I'm not totally happy with, but that mostly affects how much of the HoT effect gets consumed on average without Swiftmend Glyph. I'm assuming if Swiftmend really plays a big part of your spell usage, you will have the Glyph. This will atleast give you a rough estimate of the value of the Swiftmend Glyph.


Getting back to the lifebloom question: Getting the model to try numerous ways of using lifebloom and reporting the optimal for your gearset and fight description would be possible, but might again take minutes to give you a trinkets graph, so that you can know that with trinket X, you should cast the 2nd lifebloom immediately and then wait 4.5 seconds before casting the 3rd lifebloom, whereas with trinket Y, you should wait 6 seconds. I don't think that kind of answer has got real meaning for a healing model, since you need to adapt too much. For a dps model, you can maybe ignore what is happening in the fight and play the perfect rotation.

If I do go the adaptive route, it will probably be continuous stack, slow stack and fast stack, unless users feel other combinations should really be considered.


On the one hand I like the list of predefined rotations, since that nicely works with the Spell Rotations Graph, to quickly get an idea of the effect of trying different approaches. From that point of view, I'm not totally happy with Swiftmend as a slider, since comparing different slider positions isn't being displayed simultaniously on screen. But adding rotations with and without swiftmend to the graph, will make the list enourmous. Are others using this view to learn about their spell options as well?

Going with your idea of optimising the amount of healing to a configurable amount of targets. Is a single text line showing the selected combination going to be sufficiently useful? Essentially what we will be asking from the model is to teach us about spells and the trade-offs. What is the format of the answer most helpful in this teaching process? Or are we not interested in this answer and still only in the gear choices?

 I am relatively happy with the Rawr.Tree model overall. I think most significant spells are modelled. I would like some more feedback on sanity checks by users of the model, whether the numbers on the paper doll/spell heal value etc. tie up to what they have ingame.  On the todo list is:

  • I'm trying to fgure out the lifebloom usage configuration GUI (if at all), but that will hopefully not be a big problem.
  • I might relook at Swiftmend modelling, but not sure if there is much point.
  • Modelling tranquility healing would be nice, but I'm not sure if anyone is using a tranquility based build to heal.
  • Decursing/Poison removal should maybe be considered as extra loss in casting time and mana, but not sure if that is significant enough to model.

If there are other requirements that the model needs to address, please let me know as well.

I guess on a more philosophical level: Should Rawr.Tree only answer gear questions for perfect play? Or do we want it to adapt for our play style? Or do we want it to help teach us about adapting our playstyle to our gear as well? What are the questions the users are asking from the Rawr.Tree model and how can the answers be better provided?


Wow, this has drifted far from the original topic title, but I'm trying to think on "paper", triggered by the original topic. Hopefully the people that can most contribute to this, will also be reading this topic.