Quick Start
By the end you will walk up to a chest, press the interact key, and have the chest react - in singleplayer and multiplayer - using only CrimsonInteraction and CrimsonCommon. You author two small abilities along the way (a handler and an interact ability); they are yours to keep and extend.
UAbilitySystemComponent and you can grant abilities on the server. You have one IA_Interact Input Action mapped in an Input Mapping Context (leave its Triggers list empty - important later for holds). How-To: Get the Building Blocks covers every node and getter used below.ACrimsonInteractableActor. If your project can use it, grant UCrimsonCoreGameplayAbility_Interact to your pawn and skip to step 9's verify. Everyone else: the steps below build the same thing.1. Enable the plugin
Enable CrimsonInteraction. CrimsonCommon comes in as a dependency.
2. Define your gameplay tags
The plugin hardcodes no tags - you own them. You need one event tag that fires interactions, and two input-forwarding tags. The string Ability.Interaction.Activate matches CrimsonCore's convention (keeps content portable), but any string works as long as sender and trigger agree.
3. Author the handler ability
This is the ability an option grants via InteractionAbilityToGrant. It triggers on your activate event, reads the interactable from the payload, does its work, and ends. This one calls NotifyInteractionSuccess on the target so any interactable can react - a good generic default.
LocalPredicted handlers run on the owning client and the server. Anything that mutates authoritative state (loot, doors, quest flags) must be guarded with HasAuthority() on the receiving side.4. Make the chest interactable
Implement ICrimsonInteractableTarget (CrimsonCommon) on the chest and return one instant option pointing at your handler. Then react to success: the handler calls NotifyInteractionSuccess, so override that to open the chest (guard authoritative changes with HasAuthority).
Visibility channel - any default static mesh qualifies. Nothing detects it yet; that is the next step.5. Author the interact ability shell
One persistent, per-actor, locally-predicted ability owns the whole loop. It must run on both the server (to grant nearby options' abilities) and the owning client (to scan and take input), so it activates itself as soon as it is granted.
OnAvatarSet, so activate from the pawn instead: after the ability is granted, Event BeginPlay -> Is Locally Controlled -> Get Ability System Component -> Try Activate Ability by Class (GA_Interact). A Local Predicted activation also activates the server instance - step 9 wires this.6. Start the scan and grant tasks
In ActivateAbility: the server instance spins up Grant Abilities For Nearby Interactors (without it, the scan's CanActivateAbility filter rejects every option - the number-one setup bug); the owning client instance spins up a scan task and listens for the input events from step 7.
bShowDebug = true on the scan call and the forward trace will draw once the ability activates (step 9). Top-down game? Use Wait For Interactable Targets Top Down Trace instead - see How-To: Choose a Scan Strategy.7. Forward input as gameplay events
Keep input on the pawn (where Enhanced Input already lives) and forward presses to the ability as gameplay events - no input-component plumbing inside the ability, and the pattern is identical in Blueprint and C++.
Completed/Canceled while the key is still physically held - that breaks hold interactions later. If the IA must carry a trigger, use UInputTriggerCrimsonPressAndHold (CrimsonInput plugin - optional).8. Fire the press
On press, take the focused option (CurrentOptions[0]) and fire it with Trigger Interaction Option (UCrimsonInteractionStatics). It back-fills the target ASC and spec handle if the server grant has not resolved locally yet, lets the target customize the event payload, and triggers the granted ability by replicated handle - predicted on the client, authoritative on the server. If the spec has not replicated yet it returns false and the press is safely ignored.
9. Grant it and play
Grant GA_Interact on the server (grants are authority-only), then play. If you used the Blueprint shell, also activate it from the owning client (the note in step 5).
NotifyInteractionSuccess fires on the chest and it reacts. Test as a client too (Net Mode: Play As Client): the very first press right after entering range can be ignored while the grant replicates; that is by design. If nothing happens, check the two classic causes: the grant task is not running on the server instance, or the handler fails CanActivateAbility (cost/cooldown/tag block) - see Concept: Scan, Gather, Filter, Broadcast.