# Thread: Warrior - averaged rotation

1. Blechtroll
Join Date
Dec 2007
Location
Berlin
Posts
172

## Warrior - averaged rotation

Since the implementation of Sword and Board our consistent SS-Rev-Dev-Dev rotation is obsolete, for obvious reasons. Which is imo a very good thing, since it reduces the chance that we fall asleep while tanking a single target. =)
However, even though this reactive tanking most likely will be more fun, it'll make threat calculations a pain in the ass. The latest change to Revenge (SnB proc) makes it even more complicated.
So i think we need some kind of "averaged rotation", which is a sequence of skills that represents our inconsistent rotation in the long term and which we can use for threat calculations.

First off - I'm not particularly good at math, so i'd highly appreciate if someone with some real math skills could recheck this stuff.
Also, i'm a poor programmer, so i did this simulation with an editor and a calculator. Feel free to code a more professional simulation.

Ok, so i simulated a 100 sequences starting with Shield Slam followed by Revenge, since these are still (with the latest change to Revenge) our most effective threat abilities. Now, Revenge will proc SnB 30% of the time, so 30 of those 100 sequences go on with SS, the other 70 with Devestate (since SS and Revenge are on cooldown). And so on. The next ablility is:
- SS if SnB was procced or the last 3 abilities were not SS
- Rev if the last 3 abilities were not Rev
- otherwise Dev
Hope this is understandable.

Then, after each "round" (column), i calculated the average use of every ability in that sequence. After 4 GCDs, this is 1.51 Shield Slams, 1.49 Devestates and 1 Revenge. A ratio of roughly 1.5SS:1.5Dev:1Rev. After 4 GCDs, we get about the same ratio, and it should be about the same after 12 GCDs. I guess these are the relevant parts, because SS (in the worst case) and Revenge need 4 GCDs to cool down.

So, i would conclude this to: Our new "averaged rotation" is 1.5SS - 1Rev - 1.5Dev per 6sec/4GCD cycle or, if you want whole numbers, 3SS - 2Rev - 3Dev per 12sec/8GCD cycle.

Code:
```SS Rev	SS Rev SS	SS Rev SS Dev		SS Rev SS Dev SS	SS Rev SS Dev SS Rev	SS Rev SS Dev SS Rev SS		SS Rev SS Dev SS Rev SS Dev
(x100)	(x30)		(x30)			(x9)			(x9)			(x2.7)				(x2.7)

SS Rev SS Dev SS Rev Dev	SS Rev SS Dev SS Rev Dev SS
(x6.3)				(x1.89)

SS Rev SS Dev SS Rev Dev Dev
(x4.41)

SS Rev SS Dev Dev	SS Rev SS Dev Dev SS	SS Rev SS Dev Dev SS Rev	SS Rev SS Dev Dev SS Rev SS
(x21)			(x6.3)			(x6.3)				(x1.89)

SS Rev SS Dev Dev SS Rev Dev
(x44.1)

SS Rev SS Dev Dev Rev	SS Rev SS Dev Dev Rev SS	SS Rev SS Dev Dev Rev SS Dev
(x14.7)			(x14.7)				(x14.7)

SS Rev Dev	SS Rev Dev SS		SS Rev Dev SS Dev	SS Rev Dev SS Dev SS	SS Rev Dev SS Dev SS Rev	SS Rev Dev SS Dev SS Rev SS
(+70)		(x21)			(x21)			(x6.3)			(x6.3)				(x1.89)

SS Rev Dev SS Dev SS Rev Dev
(x4.41)

SS Rev Dev SS Dev Rev	SS Rev Dev SS Dev Rev SS	SS Rev Dev SS Dev Rev SS Dev
(x14.7)			(x4.41)				(x4.41)

SS Rev Dev SS Dev Rev Dev	SS Rev Dev SS Dev Rev Dev SS
(x10.29)			(x10.29)

SS Rev Dev Dev		SS Rev Dev Dev SS	SS Rev Dev Dev SS Rev	SS Rev Dev Dev SS Rev SS	SS Rev Dev Dev SS Rev SS Dev
(x49)			(x49)			(x49)			(x14.7)				(x14.7)

SS Rev Dev Dev SS Rev Dev	SS Rev Dev Dev SS Rev Dev SS
(x34.3)				(x10.29)

SS Rev Dev Dev SS Rev Dev Dev
(x24.01)
-------------------------------------------------------------------------------------------------------------------------------------------------------------
51% 2SS, Dev, Rev	 9% 3SS, Dev, Rev	 9% 3SS, Dev, 2Rev	 3% 4SS, Dev, 2Rev		 8% 4SS, 2Dev, 2Rev
49% SS, 2Dev, Rev	91% 2SS, 2Dev, Rev	13% 3SS, 2Dev, Rev	53% 3SS, 2Dev, 2Rev		68% 3SS, 3Dev, 2Rev
78% 2SS, 2Dev, 2Rev	44% 2SS, 3Dev, 2Rev		24% 2SS, 4Dev, 2Rev

1.51 1.49 1.00		2.09 1.91 1.00		2.22 1.91 1.87		2.59 1.56 2.00			2.84 3.16 2.00```
Last edited by Naka; 09-28-2008 at 02:16 PM.

