Concept: Two Activation Methods
An option can fire an ability on the avatar's ASC or on the target's own ASC. The fields you set decide which.
| Method | Set on the option | When the player interacts |
|---|---|---|
| 1 - grant on avatar | InteractionAbilityToGrant | The server granter gives this ability to the avatar's ASC; pressing interact triggers it by replicated spec handle via your activate event tag. Good for generic verbs (pick up, examine). |
| 2 - activate on target | TargetAbilitySystem + TargetInteractionAbilityHandle | The press triggers an ability already living on the target's own ASC. Good for complex objects that own their interaction logic (a turret, an NPC). |
Client timing for Method 1
Method 1 depends on the server granting + replicating the spec before the press. On a client there is a brief window where the option is visible but the grant has not arrived;
TriggerInteractionOption resolves the spec just-in-time from the avatar's ASC, and if it still is not ready it returns false (logged verbose) rather than firing nothing.Replication rules baked into the design
The granted spec's
SourceObject is the avatar actor because a spec only replicates if its source is net-addressable (a transient task has no NetGUID). Likewise, never carry an FGameplayAbilitySpecHandle across the client->server boundary in an event payload - handles are machine-local. Pass ability classes (net-addressable) and re-resolve with FindAbilitySpecFromClass on the far side; that is exactly what the channel launch does with OptionalObject2.The action phase (InteractionActionAbility) is separate from both: it is the timed/channelled ability run on the avatar for hold and duration interactions. The grant task pre-grants it (alongside the instant handler) precisely so it can be triggered by replicated handle - predicted client-side, authoritative server-side - instead of the authority-only GiveAbilityAndActivateOnce.