Combo System

Overview

This page documents Generic Combat System’s data-driven combo routing. UGCS_ComboAbility uses incoming FGameplayEventData to select and activate the next Gameplay Ability from a combo-definition DataTable. It manages combo steps and transitions between child abilities.

UGCS_ComboAbility does not listen to input or global Gameplay Events by itself. Input, animation notifies, or other ability logic must call StartCombo or AdvanceCombo explicitly. For attack abilities and Ability Action Sets, see Attack Abilities. The Attack Abilities page covers attack abilities and Ability Action Sets; this page documents ComboDefinition-based routing.

Components

• UGCS_ComboAbility is an abstract combat ability. It selects a definition row, activates its child ability, and advances or resets the combo.
• FGCS_ComboDefinition is the DataTable row structure. It describes the ability available at a step, event and tag conditions, activation tests, and extension data.
• UGCS_CombatSystemComponent stores and replicates ComboStep. It reports changes through OnComboStepChanged and OnComboStepChangedEvent.
• IGCS_CombatEntityInterface::GetComboDefinitionTable is how the combat entity provides its combo table. The entity implementation must return the table used for this combat; when the interface returns null, combo selection cannot find a row. See Combat Entity for the interface contract.

UGCS_ComboAbility looks up each row’s ability in the Ability System Component by class and the current Source Object. It does not grant child abilities during selection, so every ability in the table must already have an Ability Spec in the ASC, with a Source Object that matches the one used by the Combo Ability lookup.

Calling flow

1. In the Combo Ability Blueprint or C++ logic, call StartCombo(ComboEvent) for the opener and AdvanceCombo(ComboEventData) during later attack windows.
2. AdvanceCombo calls AllowAdvanceCombo() first. The default implementation allows progression; override it in Blueprint to close the current window. StartCombo does not use this gate.
3. For a locally controlled character, the Combo Ability reads the current step from the combat component and the DataTable from the combat entity interface. It walks the rows and selects the first one that passes the step, event, tag, ability-availability, optional activation-test, and custom-selection checks.
4. If the previous child ability is still running, the Combo Ability cancels it before trying the selected ability. Only a successful activation updates ComboStep: normally to the current step plus one, or to zero for a qualifying reset row. If activation fails, the combo resets.
5. When the current child ability ends, the combo resets if it was not advanced before the child ended. Ending the Combo Ability also cancels a running child ability and resets the step.

Child abilities generally should not change ComboStep themselves; the Combo Ability owns progression. After a step changes, the combat component calls OnComboStepChanged(PrevComboStep) and broadcasts OnComboStepChangedEvent, including when a replicated update arrives.

Configuring the DataTable

Create a DataTable with the FGCS_ComboDefinition row structure. Common fields are:

• AbilityClass: the Gameplay Ability class to activate after the row is selected. Rows are skipped when the class is empty, cannot be loaded, or has no matching Ability Spec in the ASC.
• MinComboStep: the step filter value. The current implementation does not behave like a conventional minimum despite the field name. At step zero, all non-negative values pass the step filter. At a step greater than zero, rows with value zero are excluded. For rows without reset enabled, a row is not excluded by the step check only when MinComboStep >= current step. This therefore acts more like an upper bound for non-reset rows.
• bResetComboStep: when true and MinComboStep > 0, selecting the row resets the step to zero. Such a row bypasses the MinComboStep < current step exclusion, but a value of zero still cannot be selected after the opener.
• EventTag: when both the incoming event and the row have valid tags, a mismatch excludes the row. An empty row tag adds no event filter. In the current implementation, an incoming event with no tag does not reject a row that has a tag.
• EventInstigatorTagQuery: matches against ComboEventData.InstigatorTags.
• TagQuery: matches against Gameplay Tags currently owned by the combat entity’s Ability System Component.
• bRunActivationTest: tests whether the ability can activate before the row is selected. If the test fails, bAbortIfActivationTestFailed set to true aborts this selection; otherwise, the row is skipped.
• Extension and NativeExtension: provide Blueprint and C++ extension data for the row. Override CanSelectedComboDefinition to add custom selection rules. The default implementation adds no extra restrictions.

When several rows match, the first row encountered during table traversal wins; the row structure has no separate priority field. Use mutually exclusive event tags or tag queries to distinguish branches, rather than relying on the DataTable’s displayed row order. An opener row can use MinComboStep = 0, but non-zero rows can also pass the step filter at zero, so use event or tag conditions to keep them from matching first.

Networking and debugging

The Combo Ability uses local prediction and only performs row selection for a locally controlled character. ComboStep is replicated by the combat component. Direct updates notify the authority or owning client as appropriate; direct updates on simulated proxies are ignored. Use the component callback or delegate to react to step changes.

Gameplay Debugger displays the current ComboStep and ComboDefinitionTable. When no row is selected, check that the combat entity returns a table, the row’s step and event/tag conditions match, the Ability Spec is granted with a matching Source Object, and optional activation tests or Blueprint selection rules do not reject the row.