Attach Combat Components

Attach Combat Components

This page wires one combat pawn into GCS: finish InitializeAbilitySystem from the GenericGameplayAbilities docs on the authority, attach the combat components, and implement IGCS_CombatEntityInterface. When you are done, the Debugger Shared section shows the components and the interface. This page does not fire an attack.

Related pages: layering is in System Boundaries; Flow and results are in Combat Flow and Attack Results.

Prerequisites

1. You enabled GenericCombatSystem and its .uplugin dependencies from Quick Start. GIPS owns input buffering and is not a module dependency of this plugin.
2. You pointed Ability System Globals at UGGA_AbilitySystemGlobals and called InitializeAbilitySystem on the authority, following the GGA docs. This page names those docs and does not link to another plugin path.
3. You have a combat pawn the server can spawn. GCS does not require a specific character base class. The actor or a component only needs the interface.
4. You have an instantiable UGCS_CombatFlow subclass (the base class is Abstract) with at least one processor. How to override it and wire the GGA callback is in Register the First Attack Result.

1. Confirm the Ability System first

Before any GCS component, the authoritative pawn already has a usable GGA Ability System Component. Combat Flow turns GGA attribute callbacks and Effect Context payloads into FGCS_AttackResult. If the ASC is not initialized, later hits and Gameplay Effects never enter Flow as expected.

2. Attach the minimum set

On each pawn that fights:

1. Add UGCS_CombatSystemComponent and set CombatFlowClass. Authority BeginPlay NewObjects that class and replicates the Flow, so the abstract base class cannot be used.
2. Add UGCS_TraceSystemComponent for melee. The Trace Subsystem ticks the sweeps; the component owns handles and hit events.
3. Add UGCS_BulletSystemComponent for ranged. It owns replicated bullet entries, instances, and the prediction contract.
4. Add UGCS_TargetingSystemComponent and UGCS_CombatTeamAgentComponent when lock-on or affiliation filters matter. Targeting can live on a non-pawn actor; the team component replicates FGenericTeamId.
5. Implement IGCS_CombatEntityInterface on the actor or one of its components. Return at least the current target, death state, current weapon, and combo table (or null when unused).

If actions are chosen by tags, author UGCS_AbilityActionSetSettings as a DataAsset. It is not a project settings class. The entity's QueryAbilityActionsByContext reads that asset.

3. Implement the smallest interface returns

The interface can live on the actor or a component. UGCS_CombatFunctionLibrary::GetCombatEntityInterface / FindCombatInterface check the actor first, then components that implement the interface.

Suggested minimum:

Leave rotation, movement-set, and death flow empty until the combo and weapon page.

Expected result

After authoritative PIE, the pawn has a combat component and an instanced Combat Flow. Blueprint Get Combat System Component / Find Combat System Component succeed. The Debugger Shared section marks the combat-entity interface as present.

Verify

1. UGCS_CombatSystemComponent::GetCombatSystemComponent / FindCombatSystemComponent are non-null.
2. Melee pawns resolve GetTraceSystemComponent / FindTraceSystemComponent; ranged pawns also resolve GetBulletSystemComponent / FindBulletSystemComponent.
3. Lock-on pawns resolve GetTargetingSystemComponent; team pawns return a team through GetCombatTeamAgentInterface.
4. Open the Combat category of Gameplay Debugger (registered at module startup as GenericCombatSystem): Shared shows the combat component, Combat Flow, and the combat-entity interface.
5. The Flow processor list is not empty.

Common failures

Next

Once lookup works, make Combat Flow produce a Result with Register the First Attack Result. Then melee is Author a Melee Attack and ranged is Author a Ranged Attack.