Theck's MATLAB thread - Cataclysm/4.x

[Kihra]

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.

[theckhd]

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.

[Kihra]

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.

[theckhd]

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.

[theckhd]

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.

[theckhd]

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).

[Kihra]

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.

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.

[theckhd]

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.

[Kihra]

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.

[Iminmmnni]

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.

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.

[theckhd]

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.

[theckhd]

By the way, all of the sims on the front page are updated for 4.1a now.

[theckhd]

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.

[Meloree]

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.

[knaughty]

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!