...`=链接，``/``=加粗/斜体，其余内联标签透明化。
+ - `_i18n/make_batches.py`：按首次出现顺序去重并分配稳定 uid，切成 `batches/batchNN.txt`（11 批，1451 条唯一模板）。
+ - `_i18n/trans/batchNN.json`：uid → 中文模板（全部 11 批已完成）。
+ - `_i18n/build.py`：回填重建 + 校验（标记一致性、结构对比）、页脚/面包屑/abbr title/代码注释润色、侧栏汉化徽标。
+- 关键实现坑（后续复用注意）：
+ 1. 片段回填必须用 `html.parser`，`lxml` 会把裸文本包成 `` 破坏结构。
+ 2. `
` 内含 ` ` 的“容器块”要跳过重建，否则会拍平丢失内层 ` `（280 个，已用容器检测处理）。
+ 3. 标题里的 `a.headerlink` 需在 clear() 前取出再回填，否则丢失 303 个标题锚点。
+ 4. 校验只强制 ``、``、`` 必须一致，`/` 允许额外配对。
+- 结果：`index.zh.html`（580KB），结构计数与原文件一致（section/p/li/a/code/pre/table/td 全部对齐），无英文残留（仅类名/方法名等标识符保留英文），45 处代码注释已译。
+- 术语约定：Behavior Tree→行为树、State Machine→状态机、Blackboard→黑板（类名保留）、Inherits:→继承：、Inherited By:→被继承：、Properties→属性、Method Descriptions→方法说明；所有 API/类名/节点名/文件名保留英文。
diff --git a/docs/limboai-stable/_i18n/batches/batch01.txt b/docs/limboai-stable/_i18n/batches/batch01.txt
new file mode 100644
index 0000000..6b81439
--- /dev/null
+++ b/docs/limboai-stable/_i18n/batches/batch01.txt
@@ -0,0 +1,87 @@
+<1> LimboAI Documentation
+<2> LimboAI is an open-source C++ module for Godot Engine 4 providing a combination of Behavior Trees and State Machines for crafting your game’s AI. It comes with a behavior tree editor, built-in documentation, visual debugger, and more! While it is implemented in C++, it fully supports GDScript for creating your own tasks and states. The full list of features is available on the LimboAI GitHub page.
+<3> Behavior Trees are powerful hierarchical structures used to model and control the behavior of agents in a game (e.g., characters, enemies, entities). They are designed to make it easier to create complex and highly modular behaviors for your games. To learn more about behavior trees, check out Introduction to Behavior Trees.
+<4> Hierarchical State Machines are finite state machines that allow any state to host their own sub-state machine. This allows you to tackle your AI’s state and transition complexity by breaking down one big state machine into multiple smaller ones.
+<5> Getting LimboAI
+<6> LimboAI can be used as either a C++ module or as a GDExtension shared library. There are some differences between the two. In short, GDExtension version is more convenient to use but somewhat limited in features. The module version provides better editor experience and is slightly more performant, but it requires using custom engine builds including the export templates. Whichever you choose to use, your project will stay compatible with both and you can switch from one to the other any time.
+<7> Choose the version you’d like to use. If you’re unsure, start with the GDExtension version. You can change your decision at any time - both versions are fully compatible.
+<8> Get GDExtension version
+<9> Precompiled builds are available on the official LimboAI GitHub page, and in the Asset Library.
+<10> GDExtension is the most convenient way of using the LimboAI plugin, but it comes with certain limitations:
+<11> Documentation tooltips are not available.
+<12> Handy BBParam property editor is not available in the extension due to dependencies on the engine classes that are not available in the Godot API.
+<13> 🛈 See also: What is GDExtension?
+<14> Installation instructions:
+<15> Make sure you’re using the latest stable version of the Godot editor.
+<16> Create a new project for your experiments with LimboAI.
+<17> In Godot, click AssetLib tab at the top of the screen and search for LimboAI. Download it. LimboAI plugin will be downloaded with the demo project files. Don’t mind the errors printed at this point, this is due to the extension library not being loaded just yet.
+<18> Reload your project with Project -> Reload project. There shouldn’t be any errors printed now.
+<19> In the project files, locate a scene file called showcase.tscn and run it. It’s the demo’s entry point.
+<20> Get module version
+<21> Precompiled builds are available on the official LimboAI GitHub page.
+<22> In GitHub releases, download the latest pre-compiled release build for your platform.
+<23> Download the demo project archive from the same release.
+<24> Extract the pre-compiled editor and the demo project files.
+<25> Launch the pre-compiled editor binary, import and open the demo project.
+<26> Run the project.
+<27> Important: To export your game using the module version of LimboAI, make sure to use the pre-compiled export templates included in the same GitHub release build.
+<28> Using LimboAI with C#
+<29> Here’s how you can use the module version with C# to write your tasks and states.
+<30> Locate LimboAI NuGet package files.
+<31> Each provided build comes with a GodotSharp folder, which has packages under “GodotSharp/Tools/nupkgs/”. Note down the directory path; you’ll need it in the next step.
+<32> Add a local source for NuGet packages using the following command:
+<33> Your C# project should be able to see LimboAI classes and compile.
+<34> Regarding GDExtension, I can only confirm success with the module version and C#. Unfortunately, I haven’t had any luck with the GDExtension version yet. If you’ve had success with GDExtension, please let me know via Discord or email.
+<35> Contributing
+<36> We target the latest stable version of the Godot Engine for development until a third beta or a release candidate of an upcoming Godot release becomes available. If you want to contribute to the project, please ensure that you are using the corresponding Godot version.
+<37> We follow the Godot code style guidelines. Please use <2/> to maintain consistent styling. You can install <3/> hooks for Git using <4/> to automate this process.
+<38> Please keep the minor versions backward-compatible when submitting pull requests.
+<39> We support building LimboAI as a module for the Godot Engine and as a GDExtension library. Make sure your contribution is compatible with both. Our CI workflow will verify that your changes can be compiled in both configurations.
+<40> Compiling as module of the Godot Engine
+<41> Clone the Godot Engine repository.
+<42> Switch to the latest stable tag.
+<43> Clone the LimboAI repository into the <1/> directory.
+<44> Consult the Godot Engine documentation for detailed instructions on building the engine.
+<45> Unit tests can be compiled using the <1/> build option. To execute them, run the compiled Godot binary with the <2/> command-line options.
+<46> Building C# Packages
+<47> If you want C# Support for LimboAI when building from source, follow Godot’s instructions for building from source with C# Support: Compiling with .NET. LimboAI’s classes will be included in the output from that build process.
+<48> Compiling as GDExtension library
+<49> You’ll need the SCons build tool and a C++ compiler. See also Compiling. Run <2/> to build the plugin library for your current platform.
+<50> SCons will automatically clone the <1/> repository if it doesn’t already exist in the <2/> directory.
+<51> By default, built targets are placed in the demo project: <1/>.
+<52> Check <1/> for other options and targets.
+<53> Contributing to the documentation
+<54> Online documentation is created using Sphinx. Source files are located in the <2/> directory in RST format and can be built locally with <3/>. See the Sphinx documentation for more details.
+<55> Class documentation resides in XML files within the <1/> directory. If you create a new class or modify an existing one, you can run the compiled Godot binary with the <2/> option in the root of the Godot source code to generate the missing XML files or sections within those files in the class documentation. After editing the XML files, please run the compiled editor binary with the <3/> option again to update and tidy up the XML files.
+<56> Sphinx RST files for the class documentation are generated from XML files using the Godot script <1/> and stored in the <2/> directory. This process is performed using our own script <3/>. RST files in <4/> should not be edited manually.
+<57> Introduction to Behavior Trees
+<58> 🛈 Note: Demo project includes a tutorial that provides an introduction to behavior trees through illustrative examples.
+<59> Behavior Trees (BT) are hierarchical structures used to model and control the behavior of agents in a game (e.g., characters, enemies, entities). They are designed to make it easier to create complex and highly modular behaviors for your games.
+<60> Behavior Trees are composed of tasks that represent specific actions or decision-making rules. Tasks can be broadly categorized into two main types: control tasks and leaf tasks. Control tasks determine the execution flow within the tree. They include Sequence, Selector, and Invert. Leaf tasks represent specific actions to perform, like moving or attacking, or conditions that need to be checked. The BTTask class provides the foundation for various building blocks of the Behavior Trees. Such tasks can share data using the Blackboard.
+<61> 🛈 Note: To create your own actions, extend the BTAction class.
+<62> A Behavior Tree is usually processed each frame. It is traversed from top to bottom, with the control tasks determining the control flow. Each task has a _tick method, which performs the task’s work and returns a status indicating its progress: <2/>, <3/>, or <4/>. <5/> and <6/> indicate the outcome of finished work, while <7/> status is returned when a task requires more than one tick to complete its job. These statuses determine how the tree progresses, with the <8/> status usually meaning that the tree will continue execution during the next frame.
+<63> There are four types of tasks:
+<64> Actions are leaf tasks that perform the actual work.
+<65> Examples: PlayAnimation, Wait.
+<66> Conditions are leaf tasks that conduct various checks.
+<67> Examples: CheckVar, InRange.
+<68> Composites can have one or more child tasks, and dictate the execution flow of their children.
+<69> Examples: Sequence, Selector, Parallel.
+<70> Decorators can only have a single child and they change how their child task operates.
+<71> Examples: AlwaysSucceed, Invert, TimeLimit.
+<72> Sequence is one of the core composite tasks. It executes its child tasks sequentially, from first to last, until one of them returns <2/>, or all of them result in <3/>. In other words, if any child task results in <4/>, the Sequence execution will be aborted, and the Sequence itself will return <7/>.
+<73> Selector is another essential composite task. It executes its child tasks sequentially, from first to last, until one of them returns <2/> or all of them result in <3/>. In other words, when a child task results in <4/>, it moves on to the next one until it finds the one that returns <5/>. Once a child task results in <6/>, the Selector stops and also returns <8/>. The purpose of the Selector is to find a child that succeeds.
+<74> Behavior Trees handle conditional logic using condition tasks. These tasks check for specific conditions and return either <1/> or <2/> based on the state of the agent or its environment (e.g., “IsLowOnHealth”, “IsTargetInSight”). Conditions can be used together with Sequence and Selector to craft your decision-making logic.
+<75> 🛈 Note: To create your own conditions, extend the BTCondition class.
+<76> Check out the BTTask class documentation, which provides the foundation for various building blocks of Behavior Trees.
+<77> Creating Behavior Trees
+<78> This chapter describes how to create and debug behavior trees.
+<79> Add a Behavior Tree to an agent
+<80> Follow these steps to add a behavior tree to a new or existing agent:
+<81> Make a scene file for your agent, or open an existing scene.
+<82> Add a BTPlayer node to your scene.
+<83> Select BTPlayer, and create a new behavior tree in the inspector.
+<84> Optionally, you can save the behavior tree to a file using the property’s context menu.
+<85> Click the behavior tree property to open it in the LimboAI editor.
+<86> Debugging Behavior Trees
+<87> In Godot Engine, follow to “Bottom Panel > Debugger > LimboAI” tab. With the LimboAI debugger, you can inspect any currently active behavior tree within the running project. The debugger can be detached from the main editor window, which can be particularly useful if you have a HiDPI or a secondary display.
\ No newline at end of file
diff --git a/docs/limboai-stable/_i18n/batches/batch02.txt b/docs/limboai-stable/_i18n/batches/batch02.txt
new file mode 100644
index 0000000..9a0be9a
--- /dev/null
+++ b/docs/limboai-stable/_i18n/batches/batch02.txt
@@ -0,0 +1,92 @@
+<88> Inspecting task properties and blackboard
+<89> When you click on a task in the LimboAI debugger, its properties are shown in the remote Inspector panel, including the Blackboard reference. Click the Blackboard to open it and view all variables across the full scope chain, grouped by scope. You can also edit variable values live, which can be useful for testing and debugging your game’s AI.
+<90> Creating custom tasks
+<91> By default, user tasks should be placed in the <1/> directory. You can set an alternative location for user tasks in the <2/> (To see those options, <3/> should be enabled in the Project Settings).
+<92> Each subdirectory within the user tasks directory is treated as a category. Therefore, if you create a subdirectory named “motion_and_physics,” your custom tasks in that directory will automatically be categorized under “Motion And Physics.”
+<93> When creating custom tasks, extend one of the following base classes: BTAction, BTCondition, BTDecorator, BTComposite. More on task types you can read in the Introduction to Behavior Trees.
+<94> 🛈 Note: To help you write new tasks, you can add a script template to your project using “Misc → Create script template” menu option.
+<95> Using the Blackboard is covered in Accessing the Blackboard in a Task.
+<96> Task anatomy
+<97> Example 1: A simple action
+<98> Example 2: InRange condition
+<99> Creating tasks in C#
+<100> You can use the following script template for custom tasks:
+<101> Sharing data using Blackboard
+<102> To share data between different tasks and states, we employ a feature known as the Blackboard. The Blackboard serves as a central repository where tasks and states can store and retrieve named variables, allowing for seamless data interchange. Each instance of a behavior tree or a state machine gets its own dedicated Blackboard. It has the capability to store various data types, including objects and resources.
+<103> Using the Blackboard, you can easily share data in your behavior trees, making the tasks in the behavior tree more flexible.
+<104> Accessing the Blackboard in a Task
+<105> Every BTTask has access to the Blackboard, providing a straightforward mechanism for data exchange. Here’s an example of how you can interact with the Blackboard in GDScript:
+<106> If you are accessing a variable that holds an object instance, and it is expected that the instance may be null or freed, you can do it like this:
+<107> It is recommended to suffix variable name properties with <1/>, like in the example above, which enables the inspector to provide a more convenient property editor for the variable. This editor allows you to select or add the variable to the blackboard plan, and provides a warning icon if the variable does not exist in the blackboard plan.
+<108> 🛈 Note: The variable doesn’t need to exist when you set it in code.
+<109> Editing the Blackboard Plan
+<110> The Blackboard Plan, associated with each BehaviorTree resource, dictates how the Blackboard initializes for each new instance of the BehaviorTree. BlackboardPlan resource stores default values, type information, and data bindings necessary for BehaviorTree initialization.
+<111> To add, modify, or remove variables from the Blackboard Plan, follow these steps:
+<112> Open the LimboAI editor and load the behavior tree you want to edit.
+<113> In the editor, click on the small button located inside the tab. This will open the BlackboardPlan in the Inspector.
+<114> In the Inspector, click the “Manage…” button to show the blackboard plan editor.
+<115> In the blackboard plan editor, you can add, remove, or reorder variables, and modify their data type and hint.
+<116> The hint provides additional information about the variable to the Inspector, such as minimum and maximum values for an integer variable. Learn more about property hints in the official Godot documentation.
+<117> You can specify the default values of the variables directly in the Inspector.
+<118> Overriding variables in BTPlayer
+<119> Each BTPlayer node also has a “Blackboard Plan” property, providing the ability to override values of the BehaviorTree’s blackboard variables. These overrides are specific to the BTPlayer’s scene and do not impact other scenes using the same BehaviorTree. To modify these values:
+<120> Select the BTPlayer node in the scene tree.
+<121> In the Inspector, locate the “Blackboard Plan” property.
+<122> Override the desired values to tailor the blackboard variables for the specific scene.
+<123> Task parameters
+<124> In some cases, it can be beneficial to allow behavior tree tasks to export parameters that can either be bound to a blackboard variable or specified directly by the user. For this purpose, LimboAI provides special parameter types that begin with “BB”, such as BBInt, BBBool, BBString, BBFloat, BBNode, and more. For a complete list, please refer to the BBParam class reference.
+<125> Usage example:
+<126> Connecting variables in BTs to HSMs: Variable mapping
+<127> Each BTState creates a new blackboard scope for its BehaviorTree instance. Because BehaviorTrees are reusable resources that can run in different contexts or on different agents, they do not automatically see variables defined in the HSM. At runtime, HSM variables are usually accessible inside the BT via the parent scope blackboard, but the recommended way to access them is through mapping.
+<128> Note
+<129> To learn more about scopes, see Blackboard.
+<130> When both the BehaviorTree and the HSM declare variables in their respective BlackboardPlan resources, the editor provides a Mapping section in the BlackboardPlan inspector. Mapping is the intended and recommended way to connect variables between related plans.
+<131> Key points about mapping
+<132> Mapping connects two variables so they behave as a single logical variable at runtime.
+<133> Linked variables are updated immediately in both scopes — they literally share the same state in memory (no polling or copying).
+<134> Mapping is explicit: you decide which variables the BT exposes as inputs and outputs.
+<135> Linkage is bidirectional — there is no distinction between input and output.
+<136> Mapping does not create new variables automatically — the variables must already exist in both blackboard plans before they can be linked.
+<137> Inspector workflow
+<138> Define the required variables in each BlackboardPlan (HSM plan and BT plan, for example).
+<139> Select the BTState node in the scene or a BTSubtree inside a behavior tree.
+<140> In the Inspector, select the Blackboard Plan property.
+<141> In the BlackboardPlan resource inspector, locate the Mapping section.
+<142> Create mappings by pairing variables (<1/>).
+<143> On startup the mappings are applied, and the variables are automatically linked for the running instance.
+<144> Programmatic alternative: linking variables in code
+<145> You can also link variables directly in code using Blackboard.link_var:
+<146> Best practices
+<147> Declare all BT dependencies in the BT’s BlackboardPlan instead of relying on parent scopes.
+<148> Use Mapping to explicitly declare which variables should be shared with the HSM.
+<149> Prefer the inspector-based Mapping workflow for clarity and editor support; use <1/> only when runtime or programmatic setup is required.
+<150> Avoid writing to <1/> from inside BT tasks unless you have a very specific reason and accept the coupling it introduces.
+<151> Advanced topic: Blackboard scopes
+<152> The Blackboard in LimboAI can act as a parent scope for another Blackboard. This means that if a specific variable is not found in the active scope, the system will look in the parent Blackboard to find it. This creates a “blackboard scope chain,” where each Blackboard can have its own parent scope, and there is no limit to how many blackboards can be in this chain. It’s important to note that the Blackboard doesn’t modify values in the parent scopes.
+<153> Scopes are created automatically to prevent naming collisions between contextually separate environments:
+<154> Within BTNewScope.
+<155> Under BTSubtree decorators.
+<156> With LimboState that have a non-empty blackboard plan defined.
+<157> Under LimboHSM nodes: A new scope is created at the root level, and each BTState child also receives its own separate scope.
+<158> Sharing data between several agents
+<159> The blackboard scope mechanism can also be used for sharing data between several agents. In the following example, we have a group of agents, and we want to share a common target between them:
+<160> In this example, blackboard.top() accesses the root scope of the Blackboard chain. We assign that scope to each agent in a group through code:
+<161> In conclusion, the Blackboard scope chain not only prevents naming conflicts that can occur between state machines, behavior trees, and sub-trees, but it can also be used to share data between several agents.
+<162> Debugging blackboard variables
+<163> When debugging a running project, you can inspect Blackboard variables in the remote Inspector. Click on a task in the LimboAI debugger to view its properties, then click the Blackboard reference to see all variables across the full scope chain, grouped by scope. Variables can be edited live to aid in debugging. For state machines, select a LimboState node in the Remote Scene Tree to access its Blackboard in the same way.
+<164> Accessing nodes in the scene tree
+<165> There are several ways to access nodes in the agent’s scene tree from a BTTask.
+<166> 🛈 Note: The root node of the agent’s scene tree can be accessed with the scene_root property.
+<167> With <1/> property
+<168> With <1/> property
+<169> Using blackboard plan
+<170> You can create a blackboard variable in the editor with the type <2/> and point it to the proper node in the BTPlayer blackboard plan. By default, any <4/> variable will be replaced with the node instance when the blackboard is instantiated at runtime (see BlackboardPlan.prefetch_nodepath_vars).
+<171> The property BTPlayer.prefetch_nodepath_vars should be set to <1/>.
+<172> Create State Machines
+<173> This guide will show how to set up and use a state machine using LimboHSM.
+<174> Initialization
+<175> To use the LimboHSM state machine, you first need to initialize it in your code. This is typically done in the <2/> function of your script. Here’s an example of how to do this:
+<176> In this example, we first declare the state machine and the states we want to use. Then, in the <1/> function, we add transitions between the states. Finally, we initialize the state machine and set it to active.
+<177> State example
+<178> You can define the behavior of a state in a script and attach it to the state node. Here’s an example of a state that plays an animation on an <1/> and waits for it to finish:
+<179> In this example, the <1/> method is called when the state is entered, and it plays the specified animation. The <2/> method is called every frame, and it checks if the animation is finished. If it is, it dispatches the <3/> event, which can result in a transition to the next state.
\ No newline at end of file
diff --git a/docs/limboai-stable/_i18n/batches/batch03.txt b/docs/limboai-stable/_i18n/batches/batch03.txt
new file mode 100644
index 0000000..5377f55
--- /dev/null
+++ b/docs/limboai-stable/_i18n/batches/batch03.txt
@@ -0,0 +1,142 @@
+<180> Events and transitions
+<181> The LimboHSM comes with an event system that helps to decouple transitions 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 LimboHSM.add_transition 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> Events are dispatched with the LimboState.dispatch 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 propagated from the leaf to the root 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 event handlers, 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 LimboState.add_event_handler 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 BTState is a specialized state node in LimboHSM that can host a behavior tree. When a BTState 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 LimboHSM has been created, a BTState can be created for a given LimboHSM:
+<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, LimboHSM supports delegation and provides chained methods 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> Inherits: BT
+<199> Inherited By: BTAction, BTComment, BTComposite, BTCondition, BTDecorator
+<200> Base class for all BehaviorTree tasks.
+<201> Description
+<202> Base class for all BehaviorTree tasks. A task is a basic building block in a BehaviorTree 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: BTAction, BTCondition, BTDecorator, BTComposite.
+<204> Tasks perform their work and return their status using the _tick method. Status values are defined in Status. Tasks can be initialized using the _setup method. See also _enter & _exit.
+<205> Note: Do not extend BTTask directly for your own tasks. Instead, extend one of the subtypes mentioned above.
+<206> Properties
+<207> agent
+<208> Blackboard
+<209> blackboard
+<210> custom_name
+<211> elapsed_time
+<212> scene_root
+<213> Status
+<214> status
+<215> Methods
+<216> _enter() <2/>
+<217> _exit() <2/>
+<218> _generate_name() <2/> <3/>
+<219> _get_configuration_warnings() <2/> <3/>
+<220> _setup() <2/>
+<221> _tick(delta: <2/>) <3/>
+<222> abort()
+<223> add_child(task: BTTask)
+<224> add_child_at_index(task: BTTask, idx: <3/>)
+<225> BTTask
+<226> clone() <2/>
+<227> BehaviorTree
+<228> editor_get_behavior_tree()
+<229> execute(delta: <2/>)
+<230> get_child(idx: <2/>) <3/>
+<231> get_child_count() <2/>
+<232> get_child_count_excluding_comments() <2/>
+<233> get_index() <2/>
+<234> get_parent() <2/>
+<235> get_root() <2/>
+<236> get_task_name()
+<237> has_child(task: BTTask) <3/>
+<238> initialize(agent: <2/>, blackboard: Blackboard, scene_root: <4/>)
+<239> is_descendant_of(task: BTTask) <3/>
+<240> is_root() <2/>
+<241> next_sibling() <2/>
+<242> print_tree(initial_tabs: <2/> = 0)
+<243> remove_child(task: BTTask)
+<244> remove_child_at_index(idx: <2/>)
+<245> Property Descriptions
+<246> <1/> agent 🔗
+<247> <1/> set_agent(value: <2/>)
+<248> <1/> get_agent()
+<249> The agent is the contextual object for the BehaviorTree instance. This is usually the parent of the BTPlayer node that utilizes the BehaviorTree resource.
+<250> Blackboard blackboard 🔗
+<251> Blackboard get_blackboard()
+<252> Provides access to the Blackboard. Blackboard is used to share data among tasks of the associated BehaviorTree.
+<253> See Blackboard for additional info.
+<254> <1/> custom_name = <2/> 🔗
+<255> <1/> set_custom_name(value: <2/>)
+<256> <1/> get_custom_name()
+<257> User-provided name for the task. If not empty, it is used by the editor to represent the task. See get_task_name.
+<258> <1/> elapsed_time 🔗
+<259> <1/> get_elapsed_time()
+<260> Elapsed time since the task was “entered”. See _enter.
+<261> Returns <1/> when task is not <2/>.
+<262> <1/> scene_root 🔗
+<263> <1/> get_scene_root()
+<264> Root node of the scene the behavior tree is used in (e.g., the owner of the BTPlayer node). Can be uses to retrieve <2/> references.
+<265> Example:
+<266> Status status 🔗
+<267> Status get_status()
+<268> Last execution Status returned by _tick.
+<269> Method Descriptions
+<270> <1/> _enter() <2/> 🔗
+<271> Called when task is “entered”, i.e. when task is executed while not having a <1/> status.
+<272> It is called before _tick 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 execute.
+<273> <1/> _exit() <2/> 🔗
+<274> Called when task is “exited”, i.e. after _tick returns <2/> or <3/> status. See also execute.
+<275> <1/> _generate_name() <2/> <3/> 🔗
+<276> Called to generate a display name for the task unless custom_name is set. See get_task_name.
+<277> <1/> _get_configuration_warnings() <2/> <3/> 🔗
+<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/> _setup() <2/> 🔗
+<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> Status _tick(delta: <2/>) <3/> 🔗
+<282> Called when task is “ticked”, i.e. executed by BTPlayer or BTState during an update.
+<283> Returns execution status as defined in Status.
+<284> Note: Tasks perform their main function by implementing this method.
+<285> <1/> abort() 🔗
+<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/> add_child(task: BTTask) 🔗
+<288> Adds a child task. The <1/> is placed at the end of the children list.
+<289> <1/> add_child_at_index(task: BTTask, idx: <3/>) 🔗
+<290> Adds a child task. The <1/> is placed at <2/> position in the children list.
+<291> BTTask clone() <2/> 🔗
+<292> Duplicates the task and its children, copying the exported members. Sub-resources are shared for efficiency, except for BBParam subtypes, which are always copied. Used by the editor to instantiate BehaviorTree and copy-paste tasks.
+<293> BehaviorTree editor_get_behavior_tree() 🔗
+<294> Returns the behavior tree that owns this task. This is only available in the editor.
+<295> Status execute(delta: <2/>) 🔗
+<296> Performs task’s execution. The execution follows a specific sequence:
+<297> If task’s current status is not <2/>, the _enter method is called first.
+<298> Next, the _tick method is called next to perform the task’s work.
+<299> If the _tick method returns <2/> or <3/> status, the _exit method will be called next as part of the execution cleanup.
+<300> BTTask get_child(idx: <2/>) <3/> 🔗
+<301> Returns a child task by specifying its index.
+<302> <1/> get_child_count() <2/> 🔗
+<303> Returns the number of child tasks.
+<304> <1/> get_child_count_excluding_comments() <2/> 🔗
+<305> Returns the number of child tasks not counting BTComment tasks.
+<306> <1/> get_index() <2/> 🔗
+<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> BTTask get_parent() <2/> 🔗
+<309> Returns the task’s parent.
+<310> BTTask get_root() <2/> 🔗
+<311> Returns the root task of the behavior tree.
+<312> <1/> get_task_name() 🔗
+<313> The string returned by this method is used to represent the task in the editor.
+<314> Method _generate_name is called to generate a display name for the task unless custom_name is set.
+<315> <1/> has_child(task: BTTask) <3/> |