Theck's MATLAB thread - Cataclysm/4.x

Warning: Theorycraft inside.

Moderators: Fridmarr, Worldie, Aergis, theckhd

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

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

Postby theckhd » Wed May 11, 2011 5:35 am

Let's do that then, and I'll fool around with some queues to see what it accomplishes. If you don't beat me to it, I'll increase the default GrCr duration to 6.5 when I get some time.
"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 » Wed May 11, 2011 7:14 am

By the way, all of the sims on the front page are updated for 4.1a now.
"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 » Wed May 11, 2011 8:14 am

I updated my local copy to increase the Grand Crusader duration to 6.5 seconds. Here's the 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                                             15642   10156  46925   30468     0       0    7.3   0.0
   2  SotR>HotR>AS>J                                           14033    8993  42100   26978     0       0    7.3   0.0
   3  SotR>CS>J>AS                                             15531   10072  46592   30216     0       0    7.4   0.0
   4  SotR>AS>CS>J                                             15452   10032  46357   30096     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                                         15616   10134  46849   30403     0       0    7.2   0.0
   7  SotR>AS+>CS>J>AS                                         15588   10114  46763   30343     0       0    7.7   0.0
   8  SotR>AS+>CS>AS>J                                         15606   10131  46817   30393     0       0    7.8   0.0
   9  SotR>AS[buffGC<2][buffGC>0]>CS>AS>J                      15644   10158  46933   30473     0       0    7.3   0.0
  10  sdAS>sdJ>SotR>CS>AS>J                                    15064    9768  45191   29304     0       0   11.5   0.0
  11  sdAS>SotR>CS>AS>J                                        15494   10059  46483   30178     0       0    8.8   0.0
  12  SotR>CS>AS>J>HW                                          15886   10401  47658   31202     0       0    2.8   0.0
  13  SotR>CS>AS>J>Cons>HW                                     16094   10514  48283   31544     0       0    1.6   0.0
  14  SotR>AS+>CS>AS>J>Cons>HW                                 16072   10501  48216   31504     0       0    1.8   0.0
  15  sdAS>sdJ>SotR>CS>AS>J>Cons>HW                            15588   10190  46764   30572     0       0    4.7   0.0
  16  Inq>CS>AS>J                                              13596    8836  40788   26507     0       0    7.8  94.2
  17  Inq>HotR>AS>J                                            12593    8041  37779   24122     0       0    7.8  94.2
  18  iInq>SotR>CS>AS>J                                        15162    9843  45485   29530     0       0    7.6  72.6
  19  Inq[buffInq<2]>SotR>CS>AS>J                              15027    9757  45082   29270     0       0    7.6  75.9
  20  iInq>SotR2>CS>AS>J                                       13843    8991  41530   26974     0       0    5.2   0.0
  21  ISotR>Inq>CS>AS>J                                        15162    9843  45485   29530     0       0    7.6  72.6
  22  SDSotR>ISotR>Inq>CS>AS>J                                 15780   10243  47340   30730     0       0    7.5  40.5
  23  ISotR>SDSotR>Inq>CS>AS>J                                 15780   10243  47340   30730     0       0    7.5  40.5
  24  SDSotR>ISotR>Inq>AS[buffGC<2][buffGC>0]>CS>AS>J          15782   10245  47347   30734     0       0    7.5  40.5
  25  ISDSotR>Inq>CS>AS>J                                      15043    9767  45130   29302     0       0    7.6  78.5
  26  Inq>CS>AS>J>Cons>HW                                      14196    9312  42588   27937     0       0    1.8  94.2
  27  Inq>HotR>AS>J>Cons>HW                                    13193    8517  39579   25552     0       0    1.8  94.2
  28  ISotR>Inq>CS>AS>J>Cons>HW                                15694   10265  47083   30797     0       0    1.7  72.6
  29  SDSotR>ISotR>Inq>CS>AS>J>Cons>HW                         16277   10637  48833   31913     0       0    1.7  40.5
  30  SDSotR>ISotR>Inq>AS[buffGC<2][buffGC>0]>CS>AS>J>Cons>HW  16279   10639  48839   31917     0       0    1.7  40.5
  31  SDSotR>ISotR>Inq>CS>AS>J>ICons>HW                        16197   10594  48593   31783     0       0    2.2  40.5
  32  SDSotR>Inq>CS>AS>J>Cons>HW                               16165   10567  48495   31703     0       0    1.7  46.5
  33  ISDSotR>Inq>CS>AS>J>Cons>HW                              15593   10204  46781   30613     0       0    1.7  78.5


