Interaction Validation
EDInteractionSystem now includes a dedicated API for special conditions validation.
This API is designed to let developers validate interactions in a reusable way for:
- normal actor interactables
- foliage / instanced mesh interactables
- C++
- Blueprint
Main pieces
Validation context
FEDInteractionValidationContext contains the runtime data that validators receive, including:
- interactable tag
- interactable actor
- interactable component
- instigator controller
- instigator pawn
- whether the target is foliage
- foliage instance component / transform / location
- interaction method
- foliage config data when available
Validation result
FEDInteractionValidationResult is the mutable result object passed through the validation pipeline.
It includes:
bAllowInteractionDenyReasonFailureMessage
Validation object
UEDInteractionConditionValidator is the reusable validation object.
You can:
- create Blueprint subclasses
- create C++ subclasses
- assign them globally on the player interaction component
- assign them inline on an interactable component
- assign them by class on foliage entries in Project Settings
Validation order
When the server checks special conditions, the pipeline is:
UEDPlayerInteractionComponent::GlobalInteractionValidatorsUEDPlayerInteractionComponent::ValidateInteractionSpecialConditions(...)- actor-specific
UEDInteractableComponent::ValidationRules - foliage-specific
FEDFoliageInteractionData::ValidationRuleClasses
The first validator that denies interaction stops the chain.
Why this API exists
This solves the previous hardcoded placeholder:
ServerSpecialConditionsNeededToInteract(...)
Instead of editing plugin internals every time, game code can now inject validation cleanly.
Typical use cases
- require a key item
- require a gameplay tag or state
- block interaction during combat
- require a specific tool for foliage harvesting
- gate interaction behind quest progression
- limit interaction to a faction/class/team