unreal.PoseSearchInteractionAvailability

class unreal.PoseSearchInteractionAvailability(database: PoseSearchDatabase = Ellipsis, tag: Name = 'None', roles_filter: None = [], broad_phase_radius: float = 0.0, broad_phase_radius_increment_on_interaction: float = 0.0, disable_collisions: bool = False, tick_priority: int = 0)

Bases: StructBase

input for MotionMatchInteraction_Pure: it declares that the associated character (“AnimContext” that could be an AnimInstance or an AnimNextCharacterComponent) is willing to partecipate in an interaction described by a UMultiAnimAsset (derived by UPoseSearchInteractionAsset) contained in the UPoseSearchDatabase Database with one of the roles in RolesFilter (if empty ANY of the Database roles can be taken) the MotionMatchInteraction_Pure will ultimately setup a motion matching query using looking for the pose history “PoseHistoryName” to gather bone and trajectory positions for this character for an interaction to be valid, the query needs to find all the other interacting characters within BroadPhaseRadius, and reach a maximum cost of MaxCost Experimental, this feature might be removed without warning, not for production use

C++ Source:

  • Plugin: PoseSearch

  • Module: PoseSearch

  • File: PoseSearchInteractionAvailability.h

Editor Properties: (see get_editor_property/set_editor_property)

  • broad_phase_radius (float): [Read-Write] the associated character to this FPoseSearchInteractionAvailability will partecipate in an interaction only if all the necessary roles gest assigned to character within BroadPhaseRadius centimeters

  • broad_phase_radius_increment_on_interaction (float): [Read-Write] during interaction the BroadPhaseRadius will be incremented by BroadPhaseRadiusIncrementOnInteraction to create geometrical histeresys, where it’s harder for actors to get into interaction rather than staying in interaction

  • database (PoseSearchDatabase): [Read-Write] Database describing the interaction. It’ll contains multi character UMultiAnimAsset and a schema with multiple skeletons with associated roles

  • disable_collisions (bool): [Read-Write] if true, the system will disable collsions between interacting characters

  • roles_filter (Array[Name]): [Read-Write] roles the character is willing to take to partecipate in this interaction. If empty ANY of the Database roles can be taken

  • tag (Name): [Read-Write] in case this availability Database is valid (not null), Tag (if IsTagValid()) is used to flag the Database with a specific name. Different availabilities can share the same Tag. in case this availability Database is NOT valid, we use the valid Tag to figure out all the possible databases that can be assigned to this availability from all the published availabilities. The reason behind Tag is, for example, to be able to have NPCs been able to interact with a main character (MC), without the MC having a direct dependency to the database used for the interaction allowing those NPCs to be contextually loaded/unloaded, streamed in/out, with the obvious advantages for the the memory managment of the “payload” database. Another reason for Tag, is to facilitate the setup of interactions, where the MC have to publish only one availability with its own assigned Role (in RolesFilter) automatically contextually resolved in multiple different types of possible databases: it could be MC-NPC, MC-Vehicle, MC-Whatever

  • tick_priority (int32): [Read-Write] the Actor with the higher TickPriority of any Availability request will be elected as the MainActor of the interaction island (containing all the actors that could interact with each other) the main Actor will tick first and all the other interacting actors will tick after in a concurrently from each other. TickPriority is useful if your setup is already enforcing tick dependency between actors, and the motion matching interaction system needs to play nicely with them.

property broad_phase_radius: float

[Read-Write] the associated character to this FPoseSearchInteractionAvailability will partecipate in an interaction only if all the necessary roles gest assigned to character within BroadPhaseRadius centimeters

Type:

(float)

property broad_phase_radius_increment_on_interaction: float

[Read-Write] during interaction the BroadPhaseRadius will be incremented by BroadPhaseRadiusIncrementOnInteraction to create geometrical histeresys, where it’s harder for actors to get into interaction rather than staying in interaction

Type:

(float)

property database: PoseSearchDatabase

[Read-Write] Database describing the interaction. It’ll contains multi character UMultiAnimAsset and a schema with multiple skeletons with associated roles

Type:

(PoseSearchDatabase)

property disable_collisions: bool

[Read-Write] if true, the system will disable collsions between interacting characters

Type:

(bool)

property roles_filter: None

[Read-Write] roles the character is willing to take to partecipate in this interaction. If empty ANY of the Database roles can be taken

Type:

(Array[Name])

property tag: Name

[Read-Write] in case this availability Database is valid (not null), Tag (if IsTagValid()) is used to flag the Database with a specific name. Different availabilities can share the same Tag. in case this availability Database is NOT valid, we use the valid Tag to figure out all the possible databases that can be assigned to this availability from all the published availabilities. The reason behind Tag is, for example, to be able to have NPCs been able to interact with a main character (MC), without the MC having a direct dependency to the database used for the interaction allowing those NPCs to be contextually loaded/unloaded, streamed in/out, with the obvious advantages for the the memory managment of the “payload” database. Another reason for Tag, is to facilitate the setup of interactions, where the MC have to publish only one availability with its own assigned Role (in RolesFilter) automatically contextually resolved in multiple different types of possible databases: it could be MC-NPC, MC-Vehicle, MC-Whatever

Type:

(Name)

property tick_priority: int

[Read-Write] the Actor with the higher TickPriority of any Availability request will be elected as the MainActor of the interaction island (containing all the actors that could interact with each other) the main Actor will tick first and all the other interacting actors will tick after in a concurrently from each other. TickPriority is useful if your setup is already enforcing tick dependency between actors, and the motion matching interaction system needs to play nicely with them.

Type:

(int32)