Compare these to the last results I posted - queue #9 only went up by 1 DPS, suggesting that being able to take advantage of CS*-SotR(m)-SotR(m)-SotR(h)-(AS>CS) is a weak effect simply because of the relative infrequency of double-misses are. It's still a good thing to do, but you're unlikely to see any significant real-world DPS gain by doing so.

More interesting is that queue #1 went up by 12 DPS, and is now almost equivalent to #9. This is probably because of sequences like CS*-SotR(m)-SotR(h)-CS-AS-CS-SotR. With the old GrCr implementation that AS would not have granted HP, but now it does. Since it only requires one missed SotR to get into this scenario, this happens far more frequently than the double-miss scenario.

In any event, it looks like the double-miss situation Khira described is at best an increase of ~2 DPS over a simple CS>AS prioritization.
"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 Meloree » Wed May 11, 2011 8:37 am

theckhd wrote:In any event, it looks like the double-miss situation Khira described is at best an increase of ~2 DPS over a simple CS>AS prioritization.


Okay, Knaughty, get your laughs in. Even I'm not doing antics for a 2 dps increase.
Meloree
Maintankadonor
 
Posts: 794
Joined: Wed Mar 12, 2008 10:15 am

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

Postby knaughty » Wed May 11, 2011 3:01 pm

Meloree wrote:
theckhd wrote:In any event, it looks like the double-miss situation Khira described is at best an increase of ~2 DPS over a simple CS>AS prioritization.


Okay, Knaughty, get your laughs in. Even I'm not doing antics for a 2 dps increase.


Good to know we've found your limit! :twisted:
This isn't the "Offtankadin" forum. My MoP FAQ: http://tinyurl.com/FAQ-5-0
- Knaughty.
User avatar
knaughty
Maintankadonor
 
Posts: 1846
Joined: Mon Dec 17, 2007 10:06 pm
Location: Sydney, plotting my next diatribe against the forces of ignorance!

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

Postby Flarius » Fri Jun 03, 2011 6:09 am

You should run a simulation that introduces the High-Powered Bolt Gun as a type of filler over Consecration and Holy Wrath since it no longer has a cast time.

