<aside> <img src="/icons/key-antique_gray.svg" alt="/icons/key-antique_gray.svg" width="40px" />

• TECHNICAL LEGEND </aside>

• NAVEGATION

  PROJECT REQUIREMENTS

  EVENTS AND INPUTS

  DAMAGE AND VISUALS

<aside> <img src="/icons/triangle-alternate_gray.svg" alt="/icons/triangle-alternate_gray.svg" width="40px" />

Events and Inputs (API)

</aside>

This section details the system's full API: how controls are managed via the health context and how replicated event logic flows.

<aside> <img src="/icons/triangle_lightgray.svg" alt="/icons/triangle_lightgray.svg" width="40px" />

1. Inputs (IMC_Health)

</aside>

The system uses its own Input Mapping Context called 🟦 IMC_Health. This context manages survival and cooperation actions.

<aside>

🟥 IA_Interact: Held interaction action.

• Logic: Holding the button over a downed ally fills an Interaction Bar in the UI.
• Completion: The input does NOT stop bleeding on its own. Only when the bar is 100% full does it trigger the server event 🟪 CES_Reanimation, executing the logic to lift and recover the ally. </aside>

<aside>

🟥 IA_Heal: Self-healing action.

• Functionality: Calls the client event 🟪 CEOC_Heal.
• Effect: Does not play a complex Montage. It simply generates the visual healing effect and restores the health amount defined in the variable 🟩 Heal. </aside>

<aside> <img src="/icons/triangle_lightgray.svg" alt="/icons/triangle_lightgray.svg" width="40px" />

2. Damage Reception (Unification)

</aside>

To optimize bandwidth and centralize logic, the 🟦 BPC_Health_System discards specific events (PointDamage, RadialDamage) and uses a single entry path.

<aside>

🟥 Event AnyDamage: The Damage "Funnel".

• Function: Acts as the sole entry point for any damage source (Shots, Explosions, Falls).
• Advantage: Unifies state validation (Shields, Immunity) and replication into a single logical flow, avoiding code duplication. </aside>

<aside> <img src="/icons/triangle_lightgray.svg" alt="/icons/triangle_lightgray.svg" width="40px" />

3. System Events (State Machine)

</aside>

These events manage critical state changes and their replication.

<aside>

• 🟪 CEOC_Downed: Entry point to the "Downed" state.
  • Executes on the owning client to manage UI and local movement restrictions before notifying the server. </aside>

<aside>

• 🟪 CES_Reanimation: Server Event.
  • Triggered only when IA_Interact has completed the charge.
  • Restores the downed player and returns them to combat state. </aside>

<aside>

• 🟪 CE_Death: Logical death execution.
  • Manages state variables and UI.
  • Ragdoll: Physical activation is NOT done via code here. It is delegated to the Anim Notify 🟥 AN_Character_Death included in the Death Montage. This ensures perfect synchronization between animation and physical collapse. </aside>

<aside>

• 🟪 CES_Respawn: Server Event for respawning.
  • Resets vital variables.
  • Teleport: Updating the actor's position to the PlayerStart is executed via the Anim Notify 🟥 AN_Character_Respawn within the Respawn Montage, avoiding visual "popping" before the animation ends. </aside>

<aside> <img src="/icons/triangle_lightgray.svg" alt="/icons/triangle_lightgray.svg" width="40px" />

4. Macros Internas

</aside>

<aside>

🟪 MCR_Update_Actor_Status:

• Macro responsible for temporal state management.
• Defines how long the actor remains in special states (like Immunity after respawn or interactions) before returning to the Standard state. </aside>

<aside> <img src="/icons/backward_gray.svg" alt="/icons/backward_gray.svg" width="40px" />

Previous Page

PROJECT REQUIREMENTS

</aside>

<aside> <img src="/icons/forward_gray.svg" alt="/icons/forward_gray.svg" width="40px" />

Next Page

DAMAGE AND VISUALS

</aside>