mirror of
https://github.com/mod-playerbots/mod-playerbots.git
synced 2026-01-13 00:58:33 +00:00
c9cc4324d3
<!-- > [!WARNING] > **This is a DRAFT PR.** > The structure is not definitive. The code might not be optimised yet. It might not even start nor compile yet. > **Don't panic. ✋ It's going to be ok. 👌 We can make modifications, we can fix things.** 😁 --> # Description This PR aims to refactor the NextAction declaration to achieve two goals: ## Eliminate C-style sentinel arrays Currently, a double pointer (`NextAction**`) approach is being used. This an old pre-C++11 (< 2011) trick before `std::vector<>` became a thing. This approach is painful for developers because they constantly need to declare their `NextAction` arrays as: ```cpp NextAction::array(0, new NextAction("foo", 1.0f), nullptr) ``` Instead of: ```cpp { new NextAction("foo", 1.0f) } ``` The first argument of `NextAction::array` is actually a hack. It is used to have a named argument so `va_args` can find the remaining arguments. It is set to 0 everywhere but in fact does nothing. This is very confusing to people unfamiliar with this antiquated syntax. The last argument `nullptr` is what we call a sentinel. It's a `nullptr` because `va_args` is looking for a `nullptr` to stop iterating. It's also a hack and also leads to confusion. ## Eliminate unnecessary pointers for `NextAction` Pointers can be used for several reasons, to cite a few: - Indicate strong, absolute identity. - Provide strong but transferable ownership (unlike references). - When a null value is acceptable (`nullptr`). - When copy is expensive. `NextAction` meets none of these criteria: - It has no identity because it is purely behavioural. - It is never owned by anything as it is passed around and never fetched from a registry. - The only situations where it can be `nullptr` are errors that should in fact throw an `std::invalid_argument` instead. - They are extremely small objects that embark a single `std::string` and a single `float`. Pointers should be avoided when not strictly necessary because they can quickly lead to undefined behaviour due to unhandled `nullptr` situations. They also make the syntax heavier due to the necessity to constantly check for `nullptr`. Finally, they aren't even good for performance in that situation because shifting a pointer so many times is likely more expensive than copying such a trivial object. # End goal The end goal is to declare `NextAction` arrays this way: ```cpp { NextAction("foo", 1.0f) } ``` > [!NOTE] > Additional note: `NextAction` is nothing but a hacky proxy to an `Action` constructor. This should eventually be reworked to use handles instead of strings. This would make copying `NextAction` even cheaper and remove the need for the extremely heavy stringly typed current approach. Stringly typed entities are a known anti-pattern so we need to move on from those.
53 lines
2.5 KiB
C++
53 lines
2.5 KiB
C++
#include "NexusStrategy.h"
|
|
#include "NexusMultipliers.h"
|
|
|
|
void WotlkDungeonNexStrategy::InitTriggers(std::vector<TriggerNode*> &triggers)
|
|
{
|
|
// Horde Commander (Alliance N)/Commander Kolurg (Alliance H)
|
|
// or
|
|
// Alliance Commander (Horde N)/Commander Stoutbeard (Horde H)
|
|
triggers.push_back(new TriggerNode("faction commander whirlwind",
|
|
{ NextAction("move from whirlwind", ACTION_MOVE + 5) }));
|
|
// TODO: Handle fear? (tremor totems, fear ward etc.)
|
|
|
|
// Grand Magus Telestra
|
|
triggers.push_back(new TriggerNode("telestra firebomb",
|
|
{ NextAction("firebomb spread", ACTION_MOVE + 5) }));
|
|
triggers.push_back(new TriggerNode("telestra split phase",
|
|
{ NextAction("telestra split target", ACTION_RAID + 1) }));
|
|
// TODO: Add priority interrupt on the frost split's Blizzard casts
|
|
|
|
// Anomalus
|
|
triggers.push_back(new TriggerNode("chaotic rift",
|
|
{ NextAction("chaotic rift target", ACTION_RAID + 1) }));
|
|
|
|
// Ormorok the Tree-Shaper
|
|
// Tank trigger to stack inside boss. Can also add return action to prevent boss repositioning
|
|
// if it becomes too much of a problem. He usually dies before he's up against a wall though
|
|
triggers.push_back(new TriggerNode("ormorok spikes",
|
|
{ NextAction("dodge spikes", ACTION_MOVE + 5) }));
|
|
// Non-tank trigger to stack. Avoiding the spikes at range is.. harder than it seems.
|
|
// TODO: This turns hunters into melee marshmallows, have not come up with a better solution yet
|
|
triggers.push_back(new TriggerNode("ormorok stack",
|
|
{ NextAction("dodge spikes", ACTION_MOVE + 5) }));
|
|
// TODO: Add handling for spell reflect... best to spam low level/weak spells but don't want
|
|
// to hardcode spells per class, might be difficult to dynamically generate this.
|
|
// Will revisit if I find my altbots killing themselves in heroic, just heal through it for now
|
|
|
|
// Keristrasza
|
|
triggers.push_back(new TriggerNode("intense cold",
|
|
{ NextAction("intense cold jump", ACTION_MOVE + 5) }));
|
|
// Flank dragon positioning
|
|
triggers.push_back(new TriggerNode("keristrasza positioning",
|
|
{ NextAction("rear flank", ACTION_MOVE + 4) }));
|
|
// TODO: Add frost resist aura for paladins?
|
|
}
|
|
|
|
void WotlkDungeonNexStrategy::InitMultipliers(std::vector<Multiplier*> &multipliers)
|
|
{
|
|
multipliers.push_back(new FactionCommanderMultiplier(botAI));
|
|
multipliers.push_back(new TelestraMultiplier(botAI));
|
|
multipliers.push_back(new AnomalusMultiplier(botAI));
|
|
multipliers.push_back(new OrmorokMultiplier(botAI));
|
|
}
|