Simulationcraft APL Discussion

Face-rippin fun.

Moderator: Forum Administrators

User avatar
aggixx
Exalted
Posts: 2292
Joined: Fri Nov 25, 2011 7:49 pm
Contact:

Re: Simulationcraft APL Discussion

Post by aggixx » Fri Jan 23, 2015 2:57 am

There's not really any implications because SimC takes more than 1s per GCD so it will end up getting the same amount of skills in the TF regardless.
ImageImage

Kojiyama
Revered
Posts: 478
Joined: Mon Jan 19, 2015 1:47 pm

Re: Simulationcraft APL Discussion

Post by Kojiyama » Fri Jan 23, 2015 11:54 am

Fair enough.

I think there are some implications for people's WA's or things like Ovale, though, since suggesting TF at 35-40 energy does appear like it would result in lost energy regardless of how fast the player's reaction times are?
Image

User avatar
aggixx
Exalted
Posts: 2292
Joined: Fri Nov 25, 2011 7:49 pm
Contact:

Re: Simulationcraft APL Discussion

Post by aggixx » Sat Jan 24, 2015 2:53 am

Well I mean it should go without saying that you shouldn't TF at anything but right before your GCD ends if you're in the 35+ energy zone.
ImageImage

Jeshu
Revered
Posts: 244
Joined: Tue Dec 14, 2010 5:34 pm

Re: Simulationcraft APL Discussion

Post by Jeshu » Sat Jan 24, 2015 10:20 am

FWIW, Ovale was modifed a few releases ago to suggest Tiger's Fury (or other similar off-GCD spells) when the previous GCD had ended so that it could be cast in-sync with the next ability and avoid losing time while the buff was active.

ShmooDude
Exalted
Posts: 1080
Joined: Tue Feb 08, 2011 5:51 pm

Re: Simulationcraft APL Discussion

Post by ShmooDude » Sat Jan 24, 2015 11:47 am

Kojiyama wrote:This is more a SimC thing than strictly an APL thing, but given the timing of various abilities and such, it might be slightly relevant.

I noticed in the SimC modeling that it basically is allowed to execute Tiger's Fury and the following attack at exactly the same time. As far as I can tell (although I could be wrong) this does not seem possible in the actual game.

I tried testing this today and could not get Shred to fire off exactly at the same time as Tiger's Fury via manual presses, a macro, or macro spam. I believe the Energize effect has to occur first and then there is a brief window where the client does not want to do anything else.

Spamming a macro, I got (at best) one instance of [Your] Shred failed. (Not yet recovered) following the energize and cast message in the combat log.