Most notably I'd be interested in knowing how much of a DPS increase merely having the weapon and knowingly slipping it in a rotation over consecration and holy wrath every two minutes is over not having it; I don't know too much about how the weapon scales with AP (I don't believe it does) so knowing its benefit in high/low/no vengeance scenarios would be useful, too. I've scanned through the thread as best I can, and I don't see it mentioned.
Flarius
 
Posts: 1
Joined: Tue Apr 28, 2009 12:21 am

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

Postby theckhd » Fri Jun 03, 2011 6:34 am

There's not much point in running a simulation for that, it's got a 2 minute cooldown. If it doesn't scale with AP, then it's going to be worse than Consecration at almost any Vengeance level (bolt gun does an average of 8500 damage, no idea if it can crit). Holy Wrath is only around 5400 damage per cast and doesn't vary with AP, so it could be a slight increase over that. Though you might be better off just using it to fill empty GCDs.

Best-case scenarios:
If you replace one empty GCD every 2 minutes, it's 8500/120 = 71 DPS.
If you replace one Holy Wrath every 2 minutes, it's (8500-5400)/120 = 26 DPS

Real-world values are likely to be a little lower than that because opportunities won't come at exact 2-minute intervals.
"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 Cassyboy » Tue Jun 07, 2011 3:26 pm

I've been wondering about a scenarion which haven't been mentioned as of yet.

Lets say GC procs on your second CS:

CS>AS>CS*>X1>CS>ShotR>CS>X2

If you cast AS at the first X, you will do about 1600 more raw damage than judgement and it grants a holy power. However, it does interfere with the CS>Y>CS>Y>CS>Y heartbeat. What I have been doing is casting judgement instead (only judgement) so that the heartbeat doesn't get interfered. With latency you'll be able to still get the holy power at the second X.

Pros:
Heartbeat doesn't get interfered, so more Shield Slams/burst.

Cons:
Less raw damage between judgement and AS and a 32% of proccing an other GC (20+20), making the movement useless.



I beg you Theck, could you make a simulation with this current scenario when you got time?

Cass
Last edited by Cassyboy on Tue Jun 07, 2011 6:32 pm, edited 1 time in total.
Cassyboy
 
Posts: 23
Joined: Wed Mar 16, 2011 7:55 am

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

Postby RedAces » Tue Jun 07, 2011 3:51 pm

the "best" rotation for singletarget is

ISotR>SDSotR>Inq>CS>AS>HoW>J>Cons>HW

So ... for your example the correct order would be:
CS - AS - CS (GC procced!) - AS - Inq (no SD or Inq up) - CS - ...
Image
User avatar
RedAces
 
Posts: 374
Joined: Tue Dec 01, 2009 9:39 am
Location: Germany

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

Postby Cassyboy » Tue Jun 07, 2011 6:27 pm

5 points to that

1. that still interferes with the holy power heartbeat

2. that is at 10 expertise and 2% hit. With my current gear and racial, I'm at 18 expertise and 3% hit (not sure about hit). The priority system you linked is less reliant on hit, so the more you got, the less viable it is

3. write down a priority up and live by it is bad. For example, will you consecrate when you got only 10K mana and you haven't got hallowed grounds? No, that's a horrible idea

4. The priority queue you linked above is very sensitive to extern spells like WoG, Holy radiance and hands spells. As if, if you use them while inquisition is up, you may not get that IShotR which results in a massive dps loss.

5. Your post is non sensible. I never asked what's the best rotation. I just asked for the outcome of this additional rule on the sim.
Cassyboy
 
Posts: 23
Joined: Wed Mar 16, 2011 7:55 am

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

Postby Kihra » Tue Jun 07, 2011 9:20 pm

Cassyboy wrote:I've been wondering about a scenarion which haven't been mentioned as of yet.

Lets say GC procs on your second CS:

CS>AS>CS*>X1>CS>ShotR>CS>X2

If you cast AS at the first X, you will do about 1600 more raw damage than judgement and it grants a holy power. However, it does interfere with the CS>Y>CS>Y>CS>Y heartbeat. What I have been doing is casting judgement instead (only judgement) so that the heartbeat doesn't get interfered. With latency you'll be able to still get the holy power at the second X.


No you can't. The Grand Crusader proc lasts six seconds and happens about 0.3 seconds or so after you Crusader Strike. You have to use it within 4 GCDs or you lose it. Your X2 is 5 GCDs removed from the CS that caused the proc and so an AS used there will not generate any Holy Power.

Cassyboy wrote:Pros:
Heartbeat doesn't get interfered, so more Shield Slams/burst.


The opposite is true. If you use the GC-backed AS immediately you get to 3 Holy Power 1.5 seconds faster. It's never going to be right to defer a GC proc when you have two Holy Power already, since you'd have to use it outside of a CS->Y heartbeat to get the Holy Power from it even if you deferred it. Either you do CS->AS->CS*->AS->SotR or you do CS->AS->CS*->J->CS->SotR->AS. The former is clearly better than the latter.
Kihra
 
Posts: 340
Joined: Mon Dec 31, 2007 12:01 pm

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

Postby Iminmmnni » Tue Jun 07, 2011 9:46 pm

Cassyboy wrote:I beg you Theck, could you make a simulation with this current scenario when you got time?

Cassyboy wrote:5. Your post is non sensible. I never asked what's the best rotation. I just asked for the outcome of this additional rule on the sim.


Your request is making invalid assumptions about how we are modelling ability rotations. Technically, we are no longer using a rotation nor a simulation in the model. Please have a re-read of the first page of posts of this thread. Theck has done a good job of keeping the information in there up to date and the current version of the model not only does a whole lot more than what you're asking, but addresses some of the issues that your request does not such a what to do if the second CS missed and you only have 2HP?

It sounds to me like you want a queue along the lines of SotR>CS>J[HP=2]>AS>J>Cons>HW. I don't have access to the code on this machine but given than SotR>CS>AS>J is better than SotR>CS>J>AS, I don't see how special casing J with SotR>CS>J[HP=2]>AS>J will somehow be better than both.

Edit: SotR>CS>J[HP=2][buffGC>0]>AS>J seems closer. Either way, it's a rather strange condition to have as not only are you delaying SotR by 1 GCD, you're also wasting the potential holy power from a GC proc on either CS before or after the SotR.
Last edited by Iminmmnni on Wed Jun 08, 2011 1:40 am, edited 2 times in total.
Iminmmnni
 
Posts: 45
Joined: Thu Mar 24, 2011 4:41 pm
Location: Melbourne

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

Postby Iminmmnni » Tue Jun 07, 2011 10:23 pm

Now these are interesting conversations to have:

Cassyboy wrote:For example, will you consecrate when you got only 10K mana and you haven't got hallowed grounds? No, that's a horrible idea


This sounds like an implicit request to add net mana usage as an output of the model. We're currently not tracking JotW uptime but it's relatively straight-forward to incorporate and given the FSM outputs cast/s for every ability, net mana usage will be fairly straight-forward to add once we know JotW uptime. As an added bonus, we'll be able to tell how the 4.2 judgement change will affect our mana.

Cassyboy wrote:The priority queue you linked above is very sensitive to extern spells like WoG, Holy radiance and hands spells. As if, if you use them while inquisition is up, you may not get that IShotR which results in a massive dps loss.


Regular WoG use is treated with separate models for which the dps/tps/hps results are on the first page. Holding HP for WoG for that incoming hit you know will be coming a) is going be a massive dps loss for any rotation and b) is not currently modeled. HR and hands are also not modeled.