2. Blechtroll
Join Date
Dec 2007
Location
Berlin
Posts
172
uhm. code is cropped by the forum, here it is again:
Nopaste - avrot

Oh, and maybe i should note that this simulation doesn't account that due to the Shield Block change, we won't necessarily have Revenge up all the time. And it doesn't account for Concussion Blow and Shockwave, obviously.
Last edited by Naka; 09-28-2008 at 08:48 AM.

3. *ponder* So you have "SS, Rev, SS, Rev" occuring in your cycle up there? Revenge has a 5s cooldown, which means you'll have an extra 0.5 second delay in this case. If you mean to do that, you'll probably want to account for varying lengths of time for different ability combinations as well. (i.e. calculate SS/sec, rev/sec, dev/sec instead of SS/rot, rev/rot, dev/rot so that the impact of using less abilities per rotation in some circumstances is clear.)

Edit: Ahh, never mind. I misread the chart, and that is unnecessary (although still possibly interesting). Carry on.

4. Blechtroll
Join Date
Dec 2007
Location
Berlin
Posts
172
Oh well yeah. Now that i look at it again, i guess the chart would really confuse me too, if i didn't write it myself. *g*
Maybe i'll find the time and make it more readable in the next days.
Or maybe can save the work... why do you think it's unnecessary?

5. I'm using some rather strange "operators" here, because I don't want to get confused between "sum of possibilities" and "sequence of operations". (I did in fact get confused by this in my early breakdowns.) So I'll introduce the concepts first.

The ";" operator is a "sequence" operator. "x; y" means "first x happens, then y happens". Sequence is not reflexive: the order matters. "x; y" is not the same as "y; x", for example.

The "&" operator is a bit more complicated. This operator denotes multiple possibilities, each of which has some probability. So "0.3 x & 0.7 y" means that there's a 30% chance that x happens and a 70% chance that y happens. The probabilities involved must sum to 1.0 within a single sequence of "&"s. So "0.3 x & 0.3 y & 0.4 z" is a valid expression, but "0.3 x & 0.3 y" on its own is not, because the probabilities don't sum to 100%.

Parenthesis serve the purpose you expect they serve: They group things up so you don't get confused about whether ";" or "&" takes priority.

Now, an example of manipulating these a little bit. Let's pretend we have two abilities "X" and "Y". These abilities are a little weird. X starts cooled down, and is the ability we prefer to use. X doesn't cool down on its own--there's a 30% chance of it becoming available after we use ability Y. Hopefully, you can see how this is a toy problem in the same general family as the Sword and Board proc. Anyway, here's how we would write that out:

Code:
```p = X; q
q = Y; 0.3p & 0.7q```
Here, we start out by defining a state "p", which is our base state: ability X is available. We use X, obviously. Now, X is no longer available, so we use another state to represent the new situation. In this state "q", we must use ability "Y". Afterwards, there's a 30% chance that X has become available (and we return to state p), and a 70% chance that X is still not available, and we remain in state q.