1/22 20:18:33.863 SPELL_AURA_APPLIED (Tiger's Fury)
1/22 20:18:33.863 SPELL_ENERGIZE (Tiger's Fury)
1/22 20:18:33.863 SPELL_CAST_SUCCESS (Tiger's Fury)
1/22 20:18:33.890 SPELL_CAST_FAILED (Shred cast attempt via CastSequence Macro Spam, "Not yet recovered" error)
1/22 20:18:34.330 SPELL_CAST_SUCCESS (Shred)

If this is the case, it probably has some timing implications. Half a second is slightly relevant, especially in regard to the timing of the energize vs. our current energy and also in regard to cooldowns or DoT timers. (Given that my unbuffed energy regen is 11.21/second, it seems like the maximum I should use TF on would be 34-35 Energy rather than 40.)

Am I doing something wrong here? Or is this worth looking into?
That's really odd, because I know it was working last expansion because until late ToT, I had tiger's fury simply macroed into all my damage abilities.

Its definitely related to the energy gain, as they'll fire at the same time if you had enough energy beforehand (or any ability that doesn't require energy).

Probably doesn't really matter for simcraft but does have implications for Ovale. Testing it myself about the closest I got the next shred from the TF cast was 338 ms, though I didn't really test it extensively.

Gonna test some lower threshold values for Tiger's Fury in simcraft and see what I get.

Kojiyama
Revered
Posts: 478
Joined: Mon Jan 19, 2015 1:47 pm

Re: Simulationcraft APL Discussion

Post by Kojiyama » Sat Jan 24, 2015 1:04 pm

Jeshu wrote:FWIW, Ovale was modifed a few releases ago to suggest Tiger's Fury (or other similar off-GCD spells) when the previous GCD had ended so that it could be cast in-sync with the next ability and avoid losing time while the buff was active.
Yeah, I think that's probably when I started noticing this issue since I noticed I had to be really careful with listening to the timing suggestions.
Image

ShmooDude
Exalted
Posts: 1080
Joined: Tue Feb 08, 2011 5:51 pm

Re: Simulationcraft APL Discussion

Post by ShmooDude » Sat Jan 24, 2015 8:43 pm

@aggixx

This Rip line:

Code: Select all

actions.finisher+=/rip,cycle_targets=1,if=remains<7.2&persistent_multiplier=dot.rip.pmultiplier&(energy.time_to_max<=1|!talent.bloodtalons.enabled)&target.time_to_die-remains>18
...is a DPS neutral/up for LI specs too. Though only barely (+10 w/ 3.2 error) but enough that i wouldn't bother having the talent check for BT and simply making it apply to all specs. If anything the one spec it probably should check for is SotF, but I don't think anyone actually specs that with how powerful incarnation is.

I would just make it:

Code: Select all

actions.finisher+=/rip,cycle_targets=1,if=remains<7.2&persistent_multiplier=dot.rip.pmultiplier&energy.time_to_max<=1&target.time_to_die-remains>18
I tried adding berserk as another condition to use it but that was actually a tiny DPS down (-10 w/ 3.2 error) as LI:

Code: Select all

actions.finisher+=/rip,cycle_targets=1,if=remains<7.2&persistent_multiplier=dot.rip.pmultiplier&(energy.time_to_max<=1|buff.berserk.up)&target.time_to_die-remains>18

ShmooDude
Exalted
Posts: 1080
Joined: Tue Feb 08, 2011 5:51 pm

Re: Simulationcraft APL Discussion

Post by ShmooDude » Sat Jan 24, 2015 10:14 pm

Using the new script as my base, here's the modified script for translation into Ovale:

Full Action List (not using on use trinket currently so it didn't add the line to use it, will add back later):
Spoiler: show

Code: Select all

actions.precombat=flask,type=greater_draenic_agility_flask
actions.precombat+=/food,type=blackrock_barbecue
actions.precombat+=/mark_of_the_wild,if=!aura.str_agi_int.up
actions.precombat+=/healing_touch,if=talent.bloodtalons.enabled
actions.precombat+=/cat_form
actions.precombat+=/prowl
# Snapshot raid buffed stats before combat begins and pre-potting is done.
actions.precombat+=/snapshot_stats
actions.precombat+=/potion,name=draenic_agility

# Executed every time the actor is available.

actions=cat_form
actions+=/wild_charge
actions+=/displacer_beast,if=movement.distance>10
actions+=/dash,if=movement.distance&buff.displacer_beast.down&buff.wild_charge_movement.down
actions+=/rake,if=buff.prowl.up
actions+=/auto_attack
actions+=/skull_bash
actions+=/force_of_nature,if=charges=3|trinket.proc.all.react|target.time_to_die<20
actions+=/berserk,sync=tigers_fury,if=buff.king_of_the_jungle.up|!talent.incarnation.enabled
actions+=/potion,name=draenic_agility,if=(buff.berserk.remains>10&(target.time_to_die<180|(trinket.proc.all.react&target.health.pct<25)))|target.time_to_die<=40
actions+=/blood_fury,sync=tigers_fury
actions+=/berserking,sync=tigers_fury
actions+=/arcane_torrent,sync=tigers_fury
actions+=/tigers_fury,if=(!buff.omen_of_clarity.react&energy.max-energy>=60)|energy.max-energy>=80
actions+=/incarnation,if=cooldown.berserk.remains<10&energy.time_to_max>1
# Keep Rip from falling off during execute range.
actions+=/ferocious_bite,cycle_targets=1,if=dot.rip.ticking&dot.rip.remains<3&target.health.pct<25
actions+=/healing_touch,if=talent.bloodtalons.enabled&buff.predatory_swiftness.up&(combo_points>=4|buff.predatory_swiftness.remains<1.5)
actions+=/savage_roar,if=buff.savage_roar.down
actions+=/pool_resource,for_next=1
actions+=/thrash_cat,cycle_targets=1,if=remains<4.5&active_enemies>=4
actions+=/call_action_list,name=finisher,if=combo_points=5
actions+=/savage_roar,if=buff.savage_roar.remains<gcd
actions+=/rake,cycle_targets=1,if=combo_points<5&remains<3&buff.king_of_the_jungle.up&active_enemies<=15&((target.time_to_die-remains>3&active_enemies<=5)|target.time_to_die-remains>3*(active_enemies%2-2))
actions+=/call_action_list,name=maintain,if=combo_points<5&active_enemies<=7
actions+=/pool_resource,for_next=1
actions+=/thrash_cat,cycle_targets=1,if=remains<4.5&active_enemies>=2
actions+=/rake,if=buff.king_of_the_jungle.up&buff.king_of_the_jungle.remains<=3&dot.rake.remains<15&target.time_to_die-remains>15
actions+=/call_action_list,name=generator,if=combo_points<5&(energy.time_to_max<=1|buff.berserk.up|cooldown.tigers_fury.remains<3|buff.tigers_fury.up|(buff.king_of_the_jungle.up&buff.king_of_the_jungle.remains<3)|dot.rip.remains<8-combo_points|buff.omen_of_clarity.react|(talent.bloodtalons.enabled&buff.predatory_swiftness.up&buff.predatory_swiftness.remains<6.5-combo_points))

actions.finisher=ferocious_bite,cycle_targets=1,max_energy=1,if=target.health.pct<25&dot.rip.ticking
actions.finisher+=/rip,cycle_targets=1,if=remains<7.2&persistent_multiplier>dot.rip.pmultiplier&target.time_to_die-remains>18
actions.finisher+=/rip,cycle_targets=1,if=remains<7.2&persistent_multiplier=dot.rip.pmultiplier&energy.time_to_max<=1&target.time_to_die-remains>18
actions.finisher+=/rip,cycle_targets=1,if=remains<2&target.time_to_die-remains>18
actions.finisher+=/savage_roar,if=(energy.time_to_max<=1|buff.berserk.up|cooldown.tigers_fury.remains<3)&buff.savage_roar.remains<12.6
actions.finisher+=/ferocious_bite,max_energy=1,if=(energy.time_to_max<=1|buff.berserk.up|cooldown.tigers_fury.remains<3)

actions.maintain=rake,cycle_targets=1,if=remains<3&((target.time_to_die-remains>3&active_enemies<=2)|target.time_to_die-remains>3*(active_enemies-2))
actions.maintain+=/rake,cycle_targets=1,if=remains<4.5&(persistent_multiplier>=dot.rake.pmultiplier|(talent.bloodtalons.enabled&(buff.bloodtalons.up|!buff.predatory_swiftness.up)))&((target.time_to_die-remains>3&active_enemies<=2)|target.time_to_die-remains>3*(active_enemies-2))
actions.maintain+=/moonfire_cat,cycle_targets=1,if=remains<4.2&active_enemies<=5&((target.time_to_die-remains>tick_time*5&active_enemies<=2)|target.time_to_die-remains>tick_time*(active_enemies+2))
actions.maintain+=/rake,cycle_targets=1,if=persistent_multiplier>dot.rake.pmultiplier&active_enemies=1&((target.time_to_die-remains>3&active_enemies<=2)|target.time_to_die-remains>3*(active_enemies-2))

actions.generator=swipe,if=(buff.king_of_the_jungle.up&active_enemies>=3)|active_enemies>=3
actions.generator+=/shred,if=active_enemies<3
Of note:
- More accurate TimeToDie on Rake/Moonfire based on number of active enemies for Rake and for Moonfire.

Code: Select all

&((target.time_to_die-remains>3&active_enemies<=2)|target.time_to_die-remains>3*(active_enemies-2))

Code: Select all

&((target.time_to_die-remains>tick_time*5&active_enemies<=2)|target.time_to_die-remains>tick_time*(active_enemies+2))

- Capped all maintain rakes at <=7 enemies.

Code: Select all

actions+=/call_action_list,name=maintain,if=combo_points<5&active_enemies<=7
- Added new Incarnation only rake line to increase the active_enemies cap and changes the active enemies TimeToDie scaling directly above maintain

Code: Select all

actions+=/rake,cycle_targets=1,if=combo_points<5&remains<3&buff.king_of_the_jungle.up&active_enemies<=15&((target.time_to_die-remains>3&active_enemies<=5)|target.time_to_die-remains>3*(active_enemies%2-2))
- Added additional Incarnation line to reapply rake at the end of Incarnation above generator

Code: Select all

actions+=/rake,if=buff.king_of_the_jungle.up&buff.king_of_the_jungle.remains<=3&dot.rake.remains<15&target.time_to_die-remains>15
- Added pooling to generators

Code: Select all

actions+=/call_action_list,name=generator,if=combo_points<5&(energy.time_to_max<=1|buff.berserk.up|cooldown.tigers_fury.remains<3|buff.tigers_fury.up|(buff.king_of_the_jungle.up&buff.king_of_the_jungle.remains<3)|dot.rip.remains<8-combo_points|buff.omen_of_clarity.react|(talent.bloodtalons.enabled&buff.predatory_swiftness.up&buff.predatory_swiftness.remains<6.5-combo_points))
- Thrash above finisher line changed to always be 4 targets, 2 piece might come into play at 3 targets with different gear but this worked for me (manually added 2 piece to my current gear for testing)

Code: Select all

actions+=/thrash_cat,cycle_targets=1,if=remains<4.5&active_enemies>=4
- Use Shred during Incarnation w/ 3 targets

Code: Select all

actions.generator=swipe,if=(buff.king_of_the_jungle.up&active_enemies>=3)|active_enemies>=4

averter
Posts: 15
Joined: Mon Sep 10, 2012 11:42 am

Re: Simulationcraft APL Discussion

Post by averter » Fri Jan 30, 2015 10:58 am

ShmooDude, can you please clarify following part. Nothing makes sense except Inc Shred /w 3 targets comment
Spoiler: show
ShmooDude wrote:Full Action List (not using on use trinket currently so it didn't add the line to use it, will add back later):

Code: Select all

actions.generator=swipe,if=(buff.king_of_the_jungle.up&active_enemies>=3)|active_enemies>=3
actions.generator+=/shred,if=active_enemies<3
- Use Shred during Incarnation w/ 3 targets

Code: Select all

actions.generator=swipe,if=(buff.king_of_the_jungle.up&active_enemies>=3)|active_enemies>=4

ShmooDude
Exalted
Posts: 1080
Joined: Tue Feb 08, 2011 5:51 pm

Re: Simulationcraft APL Discussion

Post by ShmooDude » Fri Jan 30, 2015 4:16 pm

Yeah, should be the second one.

ShmooDude
Exalted
Posts: 1080
Joined: Tue Feb 08, 2011 5:51 pm

Re: Simulationcraft APL Discussion

Post by ShmooDude » Sun Feb 15, 2015 7:04 am

Was gonna post this elseware but is far more appropriate here.

I really feel that we should modify the simcraft APL to be a bit more realistic in AoE situations. I don't believe any Ferals are really tab-dotting past 3 targets. Even on Tectus, the top parses usually end up with only a handful of Rakes during the last phase despite the fact that the incarnation buffed rake is technically superior to 10 target swipe if executed perfectly. Some don't even bother to Rake at all.

I'd suggest the following changes:

Code: Select all

actions.finisher=rip,cycle_targets=1,if=(remains<7.2&target.health.pct>=25|!ticking)&target.time_to_die-remains>18&active_enemies>1
actions.finisher+=/ferocious_bite,max_energy=1,if=target.health.pct<25&dot.rip.ticking
actions.finisher+=/rip,if=remains<7.2&persistent_multiplier>dot.rip.pmultiplier&target.time_to_die-remains>18
actions.finisher+=/rip,if=remains<7.2&persistent_multiplier=dot.rip.pmultiplier&(energy.time_to_max<=1|!talent.bloodtalons.enabled)&target.time_to_die-remains>18
actions.finisher+=/rip,if=remains<2&target.time_to_die-remains>18
actions.finisher+=/savage_roar,if=(energy.time_to_max<=1|buff.berserk.up|cooldown.tigers_fury.remains<3)&buff.savage_roar.remains<12.6
actions.finisher+=/ferocious_bite,max_energy=1,if=(energy.time_to_max<=1|buff.berserk.up|cooldown.tigers_fury.remains<3)
- Removed cycle targets from current rip lines
- If more than one enemy, don't worry about snapshotting and simply maximize Rip duration on multiple targets.

That's actually a small improvement over current APL for 2 targets and while not perfect, is certainly close enough.

Code: Select all

actions.maintain=rake,cycle_targets=1,if=remains<3&target.time_to_die-remains>6&active_enemies>1&active_enemies<4
actions.maintain+=/moonfire_cat,cycle_targets=1,if=remains<4.2&target.time_to_die-remains>tick_time*5&active_enemies>1&active_enemies<4
actions.maintain+=/rake,if=remains<3&target.time_to_die-remains>3
actions.maintain+=/rake,if=remains<4.5&(persistent_multiplier>=dot.rake.pmultiplier|(talent.bloodtalons.enabled&(buff.bloodtalons.up|!buff.predatory_swiftness.up)))&target.time_to_die-remains>3
actions.maintain+=/moonfire_cat,if=remains<4.2&target.time_to_die-remains>tick_time*5
actions.maintain+=/rake,if=persistent_multiplier>dot.rake.pmultiplier&target.time_to_die-remains>3&active_enemies=1
- Always maintains dots on the boss, while technically a DPS loss in some high mob count AoE situations, matches what you'd do in real fights anyhow

DPS neutral for 2 and 3 targets, "loss" for 4-7 or so targets. Alternative method would be to cap the cycle targets using max_cycle_targets=3 but that makes for some weird behavior (such as multi-dotting the first two of five adds in a hectic add cleave)

Obviously doesn't have to be done this way and you could conceivably raise the number of cleave targets to 4 (but that's pushing it imo), but telling people to rake up to 7 targets (or unlimited targets like the current action list) seems disingenuous at best.

If you guys don't want to under-cap the number of targets that we multi-dot in simcraft like I did above, I'd still suggest making the above changes but simply changing active_enemies<4 to active_enemies<8. Because:
1) it doesn't really lose any DPS vs the current method
2) is easier to read (no need to check number of targets for time_to_die, simply make it >3 on single target and >6 on multi-target rake lines)
3) limits each dot to only 1 cycle_target line (not strictly necessary, but makes it easier to understand imho)

