Verse API reference page for the health_component class | Fortnite Documentation

The default health component: processes damage and healing scene events against an ordered array of health pools.

============================================================================== Scene Events

Senders BUILD the adjustment event themselves and deliver it with SendUp:

Event := damage_event: Context := health_adjustment_context{Instigator := option{Agent}} Entries := array{health_adjustment_entry{HealthDelta := 70.0}} Target.SendUp(Event) DealtResult := Event.Result

The event's Modifiers stack is supplied by the sender - gather modifiers from contributors however your game sees fit before sending.

OnReceive consumes the first damage_event/healing_event that reaches this component: pools are adjusted, the event's Result is set, OnDamaged or OnHealed is signaled with that result, and OnDied is signaled when the adjustments took IsAlive from succeeding to failing.

============================================================================== The Math - Layer-Factor Multiplication

Pools are processed in order; within each pool, entries are processed in order. Per (pool, entry), three modifier stack LAYERS are consulted:

1. the event's stack (Event.Modifiers, supplied by the sender) 2. the pool's stack (Pool.DamageModifiers / Pool.HealingModifiers) 3. the component's stack (DamageModifiers / HealingModifiers)

Each layer independently evaluates the REAL entry with natural semantics - a stack's modifiers chain internally, and the whole stack's output folds to ONE factor:

Factor = Stack.Evaluate(Entry).HealthDelta / Entry.HealthDelta

The layer factors MULTIPLY: Multiplier = FEvent FPool FComponent. A factor of 1.0 is naturally inert; a 0 from ANY layer zeroes the multiplier and NULLIFIES the entry (a 0-delta result entry is recorded and nothing remains to continue on); a negative factor flips the direction.

============================================================================== Application, Unwind, and Excess

Scaled = Remaining * Multiplier

The pool is first gated by its CanProcessAdjustment. The SIGN of Scaled then decides direction: in a damage_event a positive Scaled damages the pool toward 0 while a negative Scaled heals it toward MaxValue (a healing_event mirrors this). Scaled is negative when the entry's HealthDelta or the folded multiplier is negative - a negative HealthDelta entry is valid input and starts in the reversed direction. A pool with no capacity in that direction is skipped and the entry continues on unchanged.

What the pool absorbs is recorded as a result entry carrying the pool's Tag, the entry's Categories, and the direction actually applied (damage_tag or healing_tag). Overflow UNWINDS by dividing the multiplier back out - Remaining = (Scaled - Absorbed) / Multiplier - and continues to the next pool, where the layers are consulted again. Whatever survives every pool lands in Result.Excess at its unwound value.

Example: a 70 damage entry against shields at 50 carrying a 2x pool trait, with a 3x record on the event: multiplier 2 * 3 = 6, so 420 to apply; shields absorb 50; the remaining 370 unwinds to ~61.7 and continues to the next pool at THAT pool's multipliers.


Verse `using` statement	`using { /UnrealEngine.com/HealthPipeline }`

Inheritance Hierarchy

This class is derived from component.

Name Description

Name	Description
`component`	Base class for authoring logic and data in the SceneGraph. Using components you can author re-usable building blocks of logic and data which can then be added to entities in the scene. Components are a very low level building block which can be used in many ways. For example: Exposing engine level concepts like mesh or sound Adding gameplay capabilities like damage or interaction Storing an inventory for a character in the game As components are generic there is no specific way that they must be used. It is up to the needs of your experience if you use one big game component or if you break up logic into many small components. Classes deriving from component must also specify `<final_super>` to be added to entities. This ensures the class will always derive directly from `component`. Further subclassing of the initial derived component is allowed and does not require specifying `<final_super>` on the derived classes. Only one instance of a component from each subclass group can be added to an entity at a time. For example, given this group of components, only one light_component can exist on a single entity. To create multiple lights you should use multiple entities. light_component := class(component){} capsule_light_component := class(light_component){} directional_light_component := class(light_component){} spot_light_component := class(light_component){} sphere_light_component := class(light_component){} rect_light_component := class(light_component){} ============================================================================== Component Lifetime Components move through a series of lifetime functions as they are added to entities, added to the scene, and begin running in the simulation. Components should override these methods to perform setup and run their simulation. As a component shuts down it will then move through shutdown version of these functions, giving users the opportunity to clean up any retained state on the component before it is disposed . Lifetime Methods: OnAddedToScene OnBeginSimulation -> OnSimulate OnEndSimulation OnRemovingFromScene ==============================================================================

component

Base class for authoring logic and data in the SceneGraph. Using components you can author re-usable building blocks of logic and data which can then be added to entities in the scene.

Components are a very low level building block which can be used in many ways. For example:

Exposing engine level concepts like mesh or sound
Adding gameplay capabilities like damage or interaction
Storing an inventory for a character in the game

As components are generic there is no specific way that they must be used. It is up to the needs of your experience if you use one big game component or if you break up logic into many small components.

