<180> Events and transitions
<181> The <l1>LimboHSM</l> comes with an <b>event system</b> that helps to <b>decouple transitions</b> from the state implementations. A transition is associated with a specific event, a starting state, and a destination state, and it is performed automatically when such an event is dispatched.
<182> To register a transition and associate it with a specific event, you can use the <l1>LimboHSM.add_transition</l> method:
<183> In this example, we’re registering a transition from the <1/> to the <2/> when the <3/> event is dispatched.
<184> A transition can be also associated with no particular starting state:
<185> <b>Events are dispatched</b> with the <l1>LimboState.dispatch</l> method. It’s important to note that this method can be called from anywhere in the state machine hierarchy and outside of it. Events are <b>propagated from the leaf to the root</b> state. This means that if an event is consumed by a state, it won’t be propagated to its parent states.
<186> States can also define <b>event handlers</b>, which are methods that react to specific events. These event handlers typically don’t result in a state transition; they are simply a mechanism for states to react to particular events. You can use the <l1>LimboState.add_event_handler</l> method to register event handlers in your states:
<187> If the event handler returns <1/>, the event will be considered as consumed, and it won’t propagate further or result in a state transition.
<188> State anatomy
<189> Using behavior trees with state machines
<190> The <l1>BTState</l> is a specialized state node in <l2>LimboHSM</l> that can host a behavior tree. When a <l3>BTState</l> is active, it executes the hosted behavior tree each frame, effectively using the behavior tree as its implementation.
<191> This allows you to combine the power of behavior trees with the structure and control of state machines. Behavior trees are excellent for defining complex, hierarchical behaviors, while state machines are great for managing the flow and transitions between different behaviors.
<192> Once the <l1>LimboHSM</l> has been created, a <l2>BTState</l> can be created for a given <l3>LimboHSM</l>:
<193> Single-file state machine setup
<194> In certain scenarios, such as prototyping or during game jams, it’s practical to keep the state machine code in a single file. For such cases, <l1>LimboHSM</l> <b>supports delegation</b> and provides <b>chained methods</b> for easier setup. Let’s illustrate this with a practical code example:
<195> Important classes
<196> There are a lot of classes introduced in LimboAI. Here is a list of the most important ones you should know about:
<197> BTTask
<198> <b>Inherits:</b> <l1>BT</l>
<199> <b>Inherited By:</b> <l1>BTAction</l>, <l2>BTComment</l>, <l3>BTComposite</l>, <l4>BTCondition</l>, <l5>BTDecorator</l>
<200> Base class for all <l1>BehaviorTree</l> tasks.
<201> Description
<202> Base class for all <l1>BehaviorTree</l> tasks. A task is a basic building block in a <l2>BehaviorTree</l> that represents a specific behavior or control flow. Tasks are used to create complex behaviors by combining and nesting them in a hierarchy.
<203> A task can be one of the following types: action, condition, composite, or decorator. Each type of task has its own corresponding subclass: <l1>BTAction</l>, <l2>BTCondition</l>, <l3>BTDecorator</l>, <l4>BTComposite</l>.
<204> Tasks perform their work and return their status using the <l1>_tick</l> method. Status values are defined in <l2>Status</l>. Tasks can be initialized using the <l3>_setup</l> method. See also <l4>_enter</l> & <l5>_exit</l>.
<205> <b>Note:</b> Do not extend <b>BTTask</b> directly for your own tasks. Instead, extend one of the subtypes mentioned above.
<206> Properties
<207> <l1>agent</l>
<208> <l1>Blackboard</l>
<209> <l1>blackboard</l>
<210> <l1>custom_name</l>
<211> <l1>elapsed_time</l>
<212> <l1>scene_root</l>
<213> <l1>Status</l>
<214> <l1>status</l>
<215> Methods
<216> <l1>_enter</l>() <2/>
<217> <l1>_exit</l>() <2/>
<218> <l1>_generate_name</l>() <2/> <3/>
<219> <l1>_get_configuration_warnings</l>() <2/> <3/>
<220> <l1>_setup</l>() <2/>
<221> <l1>_tick</l>(delta: <2/>) <3/>
<222> <l1>abort</l>()
<223> <l1>add_child</l>(task: <l2>BTTask</l>)
<224> <l1>add_child_at_index</l>(task: <l2>BTTask</l>, idx: <3/>)
<225> <l1>BTTask</l>
<226> <l1>clone</l>() <2/>
<227> <l1>BehaviorTree</l>
<228> <l1>editor_get_behavior_tree</l>()
<229> <l1>execute</l>(delta: <2/>)
<230> <l1>get_child</l>(idx: <2/>) <3/>
<231> <l1>get_child_count</l>() <2/>
<232> <l1>get_child_count_excluding_comments</l>() <2/>
<233> <l1>get_index</l>() <2/>
<234> <l1>get_parent</l>() <2/>
<235> <l1>get_root</l>() <2/>
<236> <l1>get_task_name</l>()
<237> <l1>has_child</l>(task: <l2>BTTask</l>) <3/>
<238> <l1>initialize</l>(agent: <2/>, blackboard: <l3>Blackboard</l>, scene_root: <4/>)
<239> <l1>is_descendant_of</l>(task: <l2>BTTask</l>) <3/>
<240> <l1>is_root</l>() <2/>
<241> <l1>next_sibling</l>() <2/>
<242> <l1>print_tree</l>(initial_tabs: <2/> = 0)
<243> <l1>remove_child</l>(task: <l2>BTTask</l>)
<244> <l1>remove_child_at_index</l>(idx: <2/>)
<245> Property Descriptions
<246> <1/> <b>agent</b> <l2>🔗</l>
<247> <1/> <b>set_agent</b>(value: <2/>)
<248> <1/> <b>get_agent</b>()
<249> The agent is the contextual object for the <l1>BehaviorTree</l> instance. This is usually the parent of the <l2>BTPlayer</l> node that utilizes the <l3>BehaviorTree</l> resource.
<250> <l1>Blackboard</l> <b>blackboard</b> <l2>🔗</l>
<251> <l1>Blackboard</l> <b>get_blackboard</b>()
<252> Provides access to the <l1>Blackboard</l>. Blackboard is used to share data among tasks of the associated <l2>BehaviorTree</l>.
<253> See <l1>Blackboard</l> for additional info.
<254> <1/> <b>custom_name</b> = <2/> <l3>🔗</l>
<255> <1/> <b>set_custom_name</b>(value: <2/>)
<256> <1/> <b>get_custom_name</b>()
<257> User-provided name for the task. If not empty, it is used by the editor to represent the task. See <l1>get_task_name</l>.
<258> <1/> <b>elapsed_time</b> <l2>🔗</l>
<259> <1/> <b>get_elapsed_time</b>()
<260> Elapsed time since the task was “entered”. See <l1>_enter</l>.
<261> Returns <1/> when task is not <2/>.
<262> <1/> <b>scene_root</b> <l2>🔗</l>
<263> <1/> <b>get_scene_root</b>()
<264> Root node of the scene the behavior tree is used in (e.g., the owner of the <l1>BTPlayer</l> node). Can be uses to retrieve <2/> references.
<265> <b>Example:</b>
<266> <l1>Status</l> <b>status</b> <l2>🔗</l>
<267> <l1>Status</l> <b>get_status</b>()
<268> Last execution <l1>Status</l> returned by <l2>_tick</l>.
<269> Method Descriptions
<270> <1/> <b>_enter</b>() <2/> <l3>🔗</l>
<271> Called when task is “entered”, i.e. when task is executed while not having a <1/> <l2>status</l>.
<272> It is called before <l1>_tick</l> in the execution order. This method is used when preparation is needed before main work begins, usually when it takes more than one tick to finish the task. See also <l2>execute</l>.
<273> <1/> <b>_exit</b>() <2/> <l3>🔗</l>
<274> Called when task is “exited”, i.e. after <l1>_tick</l> returns <2/> or <3/> status. See also <l4>execute</l>.
<275> <1/> <b>_generate_name</b>() <2/> <3/> <l4>🔗</l>
<276> Called to generate a display name for the task unless <l1>custom_name</l> is set. See <l2>get_task_name</l>.
<277> <1/> <b>_get_configuration_warnings</b>() <2/> <3/> <l4>🔗</l>
<278> The string returned by this method is shown as a warning message in the behavior tree editor. Any task script that overrides this method must include <1/> annotation at the top of the file.
<279> <1/> <b>_setup</b>() <2/> <l3>🔗</l>
<280> Called to initialize a task during initialization step. It is called only once before the task’s first execution tick. This method allows you to set up any necessary state or configurations for the task before it begins executing.
<281> <l1>Status</l> <b>_tick</b>(delta: <2/>) <3/> <l4>🔗</l>
<282> Called when task is “ticked”, i.e. executed by <l1>BTPlayer</l> or <l2>BTState</l> during an update.
<283> Returns execution status as defined in <l1>Status</l>.
<284> <b>Note:</b> Tasks perform their main function by implementing this method.
<285> <1/> <b>abort</b>() <l2>🔗</l>
<286> Resets the task and its children recursively. If a task is in the <1/> state, it is exited and its status is reset to <2/>.
<287> <1/> <b>add_child</b>(task: <l2>BTTask</l>) <l3>🔗</l>
<288> Adds a child task. The <1/> is placed at the end of the children list.
<289> <1/> <b>add_child_at_index</b>(task: <l2>BTTask</l>, idx: <3/>) <l4>🔗</l>
<290> Adds a child task. The <1/> is placed at <2/> position in the children list.
<291> <l1>BTTask</l> <b>clone</b>() <2/> <l3>🔗</l>
<292> Duplicates the task and its children, copying the exported members. Sub-resources are shared for efficiency, except for <l1>BBParam</l> subtypes, which are always copied. Used by the editor to instantiate <l2>BehaviorTree</l> and copy-paste tasks.
<293> <l1>BehaviorTree</l> <b>editor_get_behavior_tree</b>() <l2>🔗</l>
<294> Returns the behavior tree that owns this task. This is only available in the editor.
<295> <l1>Status</l> <b>execute</b>(delta: <2/>) <l3>🔗</l>
<296> Performs task’s execution. The execution follows a specific sequence:
<297> If task’s current <l1>status</l> is not <2/>, the <l3>_enter</l> method is called first.
<298> Next, the <l1>_tick</l> method is called next to perform the task’s work.
<299> If the <l1>_tick</l> method returns <2/> or <3/> status, the <l4>_exit</l> method will be called next as part of the execution cleanup.
<300> <l1>BTTask</l> <b>get_child</b>(idx: <2/>) <3/> <l4>🔗</l>
<301> Returns a child task by specifying its index.
<302> <1/> <b>get_child_count</b>() <2/> <l3>🔗</l>
<303> Returns the number of child tasks.
<304> <1/> <b>get_child_count_excluding_comments</b>() <2/> <l3>🔗</l>
<305> Returns the number of child tasks not counting <l1>BTComment</l> tasks.
<306> <1/> <b>get_index</b>() <2/> <l3>🔗</l>
<307> Returns the task’s position in the behavior tree branch. Returns <1/> if the task doesn’t belong to a task tree, i.e. doesn’t have a parent.
<308> <l1>BTTask</l> <b>get_parent</b>() <2/> <l3>🔗</l>
<309> Returns the task’s parent.
<310> <l1>BTTask</l> <b>get_root</b>() <2/> <l3>🔗</l>
<311> Returns the root task of the behavior tree.
<312> <1/> <b>get_task_name</b>() <l2>🔗</l>
<313> The string returned by this method is used to represent the task in the editor.
<314> Method <l1>_generate_name</l> is called to generate a display name for the task unless <l2>custom_name</l> is set.
<315> <1/> <b>has_child</b>(task: <l2>BTTask</l>) <3/> <l4>🔗</l>
<316> Returns <1/> if <2/> is a child of this task.
<317> <1/> <b>initialize</b>(agent: <2/>, blackboard: <l3>Blackboard</l>, scene_root: <4/>) <l5>🔗</l>
<318> Initilizes the task. Assigns <l1>agent</l> and <l2>blackboard</l>, and calls <l3>_setup</l> for the task and its children.
<319> The method is called recursively for each child task. <1/> should be the root node of the scene the behavior tree is used in (e.g., the owner of the node that contains the behavior tree).
<320> <1/> <b>is_descendant_of</b>(task: <l2>BTTask</l>) <3/> <l4>🔗</l>
<321> Returns <1/> if this task is a descendant of <2/>. In other words, this task must be a child of <3/> or one of its children or grandchildren.