Add raid_events=absorb

[mat-simon]

What

• raid_events=absorb — new event that puts an absorb_buff_t on a target enemy. Options: target=, amount=, school= plus standard timing controls. No amount= means unbreakable for the window.
• target.has_absorb APL expression and player_t::has_absorb() / current_absorb_amount() helpers (scoped to enemy actors via enemy_t overrides).
• Attacker DPS attribution: when an action damages an enemy with an active absorb, the attacker's stats credit the rolled mitigated damage instead of just the post-absorb HP impact. Implemented as a virtual credited_damage_amount on player_t, overridden on enemy_t to add the absorbed delta. result_amount semantics are preserved.

Use case

Encounter modeling — boss / add mechanics with absorb shields (Aleria-style fights). Analogous in shape to raid_event=vulnerable; class APLs and class modules can react to shielded targets via the helpers and the target.has_absorb expression.

[mat-simon]

Pushed an update: added a target.has_absorb expression to the player expression dispatch (player_t::create_expression in engine/player/player.cpp). It returns 1.0 when the actor has any active absorb_buff_t, 0.0 otherwise.

This was originally scoped as a follow-up but I'm pulling it into this PR because a planned class-module follow-up (Voidweaver's Devour Matter) needs to gate an APL line on shield presence, and the expression is the cleanest way to expose that. Three lines added next to the is_add / is_boss / is_enemy predicates.

No diff impact on the rest of the PR.

[renanthera]

Not related specifically to this change, but the PR in general...

Historically, there were issues where some effects did not proc when the action attempting to trigger the proc was fully absorbed. The most notable case I immediately recall is Slimy Expulsion Boots during Dragonflight, most notably in Underrot (as it was available in M+ and the final boss has an absorb over its entire HP for the entire fight).

More investigation is definitely required before making this change.

[renanthera]

An expression that yields the total amount of absorbs could also be useful, but it will be hard to avoid the trap that UnitGetTotalAbsorbs falls for given that there are multiple types of absorbs.

[renanthera]

This (and the following changes at 2171-2179) could be an assessor that enemy_t registers potentially?

[mat-simon]

Is a method on enemy ok?

double enemy_t::credited_damage_amount( const action_state_t* s ) const override {
double absorbed = s->result_mitigated - s->result_absorbed;
return s->result_amount + std::max( 0.0, absorbed );
}

[mat-simon]

I could make the assessor but I think the functionality would be the same?

[gastank]

There's no need to inject additional code & calculations into the main codepath that every damage goes through for something that only applies to a niche case. You can contain all the code entirely within raid_events.cpp by utilizing assessors and only have it apply to the player should the profile actually create a shield event.

Since you can't really search for existing assessors, something like raid_event_t::init( sim ) would be a good place to search for the absorb event and add the assessor if necessary.

[renanthera]

It'd be more common to set the assessor priority to TARGET_DAMAGE+1 if you want the assessor to occur after TARGET_DAMAGE assessors, but beyond that don't mind the exact ordering. That is likely sufficient in this context.