Skip to content
Back to wiki

Combat Attack/Defense

This article briefly explains the combat attack/defense process in the General Combat System (GCS), helping you to better understand the workflow of GCS.

A

Author

Author

Created: Nov 24, 2025Updated: Oct 12, 2026

Table of contents

Overview

This article follows an attack request through hit handling, then explains how the target resolves attribute changes and produces a combat result in the Generic Combat System (GCS).

Attack Process

A player, AI, or other Actor connected to the relevant Ability and combat components can initiate an attack. Melee and bullet attacks use different request and hit paths, then use attack definitions to prepare hit effects.

Melee Attacks

  1. The Ability starts the attack action and prepares a UGCS_AttackRequest_Melee, which contains an attack-definition row and the Trace tags to control.
  2. GCS_ANS_AttackTrace stores this request on the animation. It is not a runtime Trace executor.
  3. Ability or project logic calls AddMeleeRequest and RemoveMeleeRequest on UGCS_AbilityTask_CollisionTrace during the attack window. The task starts and stops matching Traces through UGCS_TraceSystemComponent, then reports hit targets and hit data to the Ability.
  4. The Ability or project logic uses FGCS_AttackDefinition to decide which Gameplay Effects to apply to the hit target.

Bullet Attacks

  1. UGCS_AttackRequest_Bullet uses a BulletDefinition row to configure the bullet and its associated attack definition. It can also configure the launch/aim source, sockets, offset, and an optional targeting preset.
  2. The Ability's GameplayEvent path places the BulletRequest in the event data's OptionalObject. UGCS_AbilityTask_BulletTrace listens for the configured event tag, reads the request, and asks UGCS_BulletSystemComponent to spawn the bullet.
  3. BulletSystemComponent prepares hit effects from the AttackDefinition referenced by the BulletDefinition. The server authoritatively applies Gameplay Effects after a hit.
Local bullet prediction covers only the trajectory and visual presentation of the first player-initiated batch. Predicted bullets do not apply Gameplay Effects. The server handles actual hits and effect resolution; chain and emitter bullets are also spawned by the server.

Adjusting Gameplay Effects

FGCS_AttackDefinition can provide target Gameplay Effects or an EffectContainer, attack tags, and SetByCaller magnitudes. The attack path can further adjust the effect spec before application according to game rules—for example, passing attack parameters into calculations, adding dynamic tags, or changing a value based on bullet travel distance.

Damage Calculation

GCS provides the common wiring between attack requests, hit effects, and result handling. Project Gameplay Effects and Damage Execution Calculations define the specific damage, resistance, and attribute changes.

Defense Process

After the target receives and executes a Gameplay Effect, the attribute system forwards the PostGameplayEffectExecute callback to that entity's configured CombatFlow. CombatFlow builds and registers an attack result from the attribute changes; the combat system component then replicates the result and passes it to configured AttackResultProcessors.

For details on callbacks, result fields, and processor execution policies, see Combat Flow.

Summary

GCS separates attack requests, melee Traces, bullet spawning, Gameplay Effect resolution, and attack-result processing into configurable stages. Melee and bullet attacks take different hit paths; attribute handling and feedback after a hit converge on the target's CombatFlow.