Archived

This topic is now archived and is closed to further replies.

Paininabox

Resto Spreadsheet

69 posts in this topic

I think that the stat weights would be more accurate if you used Healing per second cast time instead of healing over duration of the HoT. Sure the HPS of one rejuv is healing (let's say 15k) / 18 seconds or about 800HPS, but if I am GCD capped spamming 1 rejuv per second, I am effectively doing the healing of 1 rejuv every GCD, or 15kHPS. Instead of a HoT, picture each rejuv as a 15k instant heal on a target. This actually makes an enormous difference to the stat weights. For me, haste goes from 0.58 SP to 0.16 just from changing how Rejuv scales with SP. I get the same effect from multiplying my percent healing (40%) by 18 (520%).

Well, first off if you do it per second cast time, it would be 15k/0 since the spell is instant, which is undefined; alternately you could say 15k/x as x approaches 0, which is infinity, which is also wrong. Even if we assume that 80% of the rejuv casts are limited by the GCD, 20% are still not and thus unmodelable by your suggestion. Also, remember that rejuv does ridiculous amounts of overheal, which would bring your 15k per cast down to 3k or so.

The main reason why your method really doesn't change anything is that lets say you roll rejuv on 18 people and you cast rejuv once every second, or a little more so due to lag and other things. We assume rejuv heals for 15k over the 18 seconds. So HPS = 15k healing/18 seconds. Total HPS for rolling it on 18 people is (15k healing/18 seconds)*(18 people)= 15k healing for a person/second on average, which matches up with your picture. The main thing that's wrong with your model, in my opinion, is that you're not *actually* doing 15k healing every time you cast the spell. You do 0, until 3 seconds later and you do 2.5k healing, etc. What you propose is a mathematical shortcut, which doesn't work in the scales since not everyone spams rejuv to the exclusion of any other spell. If you do do that, then that will be reflected in the % of your effective healing for that spell, and thus will match your model. What it basically comes down to is your idea matches a very rare playstyle while the more general hps one covers that plus a mixture of others, which is more accurate.

Share this post


Link to post
Share on other sites
Well, first off if you do it per second cast time, it would be 15k/0 since the spell is instant, which is undefined; alternately you could say 15k/x as x approaches 0, which is infinity, which is also wrong. Even if we assume that 80% of the rejuv casts are limited by the GCD, 20% are still not and thus unmodelable by your suggestion. Also, remember that rejuv does ridiculous amounts of overheal, which would bring your 15k per cast down to 3k or so.

The main reason why your method really doesn't change anything is that lets say you roll rejuv on 18 people and you cast rejuv once every second, or a little more so due to lag and other things. We assume rejuv heals for 15k over the 18 seconds. So HPS = 15k healing/18 seconds. Total HPS for rolling it on 18 people is (15k healing/18 seconds)*(18 people)= 15k healing for a person/second on average, which matches up with your picture. The main thing that's wrong with your model, in my opinion, is that you're not *actually* doing 15k healing every time you cast the spell. You do 0, until 3 seconds later and you do 2.5k healing, etc. What you propose is a mathematical shortcut, which doesn't work in the scales since not everyone spams rejuv to the exclusion of any other spell. If you do do that, then that will be reflected in the % of your effective healing for that spell, and thus will match your model. What it basically comes down to is your idea matches a very rare playstyle while the more general hps one covers that plus a mixture of others, which is more accurate.

Suppose I am healing in a very healing intensive fight where everyone in the raid is not topped off and is taking large amounts of AoE damage. What I'm getting at is assume little to no overheal. If you take overhealing into account, you get silly arguments like spellpower is bad because it all overheals anyways. We should gear for fights where there is actually a lot of healing necessary. The heals are needed to keep people alive, healers aren't fighting for their portion of the meters.

For this example let's suppose that I have a really simple healing rotation: I only use rejuvenation and nourish. I use exactly the same number of rejuv spells as nourish spells. I only use nourish on people with rejuv for extra healing. The actual healing rotation is arbitrary, the result should be the same. I am just choosing this rotation to make the numbers easy. With my stats, my nourish heals for an average of 8000 (including crits), and each of my Rejuvs ticks for 2500, healing for a total of 15k. Therefore, approximately 65% of my healing is from rejuv, and 35% from nourish.

Suppose I am currently haste capped and am wondering if I should give up 40 haste for 25 spell power. I should only do this if for a typical fight, with the same rotation (since my rotation is clearly the best, all the resto druid experts would agree), my total healing is increased. So I go and open up your spreadsheet, I put in my gear and talents, and for the spell distribution, I put in my 35% nourish and my 65% rejuv. I say 1 HoT on nourished targets 100% of the time. It cranks out these stat weights:

SP: 1

Haste: 1.20

Conclusion: No way, keep the haste.

Let's say I casted nourish 3279 times. Each point of SP increases each nourish by about 1.5, which totals 4918.5 healing, and each point of haste increases the number of nourish spells I can cast by exactly 1, totaling 8000 healing.

Now onto Rejuv... If I casted 3279 rejuvs, (that's 19674 ticks) and each one healed for a total of 15k, 1 point of spell power increases each of those ticks by about 0.6, which totals to 11804.4 extra healing.

From this I conclude that 1 point of SP increases my healing, assuming I am using the same awesome rotation, by 4918.5 + 11804.4 = 16700, and 1 point of haste increases my healing by 8000 healing.

SP: 1

Haste: 0.48

Conclusion: I would gladly make the trade.

All of the values that I didn't declare as assumptions came from your spreadsheet (stats are in my last post), except 0.6, which I multiplied the 0.2 HPS / SP by 3 seconds to get the healing / SP of 1 tick. Also note that your current method for calculating stat weights doesn't care that after the first tick, there are 5 ticks left. If rejuv only ticked once, you would still get your same value of 0.2 HPS / SP and therefore the same stat weights. ( 1/6th the healing, but 1/6th the time!) I think you should be doing things in terms of Healing per second of cast time, not spell duration, since your cast time is your limiting factor for how much you can heal.

Unless you disagree with me that the stat weights should be chosen to maximize total healing... but I don't think that you can maximize anything else, because maximizing HPS gives you the same result since it's just total healing divide by the length of the fight.

EDIT: in response to your concerns about dividing by zero when calculation the cast time of rejuv... you would use the GCD for instant casts, not zero, since the GCD is the time you pay for the spell. This is the reason why getting haste to the soft cap is important, to raise your Healing / second of cast time

Share this post


Link to post
Share on other sites
EDIT: in response to your concerns about dividing by zero when calculation the cast time of rejuv... you would use the GCD for instant casts, not zero, since the GCD is the time you pay for the spell. This is the reason why getting haste to the soft cap is important, to raise your Healing / second of cast time

That doesn't work 100% because some of the spells are truly instant. It's true that the majority of rejuv casts will be limited by the GCD, but by making that broad assumption you discount cases like going from a nourish cast into rejuvenation, which results in rejuv behaving as an instant spell. Inconsistencies like that tend to magnify mathematical error the further you get from pure rejuv spam into a mixture of spells.

I still disagree that HPCT is a better ruler than HPS, but I'm having a difficult time pinning down exactly why or at least communicating it. However, I do have suspicions that my model isn't working for rejuv, though I do think it does a reasonable job with the other spells. I'm going to have to ponder it for awhile.

Share this post


Link to post
Share on other sites
That doesn't work 100% because some of the spells are truly instant. It's true that the majority of rejuv casts will be limited by the GCD, but by making that broad assumption you discount cases like going from a nourish cast into rejuvenation, which results in rejuv behaving as an instant spell. Inconsistencies like that tend to magnify mathematical error the further you get from pure rejuv spam into a mixture of spells.

I still disagree that HPCT is a better ruler than HPS, but I'm having a difficult time pinning down exactly why or at least communicating it. However, I do have suspicions that my model isn't working for rejuv, though I do think it does a reasonable job with the other spells. I'm going to have to ponder it for awhile.

No. All Rejuvs cost you 1GCD of execution time, regardless of what you were doing in advance. HPET is easy to calculate.

Share this post


Link to post
Share on other sites
That doesn't work 100% because some of the spells are truly instant. It's true that the majority of rejuv casts will be limited by the GCD, but by making that broad assumption you discount cases like going from a nourish cast into rejuvenation, which results in rejuv behaving as an instant spell. Inconsistencies like that tend to magnify mathematical error the further you get from pure rejuv spam into a mixture of spells.

I still disagree that HPCT is a better ruler than HPS, but I'm having a difficult time pinning down exactly why or at least communicating it. However, I do have suspicions that my model isn't working for rejuv, though I do think it does a reasonable job with the other spells. I'm going to have to ponder it for awhile.

I think Slou has it right.

Even after a Nourish, Rj has an effective cast time because you have to wait for the GCD before you are free to do something else.

Nourish+Nourish costs 2.3 seconds. Nourish+Rejuv+Nourish costs 3.3 seconds. You can't say that Rejuv was "free".

I think that once you ask the user for %healed from each spell, the low HPS gets naturally resolved. If I am healing a single tank, the low HPS from Rejuv is automatically penalized. Rejuv won't account for more than 10 or 15% of my healing, and your spreadsheet will see that 10 or 15% number.

Share this post


Link to post
Share on other sites
That doesn't work 100% because some of the spells are truly instant. It's true that the majority of rejuv casts will be limited by the GCD, but by making that broad assumption you discount cases like going from a nourish cast into rejuvenation, which results in rejuv behaving as an instant spell. Inconsistencies like that tend to magnify mathematical error the further you get from pure rejuv spam into a mixture of spells.

I still disagree that HPCT is a better ruler than HPS, but I'm having a difficult time pinning down exactly why or at least communicating it. However, I do have suspicions that my model isn't working for rejuv, though I do think it does a reasonable job with the other spells. I'm going to have to ponder it for awhile.

I think the clearest way to show the problem with using HPS is to replace rejuv that heals for 1/3rd of a regular rejuv tick, but after one second of casting the spell and never again instead of every three seconds. Notice that this is no difference whatsoever than a spell with a 1 second cast time and an instant cast that heals 1 second after casted. So basically, if I replaced our best spell, with a spell with a 1 second cast timer that heals for about 800 with 3k SP... the stat weights from your spreadsheet wouldn't change.

The main reason we stack spell power is because rejuv and WG scale so well with it, but under your method, they scale worse than nourish and regrowth.

Share this post


Link to post
Share on other sites
No. All Rejuvs cost you 1GCD of execution time, regardless of what you were doing in advance. HPET is easy to calculate.

No. I was taking cast time to mean the period of time one is forced to wait before a spell fires, not large scheme execution time loss. There is a subtle difference, but there is one. Of course if you think healing per execution time lost is better than hpct, then that's another thing but they aren't the same.

Of course I'm not saying that rejuv is free. I'm not trying to deny the existence of the GCD here. It's just kind of difficult to conceptualize. There are two kinds of spells: instants and non-instants. Each type has a waiting period associated with it but differentiated in its relative position of the waiting period to the spell firing. Instants have the WP after the spell fires and non-instants have it before, represented by the GCD and the cast time respectively. This has interesting ramifications because non-instant spells are always impeded by their own cast time since the spell fires after the WP, but instants only impede a spell so long as there is another spell queued up afterwards. You would probably argue that it's easy to simply assume you're always chain casting, but my goal is to build the sheet to support a wide range of gear and playstyles, which includes those that don't have the gear to constantly chain cast. I would rather add another constant or something so that that effect could be adjusted.

I'm kind of interested in what you mean by "low HPS gets naturally resolved", Erdluf.

Share this post


Link to post
Share on other sites
No. I was taking cast time to mean the period of time one is forced to wait before a spell fires, not large scheme execution time loss. There is a subtle difference, but there is one. Of course if you think healing per execution time lost is better than hpct, then that's another thing but they aren't the same.

Of course I'm not saying that rejuv is free. I'm not trying to deny the existence of the GCD here. It's just kind of difficult to conceptualize. There are two kinds of spells: instants and non-instants. Each type has a waiting period associated with it but differentiated in its relative position of the waiting period to the spell firing. Instants have the WP after the spell fires and non-instants have it before, represented by the GCD and the cast time respectively. This has interesting ramifications because non-instant spells are always impeded by their own cast time since the spell fires after the WP, but instants only impede a spell so long as there is another spell queued up afterwards. You would probably argue that it's easy to simply assume you're always chain casting, but my goal is to build the sheet to support a wide range of gear and playstyles, which includes those that don't have the gear to constantly chain cast. I would rather add another constant or something so that that effect could be adjusted.

I'm kind of interested in what you mean by "low HPS gets naturally resolved", Erdluf.

I think you encountered a similar issue when you looked at the HPS of glyphed HT, which is clipped by the GCD. Instead of dividing the healing by the cast time, you divided the healing done by the GCD to make the number more realistic. This is kind of the same thing.

If you want to maximize total healing, there is only one way to do this, which is divide by the cast time. I think that you aren't trying to maximize total healing, but rather maximize the healing done within a certain amount of time of the cast. For example, the fight just started and the tank got hit for 10k. I can cast a nourish for like 4k, or a rejuv, that heals for 0 before the tank dies. I think you are trying to make this show up in the stat weights, but it shouldn't. If you cast rejuv for on the tank and the tank died within seconds, rejuv is still 0% of your healing! This choice is already factored in when you select your spell usage. If your rejuv won't heal for more than 3k, it shouldn't be used. But assuming your rotation is fixed, and overhealing is small, even the last tick of rejuv matters, and your SP increases the healing of every tick. Your current model would give the same results if rejuv only ticked once instead of 6 times.

I haven't checked yet, but if you modeled all hots the same, this would also be true for LB, WG, and the hot part of Regrowth.

Share this post


Link to post
Share on other sites

Alright, fine. As I can't seem to come up with why I'm against it, then I'll change it, although I'm going to do it healing per execution time lost since hpct doesn't really work with instants.

On the plus side, I'm thinking about making the next version a rewrite of the spreadsheet so that I can make some infrastructural changes/improvements that'll make it easier to develop and work with. So, if you have any suggestions for anything, there's a good chance it will be implemented provided it makes sense.

Share this post


Link to post
Share on other sites

I would recommend you keep HPS in the spreadsheet. It is still an important number. Once someone is already in the firepot, the high HPET for Rejuv is not much help. However, HPET is usually a better measure for gearing decisions, in my opinion.

A minor correction, to the Nourish calculations. It looks like the bonus from Glyph of Nourish is additive with the 20% from having a HoT on the target. In spreadsheet terms it means changing (2*GoNo+1)*1.2 to (2*GoNo+1.2). See Rawr issue here.

That same post puts the bounds on the Nourish coefficient between .6705 and .6726. The spreadsheet is using .6702.

Share this post


Link to post
Share on other sites
Hey all. I believe I've noticed a glitch with the spreadsheet. The Runed Cardinal Ruby (epic spellpower gem) seems to have the wrong spellpower coefficient in the gem list. It's listed as 25sp and in game it manifests as 23. The gem list seems to be password protected and I can't manage to change it.

This spreadsheet is invaluable to me and the rest of my resto druids. Thank you so much for working on this!!

I noticed this was mentioned a while back but it seems as if it wasn't addressed. I just downloaded a copy of the spreadsheet and it still shows the Runed Cardinals as 25sp instead of 23. It also shows the same for the Runed Stormjewel.

Share this post


Link to post
Share on other sites

Are there any plans for making the spreadsheet to work with OpenOffice.org because it seems some VBA macros rewriting is necessary(wich lot of us i suppose cant do ourselves)? If there is some workaround possible i would be realy thankful if someone shares it.

Share this post


Link to post
Share on other sites
Are there any plans for making the spreadsheet to work with OpenOffice.org because it seems some VBA macros rewriting is necessary(wich lot of us i suppose cant do ourselves)? If there is some workaround possible i would be realy thankful if someone shares it.

There are no plans for me personally making a version of this operational for openoffice. This is mostly due to time constraints.

Share this post


Link to post
Share on other sites

Looks like the database has been updated. In free time when not feeling lazy i am writing a program for automation the getting the information on items, so soonâ„¢ might be able to tell what items are still missing.

Edit. My item parser works in such way: one manually gets html text with items, manually truncates info from it, with winword replaces some text with line breaks, saves result in text file, and only than treats the file to program. Having commas in unexpected places(e.g., item name) doesn't help writing. Getting all ways to get the item isn't easy when item can be obtained in various ways.

Edit2.items2_for_excel.zip is now testable. As always, usage of executables is on your own risk. How to use it: open Items - World of Warcraft in your favorite browser, choose the slot, click apply filter, click view source, select all, paste in notepad, save it. Double click the program, input the file name, and 3 new files should appear. The ones you would like to see, end with 1.txt and 2.txt. Open them with Excel and watch the result. The program shouldn't work with trinkets(one still may try to get the correct link).

Share this post


Link to post
Share on other sites

That would be really handy! If/when you get it up and running give me a jingle. On another note, currently I'm planning out the rewrite of the sheet and plan on making two versions. One will be for WotLK and the other for Cata; hopefully this will make the transition between expansions effortless.

Share this post


Link to post
Share on other sites

Seems you don't have the Onyxia loot added, I tried adding it in the gearlist, but it is giving me issues. Also, it seems you do not have "Solace of the defeated" added.

Edit: Oh, the error when I hit recalculate is " run-time error"13" type mismatch."

(Great spreadsheet though!)

Share this post


Link to post
Share on other sites

Yeah, adding loot to the Gearlist will error out the calculation, because the lists that the gear and buffs sheet uses are separated from the gearlist itself due to how vlookup works. Thus when the gearlist puts that item into the gear setup, it will cause all the vlookup functions to spit reference errors everywhere and cascades down everything eventually causing the vba code to error. This is one of the big things I'm going to work on in my rewrite, that and some kind of automated method for updating the databases.

Share this post


Link to post
Share on other sites

Sorry to bug you but any ETA on 3.3? I'm curious how HT is weighing in against Nourish these days.

Share this post


Link to post
Share on other sites

When Pain has one ready to work with 3.3 a new thread will be started. Since it's currently out of date I'm going to lock this so we don't end up with a bunch of folks posting for update status.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.