Kojiyama
Revered
Posts: 478
Joined: Mon Jan 19, 2015 1:47 pm

Re: Simulationcraft APL Discussion

Post by Kojiyama » Sun Feb 15, 2015 12:11 pm

Yeah, I was experimenting with the max_cycle_targets just yesterday and ran into the similar issue as you did with some strange behavior. (That said, there was hardly any DPS loss from capping Rake at 3 targets in HecticAddCleave.)

I agree that tab-Rake is not really a very practical thing to suggest since it is so easy to actually lose DPS just by having a brief targeting issue on anything more than 2/3-target cleave.
Image

User avatar
aggixx
Exalted
Posts: 2292
Joined: Fri Nov 25, 2011 7:49 pm
Contact:

Re: Simulationcraft APL Discussion

Post by aggixx » Sun Feb 15, 2015 3:09 pm

Kojiyama wrote:(That said, there was hardly any DPS loss from capping Rake at 3 targets in HecticAddCleave.)
That has everything to do with how long the adds live. You can only rake so many of them before they're close enough to dying that its not really worth it anymore.

@ShmooDude first line looks good but I'm not sure I agree with "always maintain dots on the boss". While technically there's always a main target in SimC, the fight scenario you may be trying to emulate might not have such a thing. Something like Twin Ogrons or Iron Maidens it just doesn't make sense to always prefer one target the whole sim.
ImageImage

