UtilityAIAgent do not select any behavior (building from sources)

[micaelbergeron]

I am currently integrating this extension in a game project and decided to do some slight modifications to the code.

I've tried building the project on main, the v1.6 tag or various SHAs, but couldn't get the UtilityAIAgent to decide on any behavior with my custom builds.

scons platform=linux target=template_debug
scons platform=linux target=editor

The scene I'm testing on is a very simple tree:

ROOT >
  UtilityAIAgent > (running `evaluate_options(delta)` in `_physics_process`))
    UtilityAIBehavior (with `score` set to `1.0`

The UtilityAIAgent do not trigger the behaviour_changed signal, nor update the internal state.

[micaelbergeron]

Ok so I found out the issue, this is caused by the _ready function not being called in the UtilityAIAgent node, which is required to run to create the cache of behaviour nodes and sensors in order to update them.

I moved the code back to using the internal _notification, with NOTIFICATION_READY and that fixed the issue.

On a side note, I wonder is doing this at _ready is the proper pattern: adding dynamic behaviours/sensors is now impossible as the UtilityAIAgent will ignore them in the evaluation logic. Is there any measurable gains in indexing the children nodes prior to evaluation? I would expect the indexing to be a pretty cheap operation.

One other potential approach would be to use the Node scene tree signals (child_enter_tree, enter_tree) to maintain these indices.

I will experiment on these ideas and report back.

[micaelbergeron]

Presently, if you want GDScript to override virtual methods like _ready() or _enter_tree(), you're meant to handle those like a C++ module would, which is to implement _notification() and watch for NOTIFICATION_READY or NOTIFICATION_ENTER_TREE.

In many ways, GDExtension is more similar to a Godot module, than it is to "C++ scripts", so some things need to be done in the module way. I kind of wish we didn't even support implementing _ready() and _enter_tree() from GDExtension so that folks were forced to use _notification() and we wouldn't have this question coming up all the time :-)

Anyway, there's a number of design issues around GDExtensions and virtual functions that haven't been worked out yet, and unfortunately, I don't know what we'll end up going with long-term

Reference: godotengine/godot-proposals#7821 (comment)