Core features
GenericCombatSystem is not a catalog of moves. It is a combat settlement path stacked on GenericGameplayAbilities: an ability or animation window issues an attack request, a Trace or bullet produces a hit, a Gameplay Effect callback becomes an attack result, and Combat Flow processors decide hit reaction, cues, or project rules. A sword swing and a rifle shot share the same result container; they differ only in how the hit is produced.
Six capability lines
Question | Read first |
|---|---|
What input, abilities, and combat each own, and what the project still writes | System boundaries and extension scope |
CombatFlow, the AttackResult FastArray, processor policies | Combat flow and attack results |
Attack definitions, melee/bullet requests, Effect Context payload | Attack definitions and requests |
Trace component, subsystem sweeps, animation hit windows | Traces and hit windows |
Three-layer bullet state, prediction limits, penetration and chains | Bullet runtime |
Lock-on, candidate lists, team filters | Targeting and teams |
Combo selection, weapon actors, the combat-entity contract | Combos, weapons, and combat entity |
Full field lists belong in the Parameter Reference. To change a processor, interface, or bullet instance, open the Extension Guide.
Request to processor
A visible attack usually finishes this path:
UGCS_CombatAbility subclasses UGGA_GameplayAbility and reads the combat component and combat-entity interface from ActorInfo. Melee uses HandleCollisionTraces and AddMeleeRequest for the window; ranged uses UGCS_BulletSystemComponent::RequestSpawnBullet to spawn a batch. After a hit, the function library writes the attack-definition handle into FGCS_ContextPayload_Combat and applies the effect. The target's Combat Flow consumes GGA's FGGA_GameplayEffectModCallbackData, builds an FGCS_AttackResult in HandleGameplayEffectExecute, and RegisterAttackResult appends it to the replicated FastArray. When the entry arrives, HandleAttackResult runs each processor under Default, LocalPredicted, or ServerOnly.
The base HandleGameplayEffectExecute is empty, and the plugin does not call it automatically. A project must forward GGA PostExecute into the Flow and register the result in a subclass, or processors never run. First wiring is in Register the First Attack Result. The death processor is also an empty placeholder; death presentation stays in the project.
What to read next
For a first integration, start with System boundaries and extension scope, then the Quick Start or Observe the companion project. If you already know you need melee, ranged, or combos, open that capability page and follow its links to a how-to.
System boundaries and extension scope
GCS solves “GAS and abilities already run, but melee windows, bullets, lock-on, and hit reaction still live in character Blueprints.” It turns attack requests, hits, attack results, and processors into components and data tables. Damage formulas, death presentation, animation assets, and UI stay in the project.
Related pages: setup in Quick Start, component wiring in Attach combat components.
Product delivery versus plugin modules
The Fab product ships Generic Input System (GIPS), GenericGameplayAbilities (GGA), and GenericCombatSystem together. Buyers compose “input → ability → hit settlement” from those three layers. The companion project is the place to watch a finished level; the plugin package itself sets CanContainContent to false.
GCS has one Runtime module, GenericCombatSystem. The .uplugin hard-depends on GGA plus the engine plugins EnhancedInput, GameplayAbilities, ModularGameplay, TargetingSystem, StateTree, GameplayStateTree, and MotionWarping. GIPS is part of the product bundle, not a dependency on this plugin's .uplugin list. StateTree and MotionWarping appear as dependencies; GCS runtime source does not call their APIs.
Who owns each layer
Layer | Owner | Typical entry |
|---|---|---|
Input buffering, key mapping, tagged action windows | GIPS (included with the product) | Input setup and buffer windows |
Ability grants, attributes, Effect Containers, tag exclusion | GGA | |
Attack requests, Trace / bullet hits, attack results, lock-on and teams | GCS | |
The combat ability base UGCS_CombatAbility subclasses UGGA_GameplayAbility. Combat Flow consumes GGA's FGGA_GameplayEffectModCallbackData. Point Ability System Globals at UGGA_AbilitySystemGlobals so Effect Context payloads and that callback allocate as expected.
How a press becomes a combat ability belongs to GIPS or the project's own Enhanced Input bind. GCS does not wrap Input Actions or Mapping Contexts.
What the plugin ships, what the project writes
GCS ships UAS_Poise (Poise / MaxPoise / PoiseRecover) as an optional replicated poise set. The project may grant it or use its own AttributeSet. The plugin does not impose a damage formula.
The project still owns:
- How damage numbers come from SetByCaller, captures, or an Execution.
- Death:
UGCS_AttackResultProcessor_Deathis an empty default; realStartDeath/FinishDeathlive on the combat entity or a project processor. - Montage assets, hit-stall resources, HUD, and floating damage.
- How rows in the
UGCS_AbilityActionSetSettingsDataAsset map to montages. That asset is not Developer Settings.
The developer settings class is UGCS_DeveloperSettings. The two fields you will touch most are CharacterMeshLookupTag (component tag used to find the main mesh) and bDisableAffiliationCheck, which exists only for debugging.
A concrete scenario
A third-person character buffers light attacks through GIPS. GGA grants a melee AbilitySet and health. GCS adds Combat, Trace, Targeting, and Team components on the pawn. Combat Flow holds a LocalPredicted cue processor and a Default hit-reaction processor. After a slash connects, the GGA effect changes target health; GCS folds that same execute into an Attack Result so the client plays the cue immediately and the server replicates the result to SimulatedProxies. Rifle traces and melee sweeps enter the same Flow. Damage curves, death ragdoll, and the health bar stay in project Blueprints.