Theck's MATLAB thread - Cataclysm/4.x

Warning: Theorycraft inside.

Moderators: Fridmarr, Worldie, Aergis, theckhd

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Iminmmnni » Thu May 05, 2011 4:09 am

tlitp wrote:If we are to be rigorous, haste isn't a smooth manifold for Prot. Autoattacks (via parryhaste), SoT (via Censure), ability usage (via mana income, via JotW) - they all exhibit "ugly" scaling with haste. It's fair to say, however, that their effects are somewhat lost in the noise generated by other abilities/mechanics.


If we actually modeled auto-attacks, our state space would explode as we no longer have nice multiples of 0.5s for everything. We also ignore spell GCD reductions and assume that Cons is always fixed duration. We should be able to model the haste effects you mentioned fairly accurately as they don't actually effect our ability usage (I assume we'll just switch between different rotation based on current mana and I believe net mana usage for rotations is on our todo list). It also helps that as prot we can realistically assume 0 haste on our gear.
Iminmmnni
 
Posts: 45
Joined: Thu Mar 24, 2011 4:41 pm
Location: Melbourne

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Awyndel » Fri May 06, 2011 3:26 am

Just for those who are interested. I tried sotr-cs-as-j-hw-conc with the asthetic crusader glyph and i barely had to watch the mana. Ocasionally you still have to skip a concecration but thats very rare. For those that want more mental bandwith...
User avatar
Awyndel
 
Posts: 595
Joined: Sat Feb 14, 2009 8:49 am
Location: The Netherlands

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Thornir » Fri May 06, 2011 6:19 am

Awyndel wrote:Just for those who are interested. I tried sotr-cs-as-j-hw-conc with the asthetic crusader glyph and i barely had to watch the mana. Ocasionally you still have to skip a concecration but thats very rare. For those that want more mental bandwith...


Which seal did you use?
Many fall, but one remains. - The Stranger
Men are but flesh and blood. They know their doom, but not the hour. - Patrick Stewart
Thornir

*Now with 100% more beef!*
User avatar
Thornir
 
Posts: 292
Joined: Sat Nov 29, 2008 6:25 pm
Location: In some sewers beneath a prison somewhere

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Awyndel » Fri May 06, 2011 4:39 pm

Truth
User avatar
Awyndel
 
Posts: 595
Joined: Sat Feb 14, 2009 8:49 am
Location: The Netherlands

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Lathdari » Sat May 07, 2011 5:23 pm

SotR>CS>AS>J(>Cons>HW mana permitting) (939) is our "default" rotation.
Since queues aren't easy for most people to visualize, "bugged" 939 is equivalent to the following rotation:
CS-X-, where you fill X with SotR if you have 3 holy power, and if not fill it with AS, J, Cons or HW in that order of priority.


That's not strictly true any more is it, because if you use AS off a GrC proc with 2 HoPo, then the priority means SotR comes next, breaking the CS-X- pattern.
Lathdari
 
Posts: 16
Joined: Sat May 07, 2011 4:05 pm

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby theckhd » Sat May 07, 2011 6:15 pm

Yeah, that description is no longer technically correct. I'll try and re-word it in the next update pass.
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of Grehn|Skipjack.
Simcraft 6.x, Call to Arms 6.0, Talent Spec & Glyph Guide 6.x, Blog: Sacred Duty
User avatar
theckhd
Moderator
 
Posts: 6211
Joined: Thu Jul 31, 2008 3:06 pm
Location: Harrisburg, PA

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Kihra » Mon May 09, 2011 10:07 am

I am wondering if there is a queue that models the concept that you shouldn't waste a Grand Crusader proc. The specific scenario I am thinking of is something like this:

CS (1 HoPo)
filler
CS (2 HoPo)
filler
CS (3 HoPo, Grand Crusader procs, Sacred Duty is up)
SotR (Dodged)
SotR (Parried)
SotR (Success!)
AS now or lose the HoPo from it! <-------

I've run into this scenario a few times. Even though my queue is normally

