Nodes with `enter()` and `exit()` methods

[lostptr]

Overview

We could have enter() and exit() methods for when its necessary to do some setup or cleanup before or after the first and last ticks.
The enter() and exit() methods would be called before the first tick() and after the last, respectively.
For more information, checkout #117

Possible implementation

We create an execute() method inside BeehaveNode to be called by parent nodes only. This method will call enter(), tick() and exit() when needed as well as return the result of tick().

func execute(actor: Node, blackboard: Blackboard) -> int:
	if not _has_entered:
		enter(actor, blackboard)
		_has_entered = true
	
	var result = tick(actor, blackboard)

	if result != RUNNING:
		exit(actor, blackboard)
		_has_entered = false

	return result

This way, we only need to change composite nodes to call execute() instead of tick(). Composites and leaf nodes should never override the execute() method, only tick().

[bitbrain]

Thank you for suggesting this.

Composites and leaf nodes should never override the execute() method

unfortunately, we cannot guarantee that with the proposed solution. Someone can just go and override it if they wanted to (e.g. rather than using tick they could use execute and it would even work but it would break running action behaviour unknowingly).

We could do the same logic you proposed but in the parent nodes themselves (decorators and composites) perhaps? They would then need to track which of their child nodes have entered either true or false. This would keep the action leafs clean and we do not have to worry about people accidentally overriding execute. So action leafs still may have these methods:

func before_run(actor: Node, blackboard:Blackboard) -> void
func after_run(actor: Node, blackboard:Blackboard) -> void

but they would be empty by default and are mere "callbacks".

[lostptr]

This works as well, I will create a PR with this implementation.

[bitbrain]

@lostptr let me know if you require help writing/running the unit tests. You should already find a few examples here: https://github.com/bitbrain/beehave/tree/godot-4.x/test/nodes

There is also extensive documentation on the features of gdUnit here: https://mikeschulze.github.io/gdUnit3 (we are using gdUnit4 but the API is mostly the same)

Also a thought: putting it into the composites/decorators will most likely lead to some code duplication. Let us see in a separate refactoring PR how we could clean that up but do not worry about duplication for now.