Kojiyama
Revered
Posts: 478
Joined: Mon Jan 19, 2015 1:47 pm

Re: Simulationcraft APL Discussion

Post by Kojiyama » Sun Feb 15, 2015 4:01 pm

aggixx wrote:
Kojiyama wrote:(That said, there was hardly any DPS loss from capping Rake at 3 targets in HecticAddCleave.)
That has everything to do with how long the adds live. You can only rake so many of them before they're close enough to dying that its not really worth it anymore.
Right, but I think what the APL is doing right now in HecticAddCleave, for instance, is not really what most players would likely be doing. e.g. I don't think most will be giving up 2% DPS on the priority target to gain 1% overall by Raking over 3 short-lived targets. This is pretty similar to the scenarios in a lot of real-world fights.

For instance, if I cap Rake at 3 targets I get 42053 vs. 41624 overall but only 29449 vs. 30033 on the priority target. I would imagine most are doing the latter in this type of situation.
Image

ShmooDude
Exalted
Posts: 1080
Joined: Tue Feb 08, 2011 5:51 pm

Re: Simulationcraft APL Discussion

Post by ShmooDude » Sun Feb 15, 2015 5:48 pm

aggixx wrote:
Kojiyama wrote:(That said, there was hardly any DPS loss from capping Rake at 3 targets in HecticAddCleave.)
That has everything to do with how long the adds live. You can only rake so many of them before they're close enough to dying that its not really worth it anymore.

