[FEATURE] Demonology implosion and demonic core functionality tweaks

Before You Begin

[X] I confirm that I have downloaded the latest version of the addon.
[X] I am not playing on a private server.
[X] I checked for an existing, open ticket for this request and was not able to find one.
[X] I edited the title of this feature request (above) so that it describes the issue I am reporting.

Feature Request

I will move my suggestion to a separate issue, as well as add another suggestion.

re: Implosion If this can be implemented it would make it significantly more accurate in aoe than the current simc implementation, this is one of the biggest differences between real gameplay and sims right now. The logic is relatively simple for implosion cycles, the only "real" logic would come with optimisations that aren't implemented elsewhere in the APL yet, so it does basically boil down to just replacing those lines with "summon as many imps as you can and implode when you don't have time to summon more", or in other words "implode just before your oldest imps will die".

Also, the "logic" which is separate in those lines doesn't really need to be separate. Whether you are playing IP or not, you still just want to "implode just before your oldest imps will die". The only exception is if you have very few imps (not sure exactly where the breakpoint is) such that the global spent imploding isn't an overall gain. I expect this is 3 or fewer imps without IP or 2 targets, and less than 2 with IP in 3+ targets.

My only concern is the performance hit, generally speaking imp tracking/imp related WAs/addons are quite performance intensive, so hopefully there's a way to efficiently manage it.

A separate suggestion, right now the addon doesn't seem to be accounting for the guaranteed core procs gained when dogs die (1 for each dog).

before dogs die: https://pastebin.com/szWtikz3 after: https://pastebin.com/msUJkxXX

Unsure if this falls under recommendation suggestions, so appologies if this is the wrong issue type.

Additional Information

No response

Contact Information

dubu#2080

Imp Tracking Expression(s)

"implode just before your oldest imps will die".

Hopefully, priority logic will avoid burning imps that could still be extended by your Tyrant if you have DCon.

So, let's say we want to call this next_imp_remains to time_to_imp_expires and it is simply the remaining time on your lowest imp (whether based on timing out or based on depleting their energy). Does that cover it? If not, why not?

My only concern is the performance hit, generally speaking imp tracking/imp related WAs/addons are quite performance intensive, so hopefully there's a way to efficiently manage it.

Imps are already tracked anyway. The ones that worry about tracking individual demon health to see how much power you'll get from DCon are problematic, but "when was this demon summoned" and "how many times has it cast outside of Tyrant" are not CPU intensive details to track. Anyway, it's really a matter of presenting information or making it available as an expression for priority logic. (The addon has to forecast that your imps are going away so it doesn't say to Implosion after they're gone.) Not a big deal.

Are there other imp-related expressions that would be helpful? There are some things that could already be addressed with APL criteria/variables, but maybe simplifying them would be useful. For example, time_to_new_imps might be "how long will it take me to reach 3+ soul shards and cast Hand of Gul'dan and for the imps to land." I might want to know that so I can see if time_to_imp_expires < time_to_new_imps before choosing to use Implosion. Maybe with IP, I want to generate as many as possible before Implosion, and without IP, I'm fine to Implosion ASAP because I might use new Imps for something else (i.e., DCon).

If you have ideas, be really clear, brief, and specific.

Dreadstalker Expiration Cores

It's fairly recent that I added the capability to cause things like this to trigger when buffs/summons expire, so this can be added. But I'm curious -- has this been problematic? Do you find yourself getting recommendations to cast Shadow Bolt but your Dreadstalkers expired within your Spell Queue Window, so you started hardcasting when you would've just got a Demonic Core proc?

I'm asking because expiry events are a little more expensive -- it can be similar in cost to adding another icon to a display -- and I haven't noted issues with reactively responding to Demonic Core for myself. Also, because Dreadstalkers are "totems" and totem expiration is a little wonky... A demon might take a half-second longer than you'd expect to actually despawn and no longer get extended by Tyrant and/or proc Demonic Cores.

If I implement these, the timing has to be precise because it would be far worse for the addon to anticipate you'll have a Core you don't have and encourage you to hardcast a Demonbolt in combat, vs. passively reacting to actual procs.

Hopefully, priority logic will avoid burning imps that could still be extended by your Tyrant

Hopefully yes. However, the variable.next_tyrant_cd>5 really ought to be changed to imp lifetime (a set number of GCDs). But that's a task for the APL probably. This can get a little awkward with haste buffs that come in around this time, its hard to say how problematic this is without play testing though. I bet it would be a gain to force an implosion with N+ imps (6+?) at this point, since otherwise they will just fall off while you build for tyrant.

Does that cover it? If not, why not?

This expression sounds perfect.

On a more specific "when to implode" note, there is one case in which this might not be exactly what you want, and that occurs at very high haste levels (as when playing IP). Since your GCD is so short it is possible for hog>gcd>implosion to implode before all 3 imps have spawned, This will leave you with 1 "straggler" which you probably don't want to implode, it's very hard to do sims to test this but intuition tells me that imploding multiple GCDs early and "messing up" your implosion cycles is likely not worth it. What I mean is that using a GCD on a single imp extra is not worth it when you can use that same GCD for 3 or 6 extra imps, depending on procs. It's very likely better to just let that imp fall off and continue with the cycles. So, it may be nice to know how many imps will fall off in the GCD that the oldest imp is going to fall off.

But realistically this is not going to make a huge difference one way or the other, and simply imploding when time_to_imp_expires < GCD will be sufficient, although it might work out better to leave more than a GCD spare, in game testing will be needed for specific timings probably.

As for more imp related expressions, there is one other imp related case that is somewhat clunky now and I think its related to the opener logic. Basically, sometimes the addon will recommend you keep building imps before you tyrant despite you already having as many imps as you could possibly have before you want to cast tyrant, and tyrant being ready. Eg if I go into a pull with 10 imps and dogs/tyrant ready, I just want to dogs+tyrant, but the addon will have me sit about for 10s while it builds to less than 10 imps and uses tyrant (the default opener logic).

Some logic related to "Is it possible for me to have more imps in the next 10 seconds than I will have in 1.33gcds (after tyrant cast, or 2.33 for dogs+tyrant), or should I just blast tyrant right now (and at what point will I/do I have the most, so I know to tyrant at that point)" would be good, and would "solve" the m+ opener issues without needing to alter the simc opener logic which will never account for going into a fight with imps.

Implementing this "how many imps in N seconds" logic in simc is, as it stands now, impossible. And even if it was possible, it wouldn't be implemented into the opener because it's not something that happens in sims.

has this been problematic?

It's not hugely uncommon to have 0 cores as dogs are dying and therefore have less than 1 gcd to react to the whole recommendation list changing because of this, so yes, hardcasting SB is not uncommon due to this. I understand that totem deaths can be janky, but IMO it would be better to assume that the dogs will take a short time to die, and let the APL update as it does now as soon as they die "early", rather than not accounting for the deaths at all - this is purely so that the recommendation list doesn't change so dramatically the moment they die which can be jarring. The APL tries to keep you at 0 cores more frequently this patch because of 2pc giving 3 cores now.

I think that for most users it will result in a smoother more enjoyable rotation even if in theory they will hardcast SB more frequently by following the recommended rotation and not reacting to dogs dying, because they will be able to pre-plan their casts rather than have the recs change completely. However, the users who don't react to dogs dying will hardcast SB with the current system too so in theory its not a loss for them, and not a loss for the people who do react because they will just react.

Just my 2 cents on the matter, however you have a better understanding of it.

I'll be making Dreadstalkers proc Demonic Cores when they despawn now. It'll spawn 2 without tier, 3 with tier.

Note to self: You still need to "fudge" demon (totem) expiration times because the WoW API is dumb.

Hekili / hekili