Nodes with enter() and exit() methods

[lostptr]

I noticed a pattern in a bunch of nodes that I am creating:

var _has_began: bool = false

func tick(actor: Node, blackboard: Blackboard) -> int:
    if not _has_began:
        # [...] Setup action (ie.: reset variables, connect signals, etc...)
        _has_began = true
    else:
    # Do what you need to do...		
    if should_stop:
        # [...] Clean up stuff
        _has_began = false
	return SUCCESS
		
    return RUNNING


func interrupt(actor: Node, blackboard: Blackboard) -> void:
    # [...] Clean up stuff here as well that may or may not be just like the other one.
    _has_began = false

Maybe we could have enter() and exit() methods for these scenarios. Composite nodes would have to call enter() before the first tick() and exit() after it has returned SUCCESS or FAILURE. Naturally, if this node is executed again later, enter() and exit() would be called again as well.

What do you think?

[bitbrain]

Why can't we use enter_tree and exit_tree for these usecases? Is it that both actor and blackboard would be unavailable at that stage?

[lostptr]

enter_tree() and exit_tree() are called even before ready(), what I was talking about is when the node starts executing (in the context of the behaviour tree). One example would be a WaitingAction that waits for a set amount of seconds before returning SUCCESS. Before the first tick() I need to set elapsed_time to zero and in every tick it will be increased based on delta. Right now, this is how I am doing:

@export var wait_time: float = 1.0
var elapsed_time: float = 0.0
var has_began: bool = false

func tick(actor, blackboard):
    if not has_began:
        has_began = true
        elapsed_time = 0.0
    else:
        # Get delta from the blackboard...
        elapsed_time += delta
        if elapsed_time >= wait_time:
            has_began = false
            return SUCCESS
    return RUNNING

But if we had a enter() method, we could do it like this:

@export var wait_time: float = 1.0
var elapsed_time: float = 0.0

func enter(actor, blackboard):
    elapsed_time = 0.0

func tick(actor, blackboard):
    # Get delta from the blackboard...
    elapsed_time += delta
    if elapsed_time >= wait_time:
        return SUCCESS

    return RUNNING

I'm using the same has_began pattern for moving my enemy and playing an animation (telegraphing an attack). That's why I thought about having those methods since it would make things much more organized and with less boilerplate.

[bitbrain]

It would make more sense for this case to introduce a "special" action node that provides these methods. Something like "RunnableActionLeaf":

extends RunnableActionLeaf

@export var wait_time: float = 1.0
var elapsed_time: float = 0.0

func before_running(actor, blackboard):
    elapsed_time = 0.0

func tick_running(actor, blackboard):
    # Get delta from the blackboard...
    elapsed_time += delta
    if elapsed_time >= wait_time:
        return SUCCESS

    return RUNNING

func after_running(actor, blackboard):
    elapsed_time = 0.0

This would also allow us to define something as a Template for easier setup.

[lostptr]

But why a new node though? We could add them in the BeehaveNode just like it has been done with the interrupt method. This way, both Actions and Composites could use the enter() and exit() methods.

[bitbrain]

@lostptr wouldn't you need then to always call the the super.tick() method inside every action to not break that behaviour? Or how would both enter and exit inside BeehaveNode be called? Alternatively, having two separate tick methods that need to be inherited depending on if you need a long running action or not also sounds error prone.

A separate node would solve that problem (kind of)

[lostptr]

The enter() and exit() methods would always be called by the composite parent node. There would be no need to have two separate tick methods. It would be just like we do it with interrupt().

I started the discussion to see if it would be actually useful to add it to the library.

I can open an issue and we can discuss the implementations there, what do you think?