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.

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

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 StrangerMen are but flesh and blood. They know their doom, but not the hour. - Patrick StewartThornir

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.

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.

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.

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

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?

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.

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.

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)CSAS <-- still caught the proc

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

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.

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.

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.

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.

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

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

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.

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.