SotR if Inq/SD > Inq > CS > AS > J ...

in this one particular case, I use AS, since if I don't, the proc is gone, and I won't get HoPo from it. It seems like it's the right thing to do, but I figured I would check.
Kihra
 
Posts: 340
Joined: Mon Dec 31, 2007 12:01 pm

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Iminmmnni » Mon May 09, 2011 4:56 pm

AS[buffGC<2] will do the trick: SDSotR>ISotR>Inq>AS[buffGC<2]>CS>AS>J.
Iminmmnni
 
Posts: 45
Joined: Thu Mar 24, 2011 4:41 pm
Location: Melbourne

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby M.C. » Mon May 09, 2011 5:07 pm

tlitp wrote:
Iminmmnni wrote:The approach is not feasible for specs where arbitrary haste must be modeled accurately. Prot is ideal as we essentially ignore haste (...)

If we are to be rigorous, haste isn't a smooth manifold for Prot. Autoattacks (via parryhaste), SoT (via Censure), ability usage (via mana income, via JotW) - they all exhibit "ugly" scaling with haste. It's fair to say, however, that their effects are somewhat lost in the noise generated by other abilities/mechanics.

I thought parry-haste does not happen anymore. Am I wrong?
M.C.
 
Posts: 9
Joined: Sun Oct 04, 2009 3:47 pm

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby tlitp » Mon May 09, 2011 11:05 pm

It's alive. Somewhat. :P
User avatar
tlitp
 
Posts: 487
Joined: Mon Jul 27, 2009 3:25 pm

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby theckhd » Tue May 10, 2011 6:11 am

Kihra wrote:I am wondering if there is a queue that models the concept that you shouldn't waste a Grand Crusader proc. The specific scenario I am thinking of is something like this:


Iminmmnni wrote:AS[buffGC<2] will do the trick: SDSotR>ISotR>Inq>AS[buffGC<2]>CS>AS>J.


Oddly enough, that doesn't seem to convey any advantage. The reasoning isn't completely clear to me yet, but based on this output it seems that this prioritization ends up creating more empty GCDs, which negates the benefit of using AS instead of CS.

Code: Select all
                                                            DPS            TPS            SHPS            E     I 
  Q#  Priority                                              V=100%  V=30%  V=100%  V=30%  V=100%  V=30%   %     % 
   1  SotR>CS>AS>J                                          15630   10149  46891   30447     0       0    7.4   0.0
   4  SotR>AS>CS>J                                          15446   10028  46339   30084     0       0    8.6   0.0
  20  SDSotR>ISotR>Inq>CS>AS>J                              15771   10238  47314   30713     0       0    7.5  40.2
  22  SDSotR>ISotR>Inq>AS[buffGC<2]>CS>AS>J                 15632   10148  46897   30443     0       0    8.3  39.5
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of Grehn|Skipjack.
Simcraft 6.x, Call to Arms 6.0, Talent Spec & Glyph Guide 6.x, Blog: Sacred Duty
User avatar
theckhd
Moderator
 
Posts: 6211
Joined: Thu Jul 31, 2008 3:06 pm
Location: Harrisburg, PA

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Shathus » Tue May 10, 2011 7:36 am

theckhd wrote:Oddly enough, that doesn't seem to convey any advantage. The reasoning isn't completely clear to me yet, but based on this output it seems that this prioritization ends up creating more empty GCDs, which negates the benefit of using AS instead of CS.


Perhaps because whether you use GC for the HP proc or not, it still resets the cooldown on AS, so if you're not prioritizing AS and just hit CS, it just means AS is available later and you don't have to hit HW instead (or have an empty GCD).
Shathus
Maintankadonor
 
Posts: 741
Joined: Sun Apr 06, 2008 5:02 pm

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Chicken » Tue May 10, 2011 9:37 am

