can i assign what btsubtree to execute during the runtime?

[ODtian]

or only hard code?

[limbonaut]

If I understood your question correctly, you want to change subtree dynamically at runtime in BTSubtree? Currently, it's not supported. I think, you can create a custom subtree decorator, in other words, your own (lets call it DynamicSubtree) implementation if that's what you need.

[ODtian]

Yeah, it's something similar to UE's dynamic subtree. However, I'm using gdextension version so I can't implement it in gdscript due to limitation of binding virtual method in gdextention.
Just to ask, have you got any plan on supporting dynamic subtree? If not, I will wait for this plugin for godot 4.3, as they support binding virtual methods.

[limbonaut]

The reason why BTSubtree is not actually switching those trees on the fly, is because instantiating a tree is somewhat expensive. To allow task instance members, BT is duplicated for each instance. So to support switching a tree at runtime (I assume you mean each frame, in extreme case), ideally, it would need to be pre-allocated or cached somehow. It's just not a use-case for BTSubtree, and would make code much harder to maintain.

DynamicSubtree is more like a Selector than a decorator, IMO, since it actually selects a subtree to tick on the fly, and it would need to pre-allocate or cache it for performance reasons. Have you considered creating a specialized selector for your project?

The BT structure would look like this:
SelectSubtree
-- BTSubtree
-- BTSubtree
-- BTSubtree

This way you don't need to bother with caching, since it would be pre-allocated due to nature of this structure.

[ODtian]

In this case, yes. However, just to explain my idea, I think duplicate the whole bt tree for each player is unnecessary.

In UE's bt module, the tree structure is static and stored as assets(like resource in godot), when player is initialized each node create memory - a mini object of instanced nodes' data that stored in player and pass it to node at runtime. Therefore bt only control the logic, and data can be different player wise. In this case dynamic subtree is cheap, since every bt only preloaded once.

The similar idea is used in AnimationTree, the parameters is instanced and different node wise, but you can use the same tree resource.

[limbonaut]

My main focus is for LimboAI to be easy to use, and use familiar concepts. Most users know how to create instance variables (aka class members), just like you do in node scripts, and that's what I decided to support. We also support static typing, and I'm not sure how that can be achieved with a generic "memory" object (aka dictionary). It's just a simpler method, and loosing something like dynamic trees is not a big sacrifice to make everything simpler. I think, DynamicSubtree is still quite possible to implement in the current framework, given enough demand or someone willing to do it.

The idea is interesting, and If it can be easily understood and used, the context object approach can be considered for the next major version, which will be v2.0 (1.0 is to be released soon). Would you like to create an issue detailing potential implementation?

[ODtian]

After browsing different behavior tree libs, I find out that most libs just duplicate the whole tree when they are implementing tree initialization, which is same as limboai.
Maybe separating runtime data (something like context) and static data / methods (the tree structure and methods) can save time and memory, or maybe not. I review UE5 source code again and they are manually managing runtime memory as bytes array, if such complexity is necessary to improve performance, I don't think it worth it, at least now.
But I will try to implement a simpler one to test whether I can find balance point. Just thank you for your replies on this question, they inspired me a lot.