BTTask NodeMemory?

Development Programming & Scripting AI
, , , ,
1

what is the purpose of “NodeMemory” parameters in the BTTask, i know that it was for cache a data, but for what?? had some connection with FMessageObserver? or what?? please anyone kindly can explain it to me, jjejejeje

1 Like
2

Nodes created in c++ are shared for all running behavior tree instances. If you need to store any runtime data, you can either use memory block or switch node to instanced mode and use properties of class.

block of memory:

  • (+) small & cache friendly
  • (-) only primitive types are supported, no custom allocations (array, string, etc)

instanced node:

  • (+) supports all types of properties
  • (-) new node object will be created for each instance

So basically, if all you need to store is some counter or request handle, use memory block (check UBTTask_Wait for details). If you have any arrays being used and changed in runtime, use node instancing (bCreateNodeInstance property). All blueprint based nodes are instanced by default.

2 Likes
3

thanks mr Lukasz!!! this kind of information is priceless, jejeje

4

Can you elaborate a little further? If I have a custom C++ node that is not instanced and used in multiple locations of a behavior tree and the designer changes some class properties, will the properties in fact be different among each placement in the behavior tree?

Please note there is no runtime data being changed. All the changes are made and set before compilation of the blueprint.

5

As far as I understand every single placement of any node in behavior tree will, in fact, be different.
As an example you can check UBTTask_MoveTo implementation, it is not being instanced, yet if you place it several times in behavior tree it can indeed have different settings between them.

The thing about instancing nodes is that it works per behavior tree instance. And not per node in a single behavior tree.

So again, why use instancing?

Let’s assume you have 2 AI controllers using the same behavior tree.

  • In case of non-instanced nodes they will share the same skeleton of behavior tree and only NodeMemory data will be switched for such nodes based on AI controller being updated in question.

(+) performance increase

(-) if you change property inside of non-instanced mode it will change for both Controllers, so you should use NodeMemory instead

  • In case of instanced nodes each AI controller will have its own instance of instanced node, meaning while they will share most of the tree they will have different version of instanced nodes.

(+) properties inside node can be changed, since every controller has its own instance

(-) performance decrease

P.S. Correct me if I’m wrong, still in progress of plowing through source codes on this.

4 Likes