#tc-research
1 messages · Page 45 of 1
It applies sbs to the primary target, and then applies it to the remaining targets without sbs dot active
Not sure about the 600 thing
I think the APL is making sure it spreads sbs properly for the max sim duration (600 sec)
but the call is the same if we disregard the ttd check on the 2nd, so shouldn't all SBS be caught by the first one?
The first call is applying it to the main target, the second one is cycling
target_if=min:target.time_to_die+(dot.serrated_bone_spike_dot.ticking*600)
looks like this is used to ensure the TTD call is still prioritizing targets that do not have the dot. targets that do have the dot have a massively inflated TTD so they wont get picked until all targets have the dot
600s is probably a catch-all guarantee that this will happen no matter what custom raid events you are simming, but it does not need to be nearly this long for something like dslice specifically
It's just a bit of a hack to add a level of filtering we don't have easy control over in the target_if criteria (if= is evaluated afterwards, we want to filter before a target is returned)
Based on spot checking with current builds, going with this for reroll logic for now:
rtb_reroll,value=rtb_buffs<2&(!buff.broadside.up&(!runeforge.concealed_blunderbuss|!buff.skull_and_crossbones.up)&(!runeforge.invigorating_shadowdust|!buff.true_bearing.up))|rtb_buffs=2&buff.buried_treasure.up&buff.grand_melee.up
TB good to keep with Shadowdust, SnC good to keep with Blunderbuss, Broadside the only universally kept single buff
And BT+GM is also rerolled as Fuu suggested
0.2-0.3% depending on the build, so nothing too major here but seems to check out for now
Don't some of these look wrong? gm_tb is 16919 while a single tb is 17006. 87 dps / 0.51% difference doesn't seem like too high for it to be error margin, and it doesn't make sense why a single roll is higher than double, since in neither case the APL rerolled them, or am I missing something?
error of margin is low because it is run at 100k iterations (so ~5 dps)
The buffs are the ones the sim keeps.
e.g. this is gm_tb:
this is TB
Yeah, so how come keeping a single tb is higher than keeping a tb+gm?
you keep both GM and TB single roll
GM is a quite bad roll, so by keeping it it means you also have lower chance to roll better buffs
so the answer to "why is it worse to keep both TB and GM single roll compared to only TB?"
Because you keep GM
I think the confusion here is that @hushed shell thinks gm_tb means keep gm tb double buff, while what it actually means is keep either single buff
i did change the text to make it more obvious
I don't think you keep either single buff, not at least with the APL provided. It's an and clause & inside the parenthesis instead of an or clause with |
Is it not?
the expression evaluates to 0 if either buff is up = dont' reroll
if we roll both TB and GM, this APL would return rtb_buffs<2 AND (GM is up AND TB is up). if we roll a single GM it would still reroll, since rtb_buffs<2 = true, and (GM up = true AND TB up = false), so the whole () would return false
it is actually de'morgans law, hence the negation
¬(A∨B) => ¬A∧¬B
yes, the brackets are false, so it becomes true & false = false
it needs to be true to reroll
Yeah, if either is false it's false. So it's never rerolling a single roll. A single GM returns TRUE & (FALSE & TRUE), which translates into TRUE & FALSE, meaning it doesn't reroll.
i mean, that's the point
But this wasn't my issue in the first place, was just clearing out what Mirage suggested about the possible confusion.
My point is that if it's not rerolling a single TB, and also not rerolling a double TB + GM, wouldn't a double buff always be a head of a single roll, no matter what the secondary roll is?
Yeah, that's what I mean. so it keeping a single TB is 0.5% increase of keeping TB_GM
the line that does what you just said is the tb line
But how is keeping 2 buffs lower than a single
both gm_tb and tb keep the gm+tb double buff, as well as the tb single buff
the difference is that gm_tb also keeps gm single buff
But it doesnt?
#tc-research message
we agree that a single gm roll means that the expression evaluates to false, right?
Correct, so it wouldn't reroll since it needs true to reroll.
right... then that means it keeps gm single buff
Oh wait, my head is completely backwards
rtb_buffs<2 basically filters it to be only single rolls
and !buff.x.up basically filters it to the individual buff
So example:
2 buffs are up:
rtb_buffs<2 is false so the entire condition is false, means no reroll
TB or GM is up:
!buff.tb.up&!buff.gm.up Tb or GM is false, means no reroll
RP or any of the other single buffs (that isn't gm/tb) is up:
!buff.tb.up&!buff.gm.up both are true, hence the condition is true, means it rerolls
Okay I get the gist now, I'm not sure how I was comprehending it but it makes sense now. It's basically trying to fish for those buffs, and rerolling if they're not there. Which makes sense why gm_tb is lower than a single tb since it's also rerolling more good buffs and keeping gm on top. Also makes sense why when snc solo -0.1% and solo rp -0.22% ends up together being rp_snc -0.11% since it's equalizing between the two. I think I was missing the fishing for the buffs part or something, not sure, but I was definitely thinking backwards for the moment.
Anyway thanks for sticking with me and clearing it up, sorry for the confusion and being somewhat dense.
actions+=/variable,name=finish_condition,op=reset,if=cooldown.between_the_eyes.ready&effective_combo_points<5```
this action in the outlaw apl is conflicting with other parts of the apl
since we dont cast BtE on cooldown anymore, this is forcing 5cp for basically no reason pretty often
removing it doesnt change dps much, but i noticed it when trying different finisher rules, only for them to be overwritten by this
I saw people mention it but didn't really seem to change anything either way. Probably because it cuts both ways that finishing early can still yield poor edge cases during energy/GCD periods
makes sense i guess
another thing to consider is only using pistol shot for energy, instead of also to cap you on cp exactly https://www.raidbots.com/simbot/report/esbPWQob5zSTe2t2p1mSXa/simc
i suspect this is only true for weaponmaster + blunderbuss + maybe triple threat
maybe too small of a gain and too specific of a setup to be added to the default apl
But yeah I assume this is the case
Obviously it's pretty marginal, 0.3% difference for 6 swapped globals. So the difference per cast is very tiny.
But don't really see any problem with adding something potentially here
fwiw I think something like regen*1.5 might be cleaner than a static value.
probably, was just editing what was already in the apl (deficit>regen+10 is default if you remove the cp rule)
Yeah I think that is basically just to accommodate for combat potency average
Gonna change the ordering around to make this a bit easier to analyze though
But yeah this seems to be specific to WM for sure.
It's -0.7% for normal build
figures
(Or pre-patch build that is)
Based on testing some various combos I'm leaning towards
actions.build+="/pistol_shot,if=buff.opportunity.up&(energy.deficit>energy.regen*1.5|!talent.weaponmaster&combo_points.deficit<=1+buff.broadside.up|talent.quick_draw.enabled)"
Seems the same for the main profile you linked but is also neutral in the Dust build and such
Probably a super niche thing, but does the apl hold vanish if you have a 5 buff and GM or BT are the missing buffs until after you reroll?
no
Alright, integrated most of the pending APL changes as well as some random ones I was looking at and regenerated the default profile for visibility. Still working on the Blade Rush AoE logic, but everything else should be included.
* Update RtB reroll priority for Blunderbuss and Shadowdust
* Update finish CP condition when using Blunderbuss
* Update Pistol Shot filler logic for Weaponmaster builds
* Add tab-Sinister Strike for Cache of Acquired Treasures bleed applications
* Add targeting logic for Flagellation to select the highest health target for multi-actor sims
* Update Blade Rush to not cast at high energy during Flagellation
* Update Between the Eyes logic for Greenskin's Wickers
cycling targets with SS and axe is true at any target count? surprising
last I checked it stop being a gain at around 3 or more target but doesnt rly start becoming a loss
just a good gain at like 2 and 3 targets
and then its whatever
i guess its just because u cant really maintain the bleed on more than 2 or 3 targets so it doesnt really matter
^ i cam to exactly this conclusion when doing the change back in march
I mean there's really no downside
Other than it being annoying to do 😛
It's a pretty simple trade-off of crit chance from BtE debuff vs. the potential bleed application, which should be constant at any target number
very random nitpick but i think pistol shot (_tornado_trigger) should be grouped under pistol shot and not main gauche
Why is that?
It’s not part of the DPET of PS casts. It contributes to the DPE of MG procs
Grouping in the report is more about linked actions rather than similar spells
I might put BtE 4pc procs under PS though
why should it contribute to the dpe of main gauche?
in details, the 2pc is counted as pistol shot dmg with the others
is that on details' end or from combat logs
it'd contribute to main gauche's dpe because main gauche is what triggers it, even though the spell is a pistol shot
so without any "executions" of mg, the extra pistol shot damage wouldn't happen
- Add tab-Sinister Strike for Cache of Acquired Treasures bleed applications
why doesn't the sub apl have this? I just tested it on my own profiles and it's a ~0.5% gain for 2t/3t venthyr/kyrian and neutral on dslice
2t vent: https://www.raidbots.com/simbot/report/ap5CAV6SUSmVgdpm1p6X4w
2t kyr: https://www.raidbots.com/simbot/report/dcgKXekF2QnC3bE4vgDTVg
3t vent: https://www.raidbots.com/simbot/report/hWKBmoSetWwiAEtv15qtA5
3t kyr: https://www.raidbots.com/simbot/report/r1LcbKBP27Hma1k8kZHx3J
dslice vent: https://www.raidbots.com/simbot/report/ostcPfR9Lkk8MzWxjGCANv
dlisce kyr: https://www.raidbots.com/simbot/report/2t9pUrE4vppKL4BUZmfri9
i just copied the apl line from the outlaw one and added a new shadowstrike line, there's probably a better way of doing it
As Darkscare said, because MG is what actually triggers it. If there’s an effect that increased MG proc rate (e.g. Ambi) it would increase 2pc damage. It has nothing to do with actual PS casts/executes.
Parenting it to PS would increase PS’s damage per execute which isn’t correct since it isn’t triggered at all by PS player actions.
Because this wasn’t possible until the other day due to the core buff not being available without the trinket equipped. Put it into Outlaw first since it matters the most. This is like +2.7% for Outlaw since they have no other way of spreading it.
Ah I see, tyty
But Fuu does have a change for Sub lined up already. So it’ll be in soon.
Also Details merges this all together since it doesn’t know any different. They are the same spell reused. But on the SimC side we know the source of everything. So we can parent things more intelligently.
Only spec it wasn't rly impactful to optimize for cache is for assassination
trying out different vanish conditions for weaponmaster blunderbuss, the current rule is at ambush_condition only. I think they can be free to do it at ambush_condition or finish_condition. the logic being that SS is probably a better global than ambush
interesting enough, forcing finish_condition only does not seem to be a gain https://www.raidbots.com/simbot/report/chNeiETAcynbykNnsk2S5n/simc
i suspected the loss on finish_condition only was coming from the opener, where it was using vanish > dispatch before applying flagellation, but fixing that also doesnt change the result much https://www.raidbots.com/simbot/report/x5QisigNqfPNbXsQvo28Rz
Yeah this makes sense to me especially with WM and Blunderbuss. Did you happen to check non-BB but WM builds? e.g. GSW or whatnot?
Also assume it might need to get moved inward a bit. Instead of:
vanish,if=!runeforge.mark_of_the_master_assassin&!runeforge.invigorating_shadowdust&!stealthed.all&(variable.ambush_condition&(!runeforge.deathly_shadows|buff.deathly_shadows.down&combo_points<=2)|talent.weaponmaster&variable.finish_condition)
Maybe this:
vanish,if=!runeforge.mark_of_the_master_assassin&!runeforge.invigorating_shadowdust&!stealthed.all&(variable.ambush_condition|talent.weaponmaster&variable.finish_condition)&(!runeforge.deathly_shadows|buff.deathly_shadows.down&combo_points<=2)
otherwise I think it'll mess up Deathly Shadows logic
yea i tested it with several profiles from fuu's sheet and it was either neutral or a small gain for any weaponmaster setup
i wonder why only vanish > dispatch is such a loss though
Still finding it mildly amusing that WM has been trash tier for Outlaw for ages then it's suddenly good. 😛
reminds me of ghostly strike simming incorrectly for an entire expansion
Well at least that actually was kinda explained
WM has just functionally not been good lol
yea, last i remember it was considerable for weird triple Wits setups
Think strictly constraining Vanish to Dispatch results in it munching some BtE casts
that makes sense
Only 13.8 hardcasts of BtE on that profile vs. 14.6 in the other profile
Which isn't a massive difference but like 1% less buff uptime would explain that difference
So maybe it could be worked around in some other way if also checking for some BtE condition or something but that might be overly complex without any gains
is it possible to specify the initial weapon from the cache trinket? it would be useful for double-use trinkets sim
yea i feel like its a dps gain to hold fcm if you start with haste buff less then 8 seconds
and use axe first
i think it isn't right now, but probably would make sense to add the option
A niche situation but something I've run into the last couple weeks: could someone sim if it is a gain to pistol shot into finish in the last 2 globals of flag if you have a 4set proc pooled but no opportunity proc? I've just been feelycrafting that it's a gain especially if you have a bad flag and are sub 30 stacks that the flag stacks+flag damage+cdr is > the loss from a naked pistol shot. I'm not good with the apl stuff or I'd sim it myself
https://www.raidbots.com/simbot/report/7txrtFvghSXsEhW9rj1tfe/simc seems too niche to make a difference, the gcd rules happen only about 1 time in 5 minutes
that is what i figured, it is something that doesnt pop up every fight just seemed like in that situation it could be worth to use the global on pistol shot
Thanks for checking those sims though
I feel like it's something that may happen more often with unoptimal play, and it does seem to be a dps increase?
It’s all within error margin in that report so it’s not really an increase.
following solo vanish apl changes I tried some differents things to try and optimise further more and only thing that I could find was to never ambush in flag window
(bte optimisations seemed to be neutral gain, and never ambushing with SnC a loss)
https://www.raidbots.com/simbot/report/pVkotaz4yPzCf6cb1WVtsw
also worth noting that this rule is even better when playing Dancing Steel in dg for exemple since u are probably more energy starved without playing BR
Is ignoring ambush so that you get more finisher/fish for blunder
Or to save energy/both
Is CTO treated like regular buff on simc
Yes. Obviously they have different duration and are refreshed differently but they all map to the same buffs.
It also has confusing interactions with reroll, but yeah same as regular buffs
If you want you can test the buff.x.remains against buff.roll_the_bones.remains (which is the primary container buff) if you wanna see if it's a CtO buff or not
Sure but sometimes they reroll, sometimes with low duration on RTB they don't
What case are you speaking about specifically?
if cto buff remaining duration is > to normal roll buff remaining duration, cto buff will stay
idk if its implemented in sims
CtO buffs are preserved after rerolling in general, as long as they don't conflict with the new roll
Very frequently, rerolling results in loss of CTO buffs
im pretty sure they arent preserved normally
they must have more duration than normals buffs
for them to be preserved
I'd have to see some controlled version of this because as far as our last controlled testing showed, the only time the buffs weren't preserved was if the new reroll overwrote it. They used to reroll a new buff in this case but that functionality was removed in beta.
But there are some odd cases happening where the behavior is not correct, which could be a side-effect of all of this
Always possible some functionality was changed though considering how much messing around with Outlaw they have done with the set bonus and hotfixes and such
Would be straightforward enough to add the constraint you're describing. Don't think it would impact sims much though because the overlap window here is small and given the reroll timing in SL (with the ability CD how it is) and lack of aggressive rerolls, this likely would only be a small loss in buffs on average.
are u saying that right now in sims its implemented as never rerolling cto buff away ?
Sims currently reroll CtO buffs away when the reroll buffs conflict with them. Not always. If there is a currently duration constraint then no, sims don't currently implement that as that wasn't the last known functionality when this was last tested in-depth.
Quick testing in-game does seem to indicate there may be something going on as you describe, although I found at least one case quickly that didn't conform (1 buff was dropped and 1 was maintained when they were both less than the reroll duration.) It does seem to be somewhat inconsistent, not to mention the reroll bug that has been described a few times where the full duration buff doesn't reroll.
I will note that testing this change in SimC makes virtually no difference though
To the end result, since it's so infrequent
well the only thing that is consistent is this ^
I know that there is some strange thigns happening in others scenario
but this one is a 100%
I mean I could believe it's the general rule but I dunno if it's 100% since I just observed it not happening on a double CtO into reroll in-game.
You probably didnt see it right, I play a lot and have a wa to see wich buff is cto or not and this behaviour was always consistent
but other than this case of course the rest is kinda unpredictable
I just observed a 3s and a 9s CtO buff where only one went away on a ~20s RtB reroll. Generally it seems to hold what you are saying but I'm just saying I think there may still be some inconsistent behavior here.
Happy to make any changes if they are confirmed but testing this in SimC seems to make no notable difference fwiw
It's within error margin at 0.05% error
yeah u are saying that the normal roll was > than cto in ur case
Normal roll was higher than both CtO buffs yes
im saying that if cto > normal buff it will never reroll
But one of the CtO buffs persisted for some reason instead of disappearing as expected
Pretty rare to have a long duration RtB with RtB CD available and 2 CtO buffs though
So it's hard to test this repeatedly
Since we store off the CtO buffs in SimC before restoring them after the reroll, this behavior is easy to update
e.g. right now the code is
for ( buff_t* buff : buffs )
{
if ( save_remains && buff->check() && buff->remains() != remains() )
{
count_the_odds_states.push_back( { buff, buff->remains() } );
}
To store off the CtO buffs for after the roll
Which then just becomes
if ( save_remains && buff->check() && buff->remains() > remains() )
Based on the rule you describe
But with the current APL this doesn't really yield any DPS change. Still worth changing if it's the correct behavior though.
These are the two sims
With the different versions
DPS Error margin of 7.6 / 0.049%
Makes sense that it's low impact. We don't usually have much opportunity to reroll at high duration base buff (outside of maybe Dreadblades or something where we're spam finishing or with TB up) the window for normal CtO buffs to be rerolled is quite small since the buffs are short, and any time it would matter (Stealth duration buff towards the CD coming up) it's got a decent chance of being higher duration anyway.
(Also if we have a useful CtO buff it still keeps us from rerolling right now in the APL)
well the situation happens a lot in real gameplay so a new rule could probably yield some more dps
Well that would indicate to me that people aren't totally following the same reroll rules as in the APL?
Shouldn't be more or less common of a statistical occurrence
What are you suggesting would be different about the APL/gameplay as a result of this?
If we have a good CtO buff we already won't reroll, and we only non-reroll RtB when duration is <3s which dodges most of the potential overlap.
Based on the sim putting some debugging in, it looks like this happens on average 2.2 times per 5 minute sim. (Out of 33.7 CtO procs) Basically once every 5.5 RtB casts on average, but the average duration lost is very small even in these cases. And is skewed towards bad buffs.
well what happen quite a lot for me is, lets say u have a bad buff remainning, no rtb cd yet but vanish is up, u can just vanish to get ur cto buff and reroll for free when rtb come off cd without losing the cto buff
right now the apl wouldnt reroll if the cto buff was good
in real scenario u can
Well in theory with the previous functionality in SimC we could already do that (since it assumed we wouldn't normally lose the CtO buff) but I don't think we ever saw any gain from doing this. Since you still have a ~20% chance of losing the CtO buff due to reroll overlap.
(Or not losing the buff itself, but the value of the CtO proc)
APL could probably already be tested for this by checking the durations
To see if it is worth ignoring CtO durations in the keep conditions
(e.g. !(buff.broadside.up&buff.broadside.remains=buff.roll_the_bones.remains) or something)
But basically you have a two main situations:
a) You have a good CtO (say Broadsides) buff on short duration, which will prevent you from rerolling for a couple seconds. Probably not major impact since it's sub-5s.
b) You have a good CtO buff on a longer duration, which will prevent you from rerolling. This is mostly where your suggestion would impact. Often your main buff will be sub-15s at this point just due to the structure of the CDs, so you could reroll and keep your Broadsides.
The question of b) is if it's worth the ~20% chance of throwing that duration out by natural rolling that buff again. Which throws away maybe 5-10s of Broadsides time you could have kept by delaying the reroll until later.
Probably hard to answer that without doing sim comparisons.
yeah i see what u mean I didnt think that you would have potentially a chance to "lose" the cto benefit
but you would also extend it right cause we have pandemic on rolls buff iirc
afaik if you natural roll Broadsides in this case the CtO duration is discarded rather than added to the final result (e.g. if you are getting a 30s reroll you'll just get a 30s Broadsides buff, not pandemic.)
But definitely worth investigating
I think all the results of the RtB roll are influenced only by the calculated roll duration, not any existing CtO buffs
(The duration of the hidden container buff)
315508
I kinda suspect this case is also what may cause the refresh bugs
That it may be the case where a CtO buff that exists that then natural rolls is still being considered a CtO buff for the next reroll and then has odd refresh behavior
(Probably based on duration as you describe, but since it has a equal duration maybe it doesn't get refreshed. Could be >= in this case rather than just >)
Hard to say though, whole thing is super wonky 😄
This check should be in the next nightly as well as the waste information in the proc report section.
what does movement actually do for melee dps sims?
e.g. the raid events of HAC
raid_events+=/movement,distance=25,first=22,cooldown=33,last=337
raid_events+=/movement,players_only=1,distance=8,first=13,cooldown=18```
It essentially makes them move 8 yards. Which incurs a time penalty for being out of range (based on current movement speed.) Players can still use things that are in range (e.g. Pistol Shot) that are usable while moving (not channeled things, no caster spells with cast time unless they have some way to bypass)
Technically we could add Shadowstep or something into our APL to bypass this
if the actor moves to a higher distance, it will just act as a interrupt of actions more or less
But there has never really been much of a reason to
It's an arbitrary restriction in the sim type after all
To simulate disruption I suppose
Shadowstep/Hook would only really be relevant for relative comparisons between specs and I'm not sure if HAC is appropriate for that anyway
e.g. i did just put a rly high distance to showcase it:
https://www.raidbots.com/simbot/report/Q3svfwr6aSEC2rEaZtZbz/simc
Movement mechanics work fine for melee but generally aren't relevant for anything other than like DH and maybe Monk
er well i guess only outlaw gets the 8y melee range
DH does simulate brief distance movement from using FR/VR
To get back in hitbox range
But since there's not really any "tradeoff" here other than maybe exploring when it's worth using PS/Toss/PK when out of range
Not super relevant for Rogues or most specs in general
with blunderbuss, thoughts on this rule for opp usage? https://www.raidbots.com/simbot/report/nyY5Z9rZDbE9yKMs17tpWG/simc
a small gain for a rule that is almost certainly simpler than energy.deficit>energy.regen*1.5 (just moved ss to be higher prio than pistol shot)
can you double check this in AoE? I got like 1% less there. I'm guessing that the over-fishing for BB procs that don't blade flurry is hurting the AoE.
My only concern would be applicability to other specs and situations. Since the energy regen rule I ended up using was the variant that seemed to check the most boxes of all the stuff I tested when you brought up that issue some weeks ago. Will take a look though.
I’m assuming this is also negative when running QD+BB? Not sure if you checked that.
Not at my PC right now but I can poke around later this afternoon.
khar is right that its a small loss in dslice (not getting 1% tho)
yes, i assume its only a blunderbuss thing
I'm getting -1% in pure AoE 5 targets, not dslice - https://www.raidbots.com/simbot/report/vqnVLNMyUsPS55BYgBaZCC
i see
I was also trying to test whether skipping opportunities where you proc tornado trigger was a gain or not but it's a push
because you're going to get tornado trigger eventually, I didn't see a reason to force it. there's probably latent gains from stuff like natural BTE uptime or not overcapping CPs when combining tornado trigger and BB
the 4pc can only be consumed with a casted pistol shot
the 2pc wont keep cycling it
with a BB shot?
yea bb or just regular opp
yeah, was assuming that you'd get the tornado trigger through BBs passively, but maybe it's also sucking because 2pc shots are getting wasted while you wait?
yes, the 4pc would be sitting there when it potentially could have already been fired and started cycling again
which may still be worth less than spamming ss for bb
either way, didn't seem impactful:
ST: https://www.raidbots.com/simbot/report/1m2d4QCMn9jiWfbeYfYptb
AoE: https://www.raidbots.com/simbot/report/2i4zFJHocwmvzyC2YZh835
but idk
notably, the prio damage from any of these other options seems to be like +2.5%, which doesn't really make sense to me if it's tying in ST
probably the fact that the apl is still using BR on cd in aoe, making it even less usefull to use opp proc than in st
it is likely something relating to BR, but the -1% aoe rotations should all be using fewer opp procs. I did some surface level investigations earlier and it's remarkable how much nothing else changes. casting drastically different SS/PS and getting the same CP throughput, CTO, CDs, etc
can you link to that report?
its urs
oh that's prio target damage, yeah
okay that makes sense. I thought you meant overall damage in relation to BR
Yeah I don't quite understand why the difference in prio damage there would be caused by those changes
It's worth noting that the Cache damage in the Outlaw Venthyr profile here is much higher which is interesting
(For the AoE sim)
its cache
cause the way i made the apl change
i didnt change the prio of tab target ss
Ah right so it's just changing the Cache to be focused on the ST instead of AoE spread which biases the prio calculations
so the other configs just might not be doing that at all
That makes sense looking at the other stuff
Everything else is lower or the same so must be Cache
i new a lazy apl change would bite me 
with the cache fix, dslice and cleave are similar gains as st for this profile
if you are talking about this,i can share my friend's thought,he is the people who create this usage.He thought that it's a risky usage and it should be use when you have adr,Bloodlust and flag to proc more BB for more damage,but you might be unlucky to proc BB when u ss until you don't have enough energy so that u only can consume proc opp.when u in the normal situation,proc opp should be consume 60-ish(tested by other theorycrafter).
that sounds very close to the default rule energy.deficit>energy.regen*1.5 which would adapt to having adr/lust active
yes,its kinda close,chinese player thought 50-ish is better for blunderbuss,SS when energy>50,ps when energy<50
the china dude actually thought it was same as what solo said,we had the chat
as in u send opp proc if u dont have energy for SS
it was from ramfam telling me that chinese tc'ers were doing it
I have like no experience in this specific topic but what's the advantage of sending a PS immediately instead of waiting for another SS? If SS is so great that you ignore PS in all other moments
can recall ramfam saying something on stream as well,as in when u actually wanna send opp proc but couldnt rly understand what he was talking about.But it was mentioned that there was a reseasrch from a chinese guy earlier than us
im not totally sure what you're asking
the APL you posted earlier only uses opp procs if you can't use an SS (due to energy presumably?). why use an opp proc at all instead of waiting for energy for an SS
if using opp procs was good because of energy efficiency, then it should be better to be using opp procs much earlier than as a last resort
so e.g.
"/pistol_shot,if=buff.opportunity.up&(energy.deficit>energy.regen*1.5|!talent.weaponmaster&combo_points.deficit<=1+buff.broadside.up|talent.quick_draw.enabled)"
to
"/pistol_shot,if=buff.opportunity.up&(!talent.weaponmaster&combo_points.deficit<=1+buff.broadside.up|talent.quick_draw.enabled)"
is what that would imply I think (specifically for BB, idk if that messes up other builds)
the chinese tc'ers is my friend,when ramfam ask me about him i gave him the website then he told me that he tell you about this usage,my friend are willing to join this research,i think ask him will be useful for the research.
hmm opp is likely to proc combat potency so its very close to a neutral global
going from nearly-zero to zero opp proc usages is probably well within the margin of error so idk
i couldnt tell you specifically the napkin math as to why never opp is a large loss https://www.raidbots.com/simbot/report/nHNMmCGDZoY1PNWX1GWQYu/simc
yeah never opp uses way less PS. not really "nearly-zero" I guess
my gut says there's a target number of PS you want and "opp only if you cant ss" rotation and normal rotation are sort of on either side, with a steep cliff
oh also for this profile, using dancing steel causes the new opp rule to just be neutral
with blade rush the never opp is not as bad
I'm pretty sure there's a haste concern involved also, since opp is good for energy
1.7% is a lot to overcome through stat swapping though
nice, i just meant that i shouldnt be taking credit for this potential change
does the bb still proc ramdomly in sim?
bb are so uncertain that when using might cause the data unstable when simulating
it might cause the difference about the sim
simc uses the same proc chance as in game
it's doing a pull like 30,000 times (or whatever your iterations are) and averaging the result
oh i see
does opp proc have a higher chance to proc combat potency or its just fixated to proc alongside the opp proc
nah, its just combat potency can only proc from offhand autos, main gauche and pistol shot
and its a 75% chance
ah i c,it makes sense
i know realized,even after so many years i didnt even know that
insane what u can learn
I mean even with the "if you can't SS" rule there's still a lot of chances to use Opportunity. It works with the set bonus as well as being very energy efficient source of CP gen. So I don't think this is too surprising.
But I'll take a look if anything is odd there
But generally I think it's still useful to use Opportunity and realistically the only time it's not is when it will cause you to cap energy. (Which is what the regen condition is for.) But it could be there is some more specific edge case that causes SS to be better which is what the 0.2% is eeking out
Might make sense to try to isolate specifically what that case is
Because there could just be a bigger increase to find with some more restrictive condition in when SS is preferred
I think it's clear Opportunity PS is better than SS the majority of the time based on the final sim there though
I think it at least needs a haste rebalance before a conclusion can be drawn from the same gear set. there's a pretty big downtime difference between them
it "makes sense" that pooling energy for ss is not a gain since pooling has not been a thing in the history of outlaw, but i couldnt necessarily put into words as to why
In the no-Opp (only using it on BB procs) APL it's essentially wasting almost exactly 50% of the Opportunity procs
In the normal APL it only overwrites ~25% of the Opportunity procs
Opportunity Pistol Shot is extremely efficient so it should basically "always" be better as long as you are resource-constrained or the DPET of SS doesn't become too large
There are likely some cases the energy.time_to_max condition is not capturing or some other case (maybe with SnC or AR max energy expiry?) where it's not beneficial but is currently considered as such which is what the re-ordering is exposing
For example in your original sim @finite sparrow there's a 10 energy difference on average in reduced AR energy expiry which could be contributing to that 0.2% efficiency
92.97 Overflow on Adrenaline Rush (Expiry) vs. 83.44
Yes the Overflow there is something I added to track how much unused Energy is lost
When AR expires
i see
I suspect this is an area we could improve for sure
And could be contributing to this
the SS/PS number of uses difference on this latest sim barely exists, for the record
So this is confirming my hunch a bit
This is me just changing the existing condition to be this
energy.deficit>energy.regen*1.5&(!buff.adrenaline_rush.up|energy.deficit-50>energy.regen*1.5)
So I think we just need to make something a little smarter for handling AR energy deficit handling
also in general doesn't this mean it's safer to err on the side of ignoring opp procs closer to the "opp only if you cant ss" instead of 70? e.g. rule of thumb can be 60/50/40 w.e
(Could just change it to energy.deficit-(buff.adrenaline_rush.up*50) but might just put it in a variable)
the 70 thing is just what i say to explain energy.deficit>energy.regen*1.5
not sure what the dps penalty looks like when you increase the rule of thumb so that you're overcapping instead, but you're practically pushing/gaining by going lower
Might only be worth considering if AR duration is <5s or something idk
Which would be the advantage of variablizing it
i.e so yes the number 70 is not significant as it's just an energy threshold that is usually close to that deficit rule
so i tend to say that instead of telling people to start tracking their energy regen number
That's fair
right I get it's an abstraction, but if people are trying to hit 70 and accidentally overcapping, would it generally be better to recommend even lower, if these numbers are showing a push by going literally all the way down?
e.g. going higher is risk for no reward. not everyone is tracking their flag/AR/haste/combat potency etc perfectly in the global
The numbers are showing a push only because energy.deficit>energy.regen*1.5 can be better tuned to adapt to the increased maximum energy of ADR
fixing this will not change 70 as an abstraction
also this needs to have a 4th option where it has the ADR fix and the opp if no SS together right?
or does that even make sense. I think they might be mutex
Doing something similar helps KS as well looks like
Since it also relies on deficit values
This is for KS instead of BR
BR probably needs to be converted to consider something like this too though since it's just using time_to_max.
Which is based on deficit under the hood
Probably won't keep this a variable, just going to do it for prototyping. I'll probably add an energy.base_time_to_max and energy.base_deficit expression extension in code
Ok this is for Blade Rush fixing the time_to_max to ignore AR overage

Compared to 93.43 in the base profile
Obviously won't be able to mitigate all of the overage here since there's just naturally gonna be some times we cap no matter what we try to do, especially during lust
But this is certainly more efficient
Does that mean solo was actually right or we dont know yet
(on sending opp proc when our energy is not enough for a strike)
no
sap
it means the expression energy.deficit>energy.regen*1.5 can be better adapted to not waste the 50 energy lost from adr falling off
so the rule is not actually changing
ah nice
Yeah variable in this case is something like this
actions+="/variable,name=base_energy_deficit,value=energy.deficit-(buff.adrenaline_rush.up*50)"
actions+="/variable,name=base_energy_time_to_max,value=variable.base_energy_deficit%energy.regen"
But I'll be shifting this into code
in other words simc just wasnt always doing what we I thought it was
I mean it was doing what we thought it was
It's more that all this means is it's not worth playing around the AR max at all
It's better to just consider our max energy is the base energy all the time
Tested some various duration checks like <5s for example and those weren't any better
so using 70 as an abstraction is even more correct than before
(They were better than baseline but not better than just ignoring it entirely)
instead of like, having to think of it changing to 120 or something while adr is active
But yeah I'll move this into code so we'll have options of using either energy.deficit or energy.base_deficit as appropriate
With base_deficit ignoring any temporary max
does that mean we were actually undersimming
a lil
Not really, it's just a different way of approaching things
I think a scenario where you can use the ADR extra cap is like trying to BR or KS within the window and using the extra room to get away with it, then being more moderate afterwards to bring the energy back down. that would let you get your restless blades working sooner. probably too small to actually do anything though
That could gain some more damage
Primarily around BR and KS seems like more than anything
Because they are more restricted to non-cap Energy scenarios
After all the gain to the PS rule is only like 0.1-0.2% of this, whereas the KS/BR conditions are gaining another 0.3-0.4% from ignoring the AR max
This is better than just binary ignoring KS and BR entirely during AR like we have tried in the past
Since there are plenty of cases where AR may be up but our energy is basically 0
And in that case it's still worth using
i ant rly imagine having ar up and pressing KS
even on dead energy it feels so overkill
u go from 0 to overcap half way in
I mean this is probably fairly relevant for Celerity for example. A straight AR restriction would be very limiting for no reason.
yeah gotcha
Or maybe early in AR duration if you're at low energy to start
But yeah
This will still consider AR's regen, just against the base max energy, not the adjusted max
In practical terms, all this finding means is "pretend your max energy is always base max energy and ignore the AR max because we can't reasonably dump our energy fast enough to not lose it most of the time"
without this fix, wouldn't celerity be doing pretty dumb stuff with your SS/PS decisions when you get celerity?
Possible, although since Celerity procs often will happen at low energy randomly it's probably fine most of the time anyway
But yeah it could certainly have funny cases
BR and KS timing is the most relevant here since both of those CDs are currently trying to only be used when energy starved. The PS vs. SS consideration is only a minor difference.
Since this also slightly reduces the overflow from BR energy gain itself in addition to the AR overflow reduction
Basically this is "generating" about 30 energy and swapping a few PSs for SSs when it wouldn't be beneficial. It's not huge but we'll take it. 😛
Since it's a rather simple change
sorry @opaque sedge i see how what i was typing was misleading
its fine dw,we all do mistakes,typosare a part of it 😛
im trying to soak information,mostly buzzing around,creating issues from nowhere
ultimately this is the tldr
even though i never really told people to think of 70 changing to a different threshold during adr anyway
and br/ks on st will remain 'use at low energy'
about to just put these energy rules into a weakaura and stop trying to reword them in a normal way 
guys do you get the conclusion?
yeah, the difference was only from wasted energy when adrenaline rush falls off and removes its +50 max energy
the 'opp only if you cant ss' rule was better at dumping energy before this happens
what exactly is the final rule is in this sim? And why can't we just put "use ps if under a certain treshold of energy" instead?
The rule is just ignore the additional max energy from AR when considering deficit/time_to_max
time_to_max only change if on AR or not right ?(and a bit depending on haste as well but could be ignored?)
adding ttd>20 to sepsis is a decent gain in dslice https://www.raidbots.com/simbot/report/p3X66BHUtg6A7fw9VPNgRa/simc
(ttd>10 is about .4%)
>=16 is what i use for subtlety
I suppose it could probably use a target_if=max:time_to_die condition as well
Similar to what I added for Flag
Shouldn’t really matter for HAC unless it’s the end of fight but probably should have a |fight_remains<16 check in that case too
Don’t think Sepsis will ever be cast on the adds in HAC
Looking at this, I suspect some of this could just be phantom gains
Seems to indirectly force some alignment with Vendetta ending up overlapping with Chains trinket usage
e.g.
actions.build="sepsis,target_if=max:target.time_to_die,if=target.time_to_die>20
This is actually slightly "worse" (+0.4% instead of +0.8%) and the only difference is trinket damage, even though it should logically always be better from the standpoint of uptime. The "problem" here seems to be that it finds a valid target sooner.
It's quite odd though, I don't really see why it should matter
I need to look into the direct cause some more, very curious
Guess BtE also needs to be up otherwise it's losing a fair bit of damage so need
max:target.time_to_die*debuff.between_the_eyes.up
Neither really has any impact on DungeonRoute either so seems specific to perhaps DS timing. But with a BtE conditionals it seems OK with 11 also
actions.build="sepsis,target_if=max:target.time_to_die*debuff.between_the_eyes.up,if=target.time_to_die>11&debuff.between_the_eyes.up|fight_remains<11"
isnt bte like always up?
er i guess you can start a new pack with bte still on longish cd
Yeah but the highest HP enemy isn’t always going to be your primary target in DS with overlapping waves
Some revisited logic on sin that was marginally worse in 9.1, clipping flag for a little bit of extra stacks seems to be worth it.
Single target: https://www.raidbots.com/simbot/report/8295jTVd1PFFJhTcVhg1Ek
Cleave Add: https://www.raidbots.com/simbot/report/odrUmRrQUGzF62qfN26fj3
2T: https://www.raidbots.com/simbot/report/evKkDCEZfMbSw22dret8Ex
HAC: https://www.raidbots.com/simbot/report/wewvAijw1bobqeiw42tpvv
Dslice: https://www.raidbots.com/simbot/report/efYPTBmdvvEd6CTAn5FiBs
At first I was content with just having it send an envenom and call it a day, but after some testing, I isolated it into it's own list for clarity and added rupture and crimson tempest. While this is all fairly minor, the addition of dots into the logic doubled the gain in the cleave/hac sims. I suspect it's something timing related with the intermittent adds causing minor downtimes of some kind, but it wasn't too obvious to me on first glance.
I also checked for clipping earlier, that sucked because obviously you just generate, just a sanity check, I also checked for changing the cp required, that didn't seem to care much, forcing it on 3+ instead of 2+ was worse though, 1 was still good (basically showing that any cp you have is a-ok to dump). I also fiddled with the timings on rupture/crimson tempest for the logic but it all showed duds or indistinguishable differences, plus given how small the gain is in total, I just decided to leave it be and call it a night.
So I was playing around with roll the bones and vanish a bit and I tried two things -
first - to not roll the bones if you have a good CtO buff, which ended up being a small gain and
second - improved the vanish->dispatch condition a bit to have the same constraint as ambush for having roll the bones (and a small improvement to have energy for dispatch before doing it)
ngl I thought the two changes would conflict with each other since one is asking to have roll the bones up and the other is dropping it on purpose, but it seems that they work well together.
From what I am seeing it results in slightly less vanish casts as well meaning it might be better to not just smack vanish on cooldown.
Anyways, I wanted to give the idea so someone could maybe improve it
https://www.raidbots.com/simbot/report/dNZHP9t5oTWQPSrpQoeGLK
could you highlight the changes you made, I cant find the "no reroll if u have good cto buff" line
There is something I wanted to do for some times but had no idea how to: rerolling if cto buffs> rtb buffs and ur rtb buffs arent the good ones, or rerolling if u only have cto buffs
look similar to what you are trying to do
Vanish one :
actions.cds+=/vanish,if=!runeforge.mark_of_the_master_assassin&!runeforge.invigorating_shadowdust&!stealthed.all&((variable.ambush_condition&debuff.flagellation.down)&(!runeforge.deathly_shadows|buff.deathly_shadows.down&combo_points<=2)|talent.weaponmaster&variable.finish_condition) ---->
actions.cds+=/vanish,if=!runeforge.mark_of_the_master_assassin&!runeforge.invigorating_shadowdust&!stealthed.all&((variable.ambush_condition&debuff.flagellation.down)&(!runeforge.deathly_shadows|buff.deathly_shadows.down&combo_points<=2)|talent.weaponmaster&variable.finish_condition&energy>35&buff.roll_the_bones.remains>=10)
Rolling one :
actions.cds+=/roll_the_bones,if=master_assassin_remains=0&buff.dreadblades.down&(buff.roll_the_bones.remains<=3|variable.rtb_reroll) ---->
actions.cds+=/roll_the_bones,if=master_assassin_remains=0&buff.dreadblades.down&variable.rtb_reroll
pretty sure that is what the default one uses, and my changes are the opposite
no the default one doesnt really care if ur buffs are cto or not
it does, I am pretty sure thats what buff.roll_the_bones is, unless I have it completely wrong
meaning if you only have CtO buffs, that roll the bones buff will be down and it will roll anyway
if buff.roll_the_bones is only rtb buffs yeah, but its also not doing what I suggest
it would reroll if ur rtb_buffs are unders 3 seconds disregarding ctos buffs
what I think could be done is taking into account ctos for the rtb_reroll value, and making it reroll following the logic I said earlier
I m pretty certain its not the same as what you are doing
but what you are doing should make it reroll cto buffs less often
it can most likely be tweaked yea, but if I understand it correctly what you are saying is somewhere in between my change and the default apl
kinda
My only concern with the logic of this is that it does seem to kinda discard the knowledge that CtO buffs are preserved if they are longer duration, which would seemingly make the constraint for Vanish being &buff.roll_the_bones.remains>=10 just due to existing logic, not due to actual functionality
e.g. since we know CtO buffs from Vanish will be 15s duration there's technically not a reason we should care about this since they'll always be retained
But this is working together with your other thing to prevent it from getting "hung up" on CtO buffs
But I think what that means is that the RtB cast condition needs to be more aware of the CtO state and not just reusing the reroll condition
(Which I think is what @half karma was getting at the other day)
Other consideration would be how this played with (or if it was redunant with) the pending Vanish changes already. (https://www.raidbots.com/simbot/report/pVkotaz4yPzCf6cb1WVtsw these variants)
That's next on my list to integrate
I think this change is unrelated to the current reroll issue, it just let us cast more ss for more procs, what annsie did however is "accidentaly" patching some things that should be handled in the reroll conditions (reroll condition should handle cto buffs)
It's true it may be unrelated conceptually, but in reality the goal of those changes was widening the window for Vanishing rather than constraining it, so these two changes may not be directly compatible in some ways
its true but I think if we fixed the reroll logic, vanish wouldnt need to be tied to rtb or cto buffs
what I meam is this condition wouldnt need to exist
Yeah I understand what you mean, I just think it probably has to be looked at as a whole again.
Just need to try to avoid any conflicts between the intended changes, but I generally agree that logic should be moved elsewhere
I am having to make a few adjustments for other talent/legendary combos for the suggested improvements to the Vanish line though so will post the adjusted line shortly
Some of the suggestions needed adjustment for non-WM setup (since the Flag condition being exclusive to WM is a loss but a gain when merged)
And merging outside of some of the legendary things
Looking more like something such as:
actions.cds+=/vanish,if=!runeforge.mark_of_the_master_assassin&!runeforge.invigorating_shadowdust&!stealthed.all&(variable.ambush_condition&!buff.flagellation_buff.up|(talent.weaponmaster|buff.flagellation_buff.up)&variable.finish_condition)&(!runeforge.deathly_shadows|buff.deathly_shadows.down&combo_points<=2)
After some more testing, this seemed to be a gain with the latest APL logic even for QD and GS (less, 0.3% or so, but still an upgrade) for BB/GSW/Guile. Shadowdust handled by a different line and didn't seem relevant. Also had to make an exception for Deathly since it conflicts with the CP gain.
actions.cds+=/vanish,if=!runeforge.mark_of_the_master_assassin&!runeforge.invigorating_shadowdust&!stealthed.all&(variable.ambush_condition&(!buff.flagellation_buff.up|runeforge.deathly_shadows)|variable.finish_condition)&(!runeforge.deathly_shadows|buff.deathly_shadows.down&combo_points<=2)
i think there's a bug in simc where shadowmeld > dispatch doesn't apply 15s CTO https://www.raidbots.com/simbot/report/hh636bzJtySHVaeDxSKUt1
cause the dmg loss from dispatch and dps variance difference shouldnt be so extreme
thats not the case, if you look in the sample sequence you can see it gaining broadside at 4 seconds after meld dispatch and only losing it at 19 seconds
i dont get why the dispatch sim is 2% less dps, has ~0.5% lower rtb buff uptime and a crazy high dps variance then
even if i fix the opener to not delay the first bte https://www.raidbots.com/simbot/report/oavKBBaadNWLGB1CiGnsNs/simc
is not having meld at all even a 2% loss? its probably messing up something else
hmm yeah no meld is like 0.6% loss
hmm
I think it's something wrong with auto attacks
Shadowmeld is triggered in the core and maybe it's not playing nice with the auto attack handling in the Rogue module
Can't really say for certain without looking at the actual log/debug output
Just the AA damage is quite different
in those two profiles
if i took even 1 second to compare the differences instead of impulsively posting here i wouldve seen the difference in auto attacks

20 fewer MH attacks
void execute() override
{
racial_spell_t::execute();
player->buffs.shadowmeld->trigger();
// Shadowmeld stops autoattacks
if ( player->main_hand_attack && player->main_hand_attack->execute_event )
event_t::cancel( player->main_hand_attack->execute_event );
if ( player->off_hand_attack && player->off_hand_attack->execute_event )
event_t::cancel( player->off_hand_attack->execute_event );
}
this is in the core
I don't trust this
lol
We have better handling in the Rogue module for rescheduling logic but it may be conflicting
void rogue_t::cancel_auto_attack()
{
// Cancel scheduled AA events and record the swing timer to reference on restart
if ( melee_main_hand && melee_main_hand->execute_event )
{
melee_main_hand->canceled = true;
melee_main_hand->prev_scheduled_time = melee_main_hand->execute_event->occurs();
event_t::cancel( melee_main_hand->execute_event );
}
if ( melee_off_hand && melee_off_hand->execute_event )
{
melee_off_hand->canceled = true;
melee_off_hand->prev_scheduled_time = melee_off_hand->execute_event->occurs();
event_t::cancel( melee_off_hand->execute_event );
}
}
Still not immediately obvious why it would lose so many
But I think it's certainly related to this
Still can't really explain why though, or why that APL change in particular messes it up
@finite sparrow so did some more digging here. It's still very odd. I can't fully explain it yet but I can give some ideas.
Moving Shadowmeld specifically embedded into the finish list (which exits out but since it's no GCD it should come right back in)
# Finishers
# BtE to keep the Crit debuff up, if RP is up, or for Greenskins, unless the target is about to die.
actions.finish=between_the_eyes,if=target.time_to_die>3&(debuff.between_the_eyes.remains<4|runeforge.greenskins_wickers&!buff.greenskins_wickers.up|!runeforge.greenskins_wickers&buff.ruthless_precision.up)
actions.finish+=/slice_and_dice,if=buff.slice_and_dice.remains<fight_remains&refreshable
actions.finish+=/shadowmeld,if=!stealthed.all
actions.finish+=/dispatch
performs significantly better than
actions.cds+=/shadowmeld,if=!stealthed.all&variable.finish_condition
I think some of this can be explained inasmuch as there is ~1% lower BtE uptime for this profile so it clearly disrupts some of the normal finishing logic.
I still can't quite understand fully why it is so much of a loss.
Or why this is not much of a problem for Vanish ('embedded' Vanish is not any different in performance.)
I suspect it could just be timing-related as an edge case that it throws a monkey wrench in somewhere at a specifically poor time during some iterations? But I'm still digging.
@finite sparrow Ok, I have finally figured this out. It's unrelated to Shadowmeld directly, but it was triggering a super timing specific bug.
@crystal crypt so does look like melding into normal finisher logic is good. But realistically just existing Vanish rules apply to it just fine. This is within margin of error for my local sim.
Probably will just copy the Vanish rules to keep it straightforward for all builds
Actually going with this for now, but can test more when it's on Raidbots
actions.cds+=/shadowmeld,if=!stealthed.all&(conduit.count_the_odds&variable.finish_condition|!talent.weaponmaster.enabled&variable.ambush_condition)
i didnt get very far, though i noticed that use_off_gcd=1 seemed to fix the issue for dispatch... but then cause the same issue to happen for ambush https://www.raidbots.com/simbot/report/oa5REZSNuizjLhBGfzNBmQ
may be something entirely unrelated to apl stuff
Essentially this was a very odd bug that was caused by Grand Melee being the first thing to apply SnD
i also noticed there are moments where meld is being used before the cooldown is even supposed to be ready
Which essentially never happens but with the unrestricted Meld finisher logic it could due to Vanish CtO GM into ->Meld Dispatch
This was the only real cause of the loss since the bug was persisted the entire fight generally due to GM
Took me hours to find this
Not pleased lol
😄
No idea about the cooldown thing. Shadowmeld's CD is handled in the core but I don't see anything odd about it.
in my "ambush meld off gcd" sample, meld is cast at 6:19.334, and the next meld is at 8:19.262
and then it "waits" for 8:19.334 to actually use ambush

but it seemed unrelated to whatever is happening here
oh, and that this was happening to any racial, not just meld
very rarely (scrolling through 100 minutes of samples) 
so what exactly was the issue if the first snd was caused by meld > dispatch?
Had to do with some old Legion Azerite effect code that was stomping the normal default_value which caused it to almost always be 1.0. This had been around for a long time and that is fine. However extend_duration_or_trigger() code didn't care about that and that's newer stuff that GM and a lot of other things use. This caused the default_value to be 0.5, which resulted in the modifier for SnD being 1.25 instead of 1.5
This would then be extended the entire duration of the fight
Only way this was possible was for extend_duration_or_trigger() to be the source of the SnD buff so it was just never noticed before. GM and Premed are the only cases that can do that, and Premed is short-lived and the impact would be quite minimal.
And GM into finisher had not really been possible with the existing opener logic.
Due to the priority of SnD
So it required a lot of things to go wrong... which is why it only got hit in an extremely specific case like this lol
I just ripped out all the old code now so all should be well
Also implemented a way for Shadowmeld itself to tie into the Rogue module AA handling so it won't lose quite as many AAs from that either (which was a bias of like 5-6 per fight iirc)
But at the end of the day, yeah ~2% loss was roughly just "what if SnD was half as strong" 😛
this kinda makes sense with some of the wonky damage distributions i was seeing
e.g. at 100 minutes of combat https://www.raidbots.com/simbot/report/te2b8pSCNULfppkbJGF8QP
😄
Yeah I didn't run into an APL that yielded that when testing today but that does seem like it could have happened for sure
snd having a lower multiplier makes sense with the auto attack counts
Yes, I knew it was something related to AAs but this in particular was deep into multiplier code and took me quite a lot to debug in the right spot lol
more productive than me scrolling through samples looking for an edge case that went really wrong
I think u switched the profiles around, meaning the one using it on cd isnt actually using it on cd
because you modified the apl being used by the base profile
oh did I
unless im mistaken i think u did that on both yeah
oh yea, nvm then gonna delete this 😄
idk if its was looked at but maybe try doing it while the flag isnt being build up
this
nope, still sucks 
unluck
Damn, you guys hiding your sekrit tech from me before I saw
ye, it was wrong, flipped the profiles 😄
was about pressing bf on cooldown during acquired axe driver
perhaps still worth toying with that logic cause i didnt go nuts with it
checked 1 dancing steel profile, saw a large loss and called it a day
I know he tried with bb might be ok with gsw
or as necro
bb might be the worse possible profile for it
doesnt look good as necro either, doesnt seem bad as venthyr gsw tho but still isnt a gain
For outlaw, rerolling when the buff falls instead of 3 seconds before seems to be a small gain: https://www.raidbots.com/simbot/report/vpe5xRNYAd6V3LubNtSUT4
Relevant change: actions.cds+="/roll_the_bones,if=master_assassin_remains=0&buff.dreadblades.down&(!buff.roll_the_bones.up|variable.rtb_reroll)"
As a reference, the reason !up is better than "only reroll if no good buffs":
actions.cds+="/roll_the_bones,if=master_assassin_remains=0&buff.dreadblades.down&variable.rtb_reroll"
is that variable.rtb_reroll can be kept false by CtO buffs that will persist even after a reroll, so you need the !up or a duration check on the primary buff.roll_the_bones container buff to see if it has completely fallen off or not.
Yes, that one was suggested by @gusty ridge
She had found it a while ago that it was a small increase to only reroll if you don't have good buffs from CTO
I do think there could be a case where rtb_reroll would be false AND we have bad buffs AND we have good CTO buffs that are higher duration than RtB and would persist
But that would be a much more complex check
I'd suspect it could be another 0.1-0.2% or so but may not be worth
*he 😄
Oh sorry
The issue with this in reality
That name sounds female in my native language so brain just blurped
Is that if the cause of the odd non-refreshing bugged buffs is what I think it is
Rerolling in these situations could potentially be a negative
But idk
Yeah, so we tried that
its fine, you are not the first one 😄
We still don't quite know what causes it but I do speculate it's related to duplicated rolls
Turns out it increases the times it rolls by 0.05 every 5 minutes
And is essentially neutral
Here's the sim doing that: https://www.raidbots.com/simbot/report/txWDJCYjPk2aZZFCnQFj6N
I think it's because it's very rare that a bad roll survives until 15 seconds (for vanish CTO to be relevant), and even rarer it survives until 5 seconds (for normal CTO to be relevant)
You would need to chain CTO buffs to get it there, and if it drops when rtb is offcooldown it'll just roll the same as if we weren't tracking that
Yeah I think that is likely true. I think the check could be more robust potentially but I doubt it's worth the complexity of trying to find a case where it would be beneficial
Does look like it could be a minor gain as well to move RtB up the priority list with these new conditions since it's more timing sensitive letting it drop
Hm, assuming the original position was good for rerolling bad buffs, would splitting the !up and reroll existing buffs conditions help?
I think it's more just that since RtB pandemics, having it in a lower position largely didn't matter (since it didn't really make a big difference with 3s fudge factor) but when just letting it drop off, there's some minor gain to not allowing maybe 1-2s of not rerolling due to AR/Flag/etc.
Not really a big deal just something I noticed
Easy enough to just shift it up
But yeah may be worth testing moving rerolling around somewhere else to see if there is any difference. I suspect it'll still be neutral but I'll check after dinner
@lean talon so @finite sparrow and I have been very bored tonight and we have done isolated RtB casts for an hour or two. For me I fully let every buff expire and raw cast every time. No CtO. No refreshes.
I did 128, Solo did 100. Based on our ranks, expected average was 41.4%
2 buff total for us combined was 39.4%
95% confidence interval for 228 samples with expected chance of 41.4% should be +/- 6.4%
So I'm leaning towards it looking functionally OK right now. Will do more rolls later. Would like to get the error down to sub-5%. But right now leaning towards thinking they either fixed any issues with it or there is something else wrong here with CtO interactions, dummy refreshes (as we discussed briefly last week,) or something else.
For me I fully let every buff expire and raw cast every time
fwiw i also did this
Interesting
A little suggestion in case you werent already doing it and they havent fixed it, use the ER and SnD cancel bug to reset rtb CD quicker and with less effort
It hasn't been fixed unless it got stealth fixed today, I've been using it to speed up old content runs
If u want i can log and roll/note every roll quantified+the quality factor
In experimenting more with the priorities after the hotfix, found some notable gains for SBS for AoE sims. Putting GSW higher priority than SBS cleave lines is definitely a gain. Only about 0.1% of this is from the set bonus procs, mostly just GSW. BB gains about 0.3%.
Also does appear burning GSW procs with <1.5s left on the GSW buff is a small gain (0.1-0.2%) if no Opportunity proc happens.
@finite sparrow since it's maybe relevant to the FAQ
can u link the sim pls
There's a small optimization that can be done for outlaw - the bte 5+ condition should only take into account if you would hypothetically cast BTE anyways, otherwise it'll break the 4cp finisher condition for bb build
Dps diff is pretty minute since BTE has to be off CD + you have to be at 4 cp with bb up
Seeing about 10 dps which is miniscule
there is no 4cp condition for bb. it's dps neutral and not in the APL. 10 dps is within margin of error, sims will naturally vary by ±0.05%
i did bring up that rule potentially conflicting with future changes though #tc-research message
can you also link this? best i could do was make this neutral
oh, it's in that sim too
It was included in the sim condition above but not broken out
Could have to do with the location of it at this point
Also maybe specific to Necrolord
is it not a necro+dslice only thing?
It's possible. I don't think it should be exclusive to that, since it was clear enough it was worth doing over casting SS or letting it expire when it happened. But it was pretty rare.
Imagine the other specs just hit it very infrequently
Was a few sim/configurations where it was like 0.2%
Others it was neutral
Since it was simple enough to include figured why not
i see
I'd have to dig through my sims for today to find the ones where it was ahead but can look
https://www.raidbots.com/simbot/report/e2zssnNTKRNYmg5AukUDQ3
here was one I think looking through my history.
But yeah it's like super rare anyway
like 1.7 times in the sim
that's why I just merged it into the one line
But didn't really seem to make it much more complex so can't hurt I suppose
yea, i'm assuming only necro really cares about it, but no reason to tie it to covenant.necro if its just neutral/rarely happens to the rest anyway
0.76 times in DS
So yeah mostly pointless lol
I wouldn't have bothered if I wasn't already editing the line, but since I was
I figured for something like HeroRotation or whatnot it may actually be more likely in real play than a sim
Seems like it's possible players will miss their proc windows a little more frequently
true, especially cause it can depend on pull structure a bit
Also tossed in the Sepsis stuff we discussed some days ago
And some small ST gains for Venthyr last-second buff sniping (which was about 0.2-0.3% on ST depending on gear level)
i also couldnt get that venthyr check to be more than neutral, though i didnt check <1s, did like <gcd*3 cause i figured 1s was too short, some iterations could be casting a cooldown during it or not have energy etc
Was like 0.2-0.3% on my crap gear with <1.5 was marginally better with <1
This was 1.2s vs. 1s.
i would also add &buff.flagellation_buff.stack<=25 etc, though i can see it still potentially being a gain at 30 stacks
I checked and didn't make any difference
Seemed marginally worse for lower gear levels and neutral with BiS
gotcha
thanks
That's with a kinda meh gear set
Running with the default set now
It's really too bad the 4pc is still bugged with Flag though lol
that it doesnt reduce the cooldown? i didn't consider that a bug before for some reason
oh, i thought it just didnt work with obedience
that means in flag window our 4p proc doesnt give cdr?
ehm
thats bad
can i have the full view-extend of the bug and what is the wrongness in that
imma gonna go make a post on forums for that
I noticed this discrepancy and I kept thinking my unity was bugged. Good to know.
Found something interesting. There was changes recently to start doing vanish into finish, but for some reason always saving vanish for a finisher was not a gain. I tried moving the line on ambush condition that tries to protect CTO buffs: (!conduit.count_the_odds|buff.roll_the_bones.remains>=10)
To the general vanish line as well as reserve vanish for finishers with blunderbuss. Turned out to be a decent gain. Might be a gain for other legos/covs also, have not tested.
https://www.raidbots.com/simbot/report/vwiGqz4LpxGoPytKKfRdbh
nice find, side note: if you want to have the damage diff shown in the report you can usechart_show_relative_difference=1 relative_difference_from_max=1
Basically it counts enough that it triggers the stack gain from the CPs, but does not trigger damage or trigger Obedience.
shouldn't (!conduit.count_the_odds|buff.roll_the_bones.remains>=10) be useless now that cto buffs will remain after rolling if they have a higher duration than rtb?
I cut out that condition and the dmg increase from your other change is the same https://www.raidbots.com/simbot/report/1BwibSLSZRybX8xjqmeWsA
Yeah I didn't isolate that as I thought it had already been tested
Maybe one of the recent changes made it possible now
im also not sure why vanish > dispatch only is such a gain now for bb which seemingly conflicted with earlier tests
Or was there some other reason this change wasn't already included? Maybe it is no good i aoe
Maybe the !up change?
Possible that ambush is still worth using if you are swimming in energy also
Could be we did not isolate this to BB or one of the other changes recently have opened this up.
This doesn't seem to have any positive impact on GSW
100% something opened it up
Seems BB specific atm anyway
or both of us happened to not check a bb profile
and the like 3 other people that contributed to vanish stuffs 😄
it was 100% not a gain before
My apl was bb specific, so you have to change it if you want to check other legos
Yeah I have recreated this from scratch with some more limited conditionals
Not really seeing anything for other builds right now, just does seem that vanish into finisher with no Ambush is generally a gain now for BB but not others
There's been a lot of small changes to RtB stuff, PS priority, could have been a contribution from the Vanish GM opener bug
Hard to say exactly what contributed
0.5% is notable but not a ton that can't just show up from some other dependency
Does seem this is pretty straightforward but I'm probably gonna double check with all the other legendaries also
But currently this does seem very BB-specific. Probably because it values SS way more than Ambush
should try moving flag to a higher prio than vanish
currently the opener will vanish > dispatch ... build to bte and then flag > bte
Could be tied to weaponmaster/tt as well I guess
is this guaranteed fixed? I am pretty sure I have rolled away CTO buffs this patch
cause it's a pretty old bug right? was happening since the beginning of the expac
u didnt reroll away cto rolls that were higher durations than normals rtb rolls
if cto buffs have a higher duration than rtb buffs then you will never roll them away
It's not WM specific
It's a gain for BB regardless of T1 talent choice
The CtO condition does seem largely redundant at this point, but I'll look into it more
Somewhat unrelated to this though since it seems to be a gain with or without it
Now that we're finishing in Vanish more (or always in this case now for BB) that makes sense yeah
Seems small but probably a 0.2% gain
thx gonna make a teardropping post on forums
The one thing I don't love about this opener with the Vanish Dispatch is how late it uses BtE but it may not matter.
Lol i'm fairly sure any hope of bug fixing has been abandoned cause of dragonflight being <6 months away
thats poor development from their part if thats the case
ideally they would want to fix stuff daily
but ye u ar eprolly right
i saw that and it does feel weird but what can you do
blizz add BtE to CTO in dragonflight, thanks
BtE and SnD both get delayed a bit now which is meh but if it's a gain it's a gain I suppose lol
Maybe I should check if adding it to the Vanish condition makes sense
what about keeping the initial ambush in the opener and only dispatch after that
Can also try to vanish ambush if bte is missing on target
Yeah it is possible but seems neutral so guess it doesn't matter
what causes the sim do get 5cp from first ambush though? I've noticed it on other occasions as well
oh it doesn't show on the buffs anymore?
So bb can basically macro vanish to dispatch
the 2pc activating is not a buff or anything
I swear there was a buff tornado_trigger_loading or something like that
there is, thats why i said to check
as it's basically your only indicator that the 2pc has activated in the sample sequence
hmmmmmm
Nothing there, but looks like it only appears after the first full cycle
might be just bug in the buffs output
oh good spot
Also for non BB you may wanna check only ambush with broadside, its a small gain for BB (still worse than no ambush at all) but if its a gain for BB its probably a gain for other profiles
Non-BB does seem to gain a bit more from a BtE/SnD check on the Vanish finish logic
Which makes sense as it doesn't care as much about using Ambush
Seemed more beneficial than adding a Broadside condition, but could have been indirectly doing the same thing during the opener
Probably since it has no duration, SimC thinks it's "constant" (like food buffs) until it expires for the first time perhaps. I can manually mark as never_constant though.
Just a display issue in the sample sequence though
I see
lots of working coming ur way with an alpha/beta dragonflight opening
im super hyped to get those numbers rolling
lol yeah gonna be busy in a few weeks. Get your 0.1% APL tweaks submitted to me before next Wed 😛
another small improvement (0.1%) seems to be to finish at -1, stacking with other conditions, if we have tornado trigger and opportunity up, since we get at least one CP from the free BTE
with my own apl for the only vanish into dispatch for BB changes though, doesn't look that that is in yet?
yeah, I mean it is very tiny 🙂
its not in yet
but I'm not sure why it is so tiny, unless overcapping on cp isn't much of a problem
because it doesnt happen enough
u rarelly use the 4p proc urself when playing bb
and u have to be at -1 cp for ur condition to happen
so its very rare
altough I think when i checked with celerity instead of bb it was neutral aswell
makes sense
Not yet no. Probably will be getting it in tonight. I still have to do a full testing pass with various other legendaries/talents/covenants/etc.
Change is now in the nightly, so everything should be available now.
am I correct in reading that it uses vanish > ambush in the opener and then vanish > dispatch for the rest of the encounter for all builds except deathly shadows, shadowdust and master assassin?
Yeah. Although I was thinking about merging MA back down in at this point.
MA is a little neglected for some of the recent changes I suspect (probably needs an exception in BtE line too now that we cast it more conditionally, etc.)
Deathly is still doing the same thing as before, just was cleaner to rip it into its own line
(Pretty significant loss to vanish into finisher with Deathly due to the CP gen)
If I have time before the 10.0 fiesta soon, I'll take a look at MA if someone else doesn't beat me to it. 😄
how far MA has fallen, might we still be using it without the trinket nerf? 
Yeah it's possible
MA with Earthbreakers would be pretty juicy lol
Then again the other "problem" is that Outlaw has a hell of a lot of Crit now lol
Its vanish ambush in opener unless you roll GM I guess?
just when snd isnt active
Now I want to sim never pressing SnD with GM up
But its too late and I should sleep
tbf all this stuff is pretty much neutral and just for sample sequence cleanliness
Doubt we'd find any notable gains from this, the sim already only casts SnD 1.5 times per 5 minute sim on average
pressing snd with gm active gets extended the normal way anyway
not like that global is wasted
But it could just be a super minor opener update on short fights
Would probably almost only happen in opener yeah
