OnStopCombatHook

[DoubledaCoder]

A hook to allow for custom logic to apply when combat ends for all unit types.

Changes Proposed:

This PR proposes changes to:
The UnitScript to include a new hook for custom logic to be applied when combat finishes. The hook is for a custom module i've adapted and expanded from a patch which synchronises the creature level to the player level. My issue is that there was no appropriate unit script hook for when combat finishes that allows for custom logic onto creatures.

OnEnterCombat is the initial trigger hook to sync the level, OnDamage hook is the trigger I've used which limits griefing and facilitates multi-level combat, however when combat ends e.g. leash, evade, the creature would return to the initial coordinates at whatever level it was set to. So if a Lv80 ran through a starting zone and aggroed 10 mobs, a lv5 entering that area would be swarmed (even though OnEnterCombat means they will sync to the correct level) death would be hard to avoid. With this hook, regardless of the reason, when combat is being cleared, the creature resets to within its level template bounds.

AI-assisted Pull Requests

Copilot was only used as an assistant. All code has been tested in the context of the Playerbot fork.

Tests Performed:

Playerbots were running for 1 hour with Free for all PVP active and the mod-mob-sync-level active doing quests etc. I also ran the below test to specifically check whether the hook is successfully triggered using the mod.

How to Test the Changes:

1. Install the mod-mob-sync-level
2. Using a GM character attack a creature that is 10 or so lower levels than the character so it switches it level then:
   a. run away from the creature until it resets
   b. kill it and wait to see what occurs on respawn
   c. fly up into the air so it cannot attack you
   d. go into an out of bounds area the creature cannot reach

You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:

http://www.azerothcore.org/wiki/How-to-test-a-PR

REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).

For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.