@ShmooDude first line looks good but I'm not sure I agree with "always maintain dots on the boss". While technically there's always a main target in SimC, the fight scenario you may be trying to emulate might not have such a thing. Something like Twin Ogrons or Iron Maidens it just doesn't make sense to always prefer one target the whole sim.
I mean you could split it up into cleave vs single target instead. Doesn't make any significant difference DPS wise.

Code: Select all

actions+=/call_action_list,name=cleave,if=combo_points<5&active_enemies>=2&active_enemies<=3
actions+=/call_action_list,name=single_target,if=combo_points<5&active_enemies=1

Code: Select all

actions.cleave=rake,cycle_targets=1,if=remains<4.5&target.time_to_die-remains>6
actions.cleave+=/moonfire_cat,cycle_targets=1,if=remains<4.2&target.time_to_die-remains>tick_time*5

actions.single_target=rake,if=remains<3&target.time_to_die-remains>3
actions.single_target+=/rake,if=remains<4.5&(persistent_multiplier>=dot.rake.pmultiplier|(talent.bloodtalons.enabled&(buff.bloodtalons.up|!buff.predatory_swiftness.up)))&target.time_to_die-remains>3
actions.single_target+=/moonfire_cat,if=remains<4.2&target.time_to_die-remains>tick_time*5
actions.single_target+=/rake,if=persistent_multiplier>dot.rake.pmultiplier&target.time_to_die-remains>3