Those are pretty weird results yeah. The effect it would be expected to have would be to produce cycles like ShoR>AS[buffGC<2]>CS>J>CS>… which you'd expect to outdo the standard ShoR>CS>AS>CS>J>CS>… cycle. The higher amount of empty GCDs is logical since you are at one point prioritizing a higher cooldown ability over the lower cooldown one, but you'd expect the 1 GCD faster finisher to make up for that.

Does it result in similar lower DPS on the rotation without Inq, and/or the rotations with HW and Cons included as filler?
Image
User avatar
Chicken
 
Posts: 425
Joined: Fri Jun 26, 2009 2:19 pm

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Kihra » Tue May 10, 2011 9:43 am

theckhd wrote:Oddly enough, that doesn't seem to convey any advantage. The reasoning isn't completely clear to me yet, but based on this output it seems that this prioritization ends up creating more empty GCDs, which negates the benefit of using AS instead of CS.


That result just seems really suspicious to me, but maybe there's something I'm missing. You're really just making a choice between AS-CS or CS-AS. The former will give you 2 HoPo and the latter will only give you 1 (unless GC procs again). You're only putting AS on CD 1.5 seconds earlier, and you generate HoPo quicker for the next SotR/Inq. You also get another shot at a GC proc. The situation should also occur so rarely that it's hard to believe it would have much of an impact at all, and a DPS loss is a really surprising result to me.
Kihra
 
Posts: 340
Joined: Mon Dec 31, 2007 12:01 pm

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Meloree » Tue May 10, 2011 10:14 am

Kihra wrote:
theckhd wrote:Oddly enough, that doesn't seem to convey any advantage. The reasoning isn't completely clear to me yet, but based on this output it seems that this prioritization ends up creating more empty GCDs, which negates the benefit of using AS instead of CS.


That result just seems really suspicious to me, but maybe there's something I'm missing. You're really just making a choice between AS-CS or CS-AS. The former will give you 2 HoPo and the latter will only give you 1 (unless GC procs again). You're only putting AS on CD 1.5 seconds earlier, and you generate HoPo quicker for the next SotR/Inq. You also get another shot at a GC proc. The situation should also occur so rarely that it's hard to believe it would have much of an impact at all, and a DPS loss is a really surprising result to me.


Unless I'm misunderstanding something, shouldn't it be "Buff < 1.5"?

It's a counterintuitive result to me, as well, though. Given how important HP is with the ridiculous SD uptime now, I would have expected the HP generating machine to trump an extra empty GCD - and even then, I'm not sure I see the extra empty, given that you've pulled forward the next ShoR. I suppose CS misses could well account for it, though - you create empties when CS misses, because you've already used up the filler that would have spaced it out some.
Meloree
Maintankadonor
 
Posts: 794
Joined: Wed Mar 12, 2008 10:15 am

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Kihra » Tue May 10, 2011 11:04 am

Meloree wrote:Unless I'm misunderstanding something, shouldn't it be "Buff < 1.5"?


I think I know what might be happening. There is a small time displacement on the acquisition of Grand Crusader. Typically you gain the aura around 0.3 seconds after a successful Crusader Strike. The queue I brought up is not GCBuff < 2. It's GCBuff < 0.3.

With GCBuff < 2, AS is being used here:

CS (GC Proc)
SotR (miss)
SOtR(hit)
AS <-- Oops! Technically at the time you are able to hit AS, the proc only has ~1.8 seconds left.

This is wrong of course, since you could do this instead:

CS (GC Proc)
SotR (Dodge)
SotR (hit)
CS
AS <-- still caught the proc

But below is the case I was really talking about. It's perfectly feasible to do this:

CS (GC Proc)
SotR (dodge)
SotR (parry)
SotR (hit)
AS <----- still caught the proc

But I suspect the current model sees the above as "time left = 0" and assumes you can't catch a GC proc from that. You can though.
Kihra
 
Posts: 340
Joined: Mon Dec 31, 2007 12:01 pm

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby theckhd » Tue May 10, 2011 11:15 am

Chicken wrote:Does it result in similar lower DPS on the rotation without Inq, and/or the rotations with HW and Cons included as filler?