Classes deriving from component must also specify <final_super> to be added to entities. This ensures the class will always derive directly from component. Further subclassing of the initial derived component is allowed and does not require specifying <final_super> on the derived classes.

Only one instance of a component from each subclass group can be added to an entity at a time. For example, given this group of components, only one light_component can exist on a single entity. To create multiple lights you should use multiple entities.

light_component := class(component){} capsule_light_component := class(light_component){} directional_light_component := class(light_component){} spot_light_component := class(light_component){} sphere_light_component := class(light_component){} rect_light_component := class(light_component){}

============================================================================== Component Lifetime

Components move through a series of lifetime functions as they are added to entities, added to the scene, and begin running in the simulation. Components should override these methods to perform setup and run their simulation.

As a component shuts down it will then move through shutdown version of these functions, giving users the opportunity to clean up any retained state on the component before it is disposed . Lifetime Methods: OnAddedToScene OnBeginSimulation -> OnSimulate OnEndSimulation OnRemovingFromScene ==============================================================================

Members

This class has both data members and functions.

Data

Data Member Name	Type	Description
`DamageModifiers`	`?health_adjustment_modifier_stack`	Component-layer damage modifier stack.
`Entity`	`entity`	The parent entity of this component. Components must have a parent entity pointer provided when being constructed. Components cannot be moved between parents.
`HealingModifiers`	`?health_adjustment_modifier_stack`	Component-layer healing modifier stack.
`HealthPools`	`?[]health_pool_entry`	The health pools associated w/ this health component; adjustments are applied to each pool in this order.
`OnDamaged`	`listenable(payload)`	Signaled after a damage event is processed, with the result that was applied.
`OnDied`	`listenable(payload)`	Signaled when an adjustment takes IsAlive from succeeding to failing.
`OnHealed`	`listenable(payload)`	Signaled after a healing event is processed, with the result that was applied.
`TickEvents`	`?tick_events`	Set callbacks to `TickEvents.PrePhysics` and `TickEvents.PostPhysics` to receive per-frame updates before and after physics is updated on your object.

Functions

Function Name	Description
`AddHealthPool`	Appends a pool (applied after the existing pools).
`GetHealthPool`	The first pool whose identity Tag is an instance of PoolTag; fails when none match.
`GetHealthPools`	The health pools, in adjustment-application order.
`IsAlive`	Succeeds while the component is alive; override to change the gate.
`IsInScene`	Succeeds if the component is currently in the scene. After `OnAddedToScene` is called this call succeeds. After `OnRemovingFromScene` is called this call fails.
`IsSimulating`	Succeeds if the component is currently simulating. After `OnBeginSimulation` is called this call succeeds. After `OnEndSimulation` is called this call fails.
`OnAddedToScene`	Called when the component is added to the scene by parenting it under the simulation entity or another entity already in the scene. Querying for components in the scene is valid after this phase completes.
`OnBeginSimulation`	Called when the component begins simulating within the scene. Use this to set up TickEvent callbacks or other setup that must be guaranteed to complete immediately. `OnAddedToScene` is guaranteed to run before `OnBeginSimulation`.
`OnEndSimulation`	Called when the component ends simulation within the scene. Simulation ends on a component when the experience resets, the parent entity is removed from the scene. Cached TickEvents cancelables should be canceled in `OnEndSimulation`. `OnSimulate` task will be canceled before `OnEndSimulation` is called. `OnEndSimulation` is only called on components that have already had `OnBeginSimulation` called.
`OnReceive`	Adjustments arrive as scene events (senders build them and SendUp to the target). A processed event is consumed to stop it climbing past the first health component; unhandled events keep traversing.
`OnReceive`	Respond to a scene event. Return true to consume the event and halt propagation to the next entity.
`OnRemovingFromScene`	Called when the component is about to be removed from the scene. Components are removed from a scene when the parent entity is removed from the scene. `OnRemovingFromScene` is only called on components that have already had `OnAddedToScene` called.
`OnSimulate`	Called when the component begins simulating within the scene. Use this to add asynchronous/suspends update logic for a component. `OnBeginSimulation` is guaranteed to run before `OnSimulate`. `OnSimulate` will be cancelled before `OnEndSimulation`
`RemoveFromEntity`	Removes the component from the entity. Removed components are removed from the scene and can only be added back to the same entity. Flows through `OnEndSimulation`-> `OnRemovingFromScene`.
`RemoveHealthPool`	Removes the given pool instance (health_pool_entry is unique).
`SendDown`	Send a scene event to this component, invoking OnReceive. Returns true if any participant consumed the event.
`SignalDamaged`	Signals OnDamaged and broadcasts the native delegate mirror; native because the underlying event signal is no_rollback.
`SignalDied`	Signals OnDied and broadcasts the native delegate mirror; native because the underlying event signal is no_rollback.
`SignalHealed`	Signals OnHealed and broadcasts the native delegate mirror; native because the underlying event signal is no_rollback.