ShmooDude
Exalted
Posts: 1080
Joined: Tue Feb 08, 2011 5:51 pm

Re: Simulationcraft APL Discussion

Post by ShmooDude » Fri Mar 13, 2015 4:53 pm

Ok, long story short. I tried to make a rake line(s) that would eliminate the need for persistent multiplier tracking. The reason for this is Ovale currently is super buggy with regards to snapshots and will have me quite often try to overwrite a rake with an identical (or even inferior) one because it didn't catch that Tiger's Fury or Prowl was up when I applied the previous one (Incarnation is fine due to it's GCD). While I wasn't able to find a line to completely eliminate the pmultiplier tracking, I was able with the blood talons spec come up with one that would significantly reduce these incorrect overwrite suggestions.

Code: Select all

actions.maintain=/rake,cycle_targets=1,if=talent.bloodtalons.enabled&(!ticking|(active_enemies>1&remains<4.5))
actions.maintain+=/rake,cycle_targets=1,if=talent.bloodtalons.enabled&((buff.bloodtalons.up&(remains<4.5|persistent_multiplier>dot.rake.pmultiplier))|(prev.incarnation&persistent_multiplier>dot.rake.pmultiplier))
Basically, by restricting any overwrites to only when BT is up, it reduces the number of opportunities for it to suggest to rake for a multiplier increase. It provides a negligible (+30ish) DPS increase in single target and a larger (+700ish) on 3 target cleave in my gear, though I'm very dubious as to whether that's actually executable by a player.

The same logic can also be applied to Lunar Inspriation as well for similar gains compared to current (negligible single target and +300ish on 3 target cleave).

Code: Select all

actions.maintain=/rake,cycle_targets=1,if=!ticking|(remains<4.5&active_enemies>1)
actions.maintain+=/moonfire_cat,cycle_targets=1,if=remains<4.2&active_enemies<=5&target.time_to_die-remains>tick_time*5
actions.maintain+=/rake,cycle_targets=1,if=(buff.bloodtalons.up|!talent.bloodtalons.enabled)&((remains<4.5|persistent_multiplier>dot.rake.pmultiplier)|(prev.incarnation&persistent_multiplier>dot.rake.pmultiplier))
The prev.incarnation portion of the script isn't really noticeable in simcraft, but is a tiny DPS up so is mostly there for Ovale purposes.

The weird thing though, is that under 3 target cleave, its only a gain if you have the the 2 piece. If you don't, its a loss. Even artificially raising my haste to achieve roughly the same RPS as the 2 piece still shows a loss. So something about it makes it better on 3 target cleave w/ the 2 piece, but worse on 3 target cleave without (how much depends on gear level). I found that very odd.

Kojiyama
Revered
Posts: 478
Joined: Mon Jan 19, 2015 1:47 pm

Re: Simulationcraft APL Discussion

Post by Kojiyama » Tue Mar 17, 2015 3:36 pm

A few questions for you:

1) What do you mean by, "I'm very dubious as to whether that's actually executable by a player," exactly? Just in regard to keeping up a 3 target dot-line correctly? Because this suggestion in general actually seems like it would be easier to maintain overall because you don't need to consider clipping Rake on every TF activation and therefore don't need to evaluate that case off the GCD.

