Since the model is based on infinite combat length, I assume renataki's soul charm and bad juju will be better in practice than they appear on that list due to the extra proc you typically see at the start of the fight as a consequence of the "bad luck protection" (an extra ~7-8kish agility proc for 20 sec at the start of a fight is much more valuable than an extra ~1.5-1.7k haste proc for 10 sec, especially since it's lined up with your opening burst).
For example, on an 8 minute fight, an extra 20 seconds of 541 juju is worth 364.75 average agility (8754 * 20/(8*60)), and an extra 10 seconds of 541 talisman is worth 38.25 haste rating (1836 * 10/(8*60)). 364.75 agility is worth hugely more than 38.25 haste.
*HUGE simplification, because I didn't account for the possibility of procs overwriting those procs (or extending, for talisman) or how the talisman haste synergizes with other rppm effects, but it illustrates the concept well enough for my current laziness level*
Last edited by Nitwit; 2013-04-18 at 10:45 PM.
Right, so I'm running through the maths you've posted wimp, still a bit concerned on how it's modelling Talisman - would you mind offering your methodology for, say the 541 talisman at a set haste value?
---------- Post added 2013-04-19 at 12:58 PM ----------
So, to compare, my uptimes with a 541 Talisman and 24% haste:
Stack size -> Uptime
1 -> 0.276
2 -> 0.136
3 -> 0.069
4 -> 0.036
5 -> 0.042
---------- Post added 2013-04-19 at 01:13 PM ----------
These results, however, bring me pretty much in line with my previous table and nothing to what yours looks like - which has me worried.
Sure thing. This post will probably only be of interest to Ryme/other theorycrafters. You have been warned...
Haste = 24%
Lambda = (RPPM*Proc_duration*(1+Haste))/60
The overall uptime is =bad_luck_protection*(1-EXP(-Lambda))
The uptime of 'at least two stacks' = bad_luck_protection*(1-EXP(-Lambda*))^2, where Lambda* has been calculated using the 1834 extra haste provided by the first stack.
With that, the uptime for 1 stack = 'overall uptime' - 'uptime for at least two stacks'
Same thing for the remaining stacks (except for the 5th stack, obviously, where the uptime is simply = 'uptime of at least 5 stacks').
Following this through, I get the following uptimes:
1 stack 26.92%
2 stacks 13.28%
3 stacks 6.84%
4 stacks 3.66%
5 stacks 5.20%
Let's not lose track of what we're after: we want an overall figure of haste. To get this, multiply stack % by the haste each stack gives and add them all up. Which gives 4079 haste. Which is equivalent to an average stack size of 3.98 (and that's the number you plug into your spreadsheet! Bear in mind this number is haste dependent...)
Ah, perhaps this is where I've gotten lost, would you mind clarifying since I'm not the best with statistical distributions (don't tell my boss!); would it not be bad_luck_protection*((1-exp(-lambda_0))*(1-exp(-lambda_1))
Where lambda_0 is the your lambda calculated at 0 stacks and lambda_1 is your lambda calculated at 1 stack?
My thought process here is that if you maintain the same lambda on every calculation, you lose the shifts in haste between each stack effecting the chance of the next one happening.
tbh reading this thread atm i am so confused about which trinket is best for assassination spec. I know this thread is about normal and heroic trinkets, but since i only play LFR and got so lucky about trinkets i dont know which to use. I have normal bottle non upgrade, lfr renetaki, lfr talimsan and lfr Rune of Re-Origination. So plz can anybody have good advice which 2 trinkets to choose ? And yeah I wanna know why everybody say Rune of Re-Origination sucks for assassination rogue ?
thx and cheers
@Ryme: Hehe, I suspect if anything our respective bosses might question the time we're spending modelling WoW trinkets... Nice catch there: I think you are right. I had changed the lambda for the entire calculation, but it makes more sense to have each term using their individual lambdas. Though I have to say you've made my spreadsheet much uglier!
I thought I'd try to add this to the modelling, as it's a large enough effect to affect rankings.
In a finite fight, we'll see an additional uptime = (Probability of not having this extra proc) * (additional uptime due to the guaranteed proc at the start).
The 'additional uptime due to the guaranteed proc at the start' is easy enough = proc_duration/fight_length.
The probability of not having a proc at the start is a bit harder. I'm using the Poisson answer to 'probability of not having a proc in a time equal to the proc duration', which is EXP(-Lambda'*proc_duration). Where Lambda' is the average number of procs per second, which is = (RPPM*(1+Haste))/60.
I'll give the results below, but just want to address one other thing. Since we're modelling this, we should also answer the question 'How long do we have to wait?' The answer to that is easier, in order to guarantee a proc on the pull, we have to wait =(MPT*(MPT+35))/30, where MPT is the mean proc time. The answer varies for the different RPPM trinkets, with the wait time decreasing as the square of the RPPM.
Assuming a fight length of 450 seconds, the maths gives:
Bad Juju: an extra 3.54% uptime (which translates to around 712EP for the 522 version). In order to guarantee a proc on pull, you have to wait 6 minutes.
Renataki's: an extra 3.45% uptime (which translates to around 692EP for the 522 version). In order to guarantee a proc on pull, you have to wait 6 minutes and 20s.
Talisman: an extra 1.12% uptime (which translates to around 70EP for the 522 version). In order to guarantee a proc on pull, you only have to wait 24 seconds, which is nice.
I have updated the table on my initial post, to account for all the changes mentioned on this thread, so as not to flood this thread with tables, and also to keep all the up-to-date info on the one place, since that post has been linked to from the OP. I've also left it at just the one table, since I expect most will be confused by there being two slightly different tables for different values of haste.
I have reduced the overall haste value (since the 10% melee haste value doesn't count towards RPPM mechanics).
Finally, I've added the LFR version of trinkets... It didn't seem a terribly unreasonable request, and I thought it might be nice not to be an elitist jerk. Just this once.
Last edited by wimp; 2013-04-19 at 03:26 PM.
Have you looked into Wimp's sheet on the last page? If not, take a look there and see if you can understand why. Happy to help if you get stuck.
You haven't upgraded the bottle, which really lowers the value of it. Also, the talisman helps to proc other trinkets, dancing steel and the new legendary meta gem. But in all seriousness, they're not going to mean too much if you are in a raiding team. The 1st and 3rd bosses in ToT drop some of the best trinkets, so you can grab them early. You can probably pug those anyway, they really don't take too much on normal.
I have what I think is a very simple question: how often do rogues attack? I expect this is something which has been figured out before, but a quick googling didn't get me an answer. I'm after the average number of attacks per whatever unit of time, counting everything (auto attacks from either hand, specials etc). Is there a simple formula to approximate this rate?
The shadowcraft backend has an attacks_per_second list which you could use. You don't have to be particularly skilled with python to sum over the values of the dict. For each spec there is a function get_SPECNAME_attack_counts which returns the final aps vector at the end you could drop a quick sum right in there, note that for assassination there is both an execute and non-execute version of the function. Of course then you would have to accept the various modeling assumptions of shadowcraft which you may not want to do but if you set the run script to use no trinkets and no weapon enchants you could probably get some pretty "clean" values. You could do a similar analysis in SimCraft but I'm less familiar with SimCraft.
More broadly I'm curious why you need these, one of the underlying goals of RPPM is to normalize proc rates with respect to attack rates so unless there is something tricky going on with talisman I can't see why you'd need this.