Intuitively, it does make sense that Inq rotations will be more sensitive to interruptions and is the sort of thing that can be quantified with an appropriate model. Unfortunately, due to the nature of these interruptions, finding an accurate model is difficult. Some possible models are:
- a parameter corresponding to probability of casting nothing to each FSM transition. A 10% probability would indicate that on average, 10% of your GCDs are filled with something outside the rotation (HR, Hands, moving, etc). If you're using HR/Hands as fillers, then they should be modeled explicitly (eg SotR>CS>AS>J>HR>Cons>HW)
- extending the model of a priority queue to handle randomly choosing between abilities. Something along the lines of SotR,0.7|WoG,0.3>CS>AS>J modelling hitting SotR 70% of time you have 3HP and hitting WoG 30% of the time*.

* actual WoG usage would be less than 30% because you won't be able to cast WoG twice in a row due to the 20s CD.


Is there interest from the community in having any of the changes implemented?
Iminmmnni
 
Posts: 45
Joined: Thu Mar 24, 2011 4:41 pm
Location: Melbourne

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

Postby RedAces » Wed Jun 08, 2011 1:15 am

hey,

Cassyboy wrote:1. that still interferes with the holy power heartbeat

And? Fury warrior have a similar heart-beat system and yet they break it up for spells higher in the priority list.


Cassyboy wrote:2. that is at 10 expertise and 2% hit. With my current gear and racial, I'm at 18 expertise and 3% hit (not sure about hit). The priority system you linked is less reliant on hit, so the more you got, the less viable it is

Yes, so go look at the Thread in which you write, there are the sims for hitcapped expcapped rotations with both seals!!
theckhd wrote:SoT active, 8% hit, 26 expertise
#62 ISotR>SDSotR>Inq>CS>AS>HoW>J>Cons>HW

which is the exact same rotation as for the low-hit, low-exp situation.


Cassyboy wrote:3. write down a priority up and live by it is bad. For example, will you consecrate when you got only 10K mana and you haven't got hallowed grounds? No, that's a horrible idea

Yes thats the trick ... if I look at this priority list, I'll see this:
Code: Select all
mh ok at 3 HoPo I only use SotR if I have SD or Inq up, otherwise I just use Inq
CS whenever it's ready and I don't have 3 HoPo
AS next
HoW after the AS
...
Cons > HW means I should always use Cons first, but after testing I found out that I don't have mana for this... so I'll just use whatever I can afford.

With this rules in mind, I can make this rotation happen. If not ... practicing on a target dummy helps...


Cassyboy wrote:4. The priority queue you linked above is very sensitive to extern spells like WoG, Holy radiance and hands spells. As if, if you use them while inquisition is up, you may not get that IShotR which results in a massive dps loss.


Every priority list and every rotation is sensitive to external spells. These lists are there for you in a time where you don't have to do anything else. Of course they aren't optimal if do extra things, but we're not a dps class, our raid can handle if we only output 90% TPS over the course of the fight. The only parts where this rotation really matters are the first 10 - 15seconds on a new enemy. After that you'll be able to hold aggro with just SotR -> CS (+ a few Js for mana regg).


Cassyboy wrote:5. Your post is non sensible. I never asked what's the best rotation. I just asked for the outcome of this additional rule on the sim.


You asked:

Cassyboy wrote:I beg you Theck, could you make a simulation with this current scenario when you got time?


If you had read the big thread theck posted you'd know that this scenario is simmed out!
Theckhd wrote:There's no apparent gain in prioritizing AS over CS in any circumstance (#1 vs #4/#7).


So thats why I just posted the best rotation (because by definition it includes your scenario and was deemed "best") and answered your question. I hope this made sense to you now?

Bye, RedAces.
Image
User avatar
RedAces
 
Posts: 374
Joined: Tue Dec 01, 2009 9:39 am
Location: Germany

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

Postby Iminmmnni » Wed Jun 08, 2011 1:32 am

RedAces wrote:
Cassyboy wrote:1. that still interferes with the holy power heartbeat

And? Fury warrior have a similar heart-beat system and yet they break it up for spells higher in the priority list.

Our CS-X-CS-X-CS-SotR heatbeat died in 4.0.6 when CS misses stopped generating holy power.
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