Yup:
Code: Select all

                                                            DPS            TPS            SHPS            E     I 
  Q#  Priority                                              V=100%  V=30%  V=100%  V=30%  V=100%  V=30%   %     % 
   1  SotR>CS>AS>J                                          15630   10149  46891   30447     0       0    7.4   0.0
   4  SotR>AS>CS>J                                          15446   10028  46339   30084     0       0    8.6   0.0
  11  SotR>CS>AS>J>Cons>HW                                  16084   10508  48253   31525     0       0    1.6   0.0
  12  SotR>AS+>CS>AS>J>Cons>HW                              16069   10499  48208   31499     0       0    1.8   0.0

  20  SDSotR>ISotR>Inq>CS>AS>J                              15771   10238  47314   30713     0       0    7.5  40.2
  22  SDSotR>ISotR>Inq>AS[buffGC<2]>CS>AS>J                 15632   10148  46897   30443     0       0    8.3  39.5
  23  SDSotR>ISotR>Inq>AS[buffGC<=1.5]>CS>AS>J              15632   10148  46897   30443     0       0    8.3  39.5
  24  SDSotR>ISotR>Inq>AS[buffGC<1.5]>CS>AS>J               15623   10142  46868   30425     0       0    8.3  39.4

  29  SDSotR>ISotR>Inq>CS>AS>J>Cons>HW                      16269   10632  48807   31897     0       0    1.7  40.2
  30  SDSotR>ISotR>Inq>AS[buffGC<2]>CS>AS>J>Cons>HW         16143   10553  48430   31661     0       0    2.4  39.5
  31  SDSotR>ISotR>Inq>AS[buffGC<=1.5]>CS>AS>J>Cons>HW      16143   10553  48430   31661     0       0    2.4  39.5
  32  SDSotR>ISotR>Inq>AS[buffGC<1.5]>CS>AS>J>Cons>HW       16132   10546  48398   31640     0       0    2.4  39.4



These are for 2% hit and 10 expertise. It seems that the results hold with the 8% hit / 26 expertise case though:

Code: Select all
                                                            DPS            TPS            SHPS            E     I 
  Q#  Priority                                              V=100%  V=30%  V=100%  V=30%  V=100%  V=30%   %     % 
   1  SotR>CS>AS>J                                          18270   11878  54809   35635     0       0    6.0   0.0
   4  SotR>AS>CS>J                                          18018   11713  54055   35138     0       0    7.4   0.0
  11  SotR>CS>AS>J>Cons>HW                                  18722   12233  56168   36698     0       0    0.8   0.0
  12  SotR>AS+>CS>AS>J>Cons>HW                              18667   12197  56001   36592     0       0    1.1   0.0

  20  SDSotR>ISotR>Inq>CS>AS>J                              18448   11990  55344   35971     0       0    6.0  43.3
  22  SDSotR>ISotR>Inq>AS[buffGC<2]>CS>AS>J                 18303   11897  54909   35691     0       0    6.8  41.9
  23  SDSotR>ISotR>Inq>AS[buffGC<=1.5]>CS>AS>J              18303   11897  54909   35691     0       0    6.8  41.9
  24  SDSotR>ISotR>Inq>AS[buffGC<1.5]>CS>AS>J               18300   11895  54901   35686     0       0    6.8  41.9

  29  SDSotR>ISotR>Inq>CS>AS>J>Cons>HW                      18942   12377  56827   37133     0       0    0.8  43.3
  30  SDSotR>ISotR>Inq>AS[buffGC<2]>CS>AS>J>Cons>HW         18813   12297  56440   36893     0       0    1.4  41.9
  31  SDSotR>ISotR>Inq>AS[buffGC<=1.5]>CS>AS>J>Cons>HW      18813   12297  56440   36893     0       0    1.4  41.9
  32  SDSotR>ISotR>Inq>AS[buffGC<1.5]>CS>AS>J>Cons>HW       18810   12295  56431   36887     0       0    1.4  41.9


