Hekili Priority Helper

Hekili Priority Helper

53M Downloads

UHDK: Autosnap

DrWren opened this issue · 9 comments

commented

Before You Begin

  • I confirm that I have downloaded the latest version of the addon.
  • I am not playing on a private server.
  • I checked for an existing, open ticket for this issue and was not able to find one.
  • I edited the title of this issue (above) so that it describes the issue I am reporting.
  • I am reporting an issue with the default priority included with the specialization (imported or edited priorities are not supported).

Spec

DK - Unholy

Describe the Issue

Doing keys, auto snap doing aoe pack

How to Reproduce

doing aoe pack it just sending.

Snapshot (Link)

https://pastebin.com/HJE6N5pM

Raidbots Sim Report (Link)

No response

Additional Information

let me know if you need me to test.

Contact Information

No response

commented

Image
Image

Here are the screenshots for the same thing, 2 different times

commented

This is caused by a redundant condition in the SimC APL. If they don't change the APL (or accept my PR), I can fix this via the handler for dark transformation.

In the sim, this line (almost) always triggers after dark transformation

j:wound_spender,if=buff.gift_of_the_sanlayn.up&buff.vampiric_strike.react|talent.gift_of_the_sanlayn&buff.dark_transformation.up&buff.dark_transformation.remains<gcd

But for us, buff.gift_of_the_sanlayn.up&buff.vampiric_strike.react isn't true until you actually press dark transformation and get the buff.vampiric_strike from the reset_precast which checks API calls.

From the TC: "just leftover from before i split san into its own list, doesnt hurt anything tho"

commented

Just noting that this is not the same as the other unholy ticket because this one has 3 runes available. The other one that happens is 0-1 runes, low RP.

commented

Thanks for submitting your ticket. Can you trigger this issue again ( and submit that snapshot), then manually snapshot again when the recommendation fills in? I'm trying to answer:

  • Does the rercommendation populate after the snapshot if you just wait? If so, how long and what does it recommend when it loads?
  • Does the recommendation populate if you follow the first recommendation(s) that appear? What recommendation is given and when do they reappear and what did you just use?
commented

Sorry Hekili, Syrif, didn’t see this, I can try to somewhat you asked, but it might be either late your time Hekili, 3am cst my time before I can log back in.

commented

@syrifgit -- I wonder if we need to look at our simplification of the variables in the APL.

# Variables
actions.variables+=/variable,name=st_planning,op=setif,value=1,value_else=0,condition=active_enemies=1&(!raid_event.adds.exists|!raid_event.adds.in|raid_event.adds.in>15|raid_event.pull.has_boss&raid_event.adds.in>15)
actions.variables+=/variable,name=adds_remain,op=setif,value=1,value_else=0,condition=active_enemies>=2&(!raid_event.adds.exists&fight_remains>6|raid_event.adds.exists&raid_event.adds.remains>6)
actions.variables+=/variable,name=apoc_timing,op=setif,value=3,value_else=0,condition=cooldown.apocalypse.remains<5&debuff.festering_wound.stack<1&cooldown.unholy_assault.remains>5
actions.variables+=/variable,name=pop_wounds,op=setif,value=1,value_else=0,condition=(cooldown.apocalypse.remains>variable.apoc_timing|!talent.apocalypse)&(debuff.festering_wound.stack>=1&cooldown.unholy_assault.remains<20&talent.unholy_assault&variable.st_planning|debuff.rotten_touch.up&debuff.festering_wound.stack>=1|debuff.festering_wound.stack>=4-pet.abomination.active)|fight_remains<5&debuff.festering_wound.stack>=1
actions.variables+=/variable,name=pooling_runic_power,op=setif,value=1,value_else=0,condition=talent.vile_contagion&cooldown.vile_contagion.remains<5&runic_power<30
actions.variables+=/variable,name=spend_rp,op=setif,value=1,value_else=0,condition=(!talent.rotten_touch|talent.rotten_touch&!debuff.rotten_touch.up|runic_power.deficit<20)&((talent.improved_death_coil&(active_enemies=2|talent.coil_of_devastation)|rune<3|pet.gargoyle.active|buff.sudden_doom.react|!variable.pop_wounds&debuff.festering_wound.stack>=4))
actions.variables+=/variable,name=san_coil_mult,op=setif,value=2,value_else=1,condition=buff.essence_of_the_blood_queen.stack>=4
actions.variables+=/variable,name=epidemic_targets,value=3+talent.improved_death_coil+(talent.frenzied_bloodthirst*variable.san_coil_mult)+(talent.hungering_thirst&talent.harbinger_of_doom&buff.sudden_doom.up)

st_planning

# Original Notes
1 active_enemies = 1 & Straightforward, 1 active enemy.
2 ( The following conditions are grouped:
3 ! raid_event.adds.exists Since the addon doesn't know raid events, this is not true when active_enemies > 1 and not false when active_enemies = 1.
Since active_enemies = 1 then this is always not false => true.
4 | ! raid_event.adds.in When active_enemies = 1, this returns not 3600 which would parse to false.
When active_enemies > 1, this evaluates to not 0 which then becomes true.
Since active_enemies = 1, this returns not 3600 => false.
5 | raid_event.adds.in > 15 When active_enemies = 1, this is 3600 > 15 which is true.
When active_enemies > 1, this is 0 > 15 which is false.
since active_enemies = 1, this is always 3600 > 15 => true.
6 | raid_event.pull.has_boss This would be the equivalent of boss.
In encounters/boss fights, true; otherwise false.
7 & raid_event.adds.in > 15 Same as before, though this is joined with the boss condition by &. This condition is redundant since
May be a defect in SimC APL; if `raid_event.adds.in > 15
8 ) End grouping.

Answering my own question, when 1 is true, both 3 and 5 are also true, either of which are sufficient to ensure the grouped condition is always true. So, never mind, these edits are fine. Though I don't like that we have active_enemies=1&active_enemies=1&... in our current .simc file.

commented

if/when hooking into bossmods is ready, I would likely undo this replacement since those other conditions will actually matter.

active_enemies=1&active_enemies=1&...

Also yeah I saw that lol, was going to change it if/when SimC changes the vamp strike thing.

commented

simulationcraft/simc@a9740f9

Turns out they did change it, huzzah. Let me add that in, converting to draft.

commented

But for us, buff.gift_of_the_sanlayn.up&buff.vampiric_strike.react isn't true until you actually press dark transformation and get the buff.vampiric_strike from the reset_precast which checks API calls.

This part can be resolved by adding...

if talent.gift_of_the_sanlayn.enabled then applyBuff( "vampiric_strike" ) end

...to Dark Transformation's handler, anyway.