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.