Decorators in a tree stored in the register exhibit global state about behaviortree.js HOT 4 OPEN

Heyho @Tresky.

What you are observing is the following: If you register a node, you put that node into a global registry, if you then reuse that node in different tree, both trees use the exact copy of that node. So any change you make to this within one tree, is of course immediately done on the other tree, since that is the same node.

Interestingly, I never thought about that case before, or encountered it. Guess I should write some specs for that. And have to think about a way to resolve that case, without impacting the performance. Sharing the instance way faster then having to create new ones for all trees, but on the other hand, how often are new trees created anyways…

from behaviortree.js.

Hey @Calamari! Thanks for the quick reply. I understand why you'd make it that way for lookup times.

It seems to me that you could copy the entire logic tree into the Tree whenever it is created, so you have independent instances of the nodes in each tree. You could potentially create an independent registry inside of each Tree instance that stores instances of the nodes it needs.

You could still get very fast lookup of the nodes in that tree, the performance of creating a new tree would just be impacted due to the copying of the nodes. As you said, though, new trees likely aren't created in large quantities during runtime, but I guess that would also depend on use case.

I realize, though, that it may be a big push to get to something like that because it would require changing a major implementation detail of the library. Not to mention it's risky anytime you change such a core implementation detail. Maybe you, as the author, have some better thoughts than me on what might work, given you understand the code much more than I do.

My current use case is in the context of game dev. I'm attempting to have each instance of Enemy own an instance of BehaviorTree that stores the logic for how the AI should act (wandering, chasing, idling, etc).

Could you think of a way to enable this sort of use-case using this library beyond the major changes I suggested above? Is it just to totally exclude the use of the registry altogether?

from behaviortree.js.

I just took another look at the library code. This might actually be a fairly simple change to make.

The library is using a global registry defined here:

Given the constructor of the BehaviorTree class here:

You could simply add the following to the constructor and you have an independent registry inside the tree.

this.registry = Object.assign({}, registry)

The only other detail would be to change all registry lookups to look inside the reigstry on the tree instead of the global one.

It's not necessarily 0 performance impact, but I can't imagine it would be very unless your regsitry grows to a large size. At that point, it wouldn't be hard to add some nice optimization where only the nodes needed are copied from the registry.

from behaviortree.js.

Hmm, I thought I posted some thoughts, this morning. Apparently I forgot to hit the comment button. Well, here is a more informed look:

I just checked and it is not as simple. The solution you suggest will copy the registry, but the instances will be still the same, since JavaScript is copying objects by reference. So you would gain nothing.

The best idea I came up with, until now is, for a maybe additional syntax for creating objects that are instantiated on demand, something like:

BehaviorTree.register('my-decorated-node', [MyDecorator, {
  node: 'my-sequence',
  config: { cooldown: 2 }
}])

It feels a bit cumbersome, with that array, but on the otherhand it is maybe nice to serialize, and since passing in a function as creator-function is out, since it is used as a short version to define tasks. (I wonder how many people really use that, and if that is really needed.)

On a slightly related topic:
Since a while, I have the idea in my head, that it might be a useful idea to split out the registry stuff into an own class, so you can attach different registries to different behavior trees. But I still don't see a real use case for that. Thought this might be a case to do this, but I think it will not yield benefits here sadly.

from behaviortree.js.