The above two formulas completely describe the system, except for the "base state" part. Now, the next step is that we wish to simplify the above formulas in order to understand things better. How can we manipulate them?

Well, the main things we can do are "substitution" (putting the value of q in place of the symbol q) and "distribution" where we distribute the probabilities of an "inner" sub-expression out in order to see the mix of whole chains of events. That explanation is going to be totally unclear to most people, so let me give an example:

Code:
```p = X; q
q = Y; 0.3p & 0.7q```
Here are our two equations from before. Let's try substituting the definition of q into the definition of p:

Code:
`p = X; Y; 0.3p & 0.7q`
So here we've substituted in the value of q in place of the symbol q. Doing so makes things a bit messy, so we use the "distribution" mechanism to simplify a bit:

Code:
```p = 0.3 (X; Y; p) &
0.7 (X; Y; q)```
We've moved the probabilities all the way to the outside of the equation here, to show the separate possible sequences of events. Unfortunately, this isn't a very interesting result--it hasn't simplified things at all. But what if we instead substitute the definition of "p" into the definition of "q"?

Code:
`q = Y; 0.3 (X; q) & 0.7 q`
This is a bit interesting. p isn't part of the equation at all any more. We've gotten rid of it completely. Let's simplify:

Code:
```q = 0.3 (Y; X; q) &
0.7 (Y; q)```
So 30% of the time, we use Y and then follow it with X, and then continue as normal. 70% of the time, we use Y and then just keep going. That's a bit nicer.

Okay. So, that's the basics out of the way. Now on to the real deal.

New notation: When I write "S(x, y)" below, that represents a state. That state is "there are x seconds left on Shield Slam's cooldown and there are y seconds left on Revenge's cooldown". I've done this so you can see the exact reasoning going on. Each state also has a letter assigned, and that "name" for the state will be used later (since it's a lot shorter!)

Note that you'll never see S(6.0, x) for the state. That's because the state we transition to after using an ability is the state after the end of the GCD. So right after we use SS, we go to S(4.5, 0.0): There are 4.5s left on the cooldown of Shield Slam when we get our next opportunity to do anything at all after Shield Slam is used.

Of course, all of the following states are defined assuming that we always wish to use SS in preference to Rev in preference to Dev. And they ignore other abilities.

So here are out states, with S(0.0, 0.0) (both Revenge and Shield Slam are cool) being the base state. The states are listed in order of cooldown left to go:

Code:
```   SS  Rev
S(0.0, 0.0) = a = SS; S(4.5, 0.0)
S(0.0, 0.5) = b = SS; S(4.5, 0.0)
S(0.0, 2.0) = c = SS; S(4.5, 0.5)
S(0.0, 3.5) = d = SS; S(4.5, 2.0)
S(1.5, 0.0) = e = Rev; S(0.0, 3.5)
S(1.5, 2.0) = f = Dev; S(0.0, 0.5)
S(1.5, 3.5) = g = Dev; S(0.0, 2.0)
S(3.0, 0.0) = h = Rev; 0.3 S(0.0, 3.5) & 0.7 S(1.5, 3.5)
S(3.0, 0.5) = i = Dev; 0.3 S(0.0, 0.0) & 0.7 S(1.5, 0.0)
S(3.0, 3.5) = j = Dev; 0.3 S(0.0, 2.0) & 0.7 S(1.5, 2.0)
S(4.5, 0.0) = k = Rev; 0.3 S(0.0, 3.5) & 0.7 S(3.0, 3.5)
S(4.5, 0.5) = l = Dev; 0.3 S(0.0, 0.0) & 0.7 S(3.0, 0.0)
S(4.5, 2.0) = m = Dev; 0.3 S(0.0, 0.5) & 0.7 S(3.0, 0.5)```
Now let's list those out using just the letter designations and then we'll start simplifying.