2) I assume your bottom code block is actually the 'correct' one, since it functionally supports both specs?

3) Other than the edge case you mentioned (3 target cleave, no 2pc) it does seem like this would make sense to implement in the APL as it is a DPS gain in almost every case for both specs. 400-600 DPS gains (as I saw with my profile) are non-trivial, at least compared to other potential APL tweaks. Additionally, this just seems like a more streamlined rotation with less high-duration clipping.

I think the only thing this might miss out on is possibly some TF+Incarnation refreshes. Could account for some of the difference you saw, but this seems pretty minimal.

P.S. Why does Ovale have issues with tracking these multipliers? Seems like there is plenty floating out there with WA2 and whatnot to use as reference to get this part correct?
Image

ShmooDude
Exalted
Posts: 1080
Joined: Tue Feb 08, 2011 5:51 pm

Re: Simulationcraft APL Discussion

Post by ShmooDude » Tue Mar 17, 2015 7:23 pm

Kojiyama wrote:A few questions for you:

1) What do you mean by, "I'm very dubious as to whether that's actually executable by a player," exactly? Just in regard to keeping up a 3 target dot-line correctly? Because this suggestion in general actually seems like it would be easier to maintain overall because you don't need to consider clipping Rake on every TF activation and therefore don't need to evaluate that case off the GCD.

2) I assume your bottom code block is actually the 'correct' one, since it functionally supports both specs?

3) Other than the edge case you mentioned (3 target cleave, no 2pc) it does seem like this would make sense to implement in the APL as it is a DPS gain in almost every case for both specs. 400-600 DPS gains (as I saw with my profile) are non-trivial, at least compared to other potential APL tweaks. Additionally, this just seems like a more streamlined rotation with less high-duration clipping.

I think the only thing this might miss out on is possibly some TF+Incarnation refreshes. Could account for some of the difference you saw, but this seems pretty minimal.

P.S. Why does Ovale have issues with tracking these multipliers? Seems like there is plenty floating out there with WA2 and whatnot to use as reference to get this part correct?
1) yeah, mostly in regard to multiple cycle target lines.

2) yea

3) Yeah, pretty much, even when ovale wasn't bugging out I noticed I'd say TF rake, then HT and rake again for example. This stops that kind of behavior.

As far as ovale, my guess is some lingering leftover code from trying to compensate for the upto 400 ms delay on the applying of auras.

Kojiyama
Revered
Posts: 478
Joined: Mon Jan 19, 2015 1:47 pm

Re: Simulationcraft APL Discussion

Post by Kojiyama » Tue Mar 17, 2015 8:38 pm

I think the previous conventional wisdom was that clipping Rake to reapply a stronger modifier was generally beneficial. I think the earlier sims showed this to be the case, but perhaps the 6.1 changes and various hotfixes along the way have impacted this somewhat.

It does seem like clipping just for TF (which is basically what your lines eliminate) is not particularly beneficial right now and is actually detrimental in cleave fights. (Which makes sense, as pooling for refreshes is probably a lot better of a use of energy than just getting a 15% higher damage multiplier from TF for a brief window of time. Same goes for the use of Shred/Swipe, although that was discussed in a previous page.)
Image

Kojiyama
Revered
Posts: 478
Joined: Mon Jan 19, 2015 1:47 pm

Re: Simulationcraft APL Discussion

Post by Kojiyama » Thu Mar 19, 2015 1:41 am

Although anecdotal, I tried this methodology out tonight and it felt good. Even adjusting for the ilevel boost, I put up some good parses on both ST and Cleave this evening so it certainly had no major detrimental effect. It definitely felt a lot better in some situations where I would have normally refreshed a Rake due to TF only to refresh again with BT two globals later.

