Core/Unit: Forward proc events from controlled units to owner

[gonzo1247]

Changes proposed:

Extend proc forwarding for controlled units (pets/guardians).

When a controlled unit triggers a proc event, the event is now also
forwarded to the owner so relevant owner auras can react to it. TrinityCore
already forwarded spellmod-related auras (e.g. Cobra Strikes), but other
owner auras were not considered.

This change forwards additional owner class-family auras while avoiding
double processing of already handled spellmod auras and explicitly
excluding generic auras to prevent unintended item procs.

Tests performed:

Tested proc behavior with controlled units triggering events while relevant
auras were active on the owner (e.g. pet attacks causing owner auras to react).
Verified that owner auras correctly receive and process the forwarded proc
events and that spellmod-related auras continue to behave as before.

Testing was performed on a TCCP core.
The change has not yet been tested against TrinityCore master.

[Nyr97]

Do I understand correctly that this PR would make it possible for, e.g., my own trinket auras (chance on dealing damage) to trigger through pet (negative) spells and attacks (or rather actions)?

[ccrs]

feels like this needs its own proc flag no?

[gonzo1247]

Good point – I hadn’t tested this thoroughly enough. My initial tests were only done with a Hunter whose trinkets hadn’t proc’d.
However, additional tests with a Warlock showed that this can indeed happen, which obviously shouldn’t be the case.

I originally implemented this because of the Hunter spell Killing Command (34026), which uses a script to make the pet cast Killing Command (83381).

There is also the talent Killing Streak (82748) which should react to Killing Command via a spell_proc entry:
https://github.com/The-Cataclysm-Preservation-Project/TrinityCore/blob/master/src/server/scripts/Spells/spell_hunter.cpp#L1342

That interaction wasn’t working, which is why the above logic was introduced.
However, the current implementation seems to go a bit too far.

I think ccrs’s suggestion of adding an additional proc flag would be a good way to avoid unwanted side effects.

[gonzo1247]

I reworked the implementation based on the feedback in this PR.

The previous approach was too broad and effectively allowed pet-triggered events to be treated as owner events in some cases. This could lead to unintended side effects such as player trinkets, weapon enchants or unrelated player auras proccing from pet attacks.

To address this, the logic has been replaced with an explicit opt-in mechanism on both sides.

Two new flags were introduced:

• PROC_EXTRA_FLAG_ALLOW_PET_TRIGGERED_OWNER_AURAS
Allows a specific spell event triggered by a controlled unit to evaluate owner auras.

• PROC_ATTR_ALLOW_PET_TRIGGERED_OWNER_AURAS
Marks auras that explicitly allow being evaluated on the owner for such events.

Owner aura evaluation for pet-triggered events will now only occur if both conditions are met:

the triggering spell event sets the extra proc flag

the receiving aura explicitly allows this behaviour via the new attribute

This keeps the default behaviour unchanged and prevents player auras (e.g. trinkets or enchants) from unintentionally proccing from pet actions, while still allowing specific mechanics such as Killing Command / Killing Streak to work correctly.