As to it's counter-intuitiveness, I agree. I could rationalize it at low-hit/exp based on empty GCDs and filler push-back (e.g. J-CS*-SotR(miss)-SotR-AS-CS-J-CS-empty-CS-SotR vs. J-CS*-SotR(miss)-SotR-CS-AS-CS-J-CS-SotR, assuming one of those CS's misses and no additional GrCr procs happen). However, I would have expected the result to reverse itself at high-hit/exp if that were the case, which doesn't happen. In addition, Cons/HW should help mitigate those empties, which doesn't seem to be the case based on 27/28.

I've added [buffGC<=1.5] and [buffGC<1.5] to the tables above to see if there are edge effects occurring. The situation we're interested in is CS*(6s left)-SotR(4.5s left)-SotR(3s left)-?(1.5s left). I believe the sim is still working in timesteps of 1.5s, so that ? slot should always be 1.5s left on GrCr.

Thus, the difference between [<2] and [<=1.5] shouldn't matter, but [<1.5] is functionally different since it excludes the exact case we're trying to improve. This seems borne out in the results: [<2] and [<=1.5] are identical, and [<1.5] always performs worse. That at least suggests that our intuition about the specific case is correct, and AS>CS in that particular situation is probably an improvement.

Which still leaves the question of why this queue performs over 100 DPS worse than its simple CS>AS>J counterpart. The key is probably that it's causing another, more dominant effect in a different scenario that's interfering. I'm not sure what that would be though, since the condition seems pretty specific. With the old priority code, I'd just generate a string of events and browse through them to see what sorts of local sequences occur, but I don't know how to do that with the FSM code yet. I know that Iminmmnni and I discussed that functionality, but I don't think it's implemented yet - at the very least, I don't remember seeing it in the code base, but I didn't have time to look through all of the test/troubleshooting sequences, so maybe it's buried in there.

There's also the possibility that the conditional isn't working properly (example: if it's actually evaluating buffGC>2, that would obviously change the results in a way that would cause a decrease). I can take a look at the code later today and see if that's the case.
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of Grehn|Skipjack.
Simcraft 6.x, Call to Arms 6.0, Talent Spec & Glyph Guide 6.x, Blog: Sacred Duty
User avatar
theckhd
Moderator
 
Posts: 6211
Joined: Thu Jul 31, 2008 3:06 pm
Location: Harrisburg, PA

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Kihra » Tue May 10, 2011 11:18 am

theckhd wrote:The situation we're interested in is CS*(6s left)-SotR(4.5s left)-SotR(3s left)-?(1.5s left).


That's actually not the situation I was interested in (see my previous post). I was talking about CS->SotR->SotR->SotR->? and am asserting that you can still generate HoPo on an AS used in the ? slot from a GC proc on that CS.

CS->SotR->SotR->? is not an ambiguous situation, since you do CS in the ? slot and then follow with AS and still generate HoPo from the AS.

I think that's the root of the misunderstanding... that you can still get HoPo from an AS used 6 seconds after a CS.
Kihra
 
Posts: 340
Joined: Mon Dec 31, 2007 12:01 pm

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby theckhd » Tue May 10, 2011 11:26 am

Kihra wrote:
Meloree wrote:Unless I'm misunderstanding something, shouldn't it be "Buff < 1.5"?


I think I know what might be happening. There is a small time displacement on the acquisition of Grand Crusader. Typically you gain the aura around 0.3 seconds after a successful Crusader Strike. The queue I brought up is not GCBuff < 2. It's GCBuff < 0.3.


So:

1) Based on what I posted above, GC duration is basically fixed at 6, 4.5, 3, 1.5, or 0 (not usable) in the sim. So buffGC<2 is the correct conditional for the sim if you want to limit it to "only cases where I won't be able to cast it on the following GC." In practice, I'd expect this to cover the CS-SotR(miss)-SotR(hit)-? situation properly.