Code:
```a = SS; k
b = SS; k
c = SS; l
d = SS; m
e = Rev; d
f = Dev; b
g = Dev; c
h = Rev; 0.3 d & 0.7 g
i = Dev; 0.3 a & 0.7 e
j = Dev; 0.3 c & 0.7 f
k = Rev; 0.3 d & 0.7 j
l = Dev; 0.3 a & 0.7 h
m = Dev; 0.3 b & 0.7 i```
The first thing to notice is that we can eliminate one of these because it's identical to another. a and b both have the same behavior--in both of them, we use Shield Slam next, and in both of them Revenge is cool on the next GCD. We remove b and replace b with a everywhere. So with that first pass of simplifications:

Code:
```a = SS; k
c = SS; l
d = SS; m
e = Rev; d
f = Dev; a
g = Dev; c
h = Rev; 0.3 d & 0.7 g
i = Dev; 0.3 a & 0.7 e
j = Dev; 0.3 c & 0.7 f
k = Rev; 0.3 d & 0.7 j
l = Dev; 0.3 a & 0.7 h
m = Dev; 0.3 a & 0.7 i```
The next step is to start substituting and distributing a bit. I will always distribute fully after this point, because otherwise things start to get really confusing. Let's start with that.

Code:
```a = SS; k
c = SS; l
d = SS; m
e = Rev; d
f = Dev; a
g = Dev; c
h = 0.3 (Rev; d) & 0.7 (Rev; g)
i = 0.3 (Dev; a) & 0.7 (Dev; e)
j = 0.3 (Dev; c) & 0.7 (Dev; f)
k = 0.3 (Rev; d) & 0.7 (Rev; j)
l = 0.3 (Dev; a) & 0.7 (Dev; h)
m = 0.3 (Dev; a) & 0.7 (Dev; i)```
And now let's do some subtitutions. We'll distribute at the same time. Our first set of substitutions will be putting k, l, and m into a, c, and d, because those are the only places that k, l, and m occur. That way we can remove those equations completely.

Code:
```a = 0.3 (SS; Rev; d) & 0.7 (SS; Rev; j)
c = 0.3 (SS; Dev; a) & 0.7 (SS; Dev; h)
d = 0.3 (SS; Dev; a) & 0.7 (SS; Dev; i)
e = Rev; d
f = Dev; a
g = Dev; c
h = 0.3 (Rev; d) & 0.7 (Rev; g)
i = 0.3 (Dev; a) & 0.7 (Dev; e)
j = 0.3 (Dev; c) & 0.7 (Dev; f)```
Next we'll substitute e, f, and g into h, i, and j. These are very simple, and again it allows us to eliminate more equations:

Code:
```a = 0.3 (SS; Rev; d) & 0.7 (SS; Rev; j)
c = 0.3 (SS; Dev; a) & 0.7 (SS; Dev; h)
d = 0.3 (SS; Dev; a) & 0.7 (SS; Dev; i)
h = 0.3 (Rev; d) & 0.7 (Rev; Dev; c)
i = 0.3 (Dev; a) & 0.7 (Dev; Rev; d)
j = 0.3 (Dev; c) & 0.7 (Dev; Dev; a)```
And now we'll put h, i, and j into a, c, and d. And this should show you why I've been distributing the probabilities this whole time, because it starts to get a bit hairy.

Code:
```a = 0.3 (SS; Rev; d) &
0.7 (SS; Rev; 0.3 (Dev; c) &
0.7 (Dev; Dev; a))

c = 0.3 (SS; Dev; a) &
0.7 (SS; Dev; 0.3 (Rev; d) &
0.7 (Rev; Dev; c))

d = 0.3 (SS; Dev; a) &
0.7 (SS; Dev; 0.3 (Dev; a) &
0.7 (Dev; Rev; d))```
That's with it un-distributed. And once we distribute it out:

Code:
```a = 0.30 (SS; Rev; d) &
0.21 (SS; Rev; Dev; c) &
0.49 (SS; Rev; Dev; Dev; a)

c = 0.30 (SS; Dev; a) &
0.21 (SS; Dev; Rev; d) &
0.49 (SS; Dev; Rev; Dev; c)

d = 0.30 (SS; Dev; a) &
0.21 (SS; Dev; Dev; a) &
0.49 (SS; Dev; Dev; Rev; d)```
Now, here's the interesting thing. Remember the "p" and "q" example way back? We were able to simplify the "rotation" down to a single state, q, and describe the long-term behavior of the system in terms of just that one state (even though it wasn't our start state.)

But with this, we can't do that: these three states above are impossible to unify into a single state--each of them is defined in terms of itself and the others at the same time. And, if we look closely, we can see why no further simplification is possible.

What these three states represent is "to what degree are the cooldowns for Shield Slam and Revenge 'out of phase' with each other?" State "a" occurs when Revenge will be ready immediately after performing a Shield Slam. State "b" occurs when Revenge will be ready one GCD after performing a shield slam. State "d" occurs when Revenge will be ready two GCDs after performing a shield slam. The transitions to the different states occur depending when the S&B proc happens (or doesn't happen.)

In the cases of states "a" and "c", a "one GCD early" shield slam will move to the next state in line, and a "two GCD early" shield slam will move two states forward. In the case of "d", both varieties will move to "a" because in the "two GCD early" case, the Shield Slam itself will eat up the necessary time to get Revenge ready. (And that's the same reason we ended up eliminating state "b": The Shield Slam always ate up the necessary 0.5 seconds in that state, leaving it identical to state "a".)

Okay, so that was long and convoluted. What can we learn from this?

The first thing is that our "four GCD rotation" is totally gone. The procs from S&B will cause early Shield Slams in 51% of Shield Slam cooldown periods. Because this behavior is now the same across both Devastate and Revenge, we can calculate the average cooldown of Shield Slam: 0.3 * 3.0 + 0.21 * 4.5 + 0.49 * 6.0 = 4.785. So with S&B, we'll get to hit Shield Slam on average every 4.785 seconds.

The second thing is that Revenge will get used a bit less often than it used to be. Why? Not because we want to avoid it in favor of Devastate, but because Shield Slam will occasionally become ready at the same time as Revenge. Specifically, in the first case of state "c" and the second case of state "d" this will occur. I don't think this is a bad thing: It just arises from the priority of which skill produces the most powerful threat, and the fact that the two abilities will go in and out of phase from each other based on random procs. If it's any consolation, Devastate use is reduced even more. And the "missed uses" from both abilities are of course going to Shield Slams instead, which is a net win.

The third thing to note is that state "a" will be in effect somewhat more often than the other states. I haven't figured out how to calculate the actual proportion of times spent in each state, yet (a simulation could estimate this pretty easily, though), but... Here's the deal. First, state "d" will never transition to state "c". Second, state "a" will transition to state "d" more often than to state "c", and state "c" will transition to state "a" more often than to state "d". The end result is that state "a" will happen a bit more often than the other states.

I invite anybody who wish to use these state definitions to calculate the actual time spent in each state (which will automatically imply the relative numbers of uses of each ability, since it's easy to calculate the probabilities within a single state.)

6. Blechtroll
Join Date
Dec 2007
Location
Berlin
Posts
172
Now i feel like a real amateur. *g*
No, really, thank you Hypatia. That is pretty much exactly what i was seeking for, but couldn't do it myself. Surprisingly, i understand your math almost completely (the last part is tough).
Maybe i'll try to get back to it and to the remaining task when i have more time.

Anyway - i know it's far from being capable math or accurate, but can you at least relate to my attempt and to my conclusion, that it is roughly 3 Shield Slams, 3 Devastates and 2 Revenges per 12 seconds? Or is that completely off?
Last edited by Naka; 09-28-2008 at 03:33 PM.

7. Rotations are pretty much a thing of the past now with S&B, especially when the change goes in to trigger it off of Devastate and Revenge both. It's a priority problem now. When #1 is off coodown use it, elseif #2 is off cooldown use it, else use #3.

8. Naka: Yeah, those proportions look about right. And your technique was not at all flawed--it's a good way of going about it. The answers aren't perfect, but they're certainly good enough.

And as Satrina said, not worth worrying about this all too much, in terms of "rotations", anyway. What having a good knowledge of the relative proportions of each ability does is give us a foundation for saying how much a given talent or piece of gear will impact our threat output.

For example, assuming Naka's numbers of 2.84 SS + 3.16 Dev + 2.00 Rev per 12s we can substitute the "expect threat gain" from SS, Dev, and Rev in to that formula, and get an "expect threat from abilities per 12s". Then if we say "Okay, if I trade X block value for Y attack power, SS and Dev will instead output these values." Substitute in the new values and then compare the two. (And you can add in auto-attack and heroic strike values, too, based on whatever assumptions you wish.)

So it's useful.

On the other hand, having a close approximation is certainly good enough. We know that lag, human error, and the need to use other abilities are all going to have an impact.

Anyway, kudos to you, Naka, for making an effort to calculate the numbers rather than just saying "it feels like this". Good stuff.

9. Registrant
Join Date
Sep 2008
Posts
37
For what it's worth, I updated my simulation (original code posted here).

This is the result I got:

Code:
```In a 120s cycle with 150ms lag between moves:
Shield Slams: 22.8
Free Slams: 15.0
Devastates: 34.3
Revenges: 15.6```
Note that the free slams are a subset. You get 22.8 SSlams, and 15 of them are free.

10. Blechtroll
Join Date
Dec 2007
Location
Berlin
Posts
172
Originally Posted by Hypatia
What having a good knowledge of the relative proportions of each ability does is give us a foundation for saying how much a given talent or piece of gear will impact our threat output.
That's exactly what i did it for - threat calculations, as i mention in the first post. I want to do an evaluation of the threat talents which is not that trivial with SnB. Thats why i started this thread too, btw. I'm well aware that LK is the end of the rotation as we know it.
Although, as someone mentioned in another thread, it actually has always been a priority problem, it just turned out to be a flat rotation 90% of the time.

Originally Posted by talisfears
For what it's worth, I updated my simulation (original code posted here).

This is the result I got:

Code:
```In a 120s cycle with 150ms lag between moves:
Shield Slams: 22.8
Free Slams: 15.0
Devastates: 34.3
Revenges: 15.6```
Note that the free slams are a subset. You get 22.8 SSlams, and 15 of them are free.
Very nice. Looks like you get about the same numbers, only more accurate. And you account for Revenge not being up all the time. Nice. Although 75% seems a little low to me, but i guess thats a whole new task - calculating the uptime of Revenge, hehe.

Edit: oops, missed your note, thought it were 37.8 SS total. Damn. Gotta take a closer look.
Last edited by Naka; 09-29-2008 at 09:02 AM.

11. Warrior -- it's like that
Join Date
Jun 2008
Posts
779
Originally Posted by Naka
That's exactly what i did it for - threat calculations, as i mention in the first post. I want to do an evaluation of the threat talents which is not that trivial with SnB.
Another really great use of this is simply analyzing how well we're performing. Honestly, I trust you guys to tell me which talents and gear to pick up . What this says to me is this: "Here's your optimum ratios of abilities. Reach for them.". Between the math here and a solid WWS report, you can see how close your "rotation" comes to being perfect. It never will be, because there's more to tanking than these 3 abilities, but it gives us all a great goal for which to strive.

In short: thanks to ye, o people smarter than I.

12. Blechtroll
Join Date
Dec 2007
Location
Berlin
Posts
172
Originally Posted by Naka
Edit: oops, missed your note, thought it were 37.8 SS total. Damn. Gotta take a closer look.
Alright, you just used 10% for SnB to proc, hence the small number of Shield Slams. I'll have to either install PHP tomorrow, or port the script to C, and run a few simulations myself. Btw, you updated the Revenge uptime to 80% in the comment, but not in the code.

Anyway, i cannot thank you enough for this script, as my already low programming skills have gotten totally rusty.

13. Registrant
Join Date
Sep 2008
Posts
37
Updated the simulation so you can change the amount of lag without losing accuracy. Code is here.

14. Not New Registrant
Join Date
Jul 2007
Posts
23
I did a simulation based on your teory, Hypatia.
For every shieldslam you get 0.765 revenges and 1.425 devastates. Ran the simulation with 10^8 cycles, defining cycle as the start of a shieldslam.

It is kinda close to Naka's numbers
2.84 ss, 3.16 dev, 2.00 rev (0.704 rev and 1.11 dev per shieldslam)

attached the code

edit: the proportion of time spend in each state:
state "a": 0.461
state "c": 0.190
state "d": 0.349

anyone else getting the same?
Last edited by weel; 10-01-2008 at 03:02 PM.

15. Useless Noob
Join Date
Apr 2008
Posts
145
With the crazy Revenge numbers in the latest build, would it take priority over a normal (non-free) SS even in high-rage situations?

16. Registrant
Join Date
Sep 2008
Posts
37
My first instinct would be no (SS is still more rage efficient than Rev+HS), but this is something I was interested in testing out. I'll post here if I figure it out.

17. Registrant
Join Date
Sep 2008
Posts
37
So it looks like the most appropriate answer is it doesn't matter. You'll only be presented with the choice after a SS-Rv-Dv-Dv sequence, and even then only if your lag between moves averages 167ms or more.

In the rare cases when you do have a choice, it's better to hit Revenge. However the overhead of watching carefully for the free-slam buff will wipe out the advantage. I'd recommend you just hit SS when it's up.

Also note in very high rage (where you're hitting every possible Heroic Strike), Shield Slam is better again.

18. Originally Posted by weel
I did a simulation based on your teory, Hypatia
Results look good. I calculated the expected ratios of abilities based on the ratios of states you reported, and got consistent results. I've also just run my own simulations, both using the state-transition model from above, and using the basic "compute what's done every GCD" approach, both over 100,000,000 iterations. (Which is 1e8 GCDs in the basic system and 1e8 Shield Slams in the state model.)

My results there come up the same:

Code:
```>>> test(100000000, method_a)
<function method_a at 0x3225b0> (172.86s):
ss: 31349470
rev: 23978800
gcd: 100000000
dev: 44671730```
So that's (percentage of GCDs used for each ability): 31.35% SS, 23.98% Rev, and 44.67% Dev.

Code:
```>>> test(100000000, method_b)
<function method_b at 0x3225f0> (83.94s):
a: 147023657
c: 60506360
gcd: 318993403
ss: 100000000
rev: 76491095
dev: 142502308
d: 111463386```
And here: 31.35% SS, 23.98% Rev, and 44.67% Dev (46.09% A, 18.97% C, 34.94% D)

So, I'm pretty well satisfied that the state-based description I came up with is an accurate model of what's going on. Since all of the numbers (ratios from pure simulation, ratios from state-based simulation, ratios from state-based simulation computed state-ratios times analytic ability distributions within the states) line up, this is pretty much certainly correct.

So, the end result, without computing "free-ness" of abilities, is:

Our abilities will be used in this percentage of GCDS, or on average this often (in seconds):

Shield Slam: 31.35% (SS/4.785s) (0.209 SS/s)
Revenge: 23.98% (Rev/6.255s) (0.160 Rev/s)
Devastate: 44.67% (Dev/3.358s) (0.298 Dev/s)

For those keeping score, that means we'll have 125.4% as many Shield Slams on average as without Sword and Board. Wow.

And the ratios on the states mean my deductions about which happens more often were correct... although I hadn't realized just how big the preference for "A" would be. So, almost all of the time SS and Revenge will go next to each other. 19% of the time, you'll use Devastate between a SS and a Revenge.

Which sort of makes me sad. I like the finger-rhythm of SS, Dev, Rev, Dev better than the other two options when I was in the tanking groove. ;>

19. WOW... that's a lot of shield slams O_o

20. Not New Registrant
Join Date
Jul 2007
Posts
23
Lucky me, I'm stuck in SS to Rev then Dev but I was also surprised over how big state "a" was