Add aggressive strat

[kadeshar]

Pull Request

Describe what this change does and why it is needed...

---

Design Philosophy

We prioritize stability, performance, and predictability over behavioral realism.
Complex player-mimicking logic is intentionally limited due to its negative impact on scalability, maintainability, and
long-term robustness.

Excessive processing overhead can lead to server hiccups, increased CPU usage, and degraded performance for all
participants. Because every action and
decision tree is executed per bot and per trigger, even small increases in logic complexity can scale poorly and
negatively affect both players and
world (random) bots. Bots are not expected to behave perfectly, and perfect simulation of human decision-making is not a
project goal. Increased behavioral
realism often introduces disproportionate cost, reduced predictability, and significantly higher maintenance overhead.

Every additional branch of logic increases long-term responsibility. All decision paths must be tested, validated, and
maintained continuously as the system evolves.
If advanced or AI-intensive behavior is introduced, the default configuration must remain the lightweight decision
model. More complex behavior should only be
available as an explicit opt-in option, clearly documented as having a measurable performance cost.

Principles:

• Stability before intelligence
  A stable system is always preferred over a smarter one.

• Performance is a shared resource
  Any increase in bot cost affects all players and all bots.

• Simple logic scales better than smart logic
  Predictable behavior under load is more valuable than perfect decisions.

• Complexity must justify itself
  If a feature cannot clearly explain its cost, it should not exist.

• Defaults must be cheap
  Expensive behavior must always be optional and clearly communicated.

• Bots should look reasonable, not perfect
  The goal is believable behavior, not human simulation.

Before submitting, confirm that this change aligns with those principles.

---

Feature Evaluation

Please answer the following:

• Describe the minimum logic required to achieve the intended behavior?
• Describe the cheapest implementation that produces an acceptable result?
• Describe the runtime cost when this logic executes across many bots?

---

How to Test the Changes

• Step-by-step instructions to test the change
• Any required setup (e.g. multiple players, bots, specific configuration)
• Expected behavior and how to verify it

Complexity & Impact

Does this change add new decision branches?

• • No
• • Yes (explain below)

Does this change increase per-bot or per-tick processing?

• • No
• • Yes (describe and justify impact)

Could this logic scale poorly under load?

• • No
• • Yes (explain why)

---

Defaults & Configuration

Does this change modify default bot behavior?

• • No
• • Yes (explain why)

If this introduces more advanced or AI-heavy logic:

• • Lightweight mode remains the default
• • More complex behavior is optional and thereby configurable

---

AI Assistance

Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change?

• • No
• • Yes (explain below)

If yes, please specify:

• AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.)
• Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation)
• Which parts of the change were influenced or generated
• Whether the result was manually reviewed and adapted

AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor.
Any AI-influenced changes must be verified against existing CORE and PB logic. We expect contributors to be honest
about what they do and do not understand.

---

Final Checklist

• • Stability is not compromised
• • Performance impact is understood, tested, and acceptable
• • Added logic complexity is justified and explained
• • Documentation updated if needed

---

Notes for Reviewers

Anything that significantly improves realism at the cost of stability or performance should be carefully discussed
before merging.

[Copilot]

Pull request overview

This PR introduces a new opt-in non-combat “aggressive” bot strategy that automatically selects and attacks nearby targets when the bot has no target, by adding a new target value and wiring it into the existing Action/Value/Strategy contexts.

Changes:

• Added AggressiveStrategy (non-combat) that triggers an "aggressive target" action when "no target".
• Added AggressiveTargetValue to select a nearby viable unit within a fixed aggro range.
• Registered the new strategy, action, and value in their respective contexts.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/Ai/Base/ValueContext.h	Registers the new "aggressive target" value creator.
src/Ai/Base/Value/AggressiveTargetValue.h	Declares the new target-selection value.
src/Ai/Base/Value/AggressiveTargetValue.cpp	Implements target selection logic for aggressive pulling.
src/Ai/Base/StrategyContext.h	Registers the new "aggressive" strategy creator.
src/Ai/Base/Strategy/AggressiveStrategy.h	Declares the new non-combat strategy.
src/Ai/Base/Strategy/AggressiveStrategy.cpp	Adds a "no target" trigger that runs the aggressive pull action.
src/Ai/Base/Actions/ChooseTargetActions.h	Adds AggressiveTargetAction and is used by ActionContext factory mapping.
src/Ai/Base/ActionContext.h	Registers the "aggressive target" action creator.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

AggressiveTargetAction currently inherits AttackAction behavior without the additional safeguards/side effects used by other pull/auto-attack actions (e.g., AttackAnythingAction): it does not set the "pull target" value on a successful pull and it does not override isUseful/isPossible to prevent pulling while in combat/"stay"/disallowed activity or when the resolved target is invalid. Consider adding Execute/isUseful/isPossible overrides (and setting/clearing movement state as needed) to keep behavior consistent with existing non-combat pull actions and ensure downstream logic that relies on "pull target" works correctly.

Suggested change

	std::string const GetTargetName() override { return "aggressive target"; }
	std::string const GetTargetName() override { return "aggressive target"; }
	bool Execute(Event event) override;
	bool isUseful() override;
	bool isPossible() override;