2) However, delayed acquisition of the buff isn't in the sim, which removes CS-SotR(miss)-SotR(miss)-SotR(hit)-? from the table. Empirically, that can be "fixed" simply by setting the duration of the Grand Crusader buff to ~6.3 seconds initially, so that it overlaps into the next GCD by just enough to be used. That said, I'm not sure if this is reasonable given latency penalties on CS that also aren't modeled. CS*-SotR-CS-AS is certainly possible, but I'm not sure I've ever gotten CS*-SotR(m)-SotR-CS-AS to work (for example) because of the queuing penalty on CS. It might be confined to cases with 3 sequential SotR misses as a result, and it's clear from the results that this is such an infrequent event that it's a tiny effect (<10 DPS, even at low hit, based on 23 vs 24).

I'd also want to check and make sure that the buffGC conditional is working properly and that the buff works the way you described (6 full seconds from the application time t=0.3, rather than actually lasting 5.7 seconds from t=0.3s with display rounding making it look like it's 6 seconds) before tweaking too much.
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of Grehn|Skipjack.
Simcraft 6.x, Call to Arms 6.0, Talent Spec & Glyph Guide 6.x, Blog: Sacred Duty
User avatar
theckhd
Moderator
 
Posts: 6211
Joined: Thu Jul 31, 2008 3:06 pm
Location: Harrisburg, PA

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby theckhd » Tue May 10, 2011 11:33 am

Just a quick check:
Code: Select all
                                                            DPS            TPS            SHPS            E     I 
  Q#  Priority                                              V=100%  V=30%  V=100%  V=30%  V=100%  V=30%   %     % 
   1  SotR>CS>AS>J                                          15630   10149  46891   30447     0       0    7.4   0.0
   2  SotR>HotR>AS>J                                        14022    8985  42067   26956     0       0    7.4   0.0
   3  SotR>CS>J>AS                                          15529   10071  46586   30212     0       0    7.4   0.0
   4  SotR>AS>CS>J                                          15446   10028  46339   30084     0       0    8.6   0.0
   5  AS>SotR>CS>J                                          15306    9939  45918   29816     0       0    9.2   0.0
   6  SotR>CS>AS+>J>AS                                      15601   10124  46803   30372     0       0    7.3   0.0
   7  SotR>AS+>CS>J>AS                                      15584   10112  46753   30337     0       0    7.7   0.0
   8  SotR>AS+>CS>AS>J                                      15603   10130  46810   30389     0       0    7.8   0.0
   9  SotR>AS[buffGC>0]>CS>AS>J                             15603   10130  46810   30389     0       0    7.8   0.0
  10  SotR>AS[buffGC<6.5]>CS>AS>J                           15446   10028  46339   30084     0       0    8.6   0.0
  11  SotR>AS[buffGC<2]>CS>AS>J                             15484   10053  46451   30160     0       0    8.2   0.0
  12  SotR>AS[buffGC<=1.5]>CS>AS>J                          15484   10053  46451   30160     0       0    8.2   0.0
  13  SotR>AS[buffGC<1.5]>CS>AS>J                           15472   10047  46417   30140     0       0    8.2   0.0



From this it's clear that [buffGC>0] works properly, and we can surmise that [buffGC<X] is similarly working properly based on #4 and #10. Which leads me to the solution: [buffGC<2] includes buffGC=0, which is the default state of the system.

Conclusion: this was a wild goose chase, because we need to enforce that buffGC is less than 2 but also nonzero. In other words, [buffGC<2][buffGC>0] is the condition we should be using.
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of Grehn|Skipjack.
Simcraft 6.x, Call to Arms 6.0, Talent Spec & Glyph Guide 6.x, Blog: Sacred Duty
User avatar
theckhd
Moderator
 
Posts: 6211
Joined: Thu Jul 31, 2008 3:06 pm
Location: Harrisburg, PA

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby theckhd » Tue May 10, 2011 11:40 am

