Stamina and Fitness
Activate SurvStaminaComponent on authority. It starts with StaminaValue 100, FitnessValue 0 and Resting. The project sends movement/sprint intent through an owned Server RPC and updates the stamina tags there.
Movement Tags
Use AddStaminaGameplayTag(Moving) when moving and add Running when sprinting. A Running tag alone does not select the running branch: the pulse handler requires both Moving and Running. Removing Running returns to the Moving branch; removing Moving resets tags to Resting. Adding Resting also resets the container.
Exhausted is managed by numerical exhaustion/recovery; direct adding/removing it through these interface methods is rejected. Do not rely on those checks as a complete authorization system.
Queries and Modifiers
GetStaminaValue, GetStaminaTagContainer, GetStaminaModifierValue and GetFitnessModifierValue expose native queries. There is no dedicated GetFitnessValue interface method; FitnessValue is a BlueprintReadWrite replicated property. Use it read-only for presentation.
UpdateStaminaModifier/UpdateFitnessModifier take positive values. The timer currently uses StaminaModifierValue for both stamina and fitness calculations; FitnessModifierValue and the copied AddAmountStamina/ReduceAmountStamina do not drive the pulse formulas.
Resting and ordinary Moving regenerate 1.5 times the effective stamina modifier per pulse. Moving+Running drains one effective drain modifier per pulse. Fitness changes use configured AddAmountFitness/ReduceAmountFitness. See Component Behavior for cross-affect scalars and limits.
OnSprintStateChanged is generated by stamina OnRep zero crossings, not an authoritative movement-speed implementation. Apply server sprint limits in your movement integration and display state through queries/delegates.