Managing the 3-target dot line on Iron Maidens wasn't actually all that difficult--if anything, trying to prioritize refreshing Rake at pandemic in 3-target scenarios did seem to help with overall DPS and uptime.
Image

Kojiyama
Revered
Posts: 478
Joined: Mon Jan 19, 2015 1:47 pm

Re: Simulationcraft APL Discussion

Post by Kojiyama » Thu Jul 16, 2015 2:09 am

I was poking around with the T18 logic and notice something I felt was a bit inconsistent. It is a relatively minor change, but it does seem to be ~150-200 DPS positive for me.

actions.finisher+=/rip,cycle_targets=1,if=remains<7.2&persistent_multiplier=dot.rip.pmultiplier&(energy.time_to_max<=1|!talent.bloodtalons.enabled|(set_bonus.tier18_4pc&energy>50))&target.time_to_die-remains>18

This line still had the full pooling logic which meant that it was never preferred vs. the final FB when using T18 4pc as once you reached 50 energy it would always FB.
Image

User avatar
aggixx
Exalted
Posts: 2292
Joined: Fri Nov 25, 2011 7:49 pm
Contact:

Re: Simulationcraft APL Discussion

Post by aggixx » Thu Jul 16, 2015 4:34 pm

Good catch, I'll check that out. I also feel like, intuitively, there is some gain to be had regarding smarter use of PS/HT/BT on Rake vs Thrash but I was unable to nail that down last time I tried.
ImageImage

ShmooDude
Exalted
Posts: 1080
Joined: Tue Feb 08, 2011 5:51 pm

Re: Simulationcraft APL Discussion

Post by ShmooDude » Thu Jul 16, 2015 11:59 pm

Kojiyama wrote:I was poking around with the T18 logic and notice something I felt was a bit inconsistent. It is a relatively minor change, but it does seem to be ~150-200 DPS positive for me.

actions.finisher+=/rip,cycle_targets=1,if=remains<7.2&persistent_multiplier=dot.rip.pmultiplier&(energy.time_to_max<=1|!talent.bloodtalons.enabled|(set_bonus.tier18_4pc&energy>50))&target.time_to_die-remains>18

This line still had the full pooling logic which meant that it was never preferred vs. the final FB when using T18 4pc as once you reached 50 energy it would always FB.
Thanks, I was wondering why Ovale was super aggressive about suggesting FB at like 5 seconds on rip and such.

szandos
Posts: 2
Joined: Wed Jul 22, 2015 7:44 am

Re: Simulationcraft APL Discussion

Post by szandos » Wed Jul 22, 2015 7:55 am

I got a few questions in regards to how Simcraft handles energy (or lack thereof) when running the APL.

1. Does Simcraft skip lines if we don't have enough energy?
E.g.: actions+=/ferocious_bite,cycle_targets=1,if=dot.rip.ticking&dot.rip.remains<3&target.health.pct<25
If the conditions are true, but we don't have enough energy to cast FB, will it move to the next line (cast HT), or wait for energy?

2. Does "pool_resource" pause or stop?
actions+=/pool_resource,for_next=1
actions+=/thrash_cat,cycle_targets=1,if=remains<4.5&(spell_targets.thrash_cat>=2&set_bonus.tier17_2pc|spell_targets.thrash_cat>=4)

Does this mean that, if we don't have the energy to cast Thrash, but the conditions are true, it will pause until we have enough energy, or will it stop until the next time the actor is available? Meaning, if we have "pool_resource" and, while waiting, a condition that is higher up on the list becomes valid (for example, Savage Roar falls off), will it execute that or wait for Thrash?

3. Will "max_energy" pause the APL, or will it move on to the next?
actions.finisher+=/ferocious_bite,cycle_targets=1,max_energy=1,if=target.health.pct<25&dot.rip.ticking
What happens if we don't have max FB energy, will it go evaluate the next line, or wait for energy, or stop execution of the APL?

User avatar
aggixx
Exalted
Posts: 2292
Joined: Fri Nov 25, 2011 7:49 pm
Contact:

Re: Simulationcraft APL Discussion

Post by aggixx » Thu Jul 23, 2015 4:18 am

1. Continues on with the list.
2. It checks if the energy condition is met, and if it isn't "sleeps" for a certain amount of time and then re-evaluates the action list from the top.
3. It just makes the action not usable unless it will deal full damage. Just like any unusable action it will continue on evaluating the list.
ImageImage

Post Reply