Author a Ranged Attack

Author a Ranged Attack

This page builds the smallest ranged shot: one bullet definition, one bullet request, and an ability that calls WaitForBulletEvent, reads UGCS_AttackRequest_Bullet from OptionalObject, and hands it to the bullet component. Predicted bullets own trajectory and presentation only. Gameplay Effects, chain bullets, and emitter follow-ups happen on the server.

Related pages: if the Flow still has no Result, start with Register the First Attack Result. The bullet contract is in Bullet Runtime; request fields are in Attack Definitions and Requests.

Prerequisites

1. You attached Combat and Bullet components from Attach Combat Components. Hit detection also needs the Trace component. The target Flow already registers a Result from the attribute callback, as in Register the First Attack Result.
2. The authority already called InitializeAbilitySystem.
3. You have one FGCS_AttackDefinition row whose TargetEffectClass changes a target attribute.
4. You have a bullet actor that implements IGCS_BulletInterface. Inheriting AGCS_BulletInstance or AGCS_SphereBulletInstance is enough.

1. Author the bullet definition

Create a Data Table with row type GCS Bullet Definition (FGCS_BulletDefinition):

Count, spread, and speed live on the definition, not the request. Leave chain and emitter empty on this page; those spawn on the server only.

2. Fill the bullet request

Create UGCS_AttackRequest_Bullet:

PawnForward or CameraTowardsFocus is enough here. Custom must override GetTargetingTransform. A weapon origin can also use GCS_GetTargetingStartTransform on the weapon interface.

3. Hand the request to the Task through an Event

In the ranged ability, call WaitForBulletEvent:

1. Set the Gameplay Event tag to listen for.
2. bInUseScopedPredictionWindow defaults to true and wraps a local player shot in FScopedPredictionWindow.
3. When the event fires, the Task reads UGCS_AttackRequest_Bullet from EventData.OptionalObject and passes it to UGCS_BulletSystemComponent.
4. Success broadcasts OnBulletSpawned; failure broadcasts OnBulletSpawnFailed.

You can store the same request on GCS_ANS_BulletTrace and fire a Gameplay Event with that OptionalObject from the window. The notify is not a runtime launcher either.

ValidateAttackRequest is overridable. The default only checks that the request is valid and BulletDefinitionHandle resolves a row. Fire rate, ammo, and resource legality stay with the project. Do not assume the component rejects those shots.

Expected result

After a locally controlled player fires, the client shows a trail immediately and the Debugger Bullet section lists a predicted Entry. After the server confirms, the Entry is confirmed and a hit applies GE. The predicted client bullet does not change attributes.

Verify

1. Open the Combat category of Gameplay Debugger and inspect Bullet after one shot: entries, instances, and Pending / Confirmed / LocalPredicted counts.
2. The predicted bullet has a trail and FX; target attributes do not change.
3. The server window shows the same Entry and an Attack Result after the hit.
4. If you configured chain or emitter, follow-up bullets appear only on the server. The client does not spawn its own batch.
5. Set LogGCS_Bullet to Verbose to see spawn, confirm, or deny.

Common failures

Next

After the ranged loop works, continue with Configure Combo and Weapon. Prediction that disagrees with authority: Debugging and Troubleshooting.