Updated Results:
Code: Select all
                                                               DPS            TPS            SHPS            E     I 
  Q#  Priority                                                 V=100%  V=30%  V=100%  V=30%  V=100%  V=30%   %     % 
   1  SotR>CS>AS>J                                             15630   10149  46891   30447     0       0    7.4   0.0
   4  SotR>AS>CS>J                                             15446   10028  46339   30084     0       0    8.6   0.0
   8  SotR>AS+>CS>AS>J                                         15603   10130  46810   30389     0       0    7.8   0.0
   9  SotR>AS[buffGC<2][buffGC>0]>CS>AS>J                      15643   10157  46929   30470     0       0    7.4   0.0
  11  sdAS>SotR>CS>AS>J                                        15492   10058  46475   30173     0       0    8.8   0.0
  22  SDSotR>ISotR>Inq>CS>AS>J                                 15771   10238  47314   30713     0       0    7.5  40.2
  24  SDSotR>ISotR>Inq>AS[buffGC<2][buffGC>0]>CS>AS>J          15782   10244  47345   30732     0       0    7.5  40.2
  29  SDSotR>ISotR>Inq>CS>AS>J>Cons>HW                         16269   10632  48807   31897     0       0    1.7  40.2
  30  SDSotR>ISotR>Inq>AS[buffGC<2][buffGC>0]>CS>AS>J>Cons>HW  16280   10639  48841   31918     0       0    1.7  40.2


Conclusion: AS[buffGC<2][buffGC>0] does indeed give an increase when prioritized over CS, as we initially expected. The increase is only ~10 DPS though, consistent with what we observed by comparing the [>2] and [>1.5] queues in previous posts.

Note that this still doesn't include the possibility of getting an AS off 6 seconds after the proc, but it can be inferred that this will probably also be a small DPS increase. I say small because the situation of CS*-SotR(m)-SotR(h)-AS-CS is already rare enough to only be a small DPS increase, and three-in-a-row SotR casts will be even less common. That means they're likely to be an even smaller increase as long as other factors don't interfere (possibly opening up other sequences that are more probable).
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of Grehn|Skipjack.
Simcraft 6.x, Call to Arms 6.0, Talent Spec & Glyph Guide 6.x, Blog: Sacred Duty
User avatar
theckhd
Moderator
 
Posts: 6211
Joined: Thu Jul 31, 2008 3:06 pm
Location: Harrisburg, PA

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Kihra » Tue May 10, 2011 11:42 am

theckhd wrote:It might be confined to cases with 3 sequential SotR misses as a result, and it's clear from the results that this is such an infrequent event that it's a tiny effect (<10 DPS, even at low hit, based on 23 vs 24).


That's the result I was expecting... that it would be a negligible DPS gain.

theckhd wrote:I'd also want to check and make sure that the buffGC conditional is working properly and that the buff works the way you described (6 full seconds from the application time t=0.3, rather than actually lasting 5.7 seconds from t=0.3s with display rounding making it look like it's 6 seconds) before tweaking too much.


You can basically use Seal of Insight and just hit a target dummy with CS->SotR over and over until you get a GC proc. At that point just use 3 consecutive abilities that are on the GCD, and then hit AS. Maybe I have really good latency, but I get the extra HoPo every time.

Anyway that clears up the confusion for me at least. I was talking about an extremely rare case, and the queue we ended up using was modeling a different case. :) It was never counter-intuitive to me that CS->SotR->SotR->AS would be a DPS loss over CS->SotR->SotR->CS, since I know I could still get HoPo from the AS that follows in the latter example.
Kihra
 
Posts: 340
Joined: Mon Dec 31, 2007 12:01 pm

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby theckhd » Tue May 10, 2011 11:56 am

Kihra wrote:It was never counter-intuitive to me that CS->SotR->SotR->AS would be a DPS loss over CS->SotR->SotR->CS, since I know I could still get HoPo from the AS that follows in the latter example.

Except it isn't, based on my results. They show CS*->SotR->SotR->AS is a (small) DPS gain over CS*->SotR->SotR->CS.

Remember, the sim doesn't handle your case, because it's impossible for the sim to generate holy power from the AS in CS*->SotR->SotR->SotR->AS unless we update the code to include that 0.3s gap between CS and GrCr.

The bug we were seeing is that [buffGC<2] includes any time when Grand Crusader isn't active. Thus, we were prioritizing AS>CS in cases where AS wasn't granting holy power.
"Theck, Bringer of Numbers and Pounding Headaches," courtesy of Grehn|Skipjack.
Simcraft 6.x, Call to Arms 6.0, Talent Spec & Glyph Guide 6.x, Blog: Sacred Duty
User avatar
theckhd
Moderator
 
Posts: 6211
Joined: Thu Jul 31, 2008 3:06 pm
Location: Harrisburg, PA

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Kihra » Tue May 10, 2011 12:07 pm

theckhd wrote:Remember, the sim doesn't handle your case, because it's impossible for the sim to generate holy power from the AS in CS*->SotR->SotR->SotR->AS unless we update the code to include that 0.3s gap between CS and GrCr.


Empirical evidence (just smacking the target dummy) is showing my intuition to be correct (that you can pretty much always get a HoPo on AS used 6 seconds later), but the reason why isn't necessarily clear. I'm assuming it's because there's a small delay before the GC aura is acquired, but who knows if that's really the reason.

Sometimes I see the aura at about 0.25 seconds, but it's pretty consistently at 0.25-0.4 seconds if combat log timestamps can be trusted.

For example:

[23:05:29.542] Kihra Crusader Strike Sinestra *15177*
[23:05:29.799] Kihra gains Grand Crusader from Kihra

[23:05:58.004] Kihra Hammer of the Righteous Sinestra *10163*
[23:05:58.307] Kihra gains Grand Crusader from Kihra

[23:05:38.323] Kihra Crusader Strike Sinestra *16550*
[23:05:38.641] Kihra gains Grand Crusader from Kihra

It will be interesting to see the new results (assuming testing verifies my claims), since I don't think we're getting a 100% accurate picture of Grand Crusader until this is accounted for.
Kihra
 
Posts: 340
Joined: Mon Dec 31, 2007 12:01 pm

Re: Theck's MATLAB thread - Cataclysm/4.x

Postby Iminmmnni » Tue May 10, 2011 9:33 pm

theckhd wrote:Conclusion: this was a wild goose chase, because we need to enforce that buffGC is less than 2 but also nonzero. In other words, [buffGC<2][buffGC>0] is the condition we should be using.
The bug we were seeing is that [buffGC<2] includes any time when Grand Crusader isn't active. Thus, we were prioritizing AS>CS in cases where AS wasn't granting holy power.

Sorry about that: I should have thought about exactly what was intended before answering. You are correct that both conditionals are required (order won't matter) for the scenario in question.

theckhd wrote:Remember, the sim doesn't handle your case, because it's impossible for the sim to generate holy power from the AS in CS*->SotR->SotR->SotR->AS unless we update the code to include that 0.3s gap between CS and GrCr.


The simplest way to sim the above case is to increase the duration of GrCr by 0.5s (the sim is currently modelling buffs/CD to 0.5s accuracy*). Since the model also assumes zero latency any value >0 and <1.5s are equivalent.

If people can reliably get HP from CS*->SotR->SotR->CS->AS, it'd say it'd be worth modelling that.

* we use an unsigned 64-bit integer to represent a state and do some fancy state encoding to bit-pack the CD/buff durations into it and anything less than 0.5s doesn't fit into 64 bits.
Iminmmnni
 
Posts: 45
Joined: Thu Mar 24, 2011 4:41 pm
Location: Melbourne

PreviousNext

Return to Advanced Theorycraft and Calculations

Who is online

Users browsing this forum: No registered users and 1 guest

Who is online

In total there is 1 user online :: 0 registered, 0 hidden and 1 guest (based on users active over the past 5 minutes)
Most users ever online was 380 on Tue Oct 14, 2008 6:28 pm

Users browsing this forum: No registered users and 1 guest