[TC] [AC] [Question/Feature] [Core] Queue up NPCBot interrupts to allow juking / non-instant kicks

[Shadowcoldzx]

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

• I understand that my issue may get closed without notice if I intentionally remove or skip any mandatory* field
• This is NOT a bug/crash report
• I've searched the bugtracker for similar questions/requests including closed ones

Description

So essentially NPCBots will interrupt immediately anything they can during their update ticks no matter what or who it is they're interrupting.

This is a feature suggestion to allow interrupts to be queued up similar to how a human would - meaning that once a bot wants to kick, it will do so at a later time at random - sometimes this may be immediate or very close to, sometimes it may decide to kick after a slight delay, sometimes it might try to interrupt even if the target is no longer casting (= juked).

Without this, casters are somewhat oppressed by the frequency of instant interrupts. The best alternative is to just use a different spell tree, get instantly kicked, and then proceed doing what you wanted. Normally, you would just attempt to juke an interrupt because no human should kick your off tree spells (obviously we have some exceptions such as SP's).

I think this could easily be limited to non-dungeon environments (i.e. continent/battlegrounds/arenas if done in the future). The bots should, preferably, also be able to cancel their casts if the player's cast would finish sooner than theirs - which would be more human-like and add certain element of unpredictability.

So I think that a working solution may be similar to:

• if the bot is in dungeon/raid, just do what it's currently doing, no need to randomize pve
• if in continent/battleground/arena, when the bot is about to interrupt, instead store current time in millis with a random amount of millis between 0.1 - 0.7s, as well as the to-be-interrupted target (probably a guid or something?)
• when the bot is about to interrupt, check if we already have a target and whether current millis are over stored millis
• if so, if both the bot and it's target are casting and the bot's remaining cast time is longer than that of the target, stop casting and interrupt; if the bot is not casting, just interrupt with no conditions
• do not evaluate whether the target is casting or not at the "time to interrupt" time; this allows the juke -- exception is if the bot itself is casting in which case, it should be better at paying attention and not just throw for no reason
• if the bot was supposed to interrupt but for some reason decided not to (e.g. target is out of range, dead, invisible), look for another casting target around and store variables again to attempt kicking those at later update ticks

Further details would entail checking for what stage the cast time is at the beginning of evaluation cycle:

• e.g. it should not be queueing at all if the target's cast is over half the time, such as when the bot was looking for someone new to interrupt or when it just got in range of the target
• it should probably not be trying to interrupt r1 bolts in general, there's a lot of decision making involved in whether it's worth a kick or not, and a lot of error room for getting juked due to delay, they should either skip kicking those or use much shorter delay to make it more fair (juking r1 bolts is generally not a thing)
• to better simulate differences in player level, different conditions could be set for each bot individually / at random (e.g. wanderers get randomly generated thresholds / conditions, player-owned bots could all be set at the same threshold to prevent poor rng)
• e.g. a bad player will never kick at the right time, and will easily get juked; a proper one will aim to interrupt at the end of the cast and will anticipate jukes .. but in terms of bots, we can probably just solve it with the "delay" threshold, and maybe some random 50/50 at the end whether it will kick nothing or not kick at all

Point is, there is a LOT of fine tuning, but if even the basic implementation is done, it would make bots feel a lot more natural.

This overall wouldn't be too difficult and I'll probably be doing something along these lines in near future to see if it will feel better. At the moment the instant interrupts are just either too easy to fake, or too oppressive when you can't afford to waste time, and no matter what, it doesn't feel right.

TrinityCore or AzerothCore

Both

Core rev. hash/commit

AzerothCore rev. 34c9322d4d2f+ 2024-12-26 22:26:24 +0100 (npcbots_3.3.5